A full review is posted below with lots of details on some of the things I did (and didn’t) like. The short version is:

if you are an intermediate level or above apex developer (1-2 years experience) then go and buy yourself a copy. Read it carefully, think about what is being said and make some notes. You will  learn a few things and it will make you think about how you are coding. 8/10 or 4 stars.

Okay, so you want to read the gory details?

To start with, Dan’s writing style is extremely approachable and easy to follow. You get what he is saying. the book is well structured and seems to go in a logical order. Code samples are easy enough to understand and have a good level of explanation. One small issue (not really Dan’s fault) is that due to the physical size and layout of the book, you occasionally get squashing and code over multiple pages. It is not a big problem and almost every programming books has a page of two that suffers from this, and as someone who prefers paper over pdf, I will accept it no worries. For those who might want another option, you can download the sample code and could read that on your screen alongside the book.

I am going to be honest and say there were certain things I didn’t agree with in terms of what Dan says are best practices. I won’t go into too many specifics here as I want people to make up their own minds, but I just always feel it is important to highlight that this book should not be read as a definitive patterns guide. Dan is quite open about this in the book and I would imagine most experienced developers and architects will disagree with some things.

For me this is however the books biggest positive as well. The currently available Force.com books are largely aimed at the newbie and beginner level developers with some covering of intermediate level stuff. This is the first book out there for more experienced developers and it is a welcome addition to the collection. Outside of conferences like Dreamforce/Cloudstock and local developer groups it is difficult to find somewhere to get this information in a centralised nicely presented format. I really liked Dan’s section on errors and debugging, and have adapted some of the ideas to place into my work in the future. It is a brilliant book and I hope more follow.

In summary, I really would highly recommend this book to intermediate and experienced apex developers. You may not agree with all of the book but it will make you think about why you code as you do and why you agree/disagree with what is written. And you will learn something new about the apex language. Worth every penny!

The system used to work perfectly but then suddenly stopped working. The only error was regarding null input to JSON but digging deeper showed that the authorisation was never completing. Further digging and logging on the console from the link showed an error:

Refused to display document because display forbidden by X-Frame-Options.

Some digging lead me to this StackOverflow post which lead me to update the link to have a target=”_top” attribute, and now it all works again! Basically the OAuth provider had updated their service to properly implement the protocol which leads to this error being thrown if we are about to perform some sort of XSS style action.

Hope anyone who stumbles across this finds it helpful! It caused me a few headaches so I thought I would share.

I have attended a few Cloudforce events before and always found them to be a fantastic opportunity to meetup with some people in the community (The North UK group was conceived at this year’s Cloudforce Leeds!) and see what new things were coming out from Salesforce themselves. I thought it was a really good indication of how much growth there ahs been in the world of Force.com development that London was able to hold it’s own Cloudstock event this year, mirroring the success of the San Fransisco event.

There were some fantastic talks given throughout the day on a range of subjects and it was a brilliant chance to meet up with some old community friends as well as make some new ones. For anyone who hasn’t seen yet, most of the talks given by the developers are up online in some form or another. Just tweet to the relevant person and they will happily show you where to find the information. It was great to get to chat to some of the developer groups there (Heroku, Amazon, Database.com) whom, I haven’t dealt with as much.

I myself gave a talk on Advanced Force.com Testing which was a fantastic experience. I really enjoyed getting to share some ideas with people and have received a lot of great support and interest from people since. The biggest learning lesson I had was not to eat anything for half an hour before your talk though, in case you get a small piece lodged in your throat and break down in a coughing fit as you start talking. My thanks to all those in the audience who showed concern for my well being, the lesson has been well learned!

I am looking forward to the next North UK meetup which I am organising for the end of the month when hopefully we can get to share some of the experiences and ideas that came out of Cloudstock/Cloudforce. I think next year’s event is going to be bigger and better as well which is fantastic to see. I will be posting more stuff over the next few weeks to follow on from my talk, but until then, enjoy a few pics of the event from my talk.

Firstly I wanted to say a massive thanks to all those who came along. We had around 23 people turn up in the end which was a fantastic turn out for the first meeting and gave a wide variety of viewpoints for discussions. I am looking forward to getting to learn from all these people and get to know them a bit better.

