Getting your Certified Force.com Certification

On January 8th I had the pleasure of presenting a case at the South West UK Salesforce Developer meetup, which is an event that happens every other month in Bristol UK, where the regions Salesforce developers, CTOs, and Force.com-curious meet up for a couple of pints, some short talks, and a lot of technical debate about living on the Force.com Platform.

The theme of our January meetup was "Certification" - which we thought was appropriate, what with this being the time for resolutions and making plans. I co-presented the first talk which was an introduction to certification process through the Certified Force.com Developer option. The second presentation was by Christopher Alun Lewis on his experience of the Advanced Force.com Developer.

Here are my slides from the talk, which I was asked to share by some of the audience, and below them a quick script covering what I spoke about on each, to support the otherwise vague bullet points!


Slide 1: On this deck, this is an into slide.

Slide 2: Welcome to the South West DUG presentation on becoming a Certified Force.com Developer, I myself have been certified for about 18 months now, and Julio, who will be telling us all about his experience with certification, has been qualified himself for 6 months.

Slide 3: What is the Certified Force.com Developer qualification then? It's a badge, that you can quite literally wear (see slide 4) to indicate that you are a competent Force.com developer, familiar with the platform and it's features and functions. If you want to pitch yourself to clients and employers as a Salesforce developer, it really should be seen as the minimum entry criteria. It is an exam based qualification, which is taken in an invigilated enviroment, and consists of 60 multiple choice questions about developing on the Force.com Platform, of which you must get 41 right. You have 90 minutes to do so, and once you have submitted your answers, the examination software instantly tells you if you have Passed or Failed.

Slide 4: An example of putting the badge into place!

Slide 5: So how do you go about getting certified down in the South west of England? Our test centre is in Bath, by the river, about 10-15 minute walk from the train station, so it's really not hard to get to.  A bigger consideration is perhaps that it does cost $200 USD to take the exam and you do need to book in advance (normally a week or two at least) on the certification website. Once you have the qualification, you should also note that it has to be kept up to date, and this is done via 3 annual maintenance exams. These are done on your home PC in your own time (within a 5-6 month window) and involve answering 6 more multiple choice questions on the latest features, or platform core concepts, to show you are still a valid, involved developer. The first year comes free with your qualification, but after that you must pay $100pa to keep the certification valid.

Slide 6: What is it they are looking for then when you walk through that examination door? The Certified Force.com Developer is not about code, or syntax, or APIs or Libraries. It's about understanding the Force.com platform, and knowing WHEN to code and WHEN to click. You need to show a good understanding of configuration driven solutions, or when you would be forced to code. You do not need to know the code you would use though. The second part of this slide is taken from certification.salesforce.com verbatim, and breaks down the core concepts the exam will cover. Be familiar with ALL of these areas, you cannot pass by being a total expert in some, and know nothing of others.

Slide 7: The tools of the trade then, how do you go about actually passing the exam? Your first choice would of course be the course. Salesforce 401 covers the exact requirements for the Certified Force.com Developer qualification. But in the UK you would probably be looking at taking part in a 5 day, virtual classroom experience for the best part of £3,000... if you got the time and the money, I guess go for it, but failing that, the fundamentals book, and a bit of hands on experience with the Platform will serve you just as well. All the Certified Force.com Developers I know have self-taught/learnt on the job. I do know some of the qualified trainers on the 401 track through, and they are bloody nice people :)

Slide 8: This is Julio's story, .. another great read on the Certified Force.com Developer road.

