Cannot get Force.com IDE v26 installed on Juno

IDE works just fine with Eclipse 3.7 (Indigo) but doesn’t seem to like 4.2 (Juno).  See error below:

Update: It has been solved (for me at least) by the method suggested here.  Basically you need one jar file in the Eclipse plug-in directory (found here) to satisfy the dependency.

Don't use Force.com IDE Installer

The installer may seem straightforward – run it and you get to use the IDE right away, but the installation seems to be not upgradeable.  With the rapid update cycle of Salesforce, it’d be outdated pretty quickly.  It says there’s an option for upgrade (see below), but the screen doesn’t even have a link for that LOL…  It’s much better to install Eclipse than add the IDE as a plug-in, which is fully upgradable and can be managed easily with Eclipse admin options.

 

 

iPod Touch won't charge

Old 2nd gen... Battery depleted but after plugging it just wouldn't go pass the Apple logo, and wouldn't charge either (after several hours still red).  Can't understand why charging has to be dependent on software working...  Anyhow did a soft reset (Home + sleep button hold) as some suggested and it came back to life and started to charge.

Some people just got instantly defensive when seeing complaints about Apple stuff (see the "Creative One" guy here).  Weird.

render VF page as Excel file

Pretty good solution:
http://boards.developerforce.com/t5/Visualforce-Development/Save-to-CSV-Excel-in-visual-force-with-UTF-8-chracters/m-p/183862#M24308

Validating deployments

The 3 main avenues for deploying changes in Salesforce.com - change set, Eclipse IDE, and command-line/batch/script with Ant - all provide an easy option for validating your deployment before they actually get applied.  You can address any potential deployment issues before they happen in the actual run, which is great.  In fact I try to always do that so I'm fully prepared for a successful deployment.  As a reference, the validation option in the 3 tools is as follows:

Ant tool
Add a checkOnly attribute to the deploy action in your build.xml.

<target name="validation">
       <sf:deploy username="..." password="..." serverurl="login.salesforce.com" deployRoot="staging" checkOnly="true" maxPoll="180" /> 

</target>   

Eclipse
Use the Validate Deployment button.


Change Set
Use the Validate button for the inbound change sets

The ugly truth of the Holiday object - frustrations with the Holiday settings in Salesforce.com

There isn't a whole lot of documentation for this object to begin with.  The sole description I could find is in the SOAP Dev Guide.  The object is supposedly to support escalation rules and business hours suspension, and should be the backend for the UI under Administrative Setup > Company Profile > Holidays.  From a developer's point of view, since the structure is there, the natural thing to do is to use it when any business logic calls for business day calculation, n'est pas?

Not so fast.

There are a few strange behaviors (really, bugs in my opinion) to learn before attempting to use it, or you can get into pulling-one's-hair-out situation pretty quickly.  One basic understanding you need to have (and missing from the documentation) is that for any recurring holiday entered from the UI, there's only one instance/record exists - supposedly for the upcoming one - in the Holiday object if you query it.  If that omission has not made things murky enough, here are some others:

• ActivityDate, which supposedly contains the due date for the configured holiday, will always have the current date/creation date when a holiday is first saved.  And it remains that way until it's resaved, which will correct it to the due date (but still subject to the next problem).  So good luck using it after saving your holiday from the UI.
• ActivityDate also may or may not show a due date that is coming.  Ideally, since the object contains single-instance info for holidays, you'd think it always stores the upcoming ones.  Not so.  If you enter the holiday with a Start Date in the past from the UI, you may end up getting an old instance in the Holiday object, i.e., the ActivityDate contains a past holiday date.  For instance, if you create a Labor Day holiday on 10/5/2012, and set the Start Date to be 9/1/2012, you would actually end up 9/3/2012 (after saving it twice) in the ActivityDate.  So, to get it to behave helpfully, always make the Start Date to be current or future dates.
• For Yearly holidays, you get an option to set the date this way: "On the nth day of month".  You can save it that way too.  But the ActivityDate you get doesn't match your rule at all.  In fact, only the "On every month day-x" choice is valid.  Well, if the other one doesn't work, why leave it enabled for Yearly??
  
  

All these issues have been confirmed by SFDC in my case #08151091.  Once you get passed these (mostly UI) kinks, you can go ahead use the Holiday object records happily!