AngularZone July 2016 Meetup Review

I hadn’t been to any meetups in quite some time, but this inaugural meetup of the new AngularZone community had a lot of draw… Service Workers, D3, prizes, and more.

The meetup was organised by Gerard Sans, who has a history of speaking and organising meetups. It was held in the large hall of the Skills Matter CodeNode venue, which is a perfect venue for a meetup of a decent size.

As it was the first meetup for AngularZone, Gerard gave us a brief intro to what his view was for it. His idea is that physical meetups will take place once every two months, and have topics on web tech in general, and in particular Angular. He’d like to see talks, and a community, driven by passion. As well as the meetups and obvious greatness of tech talks he would like to see a community contribution program come into affect, where folk (including himself and Todd Motto – that guy gets around, right) can give advice as seasoned speakers and bloggers. It sounds not to far removed from his previous Angular Labs idea, though to be honest I didn’t get involved in that, so this is purely guesswork.

But anyhoo… on to the talks

Service Workers – Phil Nash

Up first was Phil Nash talking us through Service Workers. Now these are not overly new, but still very much in the early days of adoption. If you are new to Service Workers though, you can start by thinking of them an intelligent way to support offline behaviour for your web sites and apps. They’re the successor to the painful-to-understand-implement-manage app cache tech and have been greatly pushed with the current rise of the PWA (Progressive Web App).

We were, of course, shown the awesomeness that is the trailer for Service Worker, and I felt sorry for AppCache, so I put one together. I could apologise for the distracting gif, but I won’t, and I still pronounce it Gif, not Jif, deal with it.

AppCache, The Trailer
AppCache, The Trailer

At the time of wrting, Service Workers are available in the latest builds of Chrome, Firefox and Opera, and are known to be being actively worked on in Edge… and in the words of Phil, “who knows about Safari”.

We were shown some demos that Phil had been playing on thath utilised the Twillio API. His demos used various features exposed through Service Workers (offline, notifications, background sync, etc). Service Worker is a very powerful browser feature, and one I hope that will soon be adopted so I can use it in the hybrid apps we’re building at MobileCaddy.

‘Service Workers, turning “online by default” to “offline first”‘
– Phil Nash, 2016

One of the key features I see available in Service Workers over AppCache is the ability to programatically blat assets from the cache, and I can not wait to use it and say good ridance to AppCache.

Phil’s talk was really interesting and very well presented. His passion and knowledge were obvious. If you’re after his slides, they can be found here.

Using D3 with Angular2 – Ændrew Rininsland

Ændrew is a journalist/data wrangler at the FT and set off to take us through using (the bloomin’ black-magical D3.js) in Angular2 projects.

His talk started off with some comments on TypeScript and how having typed languages should catch silly bugs earlier on in a project’s lifecycle (though he also mentioned a blog post that argues that there isn’t any factual proof of this). Something that is hard to argue with about TypeScript though is the benefits of it’s self-documenting characteristic, which can only be a good thing.

“Angular devs are cooler than React devs… Just sayin'”
– Ændrew Rininsland, 2016

Before we got to any real D3, Ændrew also gave a few personal observations of ng2;

  • On a blank ng2 project – Never has he had so much code, over so many files, doing so very little
  • ng2 is really fast

Even being fairly new to ng2 myself, these points certainly ring true with me.

After much config hacking and setup, we  finally got around to seeing some D3 code, which by comparison was relatively short and straight-forward – in a “my mind can’t take in any more info” kind of way. I’m not sure if I’ll ever get over how magical D3.js is and how much sorcery their implementors use to bend it into shape, but the output of beautiful data visualisations always blows my mind.

Closing

Gerard had a few prizes to be won, which is a nice touch for a new meetup, so kudos to him. I even won a year’s JetBrains license… so even better.

Talking of free-stuff now’s a good time to thank Gerard for putting on a really interesting meet and to the sponsors (skills matter, eSynergySolutions, poncho8, JetBrains, Google Developers) for covering the venue, food, drinks and prizes.

Talks were recorded and should be up on the skills matter site in the near future.

Conditional Breakpoints in Chrome Dev Tools

I recently attended WordCamp London 2016. It was a true blast and an absolute success and really deserves its own blog post, maybe I’ll get round to writing one soon. There is a small thing I need to share sooner though, as it’s been a HUGE help to me in my dev life.

Now I’m a big fan of the developer tools available in Chrome (other browsers are available) and I knew about the ability to set breakpoints in the JavaScript that can be seen in the Sources tab. What I didn’t know though was that you could set conditions against the breakpoint, so that execution would only be paused when the conditions were met. I think it can quickly be seen how this can be incredibly useful when you’re keen on digging into particular flow of events and data through your code.

To add conditions to breakpoints the process is straightforward. Simply right click on the break point and you get the option to edit it. From here you can then add the conditions.

Screenshot of breakpoints in Chrome

Now when my code runs the breakpoint shall only be triggered once the conditions are met. In my case (see this Codepen) I wanted to only trigger my breakpoint when the el.name was the string “Flop”.

Screenshot of Triggered Conditional Breakpoint in Chrome Dev Tools

I learnt of this during an extremely enlightening talk by the wonderful, passionate Katie Fenn that covered loads of gems of information on how to make the most of the Chrome dev tools. Her slides can be found here.

Android – Getting apps to appear on the market

When I first started working on Asssist for Gingerbread Design we all knew that we wanted the app to be available across as many devices as possible. We wanted to cover devices with smaller screens and lower densities such as the HTC Wildfire as well as more advanced devices. Little did I know that being able to do this would take so much searching and trial and error.

And even after trying the app out the on the Android emulator with it’s settings to match the Wildfire (which seemed to work OK) when we came to launch the device in the Google Market it seemed that the device wasn’t being displayed to all users.

We were told our app didn't appear on the market
We were told our app didn't appear on the market

Then, after weeks of searching I came across a little gem of info (sorry can’t remember where)… all you have to do is include the following in your project’s AndroidManifest.xml file.

This seemed to work for me and I hope it does for you too.