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.


Introducing: Ian (cycling up a hill near you)

I joined Urban Things in June to head up the Android development team, after eight years in mobile development at a cloud music provider. Prior to this, I spent fifteen years working in game development, dating back to the very first Java enabled mobile phones and various game consoles, mostly focussing on Nintendo handhelds. So it’s safe to say that the cornerstone of my career is mobile devices!

Some of the initial tasks I have been working on: a reorganisation of the code base to better support our growing suite of apps, and the production of a more modern and open source SDK to allow third parties to build against our platform.

I’m currently putting the finishing touches on a new flavour of our app which has a host of new features that we’ll be rolling out over the next couple of months. Beyond that, the future holds lots of interesting projects to get my teeth into, including a full visual redesign of our apps and a significant codebase overhaul to modernise the Android architecture. Part of this overhaul will be based around RetroFit, OkHttp, RxJava, as well as other well known libraries, and (hopefully!) a smattering of Kotlin.

Watch this space for some technical blog posts as we work through this.

I’ve joined a small but perfectly formed company at an exciting time, and look forward to seeing how we grow and progress while building new features that make it easier for the end user to get around – whether they are in New York, London or Sydney.


Ian’s 5 Favourite Things:

• My family, wife Gemma, daughter Amelie who is three going on thirteen, and dog Indy – named after the whip and fedora toting hero of course!
• Coffee, coffee, and more coffee
• Food, I love eating (and cooking) different food and cuisines
Cycle racing, this helps offset the eating…
• Technology, making phones, devices, servers and data all work together never gets boring!
• Off by one errors

Using AppleScript and Automator to resize iOS & Android assets

When creating assets for mobile apps, it can be a pain – and a time drain – to manually resize multiple images to their relevant screen density. For example: 1x, 2x, 3x in iOS or MDPI, HDPI, XHDPI etc in Android.

There are several great plugins for Photoshop that automate this process; but little in the way of Mac-specific workflows: it’s time for AppleScript and Automator to come to the rescue!

With a little experimentation, I created an AppleScript that allows you to re-size and copy an image into various asset-specific subfolders. And with Automator magic, this can make your resizing process as simple as right-clicking on a file.

5 Steps to Heaven

  1. Copy the contents of this AppleScript file to the Clipboard.
  2. Open the Automator app in Mac OS, then create a new workflow of type ‘Service’.

  3. Set the input to your Service with ‘files or folders’ and ‘Finder’ in the dropdowns.

  4. Drag the ‘Run Applescript’ action into your workflow and then paste the contents of the AppleScript file into it.

  5. Save the Service using a descriptive name such as ‘Create Mobile Assets in Folders’.

Using the AppleScript file

  1. Save your image file somewhere at x4 of full size, i.e. XXXHDPI.
  2. Right click on the image file in ‘Finder’ and choose the shiny new option that should now be in the drop-down menu.

  3. Subfolders will be created for each size ratio and the image will be copied into them.

As mentioned above, the script assumes that your image is already x4 of display size, i.e. XXXHDPI in Android terminology. If you need to change this, or customise the sizes and ratios, just edit the first two lines of the script accordingly.

I hope you find the workflow useful as it can save many hours of fiddling around!


A Possible Misuse of Confluence

Here at UrbanThings, we use Confluence to improve collaboration within the team. Confluence is great for linking JIRAs to collaborative spaces and for tracking the team’s activities between projects.

But… it turns out that it’s also useful for the far more important task of sharing reviews of restaurants with each other. A development we can entirely blame on the UberEats money bomb launch, and the ever-so-slightly possibly-connected Just Eat scratch card voucher giveaway outside Old Street station.

And in case the boss is reading this; there is an obvious business benefit to this valuable work: satisfying the team’s hunger will make us work harder! 😉

Now if only there was a free add-on to allow everyone to give marks out of ten…


K10, Japanese – “Excellent chicken gyoza”
Hungry Donkey, Greek – “fluffy tasty bread”
Homeslice, Pizza – “crispy and light dough base”
The Falafel Queen, Falafel – “falafel-tastic” (just in case you weren’t sure it was a falafel place…)
Hop, Vietnamese – “Tasty aromatic beef hotbox”