I juggle a bunch of projects, both in Artsy and in the Open Source community. If you don’t work with me directly, you’d be mistaken for believing that I was an organized person. I’m pretty far from that, and don’t really plan on changing that.

However, I work with other people and very strongly believe that programming is mostly a social problem once you’re good enough at writing code. It’d be hypocritical of me to not improve the people process side, so I try to automate processes that makes me a better team-mate.

I’m going to cover four things I’ve worked on lately to improve this: Danger, GitHub-Clippers and improving how I write commits and prefixing my name on branches.

Read on →

We are slowly trying to do high-level code-review views for all of our iOS apps. So far, we’ve covered Eidolon and Emergence and now Energy. This is the second part of the Energy code review. The first part covers the the critical codepaths that go from the App’s launch to sending an email, which is the main use-case for the app. This video covers how Folio does sync between the Artsy API and the app.

Sync is a complex problem. This video covers our old techniques, how we changed them, the underlying abstractions we use now and how we can test each component individually. It’s an hour long, and it’s a little computer-sciencey. So I think people who have shipped some small apps would get a lot out of it.

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

Read on →

We are slowly trying to do high-level code-review views for all of our iOS apps. So far, we’ve covered Eidolon and Emergence. Folio is an app that’s shipped to the App Store in early 2012, it’s used by our Partners to showcase their works offline, at fairs and on the go. If you want the full spiel, check out this microsite.

This video talks through a lot of the critical codepaths that go from the App’s launch to sending an email, which is the main use-case for the app. We have another video coming up which exclusively covers how Folio does sync between the Artsy API and the app.

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

Read on →

When I was at the beginning of my career, my first developer job application was to a design agency who were doing Mac development too. It was pretty nerve-wracking to apply for my first programming job, and I came into the interview with no idea what to expect. I had just graduated from university and was at the first few steps of my career, I’d call this being a junior. It was a time period where I would need mentoring, and supervision in order to grow. A good explanation is in this StackOverflow.

Now that I’m both further on in my career, and involved with so many juniors in NYC, I’m meeting with a lot of people who are in the same position I was then and I get a lot of questions asking what they can do to prepare. This post attempts at being a comprehensive collection of recommendations. It is subjective, of course, and strongly biased towards my experiences.

Before I jump through to the article, there’s one thing that should be above the fold. Chill out. You might not get it right on the first try, I’ve applied for jobs and received a “no thanks.” Yet eventually I became the head of mobile at Artsy. Everyone finds their place in time.

Read on →

While the Artsy engineering team includes many disciplines, tech stacks, and personalities, we all share a few things in common: a respect for each other, an appreciation of art-meets-science, and a celebration of learning. These are actually traits shared with our entire company, even non-engineers. So last Summer when Orta and I had some down time, it occurred to us how we could do something super-productive that was congruent with our values: we could teach the company Swift.

Read on →

The Artsy engineering team has been moving towards Open Source by Default. In 2015 the Mobile team managed to get there. Since then, we’ve been writing up our process on this blog and offering advice to anyone would would ask for it.

I’ve been in talks with lots of companies you’ve heard of, on the how and the why of this. Recently Ello got in touch, and we tried to capture the process. They came out with a great post that I’d strongly recommend reading. I’d like to try and come from the other side, and address what are the questions people ask. Consider this a FAQ for how the mobile team does/got to OSS by default.

Read on →

Artsy’s Platform engineering team is responsible for much of our shared infrastructure and services. Some of that responsibility is naturally focused on the very near term, such as diagnosing service interruptions and fixing bugs. However, we must regularly balance that with more long-term-focused work such as evaluating new technologies, paying off technical debt, and devising foundational improvements to our platform.

This is a tricky balance! Near-term work is appealing. It’s well-understood, more easily scoped, and often promises a satisfying “quick fix.” Sometimes, there’s even a customer (internal or external) eagerly awaiting the result. We recently introduced “Future Fridays” to help dedicate time to longer-term, open-ended work despite these urgent temptations.

Read on →

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 →