Slide 9: So this is my story, now you know the facts of life. I had been working on the platform for about a year when the time came for me to get the certification. I came from being a Java developer, with 6 years commercial experience and a Computer Science degree, so I felt ready for a new examination challenge. I would say one of the biggest benefits for me was working alongside an existing Certified Force.com Developer, so any time I had a question both about the platform or the certification process, I could ask him, and he could put my mind at ease about the logistics and process of the exam. I booked my exam in with about 2 months notice, to let me gear up for it, and the last thing I did, was take 2 weeks out (of life) and just ploughed through the entire fundamentals book, doing the exercises and extensions, to remind myself of the core concepts, and all the bits (like reports and, security) that we don't really think about properly during our day to day work. On the day, I took about 75 of the 90 minutes to answer, review and submit my winning score to the system, I chose not to beat myself up for the full time period, because I would only end up over thinking choices and changing right answers.

Slide 10: So, any questions? If not... here's one for you..

Slide 11: This is the actual example question off the certification.salesforce.com website for Certified Force.com Developers. Can you answer it? I'm not going to tell you the right answer, but chuck me a comment in the section below with your thoughts!

Well. Thanks for reading through that journey with me! If you'd like to know more, please get in touch and I will field your questions, you can also tweet me on @srlawr if you like. If you live in the south west UK, get in touch with your local Salesforce Developer User Group for free beer and chats like these.

Know your apps from your apps

Having just been at Dreamforce 2013 with Desynit, we have all come away with bright, wide eyes, staggering forward repeating the word "app, app, app" like a mob of geeky zombies. Filling the "app gap" has been cited as our number one priority, and the new Salesforce 1 Platform has basically been given to us as an incredible "free tonne of bricks" to start doing this.

But it appeared during discussions that this concept is starting to confuse a few people, and after a few whiteboard sessions explaining similar concepts over and over, I decided a blog post was in order on "what is the difference between an app, an app, and an app?"

It's a good question actually, and typically we use a couple of pre-cursors to help us separate the types of app, and it's important you know the difference before you go applying the term to your business.

The traditional, and predominant use of the term "app" is referring to what we technically call a "native app" and these are specifically (and expensively) written pieces of software designed to run on a certain type of device. Everything you download from the AppStore™ for your iPhone™ is ultimately a native app for your Apple™ devices.

These native apps are written in the appropriate programming language for the device they are intended to run on (ObjectiveC for Apple™ devices, Java for Android etc.etc.) and are typically fairly difficult to port between the different devices. They communicate with your Salesforce org via the various APIs sending data back and forth over secure external connections.

They are also written, compiled and released at a set moment in time, and do not change from that point (other than by lengthy update processes). This means if your underlying Salesforce data structure or business processes change, your expensive app might become redundant.

One worldwide example of a native app could be seen in downloading the facebook app available to almost every mobile device in existence.

The second most common use of the term is referring to "web apps" these are slightly newer to the scene in their most popular format as it has taken longer for mobile and tablet devices to consistently come up to speed supporting the predominant technologies, HTML5 and CSS3.

The key to web apps is that they are not "downloaded" and stored on the mobile device, but are instead "accessed" - typically though the phones standard web browser - and are so cleverly written they provide a rich and functional experience. The actual compilation and markup is generated by the webservers, off on the internet, and the interfaces then rendered out by the phone. A lot of interesting libraries and technologies exist (such as Dojox.mobile and PhoneGap) that can detect the "type" of device being used and then make the web page mimic the native control's appearances giving the user a very consistent experience, but in fact actually running almost no logical code on the device at all.

Some of the huge perks of these apps is that they quite simply run on any device that can access the internet. They can be seemlessly updated on the servers, and the user receives the updated version immediately, and because they are probably typically provided by, or hosted on the users core system, have unrivalled access to the company data.

