Monday just gone saw the return of the AngularJS meetups to London, and this time I was trigger-happy enough to manage to bag myself a spot. The meetup, as usual, was over subscribed, and with a 300 capacity it’s one of the most well-attended meetups that we currently attend.
This event was hosted at the pretty fantastic Bloomberg offices in Central London, and I really wish I hadn’t eaten earlier on that day as the free grub and drink was top-notch. In writing this I note that I always mention the food and drink at meetups… I hope this doesn’t distract too much.
Anyhoo, big thanks to Bloomberg for the great facilities and what-not.
Nifty SHAs of Code – Peter Bacon Darwin
The headline talk was ingeniously titled Nifty SHAs of Code and was presented by none-other than Peter Bacon Darwin, lead developer for Angular JS 1.x, and someone who is personally admired. The talk’s focus point was really around how users of Open Source projects can help the projects along through getting involved, even if it’s just writing better issue tickets. Now I say just here, but really a good issue ticket is worth it’s wait in gold.
The presentation took the form of a story through one application’s upgrade process from Angular 1.3 to 1.4. Along the way the app broke and Peter showed us how a ticket could be raised and how a PR could even be put together and submitted. The general gist was that contributing to a project – even one as vast and highly used as Angular – shouldn’t be seen as a daunting task.
No more shrug reports
When raising a ticket it’s best to cover as many details as possible. Detailing the scenario that the bug was seen in, as well as expected behaviour and environment details (such as browser versions, library versions) can really help. I know that from my time at previous development roles I’d be more than happy to reject any ticket that lacked the fundamental details needed to assist me.
I’d reject any ticket that lacked the fundamental details
Peter showed us some examples of brilliant issue tickets… check this one out, it’s a belter.
The next step
We then moved onto debugging, fixing and testing the bug and a fix for it. Again, this shouldn’t be seen as something that only immortals should do. In fact Angular, and a lot of projects offer some great guidance on how to contribute to such projects.
Peter’s slides can be found here.
Lightening Talks
The evening continued with a round of lightening talks. These were shorter presentations of about 10 minutes that covered some small piece of tech or project.
Doug McIvor – Data Explorer
Doug, who works for Bloomberg showed off an internal project that essentially formed a fully dynamic spreadsheet-style app that pulls in data from over 200 tables and 2000 fields. The idea being that anyone of Bloomberg’s data sources could be compared and analysed alongside each other.
The app was, of course, built in Angular but the core focus of the talk was on how the app was optimised for speed. He detailed how the app dynamically bought in chunks of data into the DOM and then replaced those as the user scrolled both horizontally and vertically. I’d seen this approach several times before, the first being in my early days of Android development and more lately in the implementation of the wonderful collection-repeat directive the Ionic folk have put together. The idea being that the number of DOM elements is reduced such that there are only just enough to cover those in view and a buffer outside, then these are updated and replaced as the user scrolls around.
Michael Watson – SVG
Michael took us on a brief tour of the SVG element, and how it is something to be embraced. The talk was short but to the point and he showed us how SVG attributes can be bound from Angular scope variables, and as such can become pragmatically created and modified.
SVGs… start using them
Michael’s project can be found on github
Svilen Gospodinov – $http Caching
Svilen, who works for Skimlinks had the graveyard shift for the meet-up, but this didn’t get in the way of him passionately talking through some of the details relating to the built in caching available in the $http service.
He talked us through a few examples using the cacheFactory including how to set cache limits, set defaults and the likes.
The topic has lots of syntactic detail, so I’d rather not just regurgitate it here. Instead Svilen’s slides can be found here.
I’ve not yet had to use the $http service as within the MobileCaddy architecture we assume offline as our default state, and our API calls handle all caching for the developer. With that in mind as well as advising you took a look at the docs I should probably do the same. If you’re interested in our MOREs design for mobile applications then take a look at this short article.