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 →

Prior to starting at Artsy, I followed a few online tutorials on iOS development. But a simple application demonstrating how to build a todo list didn’t illustrate the nuances of a production codebase. Tutorials are an important learning tool for beginners, but can’t possibly prepare you for everything you would encounter within an application like Artsy’s.

I was lucky to have a mentor at Artsy to help me get started, and I wrote this post to pass along the lessons I learned. This is meant to be a guide for iOS beginners to get to know an open source production codebase. I’ll cover the Xcode project organization and where to find things.

Read on →

It was 95 days ago, and I was sitting before of my computer in NYC. I loaded my terminal, opened TapTalk on my phone, tapped on my colleague Ash’s avatar and held my finger there. I paused, this moment was a long time, it was worth waiting. I switched the camera from my face to the screen with the terminal open.

This moment was probably the most nervous I had been in years. It showed git push origin master. I said “it’s happening.” I hit return. A new era in the Artsy mobile team had started. A few minutes later, I wrote this tweet:

Let’s go over the process we went through to get to that point.

Read on →

Obtaining, reissuing and installing SSL certificates across various pieces of Artsy infrastructure (read about our tech stack here) is a mind-numbing excercise dreaded by every platform engineer. Few people really understand what’s going on, installing SSL certificates is right up there in the opaque world of user-unfriendliness, along with onboarding a new iOS developer in an organization with Xcode.

Still, it can be done - below is our cookbook.

Read on →

We recently picked up a Rails application that was a few features away from completion. This application allows our Genome Team to classify multiple artworks based on visual and art historical characteristics. These characteristics, or “genes”, can be added, removed, and changed for any of the artworks on the panel.

Our genomers are masters of efficiency, and over the years we have worked closely with them to tailor a dynamic interface to their specific workflow.

When we started working on the app, the back-end was organized, modular, and interfaced seamlessly with the Artsy API, but there were still a few front-end features we needed to implement before it could be used by the Genome Team. The app did not use a front-end framework, and as our features scaled it was difficult to keep track of UI state with pure CoffeeScript and global event listeners. Eventually, we decided to stop trying to patch our leaky roof and build a new one.

Read on →

Fair compensation is an important part of cultivating and growing engineers, and determining how much money someone is going to make is often more art than science, especially in young start-ups. We wanted this to be a collaborative process and not an adversarial one, and as our engineering team grew past 20 members it became important to think about compensation more systematically.

In this post I will share our individual contributor engineering ladder and our performance evaluation and compensation process.

Read on →

Recently, the Artsy Mobile team had the pleasure of working together on an article for objc.io, an online publication dedicated to in-depth articles about iOS and OS X development. Each monthly issue consists of several articles centered around a theme—past issues include Testing, Animations and Swift. objc.io’s latest issue, iOS at Scale, features articles by a handful of developers about how they approach iOS development at their respective companies. Our contribution to the issue is a collaboratively-written article by and about Artsy’s Mobile team from the angle of Artsy’s focus on the core value of openness that is foundational to how we (and the greater Artsy team) work.

As our article puts it:

Our team intrinsically believes in the ideas of open source. Though our individual motivations vary — from a conviction in the power of education to a determination to help others see from giants’ shoulders — we all maintain the value of open source.

iOS at Artsy is characterized by a culture of open source stewardship. Although our team is small, our contributions to the Cocoa developer community are significant. We hope our article sheds some light on our development and testing practices while also providing a high-level look into our team’s philosophy. If you’d like to learn more, feel free to reach out to us at mobile@artsy.net or @ArtsyOpenSource.

Artsy has now grown past 100 team members and our Engineering organization is now 20 strong. For a brief overview of what the company has accomplished in the last two years, check out our 2013 and 2014 reviews.

This is a good opportunity to describe our updated technology stack. Last time we did this was when Artsy launched publicly in 2012.

Three years ago Artsy was a classic Ruby-on-Rails monolith with a handful of adjacent processes and tools. We’ve since broken it up into many independent services, and continue to heavily be a Ruby and JavaScript shop, using Rails where appropriate, with native code on mobile devices and some JVM-based experiments in micro-services.

Read on →

We built CocoaPods-Keys as a way to remove API keys and secrets from our source code. We use it to open up our code to the public, without leaking private details. One of the cool things about doing it this way was that we could all use different API keys stashed away in each developers Keychain.

To ensure we could run CI on our apps we came up with two different ways to use keys on CI. This post explains them both.

Read on →

As I mentioned in my retrospective on Eidolon, Artsy iOS codebases are often used as testbeds for new CocoaPods features. With Eidolon, we had the opportunity to try out CocoaPods’ support for frameworks and Swift. This post is a look back at the month of using dependencies as dynamic frameworks instead of static libraries.

Read on →