Sunday, 23 October 2011

London Force.com Developer Meetup #3

This week saw the third London Force.com Developer meetup take place, at the Skills Matter eXchange in Clerkenwell.  A slightly different format this time, with five lightning talks.  Click on the links at the start of each section to view the podcasts.

First up was Amjad Khan on Schema Spy.  Schema Spy is a Java tool that analyses databases and produces a graphical representation of the schema.  A plugin links this to your Salesforce instance.  This is a tool that I've used once or twice in the past, but not that frequently as one of the BrightGen deliverables from the scoping stage of a project is a diagram of the data model.  Where it has come in very handy is when we've been engaged to extend an existing solution or provide a managed service - it saves a lot of analysis time in these cases.

The new Schema Builder functionality looks likely to replace this for us in the fullness of time, mainly as it is in the cloud, and anything that gets software off of my laptop gets my vote.

Next up was Simon Goodyear on interfaces.  For some reason I'd convinced myself that this was going to be around user interfaces, rather than the programming construct as it turned out to be! Interfaces are something that I tend to use when developing products rather than carrying out a Salesforce implementation, on the assumption that I'm likely to want to swap out implementations as the platform moves on, but customers are unlikely to want (or to want to pay for!, even though the cost is usually pretty low) this level of flexibility. Usually Salesforce implementations are seen as a single-shot roll out with some additional maintenance work as time goes on.

A real-world example of interfaces for us was a custom calendar implementation.  The standard Salesforce activity functionality didn't give the flexibility that was required, Initially there were three sobject types that could feature in calendars, which were people, rooms and equipment.  It seemed highly likely that there would be other sobject types required to work in this way, and indeed this turned out to be the case.  Thus the calendar functionality was implemented to work with a Calendarable interface, and wrapper classes to encapsulate the sobjects along with an implementation of the Calendarable interface were written.   Supporting a new sobject type in the calendar was reduced to a small custom class with 10s of lines of code, rather than tweaking code all over the calendar implementation.

Next up was yours truly on the subject of testing.  I'm planning to use this as the basis for a blog post dedicated to testing, so won't say anything more here.

Stony Grunow then spoke on effective B2C management.  I found this a particularly useful talk, as I'm often having to field questions about why person accounts aren't suitable for an implementation, usually because additional, secondary contacts are required to be associated, for example spouse and children.  I'll definitely be taking a look at the Contacts and Organizations package.

Finally, Bruce Durling spoke on using Selenium to automate deployments.  Deploying configuration has always been a challenge, as there are some things that can be deployed via metadata - approval processes for example.  Re-keying these is error-prone, even when using the four eyes principle.  Using Selenium for this is an intriguing notion.  A key factor in deciding whether to go this route would be the amount of times that the deployment will take place.  If its a single shot, then I can't see there would be much benefit, as you would be effectively re-keying it through code that drives Selenium.    Where it becomes much more useful is where changes have to be deployed through various developer sandboxes, QA and pre-production environments before ending up on production.

I can also see this being a useful technique for creating custom setting values, which aren't copied over for anything other than full copy sandboxes, but supply vital configuration information to allow the system to function correctly.  It may even provide a solution to the perennial problem of determining the HTML element ids of fields to populate via URL parameters.  We use custom settings to capture this information, but there's still manual intervention required to scrape the id out of the page. Something I'll be investigating in the near future.

With all this, excellent before and after networking, and free pizza and beer, its easy to see why these meetups are growing in popularity.  Once again, thanks go to Wes Nolte (@wesnolte) and Bruce Durling (@otfrom) for organizing everything.  If you are interested in coming along to the next one, follow any (or all!) of these twitter users and the details will be (re)tweeted as soon as they are confirmed: @bob_buzzard, @otfrom, @wesnolte.  Look forward to seeing you there!

No comments:

Post a comment