At Artsy, we try hard to test our iOS applications to ensure that we avoid regressions and have a clearly defined spec of how our apps should look and behave. One of the core pieces of our testing setup is FBSnapshotTestCase, a library written by Facebook to compare views at runtime with images of those views that are known to be correct. If the images differ, the test fails. We also use Travis for continuous integration.

Lately, we’ve been noticing a friction between the developers on the iOS team and the tools we’re using to test our apps: while Travis allows us to easily access the logs of test runs, it can only indicate that a snapshot test failed, not why it failed. That’s because the images that are compared are locked on Travis’ machine – we cannot access those images, so we can’t see the differences. This is really promblematic when the tests pass locally but fail only on Travis.

Read on →

Analytics are common in iOS applications. They help inform our decisions about products. Since analytics are so common, Artsy developed a library called ARAnalytics. This library provides a single interface to many different backend analytics providers, freeing developers from having to write code for each of the providers that they’re using.

Let’s consider a typical view controller on iOS. View controllers on iOS represent the glue code between models and views. When a model changes, the view controller updates the appearance of the UI. Similarly, when the UI is interacted with by the user, the view controller updates the model. This is the core of any standard iOS application.

So let’s say that a button is pressed. We’ll handle that interaction in a method called buttonWasPressed:. We’ll want to update our model, but also to track the analytics event.

- (void)buttonWasPressed:(id)sender
{
	self.model.hearted = YES;

	[ARAnalytics event:@"hearted"];
}

Simple enough, but consider that the analytics tracking code doesn’t fall within our definition of a view controller – the button handler just happens to be a convenient place to put the tracking code. Also consider that every single button handler is going to have to have similar code implemented.

There has to be a better way.

Read on →

Although some find infinite scroll to be a contentious topic at Artsy we’ve found it to be a useful element in many portions of our site such as filtering. However, we’ve run into a common and painful usability issue with infinite scroll. That is clicking on an item redirects to the next page, losing your scroll position, and losing your place when going back. To solve this we have come up with a clever little solution using an iframe.

Read on →

When I joined Artsy, dB pitched me this idea: Open source as default.

I took this to heart. I genuinely believe the idea behind the philosophy. It’s cool that our real product isn’t our implementations on the web or native but the data which powers it - the Art Genome Project. Similarly, I spend a bunch of time on open sourcing solid abstractions from our apps, always taking the opinion if something is used in more than one place, it should be open sourced.

This week I pushed some libraries that were a bit different, read on to find out why.

Read on →

I’m the kind of guy who thinks better tooling means better outcomes. But when good tooling isn’t available, it’s time to build it yourself. It’s this attitude that lead to my work on CocoaDocs.org, and then to CocoaPods.org & its documentation.

We’ve been trying to apply this to testing, and in order to pull this off I’ve had to extend Xcode to show off the results of failing tests in a more visual way. To that end, I’ve extended Xcode to show the results of failing view tests in a more visual way by building Snapshots for Xcode. Let’s go through the process of building an Xcode plugin so you can do this too. Screw stability.

Read on →

The first time I released a patch release for Artsy Folio it crashed instantly, on every install. Turns out I didn’t understand Core Data migrations, now a few years on I grok it better but I’ve still lived with the memories of that dark dark day. Because of this I’ve had an informal rule of testing migrations with all the old build of Folio using chairs the day before submitting to the app store.

This time round, I’ve made vast changes to the Core Data models but skipped the manual work. Here’s how:

Read on →

Whatever you have against monolithic architectures, at least they’re easy to test. And when those tests succeed, you can be reasonably confident the live app will work the same way.

Artsy began as one such monolithic app, but we’ve been refactoring into an ecosystem of related APIs and sites. Today, when you search for “cultural commentary” or visit Robert Longo on artsy.net, the page is rendered by a web app, sources data from an API, retrieves recommendations from a separate service, tracks trends in another, and records analytics in yet another.

This was a boost for developer productivity and scaling, but eviscerated the value of our tests. We repeatedly encountered bugs that were failings of the interaction between codebases rather than failings of individual ones. Test libraries and tools typically concern themselves with one isolated app. When you have services that consume services that consume services, those isolated tests (with their stubs of everything else) don’t necessarily reflect production’s reality.

So how should we develop our small, focused apps (or service-oriented architecture, or microservices…) with confidence? We set out to build a dedicated acceptance test suite that would run tests across multiple services, configuring and integrating them in a way that closely matches the production environment.

Read on →

We recently launched a new personalized email here at Artsy that features content that a given user might find interesting. The goal of this post is to describe how we built a backend system that efficiently generates these e-mails for all our users. I’ll talk about the first, naive implementation that had performance problems right away, and how the second implementation (currently in production) solved those issues, and whose behavior at scale is well-defined and understood. I won’t go into the details of the design and layout of the mail itself and how we render the content - there are several earlier blog posts that deal with those: Presenters and Memoization, Pinterest-style Layouts and Email Layouts and Responsiveness.

Read on →

Artsy ran several successful auctions over the past few months. The first, TWO x TWO, raised hundreds of thousands of dollars for amfAR (the AIDS Research foundation), and the Dallas Museum of Art. It was followed by Independent Curators International, at which Artsy launched on-site auction projection screens, which displayed competing bids coming in online from places around the world, like Oslo and Santa Monica, in realtime. Users could place bids on the website, via the iPhone app or with one of the Artsy representatives in the room carrying an iPad. All the auction lots sold, and Artsy helped ICI to raise 50% more than its target revenue goal. Other, recent Artsy auctions include Public Art Fund and the Brooklyn Artists Ball, benefitting the Brooklyn Museum.

The domain of auctions is a fascinating one, and includes everything from buying items on eBay to trading livestock and selling investment products on the stock exchange. For those interested in the large spectrum of auctions I highly recommend Auctions and bidding: A guide for computer scientists by Simon Parsons (CUNY), Juan A. Rodriguez-Aguilar (CSIC) and Mark Klein (MIT).

At Artsy we implemented a classic English auction with, so called, “book bids”. I spent a fair amount of time visiting engineering teams that have built internet auctions, most of which were transactional systems where taking a position on an item involved starting a transaction, running an auction round and committing the changes. In contrast, we chose to deliver a simpler, eventually consistent system on top of MongoDB, in which all data is immutable and where some level of serialization occurs within a single background process.

In this post we’ll go over some data modeling and examine the auction engine implementation details.

Read on →

Refactoring usually describes chages to code. Specifically, small changes that bring a codebase closer to the desired state. By making these changes incrementally and without modifying the end-to-end behavior, we avoid risk and the intermediate broken states that usually plague large-scale changes. But refactoring need not be limited to code. It’s also an effective way to make infrastructure improvements.

Take the most common–and simplest–example: database schema changes. Environments that demand constant uptime have long had to chunk schema changes into steps that allow for a graceful transition. In the simple case of replacing a column, this might look like:

1. Add the new column
2. Redirect code references there from the old column
3. Migrate data as necessary, and finally
4. Remove the old column

The same sequencing applies to making larger infrastructure changes gracefully. Some recent examples from our own experience:

Read on →