I’ve been a really strong supporter of the fastlane toolset. I think it fixes a lot of common developer problems, in a space that Apple doesn’t really touch. The command line.

We’ve added hints of fastlane to our apps at different rates, Eidolon uses fastlane for everything but Eigen/Energy/Emergence have been pretty slow on the uptake, though they have more complicated setups, being App Store apps.

When Felix announced match this week, I felt like he tackled a problem we face in our small dev team. I integrated this, only to find that it could also fix my problems with deployment. The rest of this post goes into the “how I did this.” You can also cheat and look at the commits directly.

Read on →

As a part of our internal Lunch and Learn series, I gave a talk to our developers with an overview of the different types of source code licenses available.

We always recommend MIT within Artsy, but understanding what the other ones are and why we made the choices we have done is valuable.

Jump to YouTube for the video, or click more for a smaller inline preview, as well as all of the speakers notes.

Read on →

When I first proposed using Docker for development, and began doing my work that way, there were some doubts.

• Doesn’t it seem like a lot of trouble to set up Docker to get my work done?
• Isn’t it easier to use Homebrew to install the services and database servers I need?

Read on →

When we built Eidolon last year, Swift was still pre-1.0 and we couldn’t rely on the wide variety of available Swift libraries we enjoy today. I wanted to build it using functional reactive programming, because that’s how I believe everyone should write software, but there were no Swift-based FRP libraries at the time. As a compromise, I used ReactiveCocoa’s Objective-C API (the Swift API was months away from an alpha).

Read on →

For a little while, we would get very strange bug reports. People would complain that artist thumbnails (viewed in several different contexts across the web and our iOS apps) would not be an image of the artist’s work, but rather text, which had inexplicably become an actual JPG. This wasn’t just text appearing in a div that should contain an img or something like that, these were actual JPG’s that were pictures of text.

We would fix these as they came up, chalking the strangeness up to some relic of an old image processing pipeline, data being migrated, etc.

However, the reports kept coming in. This blog post is about how we diagnosed this actual bug, and how we used a simple Ruby script and OCR to help us detect and fix the existing images.

Read on →

We released the fourth app from the mobile team, Emergence, on day one for the new Apple TV and are currently getting around 2k downloads a day. The codebase was created by a single developer, and we didn’t want to keep that knowledge siloed. So, I ran an hour long code review session last night where I talked through the codebase, explained why some decisions were made and about the differences between tvOS and UIKit.

Given that I had been asked to write a blog post about tvOS in general, I felt that making the code review public for anyone to watch would be a nice alternative to the usual long-form writing on this blog.

Jump to YouTube for the video, or click more for a smaller inline preview.

Read on →

Want to know what I love writing in a pull request? Sorry this is such a big PR, but I was working offline… It is one of the key reasons I managed to get our Artsy Shows TV app released ahead of schedule with a looming unknown App Store deadline. Offering more time for polish like thumbnail image pre-caching.

During the last week before shipping I was scheduled to get a H1B VISA stamp for my passport, which means a trip to London. London is basically a million miles away from where I occasionally live in Huddersfield. So I opted for a coach. On the 5 and a half hours of travel, I had gone from behind schedule to feature complete prototype. On the way back, I had started to remove the word prototype from what we were looking at.

I always optimise to work offline on every iOS project. Here’s some tips on how we do it in all our apps.

Read on →

A while back, we wrote about How to Run RSpec Test Suites in Parallel with Jenkins CI Build Flow. A version of that still handles our largest test suite, but over time the initial division of specs became unbalanced. We ended up with some tasks that took twice as long as others. Even worse, in an attempt to rebalance task times, we ended up with awkward file patterns like 'spec/api/**/[a-m]*_spec.rb'.

To keep our parallel spec tasks approximately equal in size and to support arbitrary concurrency, we’ve added a new spec:sliced task:

Read on →

Model View ViewModel has become the default way I write apps on iOS – it makes writing iOS apps a joy. I’ve written about it again and again and oh my.

But last Autumn, as our team was all-hands-on-deck to wrap up the auctions kiosk app, we chose not to use MVVM. Why not?

We were building a new app in a new language using a non-Swift framework for functional reactive programming. I was also teaching colleagues what they needed to know about ReactiveCocoa to help write the app. We used the MVC pattern because the relative cost of MVVM was too high.

“… was …”

Read on →

As a part of going through the design patterns we’ve found in the creation of the Artsy iOS apps, I’d like to talk a bit about some of the way in which we decide our apps dependencies.

It’s easy to think of your dependencies as being things in your Podfile, but it’s a bit more nuanced than that. The tools you use for development, deployment, testing and external integrations are all things in which you depend on others to make your app work. I’d like to look into the hows and the whys of the decisions we’ve made.

Read on →