The main focus of the evening was around a group based discussion on “The Top 10 (ish) Things Every Force.com Developer Should Know”. For this, I started out giving some blurb and saying about experiences I had training people before we split into 3 groups and came up with our own lists of things that should be known and attempted to compile a top 10. These were then presented by each group to the rest of the group and discussed. We found that they had 5 items in common which (those with + next to in the pictures). I presented my top 10 I had thought of in preparing the evening and Carolina from FinancialForce.com gave us some interesting input on how she has found it best to structure triggers for data validation.

After some administrative discussion on when to meet and where to take the group a few of us decamped to the pub to continue getting to know each other.

Below are the images taken on the night, I am looking forward to the next meeting already!

Photos also available here!

1. Forget what you know about source control and start learning again. Git is distributed and as such is quite wildly different. It will take some getting you head around the idea of everybody having a repository that is a full system instead of checking in and out, but stick with it.
2. Use GitHub, they are cheap, they have a fantastic help section, they make coding social and they also help make using git a bit easier.
3. Use the command line. It will help you understand more accurately what is going on, it is the fastest way to use git and it gives you the most control. And if you are a developer and are not comfortable with a command line then you should be!
4. Learn how to branch and merge properly – this will help you to really start cooking on gas and make your development effort simple as well as highlighting git’s flexibility.
5. With Force.com development in a team, use branching and work in your own org. Sharing an org and trying to manage the source control process becomes more difficult. You can easily merge across other peoples changes.
6. In a Force.com project, make sure you create you repository in the eclipse project folder. Ignore the .settings folder and you should be good to go.
7. If you do the above, to start working on a project you just clone/fork it into your Eclipse workspace, create a new project with the name of the repo, select none for the initial metadata download and then save all the information upto the server. Easy!
8. Commit regularly! Push often!
9. You should per user story or feature you are working on. If multiple people are on a feature, either share an org (for a couple of people) or split the feature into smaller chunks. This will help your code. Remember that a branch is not a separate directory or folder.
10. All the items you can see in Eclipse are stored in text based metadata files. When merging and fixing conflicts, it is easiest to open the offending file in Notepad++ on Windows or TextMate on Mac. You can see the errors in the merge tags and resolve them from there.

There are a few things I think could be improved though. GitHub recognition for Apex and VisualForce in their code highlighting (I know linguist is open sourced but I can’t say I know where to begin with it) would be a nice start. The Eclipse git plugin needs work (as does the Force.com IDE itself…)  in order to make it easier to work with.

On a side note, I am looking into testing out Jenkins and Stratosource as continuous integration and build systems with GitHub. Anybody got any tricks or tips? I will post something up when I do get one of them running.

I would like to start this with a big thanks to Andy Mahood, Gary Breavington and Michael Botos for their guidance on this matter which I have expanded upon.

With the release of the Winter ’12 Force.com IDE update, there have been a few teething issues which have caused a number of problems. ONe of these is that it seems when connected to an org you cannot bring down the email templates folder as part of the metadata by default. I tweeted and posted to see if anyone else was having the same issues and thanks to Gary, Andy and Michael I was directed to the following github gist that give an outline of how to change the package file to include the templates.

So the problem with this method is that it can be very time consuming if you have a large number of folders with email templates you have created. Run the code snippet below in the execute anonymous window and it will output some nice XML text for you to copy across into the package.xml file. Easy!


String output = '\n\n';
List templates = [Select e.FolderId, e.DeveloperName
From EmailTemplate e];
Map folders = new Map([Select f.Id, f.DeveloperName
From Folder f where f.DeveloperName != null]);
Set folderIds = new Set();
folderIds.addAll(folders.keySet());

for (EmailTemplate template: templates) {
if (folders.keySet().contains(template.FolderId)) {
if (folderIds.contains(template.FolderId)) {
output += '\t' + folders.get(template.FolderId).DeveloperName
+ '\n';
folderIds.remove(template.FolderId);
}
output += '\t' + folders.get(template.FolderId).DeveloperName
+ '/' + template.DeveloperName + '\n';
}
}
output += '\n';
System.debug(output);


