Month / March, 2014

My current favorite tool

So in my last blog post I ranted and most definitely did not rave about the development tool I dislike the most — Xcode. I won’t bother rehashing it, but suffice to say, I’m no fan. And at the end, I briefly mentioned the tool I like the most — AppCode. Then I made you wait to find out why, well that time has finally come!

To me, AppCode is pretty much everything Xcode isn’t — productive, intuitive, extensible and flexible. A few of points listed will likely feel completely subjective, but to a developer there really isn’t much more important than their development tools, so yes, this will be tour down subjective highway for Objective-C. See what I did there?


Where Xcode will feel like it hampers you and tries to force you down one path, AppCode often frees you up to do what works best for you.
– True tab support: opening a file from the tree view will always open in a new tab. And if you already have that file open, you are just taken to the existing tab. Brilliant! Xcode offers the user minimal functionality to modify the tabbing behavior and it still isn’t sufficient.
– Keyboard short cuts for everything. Honestly, every function of the IDE can be bound to a keyboard short cut. Awesome! Xcode exposes a crap ton of functions with keyboard short cuts too … but I hate them. I could modify them, but I hate them.
– Tons of built in, quick to access tools. AppCode exposes a simple to use watch window during execution that is sorely missing from Xcode. I can keep an eye on specific properties or even expressions as I step through my code without having to constantly re-expand the variables listing. There are separate inspector windows for your tree and code structure that can be viewed at the same time. Easy code refactoring. Easy code selection. And more!