An example of a web app can loosely be seen by accessing the facebook website on a mobile device (typically accessible on http://m.facebook.com) - you will receive a rich and integrated Facebook experience, but without a native app, purely through the browser.

The final kind of app a user might experience is called a "hybrid app" and you might not be surprised to hear that this is a mixture of the two app types mentioned above. Hybrid apps - such as the latest and greatest Salesforce 1 Platform typically have a native container, that the user downloads to their mobile device, but this then delivers rich web content through windows, or frames to the companies web service.

Hybrid apps, whilst therefore still limited to distribution through appstores on the relevant hardware (basically; sorry Blackberry users) can harness the full power of the devices features and hardware, whilst delivering an up-to-date web services.

In summary the original interpretation of the term "app" being a native piece of software for a phone, is - in this developers opinion - possibly now one of the more restrictive and life-limited meanings. The huge cost and limited flexibility means that unless you directly intend to take advantage of the increased local processing power/storage and access to the device hardware it really isn't the most sensible option any more. I am convinced that more and more apps will at the very least be naturally evolving into Hybrids, the incredible power demonstrated by Salesforce 1 shows how you can be seamlessly passed between native and web services without any interruption or hassle for the end user.

Never forget Salesforce ActionSupport events are case sensitive!

I'm pretty sure this is repeated around the world, but I thought one more blog post throwing it's weight behind it wouldn't hurt. Developers, do not forget that Visualforce ActionSupport events ARE case sensitive.

The Actionsupport DOM events include "onchange", "onclick", "ondblclick", "onfocus", "onkeydown", "onkeyup", "onmousedown", "onmousemove" and so on and so on, and these are all in lowercase, despite the occasional new Javascript convention to camelCase them.

That easily cost me half an hour of visualforce debugging, and not for the first time!

Now, as a quick test to make sure you were paying attention, why won't my daysbox element rerender in this code snippet?? Use your eyes, and your minds..

Reducing SOQL queries in Triggers by updating on ID

I have recently been battling the SOQL query limit on a large Force.com project I'm working on.

One of the biggest problems we have is with SOQL in Triggers, over and over again, we were using SOQL to load a list of parent/related objects, modifying their contents and then updating them.

Then one day, I realised, we didn't need to do this at all.

Here is an example of a trigger that "passed" a status field from an updated object back to it's parent:

trigger UpdateParent on Child__c (after insert, after update)
{ 
    // get the list of parent object IDs
    List Ids = new List();
    for(Child__c thisChild : Trigger.new) {
         Ids.add(thisChild.ParentRef__c);
    }

    // Load up the list of parent objects and map them out for altering and updating
    List parentList = [SELECT Id FROM Parent__c WHERE Id IN :Ids];

    Map parentMap = new Map();
    for(Parent__c thisParent : parentList) {
        parentMap.put(thisParent.Id, thisParent);
    }

    // This is our list of parents to finally update
    List parentsToSave = new List();
    
    // Finally we're ready to go through each child in the trigger and update it's parent

    for(Child__c thisChild : Trigger.new)
    {
        Parent__c par = parentMap.get(thisChild.ParentRef__c);
        par.Child_Status__c = thisChild.Status__c;
        parentsToSave.add(par);
    }

    // update the parents.
    update parentsToSave;

}

That's actually pretty hefty, it's a lot of maps and lists, and the SOQL query right in the middle there, just to update one field on a related object. I think this technique is a bastardisation of the Force.com Fundamentals teachings, which has emphasis on batchification, and in it's example, probably has a lot more cause to go through this process. For me though, this could be simplified by taking advantage of a simple Force.com fact:

If you create an instance of an sObject, and assign a valid record ID to it, you can update or upsert it exactly as if it was originally loaded to memory.

This means, that as we already have our parent object IDs in a reference field, we don't need to LOAD them, we can just conjure up new ones, update the relevant field, and update them. That makes the above trigger look like this:

trigger UpdateParent on Child__c (after insert, after update)
{
    // This is our list of parents to finally update
    List parentsToSave = new List();
    
    // Now we can just go through each child in the trigger "instantiate" it's parent, update and, update!

    for(Child__c thisChild : Trigger.new)
    {
        Parent__c par = new Parent__c();
        par.Id = thisChild.ParentRef__c;
        par.Child_Status__c = thisChild.Status__c;
        parentsToSave.add(par);
    }

    // update the parents.
    update parentsToSave;    
}

I can literally feel my governor limits squeeling with joy already!! No SOQL, half the script statements, a quarter of the lists and maps. Fantastic.

Merry Christmas from Desynit

I'm devastated to tell you that I wasn't in the office the day that this little productive gem was filmed, but all the same, Merry Christmas from Desynit and the Simon Lawrence Application Development Blog...

 

Don't forget to like Desynit on Facebook to make us feel all loved and popular, and if you so wish to know more about what I do (typically outside of programming) dig me up on twitter too.

Merry Christmas!

Outputting the Salesforce 18 character ID

Those familiar with Salesforce record IDs, and more specifically their use within the Salesforce API will probably know that they come in both 15 and 18 character variations.

The 15 digit ID, as seen in the URL of any record within Salesforce, is a case sensitive ID, and can be confidently used internally within your org for managing objects.

If you intend to use, load or manipulate records with an external program, for example, exporting data via reports or the API, you will probably need to use the 18 digit ID, which includes three extra "check digits" and is not case sensitive. It is important to remember, that functions like Excel's VLOOKUP are not case sensitive, nor, by default are MySQL queries.

There are a number of functions and tools available to manually calculate the last three characters, and a really brilliant explainantion of how the digits are calculated, and their use can be found on the Astadia blog post 15 or 18 Character IDs in Salesforce.com.

This isn't an ideal solution though, which leaves you thinking that there must be a simpler way to get the 18 digit ID out of the front end of your organisation. And of course, you can, and once you know how, it's actually incredibly simple!

All you need to do is create a new custom formula field on your object, give it a relevant name, set it's type to "text" and in the formula box enter:

CASESAFEID(Id)

and that's it! If you're feeling particularly lazy, it's even in the righthand box of "Functions" and you can just double click it to enter.

Save the field, alter your field level security settings, and add it to the relevant page layouts and this field will display the 18 digit ID on your Salesforce record.

Now when you want to test, or work, with your Salesforce records, as they will have been saved in external applications and data exports, you can grab the 18 character ID straight off your page layout.

Dreamforce 2012: Integrating PayPal Mass Payments with Force.com

"Welcome to Dreamforce 2012"

Everywhere you look at the moment in the Salesforce.com world, there are banners, blogs and news articles hailing the largest ever Enterprise IT conference.

It used to be held at the worlds biggest conference centre, the Moscone West in San Francisco; but now, it's held at the worlds biggest conference centre AND ten surrounding hotels and facilities. Not to mention closing off a few streets and booking out every hotel in the west of the city. With 70,000 attendees, and a gala headlined by the Red Hot Chilli Peppers, this is the CRM industry's flagship event.

So who wouldn't want to give a presentation there? Especially on such an awesome topic as combining one of the worlds most popular and accessible payment gateways with the worlds coolest CRM
(ok, it's just the inner-nerd in me that's getting so excited about those bits).

Welcome then to the supporting blog post to this Dreamforce 2012 developer track session:

Integrating PayPal Mass Payments with Force.com

If you are attending Dreamforce, you'll have access to the Chatter (touch!) session page here.

So what can you expect from this session? Well, having found this post, I can promise you will be well placed to take the most away from this presentation (and if you are here after the session, you will find this blog, along with what I presented an incredibly valuable combination towards understanding the process).

Firstly, let me link you up with the GitHub repository containing the integration code and demo files:

 https://github.com/srlawr/PaypalSFDC

Once I have clearance from Salesforce.com I will post the slides from the presentation up here too, but really, what you'll want is these two blog posts on the topic, which are the original works that landed me the Dreamforce presentation in the first place:

1) Salesforce - Paypal Masspay Integration

2) Salesforce - Paypal IPN integration

Working through these two blog posts should empower a talented developer to perform their own complete PayPal Mass Payments integration in a couple of days. If you don't have this kind of resource, or want to tap into my expert knowledge on the topic.. please get in touch with my employers Desynit, and I'm sure they will be more than happy to talk to you.