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?
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!
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!
Contrary to what you might have been reading in the news lately, 2016 wasn’t all that bad. At least, not for me!
This post is coming quite late this year, but nevertheless, I’m going to take a few minutes to analyze last year’s goals and make new ones for 2017.
What Went Well:
- I continued averaging around 7 hours of sleep per night. I’m so good at this now that I no longer need to use the Microsoft Band to track my sleep.
- I ran 4 half marathons and also biked a heck of a lot more than last year. A lot of my biking came from my work commute to SODO in the summer.
- I read 12 books for an average of a book a month.
- My volunteering increased. I started volunteering at the University District Food Bank and have been going almost once per month since June fairly consistently.
What Didn’t Go Well:
- I didn’t really do well with the “continue learning” goal besides continuing to learn at my job. I will try to do better here in 2017.
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.
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!)
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.