Tag: beginning Salesforce Programming

5 Incredible Resources For Learning to Program Salesforce

5 Incredible Resources for Learning to Program Salesforce

Salesforce is an incredibly large and customizable platform with hundreds of different features. Learning to use Salesforce can be difficult, but learning to program and manage Salesforce is even more daunting. Below I’ve provided you with the best resources I could find on programming Salesforce.  Before jumping into learning to program apex, I recommend you register for a demo org and watch a few of the different product demos.

When I started learning how to use Salesforce Apex in 2013, I was amazed at the hundreds of different online resources available. Literally, there are thousands of different sites. Over the last two years, I’m sure there’s been even more resources. Salesforce has developed its own “learning portal”, and there’s been a few new books that have come out.

SFDC99

One site, in particular really stood out to me which was SALESFORCE CODING LESSONS FOR THE 99%. David has written very good and detailed tutorials that anyone should be able to follow and implement. I understand that David lead some great sessions at Dreamforce 2014; I wasn’t able to attend any of them though.

Trailhead

At Dreamforce 2014, Salesforce introduced Trailhead. A while after Dreamforce, I wrote a post about my thoughts on Trailhead. Trailhead is an incredible resource that I wish was around when I had first started using Salesforce. Over the last year, it’s really exploded and now offering a ton of different paths to learning about Salesforce.

Bob Buzzard Blog

No list would be complete without the Bob Buzzard blog. Keir has written dozens of blog articles that I have bookmarked about different Salesforce topics. His posts are primarily about visualforce and apex, although he has started writing quite a bit about Salesforce Lightning and Trailhead. He’s also written a book about visualforce and led some great sessions at Dreamforce. I believe right now Keir has almost all of the Salesforce Certifications.

OyeCode

Harshit Pandey previously worked at Salesforce as a Technical Architect. He has some incredibly basic blog articles, and some incredibly technical articles as well. One of my favourite series so far is his section on Salesforce Technical Architect Best Practices.

Jeff Douglas Blog

Prior to becoming a Salesforce Employee Jeff wrote some incredible posts about apex and visualforce. One of my favourite posts is his post about having “Fun With Salesforce Collections“.

Additional Salesforce Training Resources

  • Force Platform Fundamentals is Salesforce’s introduction to the Force.com Platform. There’s quite a bit of discussion about building metadata (creating objects, fields, custom workflows, approval process), security, and reporting. Overall, it’s pretty good but also very daunting. The pdf has about 400 pages.
  • Visualforce Developers Guide is pretty much a must for any developer that will develop pages in Salesforce.
  • Apex Workbook covers a lot about the syntax, fundamentals, and limits the Salesforce have placed in the language and on the platform.
  • Salesforce University provides some in person and online training. I haven’t taken any of the training, but it seems like it could be pretty good based on some of the Hands on Training I’ve done at Dreamforce. Prices also seem to be pretty high, and in US Dollars
  • On Youtube, there’s a lot of different Dreamforce Presentations many of which are very good and still pretty relevant.
  • Also review my blog article about about Using jQuery with Visualforce.

Salesforce Development Tips for the Novice

Salesforce Logo

For the last eleven months or so, I’ve been working a lot as a salesforce developer.  In this time, I’ve learned an incredible amount about Salesforce. This blog article is a culmination of all the different things I’ve experienced and learned along the way. The syntax for Salesforce Apex is very similar to Java, but there’s certainly some different challenges.

For the most part, I’ve become a lot more concerned about the use of resources. Salesforce.com is a multi-tenant environment; this means that resources are shared amongst many. As a result, Salesforce must impose some limits, these limits are called governor limits can be found through out the system.  One of the most common limits is the number of SOQL queries that can be done in a transaction and the number of lines of code that can be run.

The easiest way to get around these limits isn’t to look at using Future Methods (See my blog post called “What are Future Methods “) or other techniques, instead try to use native Salesforce functionality like workflows. For me, avoiding governor limits has been one of the most frustrating parts of developing in salesforce / apex. My first time experiencing a governor limit was in a long loop that queried the Primary Contact for an Account. I would have been far better off using the SOQL binding and then looping through the results after. (And it proved to also be faster when I ended up testing it.) In development, it’s very difficult to hit governor limits. SOQL queries should be avoided in loops.

Triggers should always be coded for bulk processing. Queries and operations should usually be done on some sort of collection like a list. It’s incredibly easy to hit the SOQL limits if your code will run in a very active organization. On a sandbox, you’ll probably never experience this while debugging or building the code.

Validation Rules are your friend. In the book “Clean Code”, Bob Martin was adamant about not repeating yourself and keeping things simple. By using validation rules we can keep our code clean and stop from repeating ourselves in multiple places. Validation Rules

Controllers should do the very minimum required to get a record, display a record, and save a record. If possible, pages should use standard controllers and then controller extensions to do any logic or processing. Anything else, should probably happen in a validation rule or a trigger. Unit Testing is vital because it’s impossible to test everything by hand, and Salesforce requires at least 75% code coverage across all classes and at least 1% code coverage for each trigger.

When developing custom logic for Salesforce, there’s no such thing as just a few minutes for development if a bug creeps in. Deploying code into production from a sandbox instance can take anywhere from half an hour to a few hours depending on the size of the codebase. Previously, I’ve done unit testing in .NET and in PHP and found it very helpful in reducing bugs. In Salesforce, the overall code coverage must be at least 75% for a deployment to be successful.

That’s a few things I’ve learned about Salesforce the hardway. What things have you learned since you started?