Sharing the Cloud, Part 2 - Governor Limits

Another way that SFDC makes the cloud more friendly is by using governor limits. By limiting the amount of resources consumed by a single tenant, SFDC can provide a standard level of service and reliability across its entire offering.  This post may create more questions than answers at this stage, but we will address more and more items as I add to this blog.


There are many kinds of governor limits in place but generally speaking I put them into categories:

• Platform Limits
• Work Flow and Approval limits
• Sandbox limits
• Refresh Limits
• Characters of Code
• Application Limits
• Apex Limits
• Quantity of queries
• Quantity of query results
• Cumulative SOQL statements invoked by a trigger fire
• API limits
• Number of API calls
• Visualforce Limits
• View State
• SOQL and SOSL Limits
• Relationship limits
• Length of query statement

An excellent breakdown of the current limits can be found here at the Winter '12 Limits Cheat Sheet .

But what do all of these limits mean to us as developers?

It means we have to make out code as lean as possible to accomplish everything our clients need.

Some good practices include:

• Design your Data well, with some forward looking when designing your data model. This higher Normal Form that you can maintain  the easier it will be to get the data that you want without anything additional to count against your limits while serving no real purpose.
• Avoid putting DML statements inside of loops. You can add all of your DML statements to a list and insert the entire list all at once!
• Judicial use of the "transient" keyword when creating variables that can not be saved can reduce your View state. 
• Example:
• transient boolean myBool;
• Plan your queries ahead of time, and get all the data in one query. Once you have it you can reassign the same collection more than once.

Salesforce is my first Developer platform, and it has a lot of governor limits to be mindful of. At first glance I was daunted by what I perceived as a crippling cap on what I could do as a developer. Over time though I have come to appreciate the limits. I am making better decisions when creating my applications, I am putting pages and controllers together that do all they need and them move the user on to then next page or task. I have a greater understanding of the relationships in my data. But most importantly, I am writing better more effective code.

Sharing the Cloud, Part 1 - Test Classes

One of the first questions I had when beginning to learn about Salesforce and clout development was:

What is "The Cloud"?

In the case of Salesforce.com (SFDC), it is a remote (off site) collection of hardware that is shared by multiple tenants, and maintained by another party.

Let that sink in a moment...

I can buy the rights to a server farm for a lot less than it would cost me to maintain one myself. No hardware to maintain, no people to carry out the maintenance, no real estate to hold it in. The entire infrastructure is leased out to me the tenant. This is IaaS, or Infrastructure as a Service. This allows the small 10 person company to have access to the same high performance machines and service that big businesses like Qualcomm, Dell, Siemans and Starbucks use. This is pretty darn cool. It puts some pretty powerful tools in the hands of a lot of people who may not have had the finances to access them on their own. But that is just the hardware. What about the software?

SFDC also provides robust CRM software. SaaS, or Software as a Service, is the other side of the Cloud coin for SFDC. Hosted on their infrastructure, SFDC software offers an out of the box solution to simple CRM processes. But with the use of their proprietary APEX and Visualforce languages, custom solutions can be built to allow for any business rules, workflow, and process to be brought into the package. And again all of these tools are available to anyone with a license, and free to developers who want to hone their skills.

So, here we all are playing happily in the same sandbox. But what happens when someone has an accident? What if I write a piece of code that shuts down a server with an endless loop, or build so many data calls into my code that i take too many system resources?

SFDC manages these risks through the use of Governor Limits and Test Classes.

Test Classes are a collection of method calls designed to run through your code looking for potential Governor Limit violations and logic errors. I will delve deeper into how I write test classes in a later post. For now lets just consider the fundamentals. Here are some considerations:

• Your entire Production Environment must have a minimum average coverage of 75%
• This is over total lines of code across all classes.
• While testing to 75% is the minimum, 100% should always be the goal.
• You can not deploy a controller or object that breaks another one already deployed.
• When you deploy a file you will be required to validate the entire Production package.
• If you make a change in Production that causes a controller to fail its test, you will be required to fix it before deploying any other files apart from the updated file.
• If your coverage is too low, deploying a hot fix may not be possible.
• Controllers, and Triggers require Test Classes
• Visualforce pages do not require Test Classes
• It is best practice to develop the Test Class and Controller in a sandbox environment and deploy them together.
• Properly identified Test Classes do not count towards your total code limit.

Test classes call each line of your code in a controlled environment to help you:

• Identify logic loops that never end.
• Find queries that return too many results
• Find queries that reference objects that do not exist
• Find SOQL (Salesforce Object Query Language, and more on that in another entry!) statements that reach Governor Limits

This is just the tip of the iceberg on Test Classes. I will go into more and more detail in future blog posts, but for now just consider that even though it seems like you are writing a lot of extra code, having these Test Classes required really puts you the Developer in a position to learn how you should be developing. It is much easier to test a class that uses only the queries and SOQL it needs to. Write clean and efficient code and Test Classes will be a fairly routine exercise.

A Beginning!

I found myself with an opportunity to change careers and pick where I wanted my life to take me. After some discussion with my family, and some long thought, I decided I wanted to learn about developing software.

I found a technical studies school with a good reputation, and began a 9 month course to learn the concept of "Object Oriented Programming" using Visual Studio and C# as a foundation for learning.

I was offered a position as a contractor developing Salesforce the day of my last class. At this point I was new to programming in general, and new to Visualforce and Apex (the languages used to develop Salesforce). I was nervous and embarking on a new career. Naturally I jumped at the chance!

I was fortunate to be brought in at the same time as a few other Developers that had also graduated from the same school that I had. The employer had looked for experienced Salesforce Developers without any success so they decided to bring on some contractors fresh out of Developer school and "make" their own Salesforce Developers.

In the last year I have learned a great deal about the entire Development Process from start to finish. We are involved in every step of the journey from concept to post deployment support.

A fellow developer friend of mine came up with the idea to create some blogs to document the process and share our experiences not just with each other, but with anyone who might be interested.

I could not be more excited!

I could not be happier.