Christmas in the Cloud

The official start of the holiday season is upon us. I tend to be a bit of a Grinch until closer to Christmas, so I decided to write a holiday song to help me pull out of it early this year. However, the subject took a turn towards Grinchy as the hero of our story gets stuck working on Christmas Eve.

I present for your — (hopefully) — enjoyment: Christmas in the Cloud

5 Tips for Readable Code

I’m a cranky programmer. I’m old and approaching curmudgeon status when it comes to code. I fully expect my colleagues to eventually lock me in a back room somewhere to wait for the mysterious “double flash.” I don’t know how I got here, but I’m here now and I know that I MUCH prefer readable code. Like it or not, there’s a very good chance that someday you’ll have to “open the kimono” and allow other developers to read, and even *gulp* modify code you’ve written. As a consultant, I’ve come into some code that is very easy to read, as well as come into some code that is next to impossible to decipher. Don’t get me wrong, I’m very certain I’ve written some code that has been hard to decipher and probably still do. However, one thing I learned when writing Python code in my previous life was that explicit can be a beautiful thing. Although its entirely focused on Python, a read-through of PEP-8 can do wonders for your code’s readability by getting you to think about a consistent style. I’ve not seen a coding “style guide” from the Apex world (I’ve found this and hope it gains some ground. I haven’t had a chance to consume it all yet, but its a start). That being said, the point of this is not to get into the specifics of a particular language but rather points to ponder in a hopefully “language agnostic” manner.

  1. Method Names: Luckily I’ve not seen the proliferation of bad method names lately that I used to see. However, I like to try to avoid un-necessary abbreviations. Be explicit and tell me what that method does. Such as “UpdateOpportunityStage” rather than “updateStage” — this is a very bad example in that if I’m working in a file like “OpportunityExtension” a method called “UpdateStage” should be obvious, however as an outsider coming into your org, how am I to know if you’re not updating some related object’s custom field stage? For just a few more keystrokes, you can have valuable clarity.
  2. Variable Names: more important, in my mind anyway, are the variable names that you use. Avoid abbreviations here like the plague as well. You’re not saving yourself much in the grand scheme of things, and to an outsider trying to learn the ins and outs of your code (and your business) an abbreviation can be a head-scratcher. For instance, if you have a product called Extra Widgets and you need to work with one in your code, call the variable extraWidget, not “ew” or exWg, etc. There are times when an abbreviation makes sense however, such as when everyone, and I mean everyone, refers to Extra Widgets as “EWs”, then perhaps saying “ew” is fine. However, if I’m in a rather large class file and that variable is instantiated way above the fold somewhere and I run across “ew” — wouldn’t it be a bit clearer if instead of having to figure out what “ew” was, its name told me right away: extraWidget. Again, clarity gets the nod.
  3. Spacing: Python introduced me to something that developers either love or hate. The used of whitespace. In Python, it can get annoying for newbies because indented code signifies your “blocks” — there aren’t curly braces or semi colons. This results in very readable code. It does however mean that many a new Python developer runs into issues at “compile time” because they used a tab in one place and 4 spaces in another. (Don’t get me started on the whole tabs vs. spaces thing…). I love white space and I tend to use insert carriage returns before I introduce larger chunks of logic flow. It separates your code into readable chunks of logic. Like Java, Apex is littered with curly braces and semi-colons galore, punctation that the mind just isn’t used to reading “naturally” — by adding whitespace between the different blocks of logic provides a natural separation and seems easier on the eyes.
  4. Comments: Its been said that good code comments itself, and while this is indeed true it doesn’t get you out of commenting code. I believe the real problem here however is the content of those comments. Of course good code comments itself, but it doesn’t tell you WHY its there or performing its duties in the given manner. It doesn’t tell you what was in the programmers head at the time it was written. Good code comments tell you WHY something was done, not necessarily WHAT it was doing. These types of comments can prove very valuable to any new programmers inheriting your code, or even to yourself when you have to revisit code you wrote months and sometimes even years ago. We’ve all had that moment when reviewing old code where we’ve said: “What the HELL was I thinking, why did I do it like THAT?” only to begin charging down the refactor path until you stumble across that little business rule you forgot about and realize: “Oh, THAT’s why I did it that way!” #BeenThereDoneThat
  5. Coding Shortcuts: I imagine I will catch proverbial hell from some folks on this and its really a matter of opinion (as all of this post is) but hear me out. Code “shortcuts” (like ternary operators) have their place in “oh-look-how-few-lines-of-code-I-took-to-write-this land, but they do NOTHING for readability for me. We’ve all seen them and I’d like to think I’m not the only one that sort of has to blink their eyes and read them twice:
    SomeVar var = (x == true) ? thisVar : thatVar;

    I can appreciate its simplicity and concise presentation, but I still prefer to read this:

    SomeVar var;
    if(x == true) {
        var = thisVar;
    } else {
        var = thatVar;

    While this is quite a few more lines of code its VERY clear to a newbie programmer (or cranky old one) under which conditions the value of “var” will be set to either “thisVar” or “thatVar” Most programmers are used to reading the ternary so it’s not a huge deal, but I know for myself, I always have to re-read those conditions twice to be sure. These are somewhat similar to the whole “one liner if statement” where if you are only checking if a given condition is true, you can do so on one line and eliminate your curly braces etc. (It figures, the one time you can actually NOT use the curly braces, and I don’t prefer it…weird).

In closing — I’m set in my ways and wouldn’t expect anyone to conform to how *I* want things done. However, diva though I may be — I hope that some of these points would cause one to ponder, if only briefly, about the readability of ones code by outside sources. It won’t always be a seasoned vet, or someone who knows your business in and out that winds up reading your code. They’ll have enough to deal with coming up to speed on the ins, outs, and whys of your business, learning the local vernacular, etc. Therefore, making your code a little more legible can remove one less barrier to entry.  And with that, its back in the closet I go.



Take a Break

Over the past 10 business days, I’ve been working heavily on a project for a client that is using Salesforce but my coding efforts have been nearly 100% focused on client side javascript. To be more specific, I’ve been living in the jQuery world for 10 days. Doing so has proven to be beneficial to me as a developer in several ways, and it caused me to reflect a bit on why I feel I really needed this breather:

  1. I’ve been living solely in Apex and Visualforce for two years now & I feel like I’ve lost a bit of ground on some of the things I used to do “pre-Salesforce”. Client side javascript was one of those things. It has been good to rekindle some of that front-end fire and exercise that skill set a bit. The old adage is true, “if you don’t use it, you lose it.”
  2. It revealed some features to me that I didn’t know about the platform. Specifically, the ability for the apex:actionStatus tag to call out to javascript using “onStart” and “onStop” events (perhaps a more technical post on this subject in the future is warranted). In this case, there were several re-renders happening over panels that need jQuery’s attention as well. Since these items may or may not have been part of the DOM on the initial page load, this wasn’t very straightforward. Furthermore the re-render actions were setting defaults from the server that needed to be overwritten by jQuery due to previous user actions, so after the re-render was complete, I needed to re-establish or re-evaluate the user inputs from before the re-render. Due to the project’s usage of the jQuery BlockUI plugin, I was able to tie into that plugin’s “hide” method and then execute the necessary jQuery to manipulate the newly rendered DOM elements. #Slick
  3. Sometimes you just need a break from status quo to refresh your mind. It opens you up to new techniques that living in a silo’d world may sometimes prevent you from picking up. In the end, taking these sideline breaks only strengthens your overall knowledge and that’s a good thing. #AlwaysBeLearning

I’ve still got plenty of jQuery time in front of me on this project so I’m looking forward to further honing that skill set and learning more about what is available to me on the platform side. Breaks are a good thing, but it will be good to get “home” again as well :)




Wednesday Wrap Up — October 2014 Edition

Being fairly new to this “regular blogging” habit that I’m trying to form, I’ve decided that the first Wednesday of every month will be known as “Wrap Up Wednesday” here on  What I plan to do is simply summarize everything that either influenced me, entertained me, or general buzz that interested me from the previous month. Some of it may be related directly to Salesforce but buyer beware — I’m a man of many interests so there may be some other things that sneak in from time to time. So without further delay, welcome to the first of hopefully many “Wednesday Wrap Ups!”

Personal Happenings:

  • Highlight of my year: I got to sing at Dreamforce! (Okay, i really will shut up about this…someday.)
  • I had a lightbulb moment
  • I reflected (perhaps out of place) on what I think makes a Salesforce MVP
  • Sarah Deutsch asked me to rewrite the lyrics to “All About That Bass” and she totally rocked it!
  • I smoked my first cigar and had my first Armagnac thanks to my new buddy Adam Daw. Armagnac — hell yes. Cigar — I’ve got much to learn…maybe @MichaelForce can help.

Dreamforce 2014:

  • The developer group over at Salesforce launched “Trailhead” and I’ve been enjoying watching the tweets come through as people complete the modules/challenges. I’ve not gotten very far myself, but intend to go front to back through all of the content. Some will be review but we can always use review. I’ve already referred a personal friend to it to get him up and going with Salesforce. I can’t wait to watch his progress & its a great way to started on the platform.
  • Lightning Components were opened up to developers and it promises to be slick as hell. I’ve only been able to spend a few hours with it so far, but I believe it will change much of what a developer on the platform does in the future. Our jobs won’t change immediately, there will always be enough apex work to go around, but things will indeed change. Jeff Douglas has a great intro to lightning so check it out.
  • Process Builder seems to be getting quite a bit of attention as well and really will shake things up in admin land. Brian Kwong (aka SalesforceWizard) has several good entries regarding process builder. I’ve not had the chance to do much besides give it a glance at this point but I believe its open beta so it would behoove you to get on this now.
  • Salesforce released Wave and next generation analytics platform. To be honest, I was wowed by the demo at the keynote — but that’s as far as I took it. I can’t focus on everything and I’m scattered as it is :)
  • POODLE just doodled all over SSL. On October 14th google engineers released information regarding a flaw in the SSL 3.0 protocol. Salesforce announced they’ll be shutting down that protocol and mass hysteria ensued. Its all very confusing and hard to even tell if one will be affected by it. There is a link on stackexchange that goes into excruciating detail of what the problem is and further down there is a link that will help you figure out which services may have a problem with this, but for the impatient…I think the magic you are looking for upon test completion is in the configuration section of the results. You’re looking for support of TLS 1.0 at least.

Other tech related stuff:

  • Apple CEO Tim Cook comes out as gay. This shouldn’t matter, but sadly we still live in a world where people think this an issue of some sort.
  • Apple Yosemite was released — and I like it :)
  • The Django project added four new core team members. Congrats folks!
  • An Indiegogo project was launched to help Django provide first class support for third party templating engines. I personally prefer the tempting framework that Django provides out of the box, but this can only help…

There are many more items of tech interest that I am sure I am leaving out but these are the ones I am remembering. This month, perhaps I’ll start bookmarking these things…I just hope I can keep this habit up! For now…