What I also like about Tony’s pattern is how easy it makes unit testing your triggers. You can test triggers in one of two ways; by using DML operations in your test method that will execute the trigger and exercise the code or if implementing the referenced pattern, by preparing an SObject and executing the methods in the trigger handler upon this and asserting upon the manipulated SObject. This will mean that the trigger methods are run in technical terms without context (you cannot get the Trigger.isBefore method to return true outside of a before trigger running) but it is debatable as to whether you need to test this as Salesforce will have previously ensured this is working. You will have achieved more than a sufficient level of code coverage and ensured your code works by unit testing the methods, before doing a full run through of the trigger in systems integration testing.

Myself, Alex Berg and Andy Ogenoff recently were debating with regards to testing practices and how to handle the situation where you have some code that is written about a particular SObject that then changes (a new mandatory field is added for example). This trigger pattern helps your tests to deal effectively with this, allowing you to test correctly factored methods which are not at the mercy of the SObject changing. Someone could change the SObject in this situation, adding a new mandatory field which will cause integration tests to fail. However, your code, which does not rely upon this new field, will still be tested properly and should not fail.

I know that I will be continuing to use this pattern in all of my work.

Tony is currently looking for UK based Force.com contract work. You can find him here on Linkedin. I can highly recommend him. ]]> http://paulbattisson.com/?feed=rss2&p=74 0 http://paulbattisson.com/?p=73 http://paulbattisson.com/?p=73#comments Fri, 12 Aug 2011 13:25:37 +0000 paul http://paulbattisson.com/?p=73 A week ago I read a brilliant post by Alex Berg on patterns for apex testing (you can find it here). We then had a good discussion (along with Andy Ognenoff) on Google+ about the different viewpoints we had around how testing should be done. I then disappeared for a week on holiday formulating a rough blog post on the topic in my head. I also want to make it clear that this is a technical discussion not a commentary on anybody’s work. So here goes.

I am going to start of by generalising the way in which we can go about setting up our tests with data:

1. Creating the data in the test method inline
2. Extracting the data creation to methods in the test class
3. Creating an external class which is a factory for creating data (I will differentiate between variations on this method later)

We will discuss all of these in an attempt to decide “which is best”. Before we start however, I would like to clarify, I am looking at this from the viewpoint of a developer performing unit testing. In his brilliant book the “Art of Unit Testing” Roy Osherove starts clearly by explaining the difference between integration testing and unit testing. It is a difference that I can say I think is often not understood;

Unit testing the is testing of a single unit of code where a unit is defined as a function or method. Integration testing is the testing of two or more dependent units together.

When we are discussing most tests in Salesforce we mean unit tests, testing a single method in a class. When we pull many methods together to move an SObject or piece of data through its lifecycle then we are performing integration testing. Unit testing is there so that when another developer goes and makes a change to the functionality of the system’s code or object behaviour the tests will fail (which is good news) so the system can be refactored properly to allow the existing functionality (if required to occur as well as the new behaviour). These points are key to the discussions.

Creating Data Inline

This is the situation as shown below

   1:  static testMethod void testSomeSituation()

   2:  {

   3:      //Create some object for our test and assign a value

   4:      MyObject testObject = new MyObject();

   5:      testObject.someField1 = "some value";

   6:      

   7:      //Not always necessary but for general case

   8:      insert testObject;

   9:   

  10:      //Perform some assertions on the object

  11:  }

The method creates its test data in lines 4 and 5 before inserting it into the database on line 8 where a trigger or validation rule will perform an action we wish to assert upon. The benefit of this way of performing test data creation is that it is quick and easy, we know any data created by code called during a test method gets automatically destroyed so it is safe to create data like this. However, as soon as we have another test method on this object or in this class using that object, we are likely to have duplicate code. This is evidently bad for when we update methods or objects in the future. This will be exacerbated in the situation where we have to create multiple objects (either related objects or for use in lists etc.) and become unwieldy.

Extracting to a Method

