Monday, July 21, 2014

Box Sync client update moves sync location (without really telling you)

So this is Box Sync v4.0.5101 for Windows.  Once the update was installed (acted just like previous updates), it started the location change right away pretty much silently.  The first sign of it was I no longer had the "My Box Files" symlink (under Favorites in your Explorer window).  It had a vague message on the app window but who really checks that?  Once it's "done", it also popped up a message saying so.  Again, without context you don't quite grasp what that means.  The worst part is that the move was incomplete, probably because I had various things opened in applications.  So I ended up having a bunch of folders that exist at both the old location (users/username/Documents/My Box Files) and the new location (users/username/Box Sync), and I had to manually move things over.

It's bad enough we can't choose the sync folder location - what if you want to store things out of the system partition?  Now what's the point of moving the folder up one level?  If anyone is like me, who uses Box extensively for protecting and sharing all kinds of files, you have a lot dependencies on the location: apps need to know where its stuff are, binaries need to have its path set, etc.  With the relocation plenty of headache to reset everything, let alone the hassle of reestablishing the habit of saving new things to the new location.

Box is overall a good product for cloud based storage/backup, but this sync folder location issue is definitely a drag on usability.  This recent change of location just made it even worse.

Monday, June 30, 2014

Getting Started with Node.js on Heroku ...

... is not easy on Windows.  This Guide is a good one.  The steps are clear with right amount of details.  I just couldn't get through it on Windows 7.  First I couldn't verify my app with foreman.  I got "Bad file descriptor".  After tinkering with Foreman versions a bit to no avail, I decided to go ahead deploy it, thinking maybe it's just foreman.  That didn't go either.  I just kept getting "Permission denied (publickey)" with git push, even after checking and rechecking I have the keys and they're added to Heroku (key addition notification from it as proof).

So I did anyone reasonable would do under such circumstances.  I switched to Linux.  I was able to have the app running on a dyno within 20 minutes on a Precise (12.04.4), including the time needed to set up a build environment and make the Heroku client - it's a VM I don't usually use to build stuff.  What can I say?  Next year I'm building a Ubuntu laptop (or getting a Mac).

Thursday, June 19, 2014

Why did Eclipse push 4.4.0RC3 to installations?

Don't fix it if it ain't broken.

I should have thought about that when I saw an Eclipse update (turns out to be 4.4.0RC3) coming up when looking for a IDE upgrade.  But I didn't.  I went ahead with the installation.  That's probably the old system admin version of me - always get the latest version!

Eclipse wouldn't launch, complaining about JVM 1.7 as required.  Fine, I installed Java 7.  It launched then, but I was greeted with a blank package explorer (after upgrading the workspace).  Looks like the new version doesn't work with v29.

My mistake for trusting it aside, why would Eclipse push out a RC version?  In the past I never had issues with Eclipse updates.

So stick with your original Luna - it worked fine for me.  Just be prepared to reject any update they might put out there.

Monday, June 2, 2014

How to register a custom domain for Sites

Just noticed (thanks to Jason and Kara!) that since Winter '14 the setup needed to register a custom domain to use with Sites has changed.  Here's the instructions on the setup page (will show the actual org Id):

A new or renamed domain will be permitted if any of the following criteria is true. Note that 00d7************** is your organization's unique API identifier in lower-case characters.

  • Your domain name is a CNAME record that points to [domain].00d7**************
    • As an example, if you are adding, it must be a CNAME record that points to************** that your domain will need to be a CNAME record for Salesforce to serve your domain.
  • Your domain name has a TXT record that equals 00d7************** with no punctuation.
  • Your domain name is a subdomain of an another domain in your organization.

There's a recipe in the Cookbook that really needs to be updated, but I couldn't even add a comment to suggest that (errored out each time I tried)...

Friday, April 18, 2014

Make Custom Setting use test-friendly in Apex

Custom Setting makes Apex code more configurable; code behaviors can be changed by altering setting values without needing redeployment.  That's especially valuable in a fast-moving business world.  Because of that merit it's a best practice to use it for many scenarios.  However with Custom Setting records treated as data in Salesforce, the downside is in unit test methods they are invisible by default.  SeeAllData = true can certainly be used to make them visible, but that's against best practice and not an option most of the time.  With that issue the introduction of new Custom Setting in code could often lead to headache for test methods, especially when the setting is referenced in trigger.  For instance you added this setting in your Account before trigger to facilitate a special owner routing:

UltimateOwnerDefaults__c UltimateOwnerDefaults = UltimateOwnerDefaults__c.getInstance();

Map ultUsers = new Map([select Id from User where ProfileId = :UltimateOwnerDefaults.Ult_User_Profile_ID__c]);

Congratulations!  You just give the gift of "Attempt to de-reference a null object" to many rule abiding test writers in the org.  All those nicely done test methods (existing or future) will see no custom setting record and bomb out if they try to insert a dummy account record that largely don't really care about owner routing.

Some may advocate the pattern of using a standard environment prep procedure in all test methods.  I'm never a fan of that because that has its own maintenance challenge, and it's a waste of processing time, and code character quota.  My solution is the principle of "if you create it, make it friendly".  It's actually pretty easy to do:

  1. Skip processing related to the setting if you don't have a setting record.  In the above example, if UltimateOwnerDefaults == null, don't continue to the map loading and anything related to it.
  2. If you do still want to still process things in the absence of expected setting records (as a default behavior), provide a default value (even just hard-coded) then.
  3. If neither 1 or 2 a good option in real life, handle the situation (absent setting) in an exception-free way (for instance, catch and log it in some way).  Really, I can't think of a good reason to have an unhandled exception coming out of a trigger for expected situations.
Done that way your new Custom Setting will never be a problem for any test methods that don't really care about it, and your code is more robust as a nice by product.

Tuesday, March 18, 2014

UserType and License Types in Salesforce

Salesforce has a few different license types, which you can clearly see from under the Company Info section.  However to process user records based on license types it's less straightforward.  There's a UserType field on the User object, which is related to license types not in a clear one-to-one way (see below for mapping).

A better way to get to license type is through relationship Profile.UserLicense.Name on User, which contains the exact labels you see from the User Licenses section.  

Tuesday, February 18, 2014

"Unresponsive script" with Developer Console

The Developer Console for is entirely Javascript based, so it's subject to all Javascript can offer in your browser, good and bad.  One annoying thing is that Javascript can be slow for certain things, for instance, enumerating a large list.  This is especially acute for me when listing the test classes available.  We probably have 250+ test classes in our main org (all namespaces included), and that always seems too much for the console's Javascript to handle no matter what computer I use (currently on an i7 with 8gb memory), which results in an "Unresponsive script" error in Firefox so I have to click "Continue" for it to finish loading.  So I deal with it this way:

  1. Type in about:config in the address bar and press Enter.  This gives you the master list of all settings you can manually adjust in Firefox. 
  2. After confirming that you'd be careful with the settings, search for this setting string: dom.max_script_run_time.  This controls when the browser will complain and give you a chance to terminate the script (in number of seconds). Change the value to a bigger number - default is 10 and I use 20.
I do this for all Firefox profiles I use often with the Developer Console.  Chrome seems to be more forgiving/patient with the script compared to Firefox, so there is no error message - you just have to wait until the screen is unfrozen.

UPDATE: I'm happy to report that this trick seems to be no longer necessary with Summer '14.  The test class list in the console seems to be much more speedy and non-blocking to start - kudos to the developers!