Introducing Slackforce: A Salesforce Slack Community

By now most of us are probably well aware of the various communication tools that are available to help you stay connected to your coworkers, especially if you have coworkers spread out around the world. Applications like Slack, Hipchat, and Google Hangouts are all different options that many companies use to promote sharing, collaboration, and transparency.

These tools are great for staying connected to your coworkers. But how do you stay connected to your overall community? The Salesforce community is expanding daily. There are several ways to share knowledge, including but not limited to the Salesforce StackExchange, the Twitter #askforce, and the hundreds of groups on the Salesforce Success Community.

However, there’s a missing gap here. What about real-time interactions?

Hello, Slackforce!

A former colleague of mine started a new community on Slack specifically for Salesforce administrators and developers. In the short amount of time it has been around, we’ve already seen great discussions and collaboration on lightning best practices, studying for certification exams, and more.

Interested? If you want to join us, please reach out by sending an email to me at robert [at] robertwatson.me, or send me a message on Twitter, and I’ll happily give you an invite URL.

Hope to chat with you soon!

— Robert

The Dark Art of CPU Benchmarking: Part 2

Last year I gave a talk with Dan Appleman at the 2016 Dreamforce conference and blogged about it here. While it’s only been a few months, it’s time for an update!

In perusing the Salesforce StackExchange recently, I realized that a lot of people post questions on the forum when they run into a CPU limit exception but there isn’t much content published on how to avoid hitting such errors. Furthermore, I also discovered that Adrian Larson developed an unmanaged package for profiling CPU time, amongst other Salesforce limits: the LimitsProfiler.

As a result of both of these things, I’ve published a Q&A on the StackExchange that goes into more detail on how to benchmark CPU time using the LimitsProfiler: “How can you benchmark Apex code to determine what operations consume the most CPU time?” – I hope that you’ll find it useful and share!

— Robert

Apex: The DateTime Class & Fun With Time Zones

There is quite a bit of good information and resources out there on using the DateTime class in Salesforce. In fact, the Salesforce Apex Developer Guide itself has published great examples on using this class.

However if there’s one thing I’ve learned over the past 5 years of professional development, it’s this: writing code using dates and time zones is a developer’s worst nightmare. From fixing unit tests on January 1st because a date was hardcoded and somehow made it past code review, to a client in another country complaining that something is broken because they told the system to exclude certain dates and it didn’t listen… I can’t possibly remember all of the stories I’ve heard.

So let’s take a deeper dive into the DateTime class with a few additional examples. Hopefully you’ll learn a thing or two – I know I have.

Continue reading

The Dark Art of CPU Benchmarking

Benchmarking in Salesforce is an important skill to learn, especially since Salesforce introduced the CPU timeout of ten seconds in the Winter ’14 release. If your code is inefficient, you may start to see exceptions thrown if processing the logic takes longer than the allotted ten seconds (sixty seconds when running asynchronously). Furthermore, other packages running in your Salesforce instance directly impacts all code and declarative functionality – unlike most Salesforce limits, the CPU timeout limit is not unique per namespace. (Also – benchmarking can be fun!)

I was a co-presenter on the topic of CPU benchmarking with Dan Appleman at this year’s Dreamforce conference. Missed the presentation? It was recorded! Check it out below:

The sample code used in the presentation can be found on GitHub at https://github.com/jsbulldog89/df16-benchmarking. For more information on CPU benchmarking, I encourage you to reference Chapter 3 in Advanced Apex, or search for CPU benchmarking on SearchTheForce.

— Robert

Salesforce TrailheaDX Campfire Story

In June, I had the opportunity to attend Salesforce’s TrailheaDX conference. In one of the sessions, I gave a quick 5 minute “campfire” story. Here it is, in written form!

Attending Dreamforce this year? Join me on Tuesday, October 4th as a I teach you about the Dark Art of CPU Benchmarking with Dan Appleman. Look out for a recap post here shortly thereafter!

TrailheaDX Campfire Story

Not so very long ago, I worked on a managed package that had thousands of unit tests. Thousands! To care about ensuring that *all* code is functioning properly in such a large product is pretty cool, right?

Well, there was a problem. A few, actually.

If you wanted to run these unit tests in one of the development orgs, go get a cup of coffee. Actually, you might as well go get an entire pot because they were taking over an hour to run! How could they be taking so long?

The team set out on a discovery and realized that updating the Apex Test Execution options and unchecking the “Disable Parallel Apex Testing” setting brought the time down from over an hour to 15-20 minutes. We found a solution – what a relief!

However, our journey was not yet done. Imagine you’re out walking in the sweltering hot forest – your water is almost gone, there are several blisters on your feet – and you spot your final destination out in the distance. So you keep walking, getting ecstatic that this will be all over soon… but you’ve been fooled. While your final destination may appear to be close, you soon realize there are several more hills to climb and fallen trees and rocks to maneuver around.

When running the tests asynchronously, many tests would fail due to row locking issues. It was never the same ones, and simply ignoring the failures was not an option because it wasn’t sufficient to say “oh, well they just failed because of row locking, but we know the actual unit test does really work.” So now we had to figure out which ones failed and select those to re-run again. And sometimes some of those would fail, and we’d have to re-run the ones that failed a second time.

One day, a developer stumbled upon the Salesforce Winter ‘16 release notes and made an interesting discovery. If you run unit tests through the Developer Console instead of from the Apex Test Execution page, there’s an option to re-run the failed unit tests! This means that you don’t need to manually re-run the classes that failed. Even better, you can select to run only specific test methods within a given test class instead of running the entire class.

This was great news. Developers everywhere rejoiced. While running so many tests asynchronously still causes row locking issues, we had better tools to enable us to confirm they all worked as expected.

So, what can we learn from this? First and foremost, read the Salesforce Release Notes – you never know what gems you may find. But don’t worry about remembering everything (because you won’t). You can always go back and re-read them later when it is more relevant for you – Salesforce doesn’t remove previous release notes. And even better, you can navigate the Salesforce Developer Documentation by release version as well!