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 →

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/robertbwatson/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

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!