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.
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).
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.
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.
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.
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:
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 …”
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.
Artsy practices a sort of continuous delivery. We keep release cycles short and the process of reviewing, testing, and deploying our software as reliable, fast, and automated as possible. (This blog has touched on these practices multiple times.)
Usually, commits that have been reviewed and merged are immediately built and tested. Successfully built versions of the codebase are often automatically deployed to a staging environment. On an automated or frequent-but-manual basis, that version is deployed to a production environment. Thus, commits form a pipeline:
The number of apps and services we deploy has grown to dozens per team, so sometimes things fall through the cracks. We’ve been using Releasecop for the last few months to get gentle email reminders when an environment could use a deploy.