London Salesforce Developer Meetup – April Review

Is it a bird? Is it a plane? No! It’s a Salesforce Ladies in Tech and Developer Super Meetup!

That’s right, the March meetup of the London Salesforce Developers joined forces with the Salesforce Ladies in Tech to hold a combined super-gathering.

The Brightgen offices in Salesforce Tower hosted us, and as ever I was dead pleased to ride in the outside elevator up to their amazing view over the city. And I was in great company on my way up, joined by both Jodi Wagner – one of the night’s speakers and all round Salesforce celeb – and the MobileCaddy CEO, Justin Halfpenny. Not only is he our CEO, but he’s also my brother and the latest member of the community to put their names forward to co-organise the London Salesforce DUG.

The evening was to have two talks, one from each of the meetup groups… but of course it started with a natter and a drink. Seriously, if you’ve not been to a meetup then I can’t recommend you attend enough. Even without the presentations they’re an incredible source of business and geek chat, and the odd slice of pizza.

Personal Branding – Jodi Wagner

First up was Jodi. She’s an incredibly active and passionate member of the community. Not only is she a co-organiser of the Salesforce Women in Tech meetup but she also co-organised the incredible London’s Calling and the recent Evening with Ladies who Salesforce. Oh, she’s also a delivery manager at Accenture, if she wasn’t busy enough already.

Jodi’s talk was all about personal branding, and she started with something that I hadn’t even begun to appreciate, and that’s the thought that personal branding isn’t about you, it’s about other’s perceptions of you. She recommended that, however vain it might be, it’s a good idea to google yourself. I did, and I was pleasantly relieved/surprised (delete as appropriate).

Search results for "todd halfpenny"


Once you know where you currently stand you then need to think about your Value Proposition, and where you want to be. Jodi has many suggestions around how to get there, and you can find all the details in her slides. Some key areas mentioned though include;

  • Planning
  • Know the channels – what you post on LinkedIn won’t necessarily work in your favour on Facebook, for example
  • Keep a schedule in mind – when are your target audience online
  • Monitor the results – tools can be used to see the reach and impact of your work.

A really nice touch to Jodi’s talk was a slide containing a few tips from some of the folk within the Salesforce ecosystem who appear to have mastered their online branding. A couple of messages seem to come through strongly, such as “Be authentic” and “Be consistent”, the latter could apply to message and cadence.

I had asked Jodi about whether or not she thought it was a good idea to have a personal account, as well as one for your professional self. She replied that if you get the balance right then a single account can be very strong; it was nice to hear her say that from my tweets and blogs that she knew that MobileCaddy was doing some incredible work with offline Salesforce apps, but also that I like food and go for a jog every now and again… I’ll take that.

Open Source & Apex Common and Apex Mocks

The next talk was actually in two parts, let’s respect that; The talks were by Andrew Fawcett and David Frudd of FinancialForce.

Getting the most out of the Salesforce Open Source Community

Salesforce has been notable of late in the Open Source world following its release of the Lightning Design System, but there are many more Salesforce (initiated and related) open source projects than that, and some have been around for quite some time. MobileCaddy are keen open source contributors too, not only into our own projects such as our mobile starter apps, but also the Salesforce Mobile SDK projects that we extend to provide fully offline mobile apps with custom UIs. We also contribute to other projects such as ngCordova and Ionic that help provide support for incredible hybrid mobile applications.

Andrew talked us through things of note to look out for when contemplating whether or not to contribute (or even use) open source projects, though more of interest to me was what you can get out of it. He spoke about how FinancialForce’s open source projects had helped them with;

  • Recruitment
  • Product Promotion
  • Social/ethical Rewards

What’s new in FinancialForce Apex-Common and Apex-Mocks?

Andrew’s colleague David was up next to talk about two of FinancialForce’s projects. Apex Common and Apex Mocks are two projects that we use and love at MobileCaddy and David gave us an explanation of each, and some of the new(ish) features and fixes that had been contributed not only by FinancialForce employees but also the wider open source community.

The fflib-apex-common repo gives you a wonderful project that aids Apex developers by giving them a best practice and practical design patterns library for use within their Salesforce applications. One can combine the beautiful modular code you get from using this library with the fflib-apex-mocks repo to achieve great coverage in your unit tests too.

For information and examples and tutorials on using these, and the other FinancialForce projects head over to their developer site.

Wrap Up

It was really nice to share the meetup with the Ladies in Tech, and I hope it’s something we get to do again. I’d love to have chatted to some of the other attendees more, but time as always was not on our side.

Videos of the evening’s talks should be available on the meetup’s YouTube channel (soon if not already there).

Thanks, as usual, to the organisers and sponsors.

The next meetup should fall on the 25th May, less than a week after the London edition of the Salesforce World Tour. I hope to be at the meetup if manning our sponsorship booth at the World Tour doesn’t prove too much for me. UPDATE: the meetup has moved to the 17th May – Developing Wave Apps with Skip Sauls, hope to see you there!

And if you are planning on coming to the World Tour in London then drop by our sponsor booth and check out some of the apps we’ve built for, and with, our partners, and how you too can realise the mobile advantage of taking the power of the platform with you.

ngCordova – Contributing a Plugin Mock with Tests

One of our current projects covers creating a bespoke Salesforce mobile application for a large company in the tourism sector. One of their requirements was to have printing functionality from the app. Seeing as our MobileCaddy SDK provides a toolkit for building hybrid mobile applications for Salesforce we turned to the existing Cordova plugin ecosystem and came across the cordova-plugin-printer plugin. It is common place for the Salesforce consultancies that use our SDK to consume the Cordova plugins via the mightily handy ngCordova project, and luckily this printer plugin was already supported by the project.


Although this plugin, and the ngCordova interface, suited our needs (and worked well) part of the beauty of building hybrid apps is the ability to use common web development workflows, which include building and (doing a certain amount of) testing in the browser.  To do this many of the plugins on ngCordova also include mock instances that either interact with standard browsers capabilities or simply stub the calls. In the case of the cordova-plugin-printer though, this mock did not exist.

This post covers the steps we used to create a mock for the plugin and then create a PR for ngCordova, with the hope our code can be included in a future release. Giving back (even if in a small way) to open source source communities is one of the things we really enjoy. Through this post I hope that others may feel inspired and able to do the same. Creating fixes, patches and features are just small parts of developing software; interacting with an OS project can sometimes feel a bit daunting, but hopefully this post will help.

Getting setup to make our change

First up we need to make a fork of the ngCordova github repo, and I’ve assumed that you already have a github account. This fork is where we will do our development and run initial tests against. So next step is to clone this fork to your development environment.

Once we have our own clone of the project we need to create a branch to work on. In the case for the above (adding a mock for the printer plugin) I created a branch called feat/printerMock.

I also want to confirm that all unit tests for the project currently pass. If I did this after I started making my code changes it would be a bad idea as I wouldn’t know if I’d accidentally altered something. The ngCordova project comes with support for running karma unit tests via gulp. All tests can be run with the following command;

Running this initially gave me the following errors, it seems my project’s development environment isn’t quite ready yet

Looking at the project’s directory I can see that we have a package.json and a bower.jsonand so it seems I need to install some packages and dependencies. These can be installed with the following two commands.

From the output of these commands I can see that a whole host of things, including angular, has been installed into my project’s directory… so I run the gulp karma command again. This time all looks good; at the time of writing there were 269 unit tests, and all passed so I was happy to continue.

Adding the Printer Mock

The plugins’ code can be found in the src/plugins directory. And looking at the printer.js file I see a simple interface with just two functions exposed, isAvailable and print. These are the functions I want to create a mock for. First up I create a new file in the src/mocks directory called printer.js (to match the real one). My first skeleton file looks like this;

Add a test for our mock

Next up I create a test spec for this new mock, this is a file called printer.spec.js that I put in the test/mocks directory. This test spec will contain a couple of basic tests to check my mock implementation.

The skeleton file for the test spec looks like this; it’s very basic, and at present doesn’t do anything much other than describe a test block and ready it for use in testing the ngCordovaMocks module.

Following the beforeEach block I now add another describe block that will contain my specific printer plugin tests. This itself contains another beforeEach that injects the cordovaPrinter factory seen in our skeleton mock above. Our spec now looks like this;

If we run gulp karma again now we can see that we still have the same number of tests running and passing… and we’re now ready to add to that.

Firstly let’s add a test to cover the isAvailable function. We know from the code in ngCordova (and the original plugin) that this returns a JavaScript promise resolving to a boolean value, so let’s write a test for this, bearing in mind that our mock code will always return true. The following is the test for that, and this follows the beforeEach block in our nested describe block that we added above.

We are ready to run our gulp karma again, and this time the result shows and extra test has run, but failed;

But this failure is good right… we haven’t written our code yet.

Add our mock code

For our isAvailable call we know we need to return boolean and in our mock’s case this will always be true. To implement this we add the following into our mock’s return block, so that it looks like this;

If we run our gulp karma again to kick off the tests we should see that our new test is now passing. Grab yourself a glass of your favourite beverage to celebrate.

Using the same TDD(ish) approach we can then add the extra test and code for the print function. In fact a slightly better workflow here is to run gulp karma-watch. This will set a watch running on both our source and test specs and will re-run the unit tests when it spots a change to either.

The finished code for the mock and mock test spec are here

Creating the PR

Now that we’re happy with the mock and test code we are ready to create a PR. The ngCordova project actually requires that the project is built prior to submission. The following step performs the build steps that outputs the concatenated and minified versions of the distributable ngCordova modules, and we need to include these in our PR.

Once this is run we should see that we have, as well as our 2 new files, updated files within the dist directory exist. This can be seen by running a git status command.

Now commit the changes and push to your fork of the project on github. If you now view your new branch on github you should see a “compare and create pull request” button. Click this and (at present) select the dev-next branch as the target.

And that’s it, PR created. And in the ngCordova project’s case a travis job will automatically be kicked off causing the unit tests to be run, and we should see these all pass (including our 2 new ones).

The PR mentioned in this post can be found here.

Please don’t feel that contributing to open source projects is a daunting task, only suitable for ninja, guru, unicorn, blah blah developers… get stuck in and have a go.

Our next PR?

Well perhaps we should raise a documentation PR to add the above steps to the on the ngCordova repo?