The Bristol API

Bristol wants to become a “programmable city” and right at the end of last year Bristol City Council unveiled The Bristol API. Let’s take a look…

Bristol programmable city

The Bristol API

In 2015 Bristol City Council’s City Innovation team appointed the London-based software company Urban Things to build an API to give developers access to transport data for Bristol in real time (plus some other nice features like route planning).

It looks like a dig at the council to mention that the company hired to do this was a London company when I’m sure there are plenty of companies in Bristol that could have delivered this but actually Urban Things already have good experience and an established platform for managing bus data so hopefully BCC got a good price with our tax money because of that!

And, dear citizen, you can get access to the Bristol API here for free so don’t say the council never give you anything back!

…click here to read the rest…

Bristol Exercise Insights from the Strava Global Heatmap?

Strava, a popular GPS run / ride tracking app, have compiled their data into a beautiful Global Heatmap showing the preferred paths of runners and cyclists around the world.

I, of course, have been taking a zoomed in look at Bristol to see what we can learn.

Here are the cycling and running GPS tracks through central Bristol. Single tracks are thin blue lines then as more tracks stack up on a route you get a thicker blue line and then a red thick line for the most common routes.


Strava Bristol Bikes


Strava Bristol Runners

Here are some interesting features I found:
…click here to read the rest…

Which generation is winning on income? – data insights from the Guardian

Some really interesting data visualisations from the Guardian in their article here that’s part of their series on millenials.

You can enter your age and country and it will tell you on average whether you’re better or worse off than your equivalents in the past and in different countries.

Helpfully they also take that 2d matrix of combinations and plot all the possibilities in a single view like the below which really neatly gives you the full overview in a single screen-sized chunk. Each plot represents income (or possibly disposable income – it’s not clear from the site) from 1979 to 2010 with green representing groups that are now better off and purple those that are now worse off.

disposable income by age and country

It’s a shame the data doesn’t extend to 2016. It’s a really interesting view on some of the real effects of recent economic events across the globe and how their impacts are shared across different age-groups in the same society (spoiler alert: they’re not shared evenly!).

In only one country are under-30s better off now than they were in 1979. That’s crazy!
In the UK particularly, things have been getting a lot worse for under-30s and a lot better for the over-60s. Maybe the state pension pot should be going to help the young rather than the old!
Something’s not right but maybe it’s down to that age-old problem – young people don’t vote, older people do.

Playing with Fire(base) – Three Way Data Binding

I’ve been playing with Angular and Firebase over the last few days. But it sounds better the other way round. I remember one of my school teachers getting angry with some other kid being naughty and shouting “you are playing with fire!”. Except the teacher was German so it was “you are playing wiz fire!”. We used to shout that at each other for a while after that. Kids, eh?

Anyway, one of the core principles in Angular is two-way data binding between the model and the view (in your MVC structure). The user changes the data in the view, it gets changed in the model. Some code changes the data in the model, it gets changed in the view. It’s pretty neat in practice and makes pages feel really dynamic as you interact with them.

So that’s two-way data binding but what if you could go another layer down and bind that to your database as well and have all three update whenever any one of them is changed? Well that’s what Firebase allows you to do through the AngularFire library. You just bind your model to a Firebase object and you get this:

three way data binding

(Normal Angular data binding is the bit within the browser window frame)

…click here to read the rest…

Minimum Viable Product vs Cutting a Slice

“Minimum Viable Product” or MVP should be pretty familiar to anyone who’s been keeping an eye on the developments in business and software development practices over the last few years, particularly in Silicon Valley and the lean startup movement. If you spend any time on Medium, you’ve probably read an article with a title like “7 Ways to Minimum Viable Product your Life in Just 30 Days”. In fact, I might go ahead and write that article!

Minimum Viable Product

But I digress. When I started talking about minimum viable products with some of my coworkers that are not developers, I did find that many weren’t aware of the concept so briefly the aim with a minimum viable product is to get as quickly and cheaply as possible to the most basic version of your product and get feedback on its value, flaws, potential improvements, etc before spending the time and money required to build a full-featured product. A sort of rapid prototyping (but may not even be a prototype!) Or, to quote Eric Ries:

The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

…click here to read the rest…

Implementing Roles in Firebase

Roles in Firebase

Firebase provides a JSON-based language for us to restrict different parts of a back-end database to different users based on their auth token id (auth.uid).

That’s handy enough for restricting a user to only be able to see their data but what if you want to assign some roles to distinguish between user types and give those roles different permission levels throughout your Firebase database?

Well, that’s something I’ve been flirting with over the last couple of days with some limited success but today I stumbled on a project built by Firebase themselves called Firechat and I just wanted to draw people’s attention to it as it has a pretty useful rules.json file that gives a good example of how to implement read and write permissions at different levels of the database tree.

I don’t really like that the default permissions in Firebase are read and write on everything. I do like that in this example they are both set to false for everything and then you have to explicitly set how you want to handle permissions for everything down the chain.

So in this example we’re looking at chat rooms which have users and moderators. Here’s the rules file on Github:

And here’s the Firechat app in action:

It’s pretty useful to see a full app built by the Firebase developers to get some insight into how they use it and/or expect it to be used. I think this is a better example to work from than the Gist here which comes high in Google at the moment.

…click here to read the rest…

Playing with Fire(base) – Preamble

Firebase wants to take the headache out of building full-stack JavaScript apps (and mobile) by taking care of your back-end and authentication for you.

But first a little background…

When I first got into the idea of full-stack Javascript about 6 months ago, my first step was to start playing around with Node.js and then Angular trying to connect the two but I quickly became frustrated with every step requiring me to learn some new component that would make my life easier (Bower, Gulp, Grunt, Sass, etc) but only after I’d got up the learning curve. Each time becoming another step removed from just writing some code of my own.

In the end I put it all to one side and just focussed on building an entirely front-end single page app (SPA) in pure Angular so that I could learn some of the principles without the clutter and confusion of working out what was doing what. Fortunately I’d chosen a little toy project that didn’t require me to build a back-end as I was building on top of Spotify’s API –

Anyway, at that time I did look into a couple of Backend-as-a-Service (BaaS) providers, including Parse, whom I see today are shutting down their service and releasing some of their code into the wild for people to use on their own servers. A shame for them – the absence of reasons in their statement I suspect means it’s down to not being able to sufficiently monetise their product. I guess the BaaS area will become commoditised pretty soon with Google, Amazon and others fighting to be the Supreme Cloud.

One thing that might help Google with that is their acquisition in 2014 of Firebase which is really what I’d planned to write about but maybe I’ll just leave this post here as a thought on getting started in full-stack JavaScript (too many things you might or might not have to learn) and on the future on BaaS (probably a race to the bottom on pricing which will be won by the players that can afford to make a loss until hardware costs catch up with their low prices and until after the competition are gone).