This is likely the most subjective section, because what is intuitive to me is likely not intuitive to the rest of the human population. Just as The W about any of the times I make some crazy leap of logic without actually providing context. It happens daily.
– Powerful syntax inspections. There is some decent help in Xcode about fixing basic issues; but, AppCode takes it to the next level. It will give you hints on dead/unreachable code, parameter type mismatches (though honestly, I wish it would ignore the [NSArray objectAtIndex:[indexpath row]] inspection because no one cares that it should be an NSInteger but we are passing in an NSUInteger (though maybe we should?).
– It includes serious HTML/JS support out of the box and inline. Honestly, I don’t use this a lot, but it is super nice to have. AppCode essentially comes with serviceable support for HTML formatting and JS inspection. It is no PHP/WebStorm, but it is good for what it does. I have had a need to occasionally output HTML to a view, and having the syntax highlighting and gutter color preview was extremely helpful.
– Inline documentation viewer. This is just one spot where Xcode really has no comeback — put your cursor in any symbol (variable name, type, whatever) and hit F1 and AppCode pops up a window displaying relevant documentation for that symbol. Hell, if you place your cursor in the name string of [UIImage imageNamed:@“Name”] a preview of the image is displayed.

Extensible and Flexible

Here is probably where the real power of AppCode shines through — it can be pretty much anything. AppCode is built on the bones of the uber powerful IntelliJ IDEA, and so inherits many of the amazing features of that editor. It is fast and gorgeous. It is cross platform (though, really AppCode isn’t because no one does Objective-C anywhere but on an Apple computer, but still). The core is always going to be maintained as it transitions from version to version of the underlying IDEA platform.

On top of that level of quality, is the fact that being built on the IntelliJ IDEA platform means AppCode can also run most of the plugins developed for IntelliJ. That means, Objective-C developers can install plugins that add other languages to the IDE including full syntax highlighting, syntax inspections, templates, whatever. Many work for AppCode even though originally developed for IntelliJ. AppCode users can also get interface enhancements through the plugins like a mini-map of the code and integration with most major tool sets. For example, there is a plugin to add a fully featured REST client to the IDE. No longer do you need to pull out your browser and a plugin there, or a different app entirely, to test/prototype your REST calls. You can do it all from within AppCode.

Lastly, AppCode comes with an integration with almost any version control software available. This means a user can be connected to their Github account, Bitbucket account (interestingly, it seems that Atlassian and JetBrains are pretty tight with both being active users of each other’s products where it isn’t a competing service), company SVN, private Git host, etc. This makes it easy to move around with AppCode to various development environments. This agnostic approach means that there are some super useful features within AppCode to help the user manage their history — inline history view, keyboard shortcut to bring up a window to display quick VCS actions, pretty much any functionality exposed within the editor.

So yeah, I love AppCode. It makes developing for iOS and OSX a joy. So much more than Xcode ever has. If you’re ever interested in seeing how I use AppCode on a daily basis, feel free to swing by and let me know!

the tool i dislike the most

incendiary titles to posts are my favorite. i think from here on out i will only publish blog posts that have click-bait titles. surely that will help me get famous, right?

however, to the point — there is one tool i have to use in my daily work life that i just cannot stand. i’m sure most people are that way. there is likely something you use that just seems to slow you down or work totally contrary to how you naturally would. for me, that is Xcode.
Continue Reading

salesforce: things i’ve learned

i recently posted a blog about a solution i came up with for an issue i had while using salesforce. however, that was probably kind of premature as i had never really mentioned before that i have become a salesforce (sfdc) developer … of a kind. i feel relatively confident in my skills, but there is so much for me to learn still.

yet, in the time i have spent developing for salesforce, effectively 3 months, i do feel pretty good. i have picked up many of the best practices for the platform and also banged my head against many of the innate limitations of the platform that other coworkers have not really had to deal with.

so what are some of these best practices? let me list them for you
– do not do anything in a trigger. if you aren’t a sfdc admin/developer, then this probably doesn’t mean much to you, but those folks should know this. honestly, triggers are a great idea, but they are seriously hampered in their true usability as a place for code because they do not maintain state. to maintain any stateful information you need to have a helper class that the trigger references. and since you are going to be going down that path, you should just move all of your logic to that helper class (or even helper classes to that helper. reader, meet the rabbit hole).
– keep class level collections of objects. this is especially true in the development of trigger helper/implementation classes. this is because, you only have 100 soql queries per any transaction, and it is surprisingly easy to get up against that limit with little care. this is due to the potential recursive nature of any transaction. therefore using a class level collection means you do not have to constantly refetch the same records for each method.
– sfdc objects are pointers, no need to constantly move them around. this applies to the above topic in a way. since sfdc apex code is essentially just java code, and therefore all objects are pointers, you can just make the class level collections work for you. this is because if you create a new reference to the object, any time you modify the object it is modified for all references. this way you can just pass the same objects for updates around until the very end when you actually do the dml work.
– objects are not acceptable as the keys in a map. this may seem obvious, but it is easy to fall into this trap — you want to keep a map of accounts to opportunities so you create a Map> and you’ll be golden. until you start modifying the objects you used as keys. then you will discover the mapping you did is no longer valid because your key is different — maps apparently keep clones/copies of the keys as opposed to just pointers. this makes some implementation sense because that is the only way to create a hash of the object. if you were to allow for just the pointers then your hash would change any time the object changed. one solution would be to use the memory address of the object for the hash, but that would surely open sfdc up to some security vulnerability.

and now, what are those issues? again, another greatest hits list!
– sfdc is more svn than git. i’m sure plenty of other developers have run into this is. because of the fact that whenever you save a file in sfdc it is immediately available to the org, you really cannot consider there any branching within the org development. as such, it is much more like the svn model of just one repository timeline. one solution to this would be for developers to have their own sandbox orgs to work in. however, that adds considerable overhead (though that is how our dynamics developers work, so it can’t be that bad). the bigger hurdle is that not all clients can afford or want to have that many sandboxes.
– http callouts are second or third class citizens in apex code. wait, what? you mean a company that is solely based online would make developing code to work with other web services a challenge? indeed they do. one of the reasons for this is the shared architecture nature of sfdc, so they need to prevent crazy monopolization of resources. and that is fine and good. however, you are not allowed to perform callouts in the normal process of a trigger transaction, so they must all be executed in a @future method (or a form of chained work). okay, that isn’t the end of the world really, just annoying. you make your http callout, you do some object updates and then need to make another callout and you think “hey, i’m in a @future call already, this should be golden.”, but it isn’t. you cannot make any http callouts after any dml statements in the same transaction. umm, okay? so let’s throw the next call in another @future method. oh yeah, no can do because you are already in a @future context and cannot call a @future from another @future. DOH!
– http callouts have a very limited time to execute. all sfdc apex code must execute within a specific time frame, again to prevent resource monopolization. however, callouts should be a slightly relaxed situation due to the nature of web services. yet, all http callouts in any given transaction have a max execution time of 120,000 milliseconds (2 minutes). that seems like a lot, but you better hope you don’t have a slow connection on either end of the callout or a long processing request.
– testing http callouts makes a developers life a living hell. and no, it isn’t that you have to write a class to mock up any responses you want. instead, remember that thing about no http callouts after dml? well, turns out that using a test context does not actually relax or resolve that issue. so there are many instances where the Test.startTest(); … Test.stopTest(); will not actually let you do all the testing you may want because the following error will still be thrown You have uncommitted work pending - Please rollback or commit. FUN!!
– testing batch apex and http callouts is impossible. seriously, it just is. you have to wrap your entire test within the Test.startTest(); … Test.stopTest(); methods. literally all of it must be if your batch has any http callouts. which means, you cannot actually test your batch code because the batch will not run synchronously until after the Test.stopTest() and you cannot have any code outside of that. so, all you can do is code coverage, not any testing. and effectively the only way to solve this is to put a if (System.isRunntingTest()) check around your http callout.

so yeah, those are some of the fun things i’ve learned with sfdc!

saleforce: dynamic parsing of soql results

fun fact that you probably will never have to deal with:
when you perform a SOQL query like

Account acct = [SELECT Id, Name, Parent.Name FROM Account LIMIT 1];

and then try to use acct.get('Parent.Name’) you will get

"System.SObjectException: Invalid field"

i can see how that makes sense, but it means that retrieving the value of Parent.Name is not straight forward if you just have a collection of strings as field names. to accomplish that, you need to do something like:

SObject parentObject = acct.getSObject('ParentId');
String parentName = parentObject.get('Name');

the real awesome bit, is that to do this dynamically you will need to parse any string that comes to you like Parent.Name and properly format it for each object (system fields get the format [NAME]Id and custom relationships change from [NAME]__c to [NAME]__r). so be careful that you do not try to get information for a field that was not actually queried, or you’ll get the same error as before, but on a different object.

for a recent work project i had a need to build a JSON serializer that takes custom key values and matches them up to field names which is where i ran into this problem. of course one option to avoid this was to build custom classes for each kind of serialization i would need to do and in the constructor take in the associated object(s) to assign to member variables. then using the default JSONGenerator.writeObject everything would be done. however, that isn’t very flexible, because it essentially adds unnecessary code to cover, and a pretty brittle implementation. my solution was to build the custom serializer (still leveraging the JSONGenerator in the shadows) that takes in a Map where the keys are the JSON keys and the values are the mapped fields. since this is generalized, it just uses basic object and field describes and can be used for any object type. code reuse ftw!

lastly, the advantage here is that i could extend the implementation to exposing an interface and create even more customized implementations for specific field formattings along with the default. while that ends up adding complexity to an extent, it will abstract out the formatting and so i do not have to add it to various classes specifically created for serialization. that is in the future sometime though.

in my code, i think there is one optimization that could be made — Apex offers the ability to use array notation to access members of an Object. however, if an instance is cast as a specific subclass (Account, Contact, etc.) this no longer works and to dynamically get fields you will need to use describes. however, it may be possible to cast back to Object and use the array notation to simplify the code. the biggest downside is no real type checking. and it may not work really, haven’t tried it.

What does failure feel like?

I have discussed Start Up Weekend (SUW) a couple times on this blog. There are a couple reasons for this — it is a fun experience, and it is one of the seminal events of my life to date (behind being married, graduating from college/grad school, etc.). However, it is also one of the most disappointing moments.
Continue Reading