In this situation we extract the code on lines 3-8 to a method for reuse in the test class multiple times (see below):

   1:  private static MyObject createTestObject()

   2:  {

   3:      //Create some object for our test and assign a value

   4:      MyObject testObject = new MyObject();

   5:      testObject.someField1 = "some value";

   6:   

   7:      //Not always necessary but for general case

   8:      insert testObject;

   9:   

  10:      return testObject;

  11:  }

  12:   

  13:  static testMethod void testSomeSituation() 

  14:  {

  15:      //Create an object for use

  16:      MyObject testObject = createTestObject();

  17:      

  18:      //Update the SObject for this test

  19:      doSomething(testObject);

  20:   

  21:      //Perform some assertions on the SObject

  22:      System.assertEquals(aValue,testObject.Field1);

  23:  }

  24:   

  25:  static testMethod void testAnotherSituation() 

  26:  {

  27:      //Create an object for use

  28:      MyObject testObject = createTestObject();

  29:      

  30:      //Update the SObject for this test

  31:      doSomethingElse(testObject);

  32:   

  33:      //Perform some assertions on the SObject

  34:      System.assertEquals(anotherValue,testObject.Field2);

  35:  }

Here we have extracted the creation of the object for testing out to a separate method that is still within our test class. If we wish, we can create many other similar methods for other objects needing to be setup in this test class which will again give us more controlled and useful code.

I believe this to be the ideal situation for unit testing. The data required for any units of code under test is visible near to the code. It is clear as to what the actual test is doing and if the system is edited to alter the behaviour such that the tests fail, then the data is in a central place for updating this area of the codebase to get it working. It also allows any developers that are adding or updating code to the class under test to add new tests quickly and easily with the object needed. You are also adding the minimum amount of required data at all times which is important for speed.

Many will argue that having a centralised set of classes that handles all data creation is better (for integration testing I agree). Let’s discuss this.

Test Data Factory

In this situation we will have a test data factory class that we can call to create SObject instances for use in the tests. This system is the one described by Alex on his blog post.

On its positive side, this means that we have a single class (or set of classes) that we call in order to create some test data. If the system changes then we merely change the data once and this should update every test method where the data is used. It means that the same data is being used consistently across the entire test system as well which is helpful, and if written in a correct way, the data creation methods can be called to provide demo data for salespeople by calling the methods in the system.

The problems arise when we consider the following. Firstly, what happens when someone has two test cases where they needs the data slightly differently in each situation? We could setup the classes so the factory methods take in a series of parameters to create a personalised object, but this removes the power of having consistent data and also leaves us with hard to read code. This data must now also be closely regulated by the development team as any changes to it could have repercussions throughout the system’s unit tests. As the system grows in size and complexity, the factory can get very entangled and difficult to maintain for a series of small tests and can also lead to an increase in the time it takes to run tests. For example, we are writing a unit test that asserts whether a particular field value has been set properly. We do not need any related objects or other data created to perform this test, but it is more than likely that our test data creation methods will create surrounding data by default as it is being used throughout the system. For anyone wanting to go into the system and quickly create a test or update/add some functionality, they must then check the test factory is updated correctly and that this does not impact upon other areas of unit tests – developer flexibility is hampered as the data creation class becomes locked down and protected. In such large systems as well, and breaking of the test data class can cause all the unit tests to fail whether they are related or not as background data that is not needed fails to get created.

Having used this method of doing testing as well, you can find it leads to people writing tests without really understanding what they are doing and why they need it. It is good for a developer to write a unit test where they must set their data up for the test. That way they can know for definite what they have tested and be sure they are happy it works.

I personally employ this method, but use it for integration testing. If a change to the data can cause more that just the unit tests associated to that object to fail, you are not doing unit testing. Unit testing is about creating small piece of data to test small pieces of functionality so that if a change is made to a method, we can check it still works and acts as we expect it to. Having the test data being created in the test class (albeit in neatly extracted methods) allows us to know exactly what we are testing (and why). Having a full data creation factory is much more useful for integration testing as it can create a single set of data for use in testing the system or for use in demonstrations, but without interlinking the system to tightly.

I would love to hear what people think. As I have said, these are personal preferences based upon many hours of writing and fixing tests and also having done testing in more mature languages such as C#.

An aside:

