Salesforce Ninja: An Elite Blog about Salesforce.com

A few days ago I was speaking to a developer friend, he was asked about a Singleton design pattern and he had no idea about. He spoke about how we developers never talk about patterns. And that time it hit me, we developers do not talk about design patterns and algorithms. There are many design patterns available off the shelf, they talk in detail about the problems they can solve. However, in my experience, I have come across and used the following 1. Singleton This is one of the most common and important design pattern to be used. When initiating objects, we need to make sure only one instance of the object is initiated. In a multi-tenant system like Salesforce, it becomes imperative that we do not hog more resources than needed Lets look at an example trigger AccountTrigger on Account (before insert, before update) { for(Account record : Trigger.new){ AccountMasterRecordType rt = new AccountMasterRecordType (); .... } } public class AccountMa...

This post is very old but it is long overdue. Have you seen the Ghost records in Salesforce? Whenever there is an auto-number field on an Object, it suddenly seems to have gaps in between? For e.g., if you have a auto-number set at 00001 and the next record it creates is 00004. These gaps are sometimes attributed to people who create records and delete. Auto-number fields Lets talk a bit about auto-number. Apart from the part that they are cool, they are also very stubborn. An auto-number field resets only once in its lifetime and never turns back. When an auto-number is incremented it does not go back, even if the record is deleted. So when you delete a record that has auto-number field on it, it will not decrement it by 1 but instead create the gap. Ghost records The real crux of the issue lies when developers write unit classes. Developers always create dummy records for testing. The test execution runs in a separate context than the main Salesforce. These records are not s...

A new intern joined the team excited to learn about Salesforce. She had a little Java background and thought that Salesforce was very easy compared to Java. In her eagerness, she wrote a 20 lines of code to prove her skills and grasp on Salesforce. The problem was, the code could be written in just 3 lines. When you are coding on Salesforce, you have to keep in mind the following things: i) If you can save some lines of code, save it, you can use those lines later.  If you can write a code in 5 lines, don't waste a 6th one. That one line you saved could be the difference between spending a weekend in office optimizing the code or going to a party at the weekend. ii) Write like the code will run forever. Yes, your Sales team has taken in writing that there will only be three records in the system. Yes, you have written a good code for that. But when you are dealing with Salesforce, remember that data is going to increase over a period of time. Today you may be processing ...