I’m pleased to announce the immediate availability of the fourth edition of Advanced Apex Programming!
I know what you’re thinking – what has changed? Do I really need a new edition?
Well, the first thing you should know, is that this book is about 20% larger than the previous edition. But, the price is the same – instead of increasing the page count, I was able to increase the page size – from 6 x 9 to 7.5 x 9.25.
And what’s in that 20%?
Here’s a brief summary of the major changes for this edition:
Chapter 2: The section on “Controlling Program Flow” has been largely rewritten with a new example.
Chapter 3: The sections on “CPU Time Limits”, “Benchmarking”, “24-hour Limits” and “Other Platform Limits” are new or have been rewritten.
Chapter 5: There’s a new discussion on detecting duplicate fields in dynamic SOQL queries.
Chapter 6: The trigger framework has been enhanced, with particular attention to handling record DML updates across multiple trigger handlers (a subject discussed in previous editions but not actually demonstrated).
Chapter 7: New coverage of platform events.
Chapter 9 is a completely new topic: Application configuration. The previous chapters 9-12 are now chapter 10-13 and the following paragraphs refer to them by their new chapter number.
Chapter 10: Additional discussion of platform events.
Chapter 11: Revised recommendations for unit tests and managed packages.
Chapter 13: Updated for Salesforce DX
So even if you don’t buy this new edition, please don’t read the previous one – the platform has changed, and many of the earlier recommendations no longer reflect best practices.
And by the way – the Kindle edition is still priced considerably lower than the print edition – so that offers an inexpensive way to check out what’s new without buying a new printed book, for those of you who are more cost sensitive (I do recommend the printed book in general though, as listings just don’t come through that well in the eBook editions).
As always, watch for corrections and updates here on advancedapex.com – as I’m quite sure Salesforce will continue to update the platform faster than I can revise the book 🙂
Every admin and developer in the Salesforce world uses formulas – they are everywhere. And everyone learns them – sort-of. People tend to pick things up along the way, tweaking an existing formula here, reading the online docs there, borrowing from an online source – everywhere.
As a result, even experienced admins and developers tend to have holes in their knowledge – a less than complete understanding of data types, or of formula limits – or, and don’t get me started – endless confusion when it comes to logical operators (And, or, Not – you now – the ones that cause most formula bugs).
In my latest course, Formula Fundamentals in Salesforce, you’ll go back to the basics with in-depth coverage of Salesforce formulas. You’ll learn about data types, operators and functions – limits and testing. And yes, those dreaded logical operators and how to translate human logic into formula logic, and then validate that you did it correctly and test your work.
Watch Formula Fundamentals in Salesforce on Pluralsight
One of the more interesting challenges in Salesforce has to do with updating related records. For example: If you change the owner of an account, you might want to change the owner of all contacts for the account, and then maybe change the related tasks for those contacts and so on.
While there is some support some some situations (such as changing a single account owner using the UI), the general problem of doing so in bulk is actually quite challenging, as the number of related records that need to be updated can be huge.
If you’re interested in digging deeper into this subject, check out my new course on Pluralsight – “Play by Play: Managing Data in Salesforce using Apex“.
Play by play courses are a bit different than most. Instead of watching me present a screen cast, you’ll watch a video where I sit down with Don Robins and build out a solution in real-time. You get to see the entire development process, including the creation and resolution of bugs along the way. You’ll watch as I implement several different approaches, including some common ones that have hidden flaws that might not appear until long after they are “successfully” deployed.
As always, you can easily sign up for a free Pluralsight trail to watch the course if you aren’t currently a subscriber.
Watch Updating Related Records in Apex on Pluralsight
Update – The real TrailheadX agenda is now posted https://developer.salesforce.com/trailheadx/agenda. If you’re attending be sure to stop by the Campfire Tales session being put on by Pluraslight on Wednesday at 12:40!
Like everyone else, I await the official agenda for TrailheadX – the first Salesforce developer conference.
However, being as impatient as I am, I did some digging (through my imagination) and came up with a short list of some of the amazing experiences we can look forward to. Here they are:
- Everyone will get loaded onto RVs for learning on the road with Jeff Douglas @jeffdonthemic – learning coding while driving through California’s beautiful state and national parks.
- You’ll then practice your skills on tablets as naturalists guide you on a nature trail as part of the innovative Trailhead on Trailheads program.
- TrailheadX takes place on the same day as the California primary. Donald Trump will lead a hands on training of implementing wall management on Salesforce platform using advanced currency management (since it’s going to be paid for in pesos) assuming he can get currency management to work (See here ).
- A Benjamin Franklin lookalike will demonstrate building a mobile electrical system management app built on Lightning.
- As part of our commitment to community service we’ll be reaching out to the homeless – the thousands of San Francisco tech workers who struggle to afford a bed in a hacker dorm while only making six figures.
- Featured performance by Adele singing her hit song “Hello World”
The third edition of Advanced Apex Programming is now available!
And have I got a deal for you!
I’ve often been asked by people, what’s new in this edition and is there any way to get a discount on upgrading? Now there is a lot new in this edition – with numerous changes throughout the book both in content and in recommended best practices. The chapter on asynchronous programming has been almost completely rewritten to address queueable Apex (yes, all of the previous best practices have been rendered obsolete), and there’s a new chapter on maintaining Apex.
But how do you offer upgrades on a book? It’s not like software, where people can register and updates can detect previous versions. Or SAAS applications where the upgrades come with your annual subscription.
Also, in previous years, Salesforce licensed a special printing for distribution at Dreamforce, which was great for Dreamforce attendees, but not so good for everyone else. This year timing and their budget didn’t allow for that.
Still, it’s the Dreamforce time of year, right? Good time to do something special.
So, I decided to do an experiment – and offer “upgrade” pricing to everyone.
For the next 90 days the eBook version will be available on Amazon Kindle through their Select program – at a price of 9.99 (or whatever the Kindle select pricing is where you are). Prime customers will be able to borrow it. Kindle unlimited customers can just download it. After 90 days, it will revert to the normal $34.99 or equivalent price (unless the experiment is so successful that it makes more sense to extend the deal).
Books are a lot more limiting – I don’t have the same flexibility I have with the EBook. But there is one channel where I do have the ability to offer a great discount. So for those of you who want a new printed copy, I can do this – if you go to the book’s store on createspace, you can get a 50% discount by entering this code on checkout CDUK54Z5 – 50% off the regular price of $39.95. Keep in mind, this code ONLY works on that store, and yes, they can ship internationally. This offer, which is sponsored in part by Full Circle Insights (which you should check out for our great marketing analytic tools), is good for 30 days, after which it too can go away at any time.
So that’s the deal. No free books at Dreamforce, but upgrade pricing for everyone for a limited time. Hopefully this approach will be more fair, and still provide a reasonable return (because I have to tell you – it was a lot of work!)
Purchase the print version with upgrade pricing – Use code CDUK54Z5 on checkout for the discount.
Purchase the Kindle version with upgrade pricing:
(note, it may take a few days for the printed edition of the book to appear on some international Amazon sites – I’ll update the home page as I see them become available)
On each Force.com release, developers eagerly look through the release notes for exciting new features. I’ve found that the things that excite me most often aren’t the same things that thrill others. I often get most excited about small changes – sometimes they can have a huge impact on software design patterns.
This summer, the biggest feature for me is the elimination of Describe limits. This eliminates a huge Catch-22 when developing on the platform. On one hand, good Apex code is supposed to respect field level and object security. But the previous Describe statement limit made it difficult and sometimes impossible to do so on larger applications and systems, where the number of fields processed in an execution context could easily exceed the available limits.
The elimination of Describe limits does, however, raise an interesting question. How does this change impact design patterns and could other limits come into play? Or put another way – how costly are Describe calls in terms of CPU time?
Prior to now, the best design pattern for using Describe statements involved caching each Describe call so that you could at least ensure that you don’t call getDescribe on a field more than once in an execution context. The design pattern looked something like the getDescribeInfo function below, where the parameters are the field name and SObjectField token for the desired field:
private static Map<String, Schema.DescribeFieldResult> fieldDescribeCache = new Map<String, Schema.DescribeFieldResult>();
private static Schema.DescribeFieldResult getDescribeInfo(String name, SObjectField token)
if(!fieldDescribeCache.containsKey(name)) fieldDescribeCache.put(name, token.getDescribe());
Does it still make sense to use this kind of pattern? Or should you just call getDescribe() whenever you need describe information?
To find out, I did some benchmarking using the techniques described in chapter 3 of the second edition of Advanced Apex Programming.
I found that the approximate cost of a Describe statement is about 3 microseconds. This looked pretty fast to me. Can the earlier design pattern, with its cost of an additional function call and map lookup, be any faster?
The answer, as it turns out, is no. The overhead of caching and looking up data exceeded any benefits that might have come from avoiding the extra Describe calls.
Further testing showed the same results with SObject describes as field describes.
I don’t know if Describe calls on summer 14 are fast because work went in to optimize them, or because the platform is now caching describe data internally for you, but it doesn’t really matter. It seems clear that going forward, the optimal design pattern for describe statements is to use them inline as needed.