I had a friend who told me the biggest risk Salesforce had was that it is so accessible that non-developers often start writing code and it reminded him of the MS Access boom when many poorly written systems started to fall over as they had been written by people that were not thinking far enough ahead. I am not suggesting that anybody reading this post is like that or that Salesforce should become less accessible. I do however wonder whether we would have a Billion Lines of Apex still if had all been written by people who were pure developers. For another post however.

So what have I been doing all this time? My last post was in February and revolved around some of the Force.com features that I had found most useful in team based development. I made a short presentation to the Agile Yorkshire user group based upon this post that was fairly well received.  In one of those interesting moments of hindsight I am getting now, I honestly don’t feel the presentation was really that good and if I were to do it again I would completely rewrite it, but the presentation did encourage a few people to look into Salesforce and that is good enough for me.

At work I have moved onto doing some iPad and mobile development which has been exciting, culminating in the recent release of DATASHELTER Mobile for Salesforce. I am now working on other exciting pieces and look forward to releases and launches of these for you guys to see.

There has been some slow emergence of some open source projects I am founding and co-founding for Salesforce developers and users. One of these will be based around the premise of improving the ease of learning Salesforce development for both non-developers and migrating developers. We saw recently
with the hiring of Matsumoto-san that Salesforce is very keen to drive developers to its platforms and is aware that the strength of any platform offering comes in no small part from the way it interacts with and aids developers on it. A large reason that Microsoft were so dominant in the past 20 years is the way in which they looked after the developer community they had. We all remember Ballmer’s developer chant. It is evident that Apple and Android are destroying RIM and Nokia because their development platforms are easy to use. I think Salesforce realise this (and if they don’t they should soon) and as such want to try and help developers utilise the technologies they have in the best way possible. The hope is my little project can help this aim on its way.

Again, revolving around the world of work, we have started using the fantastic GitHub system and I have been given the enviable job of leading the roll out of this. I can honestly say I have never used a more consistently brilliant and quick system. [On an aside, I did try out the GitHub for Mac offering and its nice. It just din't do everything I wanted exactly as I wanted it to though and I did find myself grumbling at its speed and feedback occasionally. It will remain installed and updated, but only get used sporadically. The command line is much more fun anyway.] I have been coming up with a branching pattern and testing it to ensure it fits in with our development systems in the smoothest way possible and hope to start linking Git and Chatter together for our own internal reporting needs.

So I do plan on keeping this more up to date. I haven’t even mentioned the fact I have been playing with Ruby, looking into UX and Human Interface, getting back into some graphic design work and reading a lot into Agile development and complexity theory, Core Animation and re-reading the brilliant Pragmatic Programmer, Refactoring, Design Patterns and slowly working through The Art of Computer Programming. I have started looking at obtaining my DEV 501 status as well and whether I should renew my CSM, obtain a CSP or quit the Scrum Alliance all together.

So expect some hopefully exciting writings soon!

rapid application development

To start developing on the Force.com platform, you simply signup for a free development org (which is an instance of their software in the cloud) and you are good to go. I generally attach Eclipse to my org using the plugin that Salesforce provide (you can download this bundled and redistributed as a standalone IDE but I play with other languages so like to be able to use one tool for the many tasks) but through the web interface there is a built in code editor.

Firstly, as you can imagine, this is an extremely quick and easy system to get setup and started on; I can have this all setup and be creating my first objects (analogous to tables in an RDBMS) for use in under 10 minutes – something that I think you will find hard to better elsewhere. This is the first plus point for Salesforce in terms of agile – it is extremely quick and easy so you can get started right away. Often teams tend to have a series of other admin tasks that they have to perform in order to get working, but with Salesforce, your effective “admin” time is zero. If you fancy seeing something amusing for 4 minutes look here. It sums the speed of Salesforce better than I ever could.

Testing, testing, 1, 2…

As a developer who likes to use agile practices, I try to work in a test (or sometimes behaviour) driven way to ensure that I am testing my code as I go. Another benefit of the platform is that in order to publish/package or use some code in production, it must have at least 1% test coverage and the entire code base must average at least 75% coverage! I have worked with a lot of developers before that seem to think (incorrectly) that testing is not an integral part of development, but on the Force.com platform you must do some unit testing. I have sadly seen cases where people have merely “exercised” their code by ensuring it is called in a test method, but as a general principal it serves to try and enforce the correct practices. (At the end of the day my 2 pence is that if you are going to have to write some test methods to cover the code, why not get it to do something useful and add an assert or two? Go on, you will thank me for it later. If you haven’t got proper unit tests you can never do any refactoring, only go changing code blindly.)

Continuous integration

In a previous life doing .Net development I had the pleasure of setting up a continuous integration system. Now I am actually not being sarcastic when I call it a “pleasure” because it was both a great learning exercise and also a magical tool. We could work on a copy of some work in .Net, ensure all our tests and code worked properly locally, then push them to our source control system where it would compile the entire system, run all the unit tests and other tests we had built around it (selenium etc.) and tell us either that everything was all good or that we had messed up somewhere and needed to fix it. This was all done really quickly and speedily and gave great instant feedback on what your code was doing to your overall code base and whether or not your product was always ready for deploying out to a customer (from a purely “it compiles and the code in there works” point of view, some functionality may not have been fully linked together just yet).

When working with the Force.com platform, if you are working on your own the “local copy” you are working on is actually just a copy of the files that are on and running on the cloud somewhere. If developing solo, this is fine as you can have your own source control system where you can deploy your changes from to a fresh org if you want to tests it is all okay. When working in a team it starts to become a little more tricky. Firstly you can’t always work in a single development org (I have worked in groups of 5 or so in a single org and you can nearly guarantee that you will either blow the request limit for a 24 hour period or that someone will be waiting relying upon changes from someone else etc.). The maximum number of developers that can sensibly work in an org is about 3 or 4 if they are working on mutually exclusive tasks, otherwise it becomes a bit more complicated. Often it is easier to work in separate development environments, then merge your changes into a single source control system together. My preferred method is to have the developers agree to deploy the package with the latest code after having committed code to the system. They just simply take a build token to signify nobody should make changes and the job is easy. It is also work setting up a nightly build where the latest code is deployed and tested (through both unit testing and selenium testing). Salesforce provide a great metadata tool to do the deployment and some simple ant scripting gets it all going nicely.

release early, release often

One of the basic principals of any agile development setup is that at the end of an iteration a release with as few a number of bugs as possible (see testing above!) should be available. Again Salesforce have got this covered by allowing you to create packages and now change sets that allow you to make releases available after each iteration. The ideal situation for a team developing a project on the Force.com platform would be to create a beta managed package at the end of each iteration which can be used for user testing, demos and also as a snapshot of where the system is. I have worked with teams and seen situations where development is still on-going on the last day of an iteration, and there is no visible release made internally (or even made at all) in the code base. By having the pressure (for want of a better word) or creating a managed package (75% code coverage and all) you focus on finishing stories/tasks/work and make sure that it is properly done. If you fail to make the cut you have failed to do the work properly. It is a very hard lesson to have to enforce (“but we were so close, honestly it is only an hour or so away from being finished…..”) but if enforced properly you will find your team getting more done of higher quality because the right system is in place. Continuous integration (as discussed above) helps to make this happen. This way you can also ensure that when you tell someone that a release is going to be on a certain date, you can make sure it is.

Logical separation

Salesforce enforces an MVC architecture when using Visualforce (its page mark-up language) and Apex in a controller. There are also triggers which handle work done on or with an object before and after update/insert/delete (validation, creation of related objects etc.) There are also components that can be created by a developer in order to reuse pieces of work. More recently as the Salesforce governor limits have started to be relaxed further and further, more traditional design patterns (such as those by the GOF or Martin Fowler) can be implemented alongside the newer patterns that have been developed for working on the platform. These combine to make it very easy and logical to separate out your code into correctly structured layers and provide yourself with patterns for use in the future. There is even dynamic apex to help further this extensibility in providing correct layer structure for your code. Add onto this you don’t have to do anything with a database (as it is already there and provides you with a large portion of your object structures) then correct layering and code practices are hard not to do.

Summary

Hopefully this somewhat brief and not fully comprehensive post has helped you to see some of the awesome features that Salesforce have setup in order to help you become a better developer and help you develop in an agile manner. Please feel free to post comments or suggestions for additions and I may either add them or create an entire new post to entail all those things I forgot.