London Salesforce Developer Meetup – March Review

Written by

 

Last month I attended the London Salesforce Developers’ meetup, which was hosted at the SkillsMatter at CodeNode in Moorgate. You may remember that this is where the 2016 London’s Calling Salesforce community event was recently held.

MobileCaddy is the new proud video sponsor and was recording both talks, which will be published to the new London Salesforce Developers YouTube Channel as they become available. So why not check out the existing videos once you’re done reading this, as they include my goodself doing a live coding demo – building a fully offline Salesforce mobile app using the MobileCaddy SDK.

There were two talks on the night, both Lightning related, though they were quite different from each other. I suppose that’s what happens when you get a new, slightly ambiguous, branding phrase.

Migrating your Apps to Lightning – John Belo

John is an ISV Technical Enablement Director (EMEA) for Salesforce and I’d met him a couple of times before. He had offered his assistance to us at MobileCaddy if we ever needed help with anything Salesforce Mobile SDK related, a kind offer to which I replied that we found them very helpful already – MobileCaddy has actually been submitting code to the core Salesforce Mobile SDK project for a couple of years, providing improvements and bug fixes alike.

The team who work on the Salesforce Mobile SDK are key to anyone wanting to build mobile apps that offer true offline capabilities, and stretch the demands beyond those that are catered for by Salesforce1. We’re thankful for them doing such a great job, so that we can do ours.

migrating-your-apps

 

John was here to talk about how ISVs can start migrating their apps to Lightning. This is something I’m sure Salesforce wants to really push, to generate some traction around the technology. It was interesting to see though, when asked, how many users were already using Lightning in their apps, which turned out to be only one amongst us all. Other notable stats mentioned were;

  • 140+ Lightning-ready Apps
  • 50+ Lightning-ready Components

These stats show that although Salesforce is mightily keen on pushing Lightning, it still has a long way to go to gain traction and take-up among ISVs and users alike.

The core of the talk was focused around how ISVs can start using Lightning today to prepare themselves for further takup by users. There are several routes to this, depending on how much work you want to undertake, and also the architecture of what you currently have (if anything). These approaches range from simply adopting the Lightning Design System for style, right through re-writing apps with Lightning components.

One handy route to slowly and controllably adopting Lightning is to migrate chunks of functionality to Lightning, piecemeal. This can be achieved by using Lightning components within Visualforce pages.

vf-lightning-component-sm

Pic courtesy Salesforce

Talks like this from the ISV team are really handy, though I think it will take more (at least more time) for partners to really start rolling Lightning into their current offerings, especially when there are still some elements that are’t available through Lightning yet (and no concrete ETAs, either).

From a mobile perspective, the drive to Lightning may smooth the road to getting apps to fit well with Salesforce1, though of course they will then be subject to the constraints that come with it. Applications that still require advanced features, such as a fully customised UI, or full offline support, need to be built outside of Salesforce1. If your app has the requirements then MobileCaddy is the answer for you.

Lightning Connect Int. with OData Services – Marc Paris

Marc is a Technical Architect at Cognizant and kicked off a passionate talk on Lightning Connect. He talked about how and when it can be used to pull external data into the Salesforce UI.

Lightning Connect was launched towards the end of 2014, but I hadn’t really seen it in action – or maybe I had, and I wasn’t aware of what was happening under the hood, but I suppose that’s its beauty, right?

Olingo Logo

 

Lightning Connect can be used to connect in these scenarios;

  1. Lightning Connect ←→ Lightning Connect – for inter-org communication
  2. Lightning Connect ← → oData Service
  3. Lightning Connect ← → Custom Adapter

Marc took us through a demo of the second option, where he had a basic oData service running using the Apache olingo project. He showed us how, through config, the connection could be added, and how Salesforce would use the web service to discover the objects available. Lightning Connect can support the following features, as long as the backend service does likewise;

  • Create, Read, Update, Delete
  • Filters
  • Inter-object Relationships
  • Integration with Global Search.

His demo included querying the REST API in a basic manner, as well as using page layouts to filter the data that is requested from the source. He also showed us basic update and delete flows too… it all seems very powerful.

