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:

• From developers’ working branches
• To the master branch
• Through a hopefully-successful build
• To a staging environment
• To production

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.

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 patterns that we’ve had and migrated away from. This is not 100% comprehensive, as there has been a lot of time, and a lot of people involved. Instead I’m going to try and give a birds eye view, and zoom in on some things that feel more important overall.

It’s important to preface that I don’t believe in perfect code, or am I a fan of big re-writes. We can spot a bad pattern, but not do anything about it. We do have apps to ship, not a codebase to make perfect for the sake of technical purity.

Read on →

On Tuesday at our mobile practice standup, I mentioned that I was in-between projects and looking for something to do. Orta suggested migrating Eidolon, the Artsy bidding kiosk app, to Swift 2.

Our CI is broken anyway, so now is the perfect opportunity to make changes that would break CI. Additionally, Swift 2 seems to have more-or-less stabilized in the latest betas, so we don’t expect many gotchas leading up to the GM. Finally, this is an enterprise-distributed app, so we don’t have to worry about submitting to the App Store using betas of Xcode.

So Swift 2 it is!

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 Hybrid Applications. A hybrid application refers to an app that uses native code and web content intertwined. Our flagship iOS app, eigen is a hybrid app, and it seems to get more and more hybrid-y each release. Let’s talk a little bit about the pros and cons of this approach.

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 introduce the Switchboard pattern. This evolved quite naturally out of ARRouter when applied to generating view controllers instead of API requests.

Read on →

I want to talk about a pattern that we’ve been using for the last few years on the Artsy Mobile team. This pattern pre-dates me joining Artsy by a few weeks, and was introduced into our codebase by Ben Jackson, this was the ARRouter’s first method:

  + (NSURL *)newOAuthURLWithUsername:(NSString *)username password:(NSString *)password {
      NSDictionary *params = [[NSDictionary alloc] initWithObjectsAndKeys:
                              username, @"email",
                              password, @"password",
                              ARAuthClientID, @"client_id",
                              ARAuthSecret, @"client_secret",
                              @"credentials", @"grant_type",
                              nil];
      NSString *url_string = [[NSString alloc] initWithFormat:@"%@%@", AROAuthURL, [params queryString]];
      NSURL *url = [ARRouter newURLWithPath:url_string];
      [url_string release];
      [params release];
      return url;
  }

Yep, that’s pre-ARC, pre-Dictionary Literals, memory-managed code. We took this pattern and rolled with it for the next 4 years, this article is about where we’ve taken it.

Within Eigen, ARRouter is one of our biggest classes, coming in at almost 1,000 lines of code. Whereas in Energy, it sits at a more reasonable 300 lines. Eidolon does not have an ARRouter, what gives?

Read on →

When I was living in Amsterdam, I participated in plenty of Appsterdam events. Things like the weekly Meeten en Drinken. I even helped lead a class in Swift. One of the events I liked the most was called Peer Lab, organized every Saturday morning by Samuel Goodwin.

The idea of Peer Lab is pretty simple, but also somewhat profound: developers gather in a physical space to work on things. If someone has a question, they ask the group. If you can help, you offer assistance. The goal is to foster a collaborative learning environment where everyone feels fulfilled.

Read on →

The Artsy Mobile team is pretty aggressive in our stance on Open Source by Default. We’ve talked about it at conferences around the world, in renowned magazines and on our blog.

It’s worth mentioning that we don’t just talk externally about Open Source. Internally, the Mobile team runs talks about Open Source for the rest of the Artsy staff. As well, we discuss the tooling and business implications of having our work in public repos. Artsy strives for an open culture, in this case the development team, on the whole, is just further along in the process.

The Open Source app idea started with an experiment in the Summer of 2014, asking, “What does a truly Open Source App look like?” The outcome of that was our Swift Kiosk app, Eidolon. Open from day one. We took the knowledge from that and applied it to our public facing app, Eigen. Open from day 806. That made 2/3rds of our apps Open Source.

I’m going to talk about our final app, Energy. Open from day 1433 and ~3500 commits.

Read on →

When the odds are stacked against you, your mind is overflowing, and you are ready to just pop, there’s always practical debugging tips to help you through a cloudy day.

In this post I’ll take you through a debugging session where I reproduce a crash, for which we were receiving a bunch of crash reports, but I was unable to reproduce by just using the application.

It will cover the following topics:

• Narrow down the breakpoint to the method invocation where the crash occurs.
• Locate the exact instruction that causes the crash.
• Look at the implementation of the method where the crash occurs.
• Simulate the crash.

Read on →

To a beginner, OCMock looks scary. The syntax is strange, the idea of stubbing seems complicated, and skirting around the need to use it at all times kind of works out for a while.

[[[mock stub] // three brackets!!

[OCMockObject niceMockForClass:UINavigationItem.class]; // it has to be told to be nice?

All of this can be overwhelming for someone who just wants to write simple unit tests for a particular view controller.

Once you look into the specifics of OCMock, however, things get less terrifying really quickly. It is helpful to compare OCMock’s approach to stubbing to the behaviors of certain bird species. As always, the soothing voice of David Attenborough brings clarity and joy to even the most mundane puzzles of life’s journey.

Read on →