The #makebristolmobile hackathon: What went down

Our 4th hackathon co-hosted with Bristol City Council was a success! Read all about some of the great ideas our hackers came up with.


First things first, a huge thank you to OVO Energy for hosting us at their beautiful HQ, to Bristol City Council for running proceedings with us and, of course, everyone who turned up on the day to put their app-making skills to the test.

Four teams of developers, designers and hobbyists put their heads together to come up with creative and practical solutions to issues faced by sustainable transport in the area. They had access to The Bristol API and our brand new iOS and Android SDKs, the rest was up to their imagination.

A day’s worth of pizza and beer later and it’s our pleasure to show off what they built.

Continue reading “The #makebristolmobile hackathon: What went down”

UrbanThings @ SwiftSummit 2016

Firsts – SwiftSummit 2016 – Uber – AirBnb

UrbanThings Head of Mobile, Mark Woollard, headed to San Francisco to discover cutting-edge solutions using the Swift Programming language. He shares the highs and lows of his experience – and how a conversation over pastries brought him face-to-face with a coding idol.



A few months ago, I was offered the chance to attend this year’s SwiftSummit in San Francisco and, after some consideration, decided that getting on for 24 hours travelling time from and back to the UK was worth the experience of joining the premier annual conference for the Swift programming language.

So, to my other firsts, as someone who lives outside London and gets around using my own car and uses train / tube / hire cycles in London I’d yet to try out Uber. I decided I should find out what it’s all about and use it for appropriate legs of the trip.

I’d also yet to use AirBnb so, in an effort to discover some of these disruptive services, booked accommodation in San Francisco with a certain ‘Trish’ via AirBnb having checked out type of accommodation, reviews, location and price.

More on these at the end, but let’s turn to the conference itself…

Continue reading “UrbanThings @ SwiftSummit 2016”

Continuous Integration for .Net with Jenkins and NuGet

UrbanThings Head of Platforms, David Else, discusses the challenges of managing internal .Net dependencies and how we’ve created a robust and performant solution to address this.

Many of our platforms here at UrbanThings are built using Microsoft .Net, project dependencies are managed through the use of NuGet packages, and we manage both internal and external packages in the same way. Re-usable, shared components are built into NuGet packages and uploaded to our internal NuGet server, which allows us to easily manage project dependencies, and limit the impact of changes to library code.

One of the major drawbacks to this process occurs when developing locally: when changes need to be made to the shared libraries a developer would need to make their modifications, manually build the libraries, package them, and copy them up to the NuGet server. If further modifications need to be made, this process has to be repeated. This can stifle a developer’s productivity, since they end up spending a lot of time building and packaging libraries instead of writing code.

To solve this problem, we have automated our build processes so that libraries are automatically built, packaged and uploaded to the NuGet server as soon as changes are committed. No more manual updates!

Jenkins is our continuous integration server of choice, mainly because it is very extensible through plugins, and has good coverage of multiple platforms, including .Net, Android and iOS. Using the Multi-Branch Pipeline plugin, Jenkins automatically picks up new branches as they are created within our git repositories, and automatically builds the projects when code is pushed.

The build process goes through a number of steps:

  1. NuGet packages are restored to ensure we have all of the relevant dependencies
  2. The projects are built
  3. Unit tests are run and the results collected
  4. Libraries are packaged
  5. Results are published

The packages are then published to the NuGet server where we have a special feed for development and pre-release packages, plus a production feed which only includes released packages. Any non-NuGet package results are uploaded to Amazon S3, where they are made available for deployment to development, test and production environments. We are also notified via Slack notifications of build completions and failures, so we can quickly and easily react to any issues during the build process.

It now only takes seconds to have code updates included in a library and made available on the NuGet server, and in order to avoid clashing with other developers’ work, the packages are versioned based on the git branch. As well as making our development more productive, this process also encourages developers to use appropriate git-flow feature branches for their work, and encourages them to check in more often.