£33k per external source, wowee! – Todd Halfpenny 2014

The power though does come at a cost, currently £33,000 per external data source… a price tag though that may well put a big-ol-hole in a lot of business plans.

It’s interesting to think that through the use of Lightning Connect that no data is stored on SFDC itself, and that it is all pulled/pushed in real-time to and from the external data source. Whether this helps with any data residency restrictions is, of course, another topic altogether. In the questions that followed Marc’s talk the mention of PCI was also raised, but it seemed we all agreed that internal logs may also contain data, so this would need further investigation.

I will post a link to Marc’s slides once I have it.

Wrap Up

Initial thanks, as always, go to the organising crew, and especially to Anup as he was the only one able to make this outing. And thanks to must go to Cognizant who sourced the venue, beers, and pizza (and chocolate snacks too).

Lightning isn’t going to go away, but the path for ISVs is a long one, and one that is going to need investment. With regards to Lightning and fully offline, robust mobile apps, there are still several gaps to be filled. For these reasons it’s not currently our go-to framework; it does not, at the current time, lend itself to the control and extensibility needed to support mobile apps that fulfil parts of critical business processes. Performance issues are another reason that, at present, we are steering our partners and clients to alternative such as Ionic, though of course we hope that this will change in future.

And as for Lightning Connect, I have so many ideas on how it could be used, I just don’t have pockets deep enough.

Useful Links

London AngularJS Meetup – March Review

Written by

A very hectic few months has meant that I hadn’t been to an AngularJS meetup in quite some time, so I was looking forward to getting along again. And with the topic being AngularJS Performance – Tuning the Engine I was doubly set on making time for it.

The meetup was again held at the Bloomberg office at Moorgate, and as with the previous meetup there their food did not fail to impress – “Chicken Caesar on flatbread with a quail’s egg” canapés. As for the rest of the venue it’s perfectly suited to a large meetup. Huge thanks to them for hosting.

Tuning the Engine – Todd Motto

I’d heard of Todd before, though I wasn’t even following him on Twitter (I have rectified that now) so I wasn’t sure what to expect. Todd is a developer advocate at Telerik, who provide developer tools for desktop and mobile apps.

His talk was originally going to be called AngularJS: The Performance Parts but he’d updated it to suit the story of his presentation. At MobileCaddy performance is key, and potentially any tweak that can be made to improve a desktop JavaScript application has an even greater impact on performance when run on a mobile device.

digest

 

Todd’s talk was split into two main parts, the first being some educational coverage of the Angular event loop and its $digest cycle, and the second covering some things you could do to help your app’s performance, as informed by the first part.

The slides for the talk are available here.

Angular Event Loop & $digest Cycle

First up, Todd talked us briefly through the Angular event loop (or should that be AngularJS event loop?). He showed us that it looks like the below (thanks to Todd for the image), with events from the DOM (change, click, blur etc) prompting a chain of events that results in a run (or two) of the Angular $digest cycle that generally ends up in the DOM being re-rendered with updates.

angular-event-loop

 

He went further into the $digest cycle next, covering $rootsScope, $scopes and $$watchers. This slowly built up a picture of how these, especially the $$watchers can impact AngularJS performance of an app. This idea, on a general scale, was one I was already familiar with, but he then mentioned something that I wasn’t aware of. When you assign a value to $scope it does not create a watcher for it, a watcher is created when interpolating a value in the view;

someController.js

someTemplate.html

During the running through of the above, Todd showed us a very basic demo, and Angular uses the same techniques internally.

Tweaking

The second part of the talk covered a few techniques that can be used to make the most of the way Angular works, and one or two that, for me at least, seemed to appear from left field.

I don’t want to re-produce his talk here as I’d rather you use his material for that (useful links below). But I was previously unaware of a particularly interesting one, so I thought I’d cover it briefly as well as bullet-pointing some of the areas covered;

  • Reducing the $digest frequency
  • Optimising the use of ng-repeat
  • Speeding up filtering (using controller filters)
  • $digest batching
  • Production Settings

Disable Debug Info – You can remove unwanted (for production) bindings and class names by disabling the Angular Debug Info config. It’s a one liner in your config block;

I have yet to try this out myself, but I’ll update here once I have to see what impact this has. I have high hopes as the official AngularJS docs state a “significant performance boost.” Note though that doing this at build time might not be ideal as protractor and batarang (among others?) need it enabled to work.

Useful Links

Wrap Up

It was another really useful and interesting meetup, and as well as the talk itself being great I also got the chance to chat to a couple of folk I’d met at previous events: one of whom had actually seen me talk about how MobileCaddy and Ionic can be used to create offline mobile Salesforce apps – what a small world.

 

Big thanks should go to the event sponsors and also to Ed and Josh for organising another really good meetup, I really hope that time allows me to make the next one.

 

London’s Calling – A 1st Time Speaker’s View

Written by

londons-calling-1

 

Unless you’ve been living under some kind of Salesforce-repellent-rock you’ll be aware that the inaugural London’s Calling event took place on the 5th Feb. But if you were under that rock then I’ll quickly mention that it was Europe’s largest Salesforce Community event to date.

When I first heard of the event, at the monthly London Salesforce Developers meetup, I was very excited, and pitched to the MobileCaddy team that we should submit a talk idea… so to say I was honoured to have our MobileCaddy CFP response accepted was (is) of course an understatement. There were 70 CFPs received by the organising team (more on that motley crew later) and there ended up being 28, plus two keynotes.

Only the Paranoid Mobile Apps Survive

This was to be my first speaker slot at a Salesforce event… I’d done a couple at the Ionic UK Meetup group before but they’re not on quite the same scale. My talk was entitled Only the Paranoid Mobile Apps Survive and focused on some key stumbling-blocks and factors that needed to be taken into consideration when wanting to take a critical business app mobile. Although our MobileCaddy SDK greatly helps in supporting the app designer and developer in these areas I was keen for my talk to steer clear of becoming a sales pitch. Having spoken to Simon following the acceptance of the talk into the program he mentioned that this angle was one that led them to choosing it for inclusion. Simon and co have been extraordinarily efficient since the event too. And in speaking of them, the fabulous organisers were;

In the lead up to the event Simon made sure I had a clear timetable for submission of various steps of the talk, and I don’t know if this is the norm, but it certainly helped me avoid a “last minute rush job”.

On the day I arrived early since MobileCaddy were also gold sponsors of the event and we had a booth to set up. I’ve no idea what time Jodi and the gang had gotten there but things were already in full flow… and the first sight of the T-shirts was really exciting… it was all very real.

I had planned to get to as many talks as I could, but the flow of attendees coming over to our stand was really quite astounding, and I made it to far fewer than I had hoped. It was a genuine pleasure though to experience a real informal, community atmosphere and to have so many chats with folk who were really interested in Salesforce and intrigued to learn more about how we’ve enabled true offline mobile Salesforce apps; the entire sponsors area had a real buzz, and feedback from the other sponsors seemed to mirror mine.

booth

 

Over lunch (which was top notch, by the way) I met a fellow speaker, David Biden who was also due give his talk in one of the afternoon slots. It was almost uncanny how similar his situation was to mine; a first time talker who had planned an anecdotal style talk who was eager to avoid pimping his own company. We shared thoughts on how tough 15-20 minute talks were to plan, trying to make sure there was enough depth without getting in so deep you run out of time. His presentation covered Salesforce in the Public Sector and is definitely worth 17 minutes of your time… so go watch the video once you’re done here.

Whilst setting up for my talk the event tech-chap in my room was baffled that my laptop hooked up to the projector without issue; well that’s Ubuntu for you 😉

guide

 

The talk went well, I think. Though there were a few spare seats, but in all honesty I wasn’t surprised… the three other talks on at the same time were being run by seasoned pros, and talks that I definitely would have wanted to attend. Of course I’d love any feedback so please feel free to have a gander and let me know your thoughts.

 

There’s no way I can’t write an article on the event without mentioning Peter Coffee’s closing keynote… full of food for thought and delivered in the coolest of fashion. Again, check out the vid and enjoy.

“He has two problems.
1) He’s dead.
2) When he was alive he wasn’t scalable.”
– @petercoffee on Steve Jobs

And following that was fun and frocking at the after-party, again the community spirit was in full flow and another chance for myself and the rest of the MobileCaddy team to mingle and chat… and by the time I left I have to be honest I was a little tipsy and very tired.

In wrapping up I can only say that I’m already looking forward to next year’s London’s Calling, and of course any of the other European events that were much talked about during the day. The organisers did a grand job of supporting me, and the rest of the community made me feel very welcome.

5 Blog Posts You Should Read on London’s Calling

Written by

londons-calling-1

As proud sponsors we’re very excited that London’s Calling is now only 11 days away, so we thought we’d compile some of the best blog posts on the subject.

  1. 5 BIG reasons why attending London’s Calling will be beneficial to your career – Scott Gassmann
  2. My Top 5 Sessions At London’s Calling – Ben McCarthy
  3. The 5 Essentials You’ll Need for London’s Calling – Jodi Wagner

What? Only 3 posts?
Erm yes… but 3 “…5 etc etc” posts.

The posts are well worth a read and should help you get the most from the event.

And for those that aren’t aware of London’s Calling then where have you been? It’s Europe’s biggest Salesforce community event to date, and it should be great.

There are 4 tracks and 30 speakers, including keynotes from Erica Kuhl and Peter Coffee. Among those speaking is yours truly on behalf of MobileCaddy with a talk entitled “Only the Paranoid Mobile Apps Survive”. The talk shall cover what needs to be taken into account when embarking on a mobile transformation project for business critical applications.

But even if you’re not interested in mobile (come and talk to us… you need to be) then go grab you’re ticket now, and be a part of what’s lining up to be a fantastic event. We look forward to meeting you there.

ngCordova – Contributing a Plugin Mock with Tests

Written by

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.

ngcordova-logo

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.json, and 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 CONTRIBUTING.md on the ngCordova repo?

Salesforce Mobile SDK 4.0.0 Bug – Removing and Adding the Android Platform

Written by

During our adoption and testing of the latest version of the Salesforce Mobile SDK (v4.0.0) we noticed a bug with the behaviour when using it via the Cordova plugin for Android.

We found that if you set up the project as follows (and as per the README, but specifying the cordova-android version to 5.0.0) then all was fine.

However if for some reason you were to remove and re-add the Android platform via the following standard commands then you’re build would fail.

The following output is seen following the platform add command

And errors like this can be seen in the Messages panel when building via Android Studio

We spotted that the tools/postinstal-android.js script that is run after the platform is added moves some files relating to gradle across to the platforms directory. This is fine for the first addition of the Android platform but subsequent runs of this cannot find the source files as they were moved out of the source directory.

Pull Request 139 was created and submitted to the project and has since been merged into the master branch. The changes were to simply make the process copy the files, rather than move them.

This Salesforce Mobile SDK 4.0.0 Bug should now be fixed if installing the master branch.

London JS Meetup – Dec Review

Written by

December saw the topic of Ionic come to the London JavaScript Community meetup. It was a chance to expose the magic of Ionic to some already enthusiastic JS developers, some of whom may not have already looked at the mobile ecosystem, and some of whom perhaps had already been using other technologies to build mobile applications.

ionic-logo-horizontal-transparent

 

Meetup organiser Luca had bought in Sani Yusuf to present. Sani co-runs the Ionic UK meetup group so he was a wise choice indeed. The meetup itself was well over-subscribed on the site and it looked like the Skills Matter venue would be packed, sadly there seemed to be a lot of no-shows and I counted around 60 attendees in the end; not a poor showing, but down on what was expected.

I was joined at the meetup by one of the developers from Ceterna, one of our integration partners who build mobile Salesforce applications using MobileCaddy, and who more often than not choose Ionic as their framework of choice.

Ionic – Sani Yusuf

Starting from scratch Sani talked through the state of Mobile application development pre-Ionic; he mentioned the need to have multiple skill-sets to cover the different device OSs (IOS, Android, Windows, etc) and how this added cost and complexity to any project and organisation wanting to have apps that covered more than one target.

the-downsides-of-native

 

The needs to have two teams of devs, one objective C and one Java based, each with their own code bases… you can quickly see how having to do this can cause all sorts of an issues. This is amplified of course for any organisation (or individual) that doesn’t have the luxury of a big budget.

Native, is there an alternative – Sani Yusuf, 2015

Sani explained that with all this in mind Ionic entered the scene, answering the question “is there an alternative” with a resounding “yes”. Ionic is a JavaScript SDK that uses the Angular framework and the powers of Apache Cordova to enable developers with traditional (???) web development skills to code and build hybrid mobile apps capable of running on IOS, Android and Windows mobile devices.

The best tools are the ones that meet the developer’s needs, not ones that make them learn new stuff – Sani Yusuf, 2015

Ionic’s adoption has been truly amazing;

  • In the top 50 “most starred” github repos – currently 21,000
  • 1 million plus apps have been initially created using it.
  • v1.2.0 was released last week.

We were then given a tour around the Ionic SDK and some of it’s key features. To be honest Sani didn’t need to say anything as I’m already a big fan. It was clear though from the questions and reactions from others in the audience that they were really excited by the platform continuity and the UI elements that you get for free with Ionic. Other tools that seemed to get a good raise was the ionic serve –lab command and the Ionic Lab. The aforementioned command allows you to see what the app will look like on the different OS types, and the Ionic Lab is a GUI tool that makes project creation and management easier for those who don’t like the command line.

To be brutally honest I think that perhaps Sani went into too much depth with each feature – he covered nav, tabs, side menu, slide affect, platform continuity, collection-repeat, and many more – and his talk heavily over-ran.

We were also given a brief look into what the future holds for Ionic and how the adoption of Angular v2 and Ionic v2 will bring even more goodness to the world of mobile application development. There’s a whole wealth of improvements in both camps, and Ionic’s v2 docs are a useful place to start if you want to find out more.

Sani’s slides are available here.

Wrap up

I think Sani did a good job of covering a topic as vast as Ionic, despite my feelings that the talk was probably too long.

The venue was cool, I’d been there previously for the Chrome Dev Summit and was aware that it’s a great setup for these sorts of things.

I was obviously saddened to hear that there wasn’t any pizza or (free) beer as I’d skipped lunch in preparation… but the biggest downside to the meetup was the lack of an “after chat” and the opportunity to share ideas and experiences with the other attendees. Hopefully the next meetup will have these re-instated (please).

I’m sure, and hopeful, that Ionic will continue to gain momentum and popularity and know from experience with the apps we’ve built with MobileCaddy that the enterprise mobile space is going to love it too.

London Salesforce Dev Meetup – Nov Review

Written by

What with Dreamforce and other commitments it had been 3 months since my last Salesforce Developers meetup. With this in mind I was very keen to get back in the saddle and mingle with the cream of London’s developers. This month we were back at the MakePositive offices and myself and Justin from MobileCaddy were in attendance. The topic for the night was to be CI (Continuous Integration).

Gearset – Kevin Boyle

We had previously met Kevin at one (or maybe more) of the Salesforce World Tour events in London. It was nice to catch up with him again and see how Gearset are doing. In their own words Gearset’s “mission is to make deployment and developer collaboration on the Force.com platform ingeniously simple.”… and their talk was mostly a demo of the suite of products that they have (and hope to have).

…make deployment and developer collaboration on the Force.com platform ingeniously simple

Kev first started out giving an overview to CI, and why implementing it when working with Salesforce can be tricky if undertaking it with tooling used for other software stacks, think TravisCI etc.

Kevin from Gearset, talking about C

 

We were then given a demo of the Gearset Deploy tool and run through some of it’s features. A basic list includes Org Comparisons, dependency checking (included nested… which is very cool), history tracking and master/detail relationship support. The options of comparison has a nice touch of being able to compare not only Salesforce orgs, but also a local codebase and an org. There’s a 30 day free trial available, so why not try it out?

As for the core CI stuff, this is on their roadmap and (I think) is going to be available early in 2016. For more information check out their roadmap.

Copado – Philipp Rackwitz

I’d not heard of Copado before, and in fact I misheard the name and though that someone from Pardot was giving a talk… this definitely confused me! Thankfully I was wrong as Phil, CEO and Co-founder of Copado gave a very interesting demo of the suite of products.

With automated Apex tests, kicked off by changes to source code in bitbucket for example, and deployments including permission sets and metadata you can see quite easily how a lot of potential errors can be avoided.

philipp_Rackwitz

To be honest the list of features and options goes on-and-on… it does seem to be that Phil and his team have really thought of almost everything. They have a couple of videos over on their site so take a look.

Wrap up

Both talks and tools look incredibly useful and I certainly reckon they’re worth a look.

The venue and refreshments were as usual spot-on and appreciation should be shown to the kind folk at MakePositive as well as of course to the meetup organisers, though I think I only spotted Francis at this one.

I did note though that diversity of the attendees is hugely lacking, with ~55 folk there I only counted 3 women. The Salesforce Developers meetup has previously clashed with other meetups (e.g. Women Who Code) that are more heavily attended by ladies, so perhaps this was the case again.

Adopting the Angular Style Guide

Written by

This week we pushed a considerable update to our seed and shell apps and I thought I’d give some thoughts as to what they included, why they were done and what the future holds for them too.

For those of you that don’t know, our shell apps are repositories that can be used as starting points when first beginning the process of building mobile apps for Salesforce. They contain some skeleton code as well as the dependencies needed to install all the tooling-goodness that MobileCaddy provides to make the app building process and breeze and a joy. Our seed apps are similar, but instead of a skeleton app they are a full blown demo apps, useful if you want to quickly see an application in action.

What changed?

Well, we’d known for a while that our current shell apps could be improved when it came to scaling out to full enterprise requirements and use cases… and then we came across this John Papa talk on his Angular Style Guide that he presented at ng-conf.

This led us to his style guide over on github and this gave us a clear way forward, and we definitely recommend you give it a read.

From this list of recommendations we have picked off some of the bigger changes and they’re now in the shell and seed apps that are used by our MobileCaddy CLI tool when you start off a new project. The changes included in the lastest release are;

Why did you do this?

The style guide mentioned above does a really great job of explaining the benefits of each, but along with all of that comes the alignment to one of our favourite taglines here at MobileCaddy, an app is for life, not just for Christmas. A mobile app should be around for many, many years, delivering value to your business day-after-day; but it shouldn’t stagnate, it should evolve along with your business and it’s demands.

An app is for life, not just Christmas

The approach outlined in John Papa’s guide allows for good code management and maintainability. It means that a team of developers could be working on it at the same time. It means that a new developer, perhaps a contractor, should be able to take a look at the project and it’s structure and known where to look for relevant code and functionality relating to a change or bug. It means your application will be in the best state to facilitate updates and fixes.

And are you done?

Oh no… there are a host of other items in the guide that we want to take on too, and these should be rolling out to our public repos once tested over the coming weeks.

 

Node v5.0.0 Support

Written by

Following last night’s announcement of the release of node v5.0.0 stable release we’ve been busy making sure that you can continue to build your mobile apps for Salesforce without interruption, even if you want to move on from the current LTS (long-term support) version of node (v4.2.1).

NodeJS Logo

New Applications

If you are creating new MobileCaddy projects using our MobileCaddy CLI and you’re running node then you should have no issues at all as our Seed and Shell applications have all be updated to have (backwards) support for node v5.0.0

Existing Applications

If you already have applications built out on your local environment and you’re updating your version of node (and not using nvm to have multiple versions of node available) then you should be able to continue developing your applications without issue.

If you find you need to remove your existing projects node_modules directory structure though and then do a fresh npm install using node v5.0.0 then you will find that you’ll need to modify a few pathnames in your applications www/index.html. This change is not large and essentially is needed to remove the nested node_modules paths. For example your index.html might include this;

You should change this to be as follows to make sure the files are still found.

If you have any concerns please don’t hesitate to get in touch with us.