Lately, I’ve been trying to improve my Salesforce skills. It’s been getting pretty interesting, to the point where I’d like to dedicate a post to it. (Hardcore .NET/C# readers may want to skip this week!) There are bits of the Salesforce developer ecosystem which I love and a few bits that are a little janky. I think the most interesting thing for developers is “Salesforce DX”, which I’ll try to explain briefly.

At work, I’ve been advocating for greater use of our Salesforce org for a while now. I’m not going to do the sales pitch here (lord knows the Salesforce sales team are effective enough), but it makes a lot of sense for us as a business. As the months went by my suggestions starting gaining traction. Recently it all started to fall into place: over the next few months, we’ll be migrating several core functions onto the Force.com platform.

As the saying goes, “be careful what you wish for”. We were Salesforce amateurs really. We knew enough to know we liked it, but not enough to make our plans a reality. So I put a plan in place for me and a junior colleague to start learning the nuts and bolts of Salesforce development in a fairly intensive way. For the past few weeks, I’ve been dedicating a day a week to studying with Trailhead.

Observation #1 – Trailhead is brilliant

If you’ve not come across it, Trailhead is Salesforce’s platform for self-directed study. It’s easy to get started and flexible arrangement of modules of units within “Trails” means you can do as focused or as broad as time allows. Each unit concludes with a test, which will either be a quiz or a practical problem you’ll need to complete in one of the provided “playground” orgs.

Trailhead is mildly, but not annoyingly, gamified. Completing the challenge at the end of a unit will win you points. Finishing a module or project will earn you a badge. When you’ve got enough points and badges, you advance a rank. It’s nice to see your progress being recognised and the way it’s executed smartly avoids penalising people for taking an eclectic mix of modules. There are also “super-badges”, which become available to tackle when certain modules have been completed. I’ve not done a super-badge yet, but they look like extended practical projects with less hand-holding.

So far I’ve earnt 29 badges and approx. 40k points, which puts me about mid-way through the “mountaineer” rank and well on my way to being an “expeditioner”. In fact, check out my profile page.

My general impression has been very positive so far. The “playground” system works very well and I’ve only had one technical problem (apparently something called Locker Service doesn’t play nicely with Firefox) with the practical challenges so far. More importantly, I feel like I’ve learnt loads. Trailhead has allowed me to go at my own pace and has kept the content engaging.

Favourite modules so far:

• API Basics
• Apex Testing
• Asynchronous Apex

The best thing about Trailhead? It’s completely free – even the playground orgs.

Observation #2 – Apex is really well thought out

“Apex.” Does the name fill you with visions of mountain summits peaking out of the clouds? Well, whilst it may not actually be a path to heaven, it is pretty good.

The thing I really like about Apex is actually the same thing that initially attracted me to C# – it feels really well thought out. Back in the day, the syntactic sugar of C# was a refreshing liberation from Java’s boilerplate monotony. You could tell smart people had sat down and really thought about the craft of software development. Apex has that same vibe. Yes, it’s a strongly-typed language with a Java-esque syntax, but it’s got a lot of little bonuses baked in too:

• Testing is mandatory. To deploy Apex classes, they must have at least 75% coverage with unit tests. Apex also has its own test and mocking frameworks built in. When I’m testing back-end C# applications, mocking the database is usually a real pain-point, so it’s really significant to me that Apex gives you this for free.
• Working with the database is easy. In .NET land, I’m a big fan of Entity Frameworks and especially it’s “code-first” approach to database development. In Apex, it’s super easy to query data using SOQL (Salesforce Object Query Language) or SOSL (Salesforce Object Search Language), and to perform operations on the data using DML (Data Manipulation Language). These are all easily accessible within Apex and helpfully return native objects.
• Limits are there to be broken. Well, not broken per se, but they’re definitely not going to be an obstacle to a smart developer. Salesforce provides so many mechanisms to perform large amounts of work without hitting the limits. Code run asynchronously gets its own set of limits. Large data operations can be easily batched. It’s pretty much nudge theory: the limits are there to dissuade people from being anti-social in a multi-tenant environment; the workarounds are there to encourage people to write efficient code.

There are probably loads more examples of this sort of thing, but I’m only part-way through the modules I’ve assigned to myself. From what I’ve seen so far though, Apex is very well suited to it’s environment.

Observation #3 – Salesforce DX will be huge

The thing that bugged me at first was how disjointed Salesforce development can feel. Sure, I was doing some seriously “RAD” development, but it didn’t feel coherent in the same way that developing a website in Visual Studio does. I was jumping around the backend GUI (“setup”) to configure new objects, permissions etc., but then jumping into the “Developer Console” to do the odd bits of coding. As a development framework, most of the nuts and bolts are taken care of, but the result is that the scraps of actual coding in Apex feel more akin to scripting, if that’s not too strange a distinction to draw.

As someone used to treating everything as code, this can be quite jarring. To me, a lot of the stuff I was configuring in the GUI was part of my application, but it didn’t feel like a cohesive whole. I’d create objects over here, set permissions over there, dip into the developer console to do some coding, upload a static resource, do a bit more coding… You get the idea.

Salesforce DX changes all this by representing everything as code. Not that this means everything has to be hand-coded – configuration can be performed by clicking the UI, then pulled down as code afterwards. Ephemeral “scratch orgs” can be spun up in seconds, ready for the sfdx force:source:push that will apply configuration and code in one go.

This is a big deal for a couple of reasons. Firstly, it allows us to bundle together the various Salesforce parts that make up a functional application. We can make sure it is a complete representation of the app by pushing it to a fresh scratch org and testing it. Secondly, representing the whole application as text files make it much easier to manipulate using the tools that developers already know and love. Source control anyone? Diffs? Text files are so much easier to reason with than settings spread through a sprawling UI.

What surprises me about Salesforce DX is how few people seem to know about it. I’m currently in conversation with several ISVs (Independent Software Vendors; Salesforce lingo for app development shops) and consultants, but whenever I point out how DX could help them, they say: “we’ll have to get back to you on that…” Is this a rare example of a Salesforce marketing failure?

Summary

So there you have it. Three observations from my short time learning about Salesforce development. I hope some of it is useful.

I started persuing Salesforce to scratch a business itch. I wasn’t expecting to enjoy it. Sure enough, the developer experience left me feeling conflicted, but discovering Salesforce DX made it all feel a lot more natural. I really think DX will catch on among some groups of developers. I’d love to speak to professional Salesforce devs who are using this already, so if this is you, drop me a line!

Apex is smart and feels comfortable for someone coming from my sort of background. It’s clearly been well thought through and cleverly executed. If you’re a C# developer, you’ll pick up Apex really quickly. And Trailhead is an excellent way to do it. It’s a brilliant format and I’ve found it a highly effective way to learn.

It’s not all sunshine and roses though. For instance, I found the Developer Console to be quite janky. I was unable to dismiss old test runs and occasionally there were problems loading my workspace. Nothing too major though. The other irritation I’ve encountered was the problem with Locker Service that I mentioned above. This was a bit of a pain because I spend a long time labouring under the assumption that the fault was with my code. Oh well…

All in all, though, I did find myself really enjoying Salesforce development. Whilst you’re likely to either need to know about Salesforce or not, I’d encourage my developer friends to give it a go. If nothing else, it will likely introduce you to some new concepts and paradigms, which can only make you a better programmer.

Have you tried developing in Salesforce? What were your thoughts? Please share them in the comments below.