When we talk about our React Native setup in abstract, there are two kinds of “now draw The Tick” for iOS developers:

• How do I build this React Native as a CocoaPods setup?
• How do I get all the JavaScript tooling setup up?

We’re going to address the first part in this post. By the end of this post we’re going to get an Emission-like repo set up for an existing OSS Swift iOS app called GitHawk. The aim being to introduce no JavaScript tooling into GitHawk itself, and to only expose iOS-native UIViewControllers via a CocoaPod which is consumed by GitHawk.

To do this we’re going to use the CocoaPods’ pod lib create template, and React Native’s react-native init to make a self-contained React Native repo. It will export a JS file, and some native code which Podspec will reference. This keeps the tooling complexity for iOS and React Native separate. Read on to start digging in.

Read on →

In 2017, Apple released ARKit to universal acclaim. It’s a solid foundation for application developers to build Augmented Reality (AR) experiences without learning a whole new skillset in computer vision. Like a lot of Apple’s technology, it’s a clever blend of existing projects: SceneKit, CoreMotion, CoreML and some very clever camera work. From the developer’s perspective, ARKit has an API which fits perfectly with the rest of Apple’s APIs. You spend most of your time working with a few delegate functions and you’re good to go.

For the last 2 months, I’ve been working with ARKit on a replacement for our View in Room feature on modern iOS devices to support a “View in My Room”. I’m going to try cover how we approached the project, the abstractions we created and give you a run through of how it works.

We believe that our implementation is a solid improvement over similar features in other apps that allow users to place artworks on walls, and we’re making the source code available free and open-source under the MIT license.

Read on →

@alloy first mentioned React Native as an option for Artsy back in March 2015, and in February 2016 he made our first commit to get the ball rolling. Since then, we’ve grown a new codebase, Emission, which has slowly taken over the responsibility for creating the UIViewControllers presented inside our iOS app.

We’ve come quite far from where we started, and I was asked if I could give a talk to summerize what we’ve learned in the last 2 years as a set of native developers using React Native.

The slides are on speakerdeck, and I’ve opened comments for this post if people have questions. Jump through to get to the video or watch it on Prolific’s site for iOSoho.

Read on →

On the engineering team at Artsy, we’ve built a CMS for both internal and external editors to write and publish articles. We have a team of a dozen in-house editors creating new content on a daily basis. As many people starting using the app simultaneously, something became apparent. Editors would unintentionally go and override each other’s work because there was no way to tell if someone else was currently editing an article. As a workaround, team members would be forced to edit drafts in another editor such as google docs and copy their work over once ready. This made for a lackluster collaborative experience.

So we decided to implement a system that would make our editors more confident in our CMS by ensuring only one editor could go in and edit an article at any given time. I was tasked with coming up with an elegant technical solution for this feature. Here’s the approach I took….

Read on →

We’ve previously covered what Apogee is and how it’s deployed, so all that’s left to cover is the technology used to build it. As a refresher: Apogee is a Google Sheets Add-on we built to help our Auctions Ops team transform the data given to us by our partners into a format that our CMS can understand. This process, done manually up until now, takes a long time and is a perfect candidate for automation.

Apogee had some really interesting technical challenges that I enjoyed solving, and I’m excited to share some lessons I learned. So let’s dive in!

Read on →

Apogee: the point in the orbit of two objects at which they are furthest apart.

In 2017, the Artsy Auctions Operations team coordinated and ran 190+ sales on our platform. This year, our ambitions are set even higher. But scaling up the number of sales we run will require scaling up our tools and processes, too. This post describes Apogee, a tool I built to help us scale our businesses processes. I never thought I would be so excited to build a spreadsheet plugin, but I honestly had a blast. So let’s dive in!

Read on →

This past week has found me working on a brand new Rails project. Now, if I was building this project for my personal needs, I would without a doubt deploy it to Heroku – for both the ease of use and the high level of abstraction that Dynos afford. But I’m not building this for myself, I’m building it for my team.

Read on →

I was really excited about CircleCI 2.0, especially the workflows features. It seemed to me that with the work they had done here, really complicated builds would be able to be configured in a way that made more sense than on 1.0. This was something that was causing me grief on one of our projects so I upgraded to 2.0. It was pretty hard to get green and once we did, we decided to downgrade back to 1.0. Here’s why.

Read on →

C4Q is C4Q is a non-for-profit hacker school based in NYC. We’ve had members of the Artsy team help out by being TAs, running committees and steering the curriculum as Engineers in the industry for many years. In 2017, C4Q reached out to arrange a meetup between Artsy engineers and students who were learning Android and Web development. This year we ran a panel for the other half of the C4Q students who study iOS and Web.

We got an entirely new set of panelists to cover similar topics as last time - so if you’re wondering what it’s like in the industry, and what makes an Artsy engineer. The video is after the link.

Read on →

In Modernizing Force we discussed some of the tools we’ve been working with to modernize Artsy.net’s development environment, from introducing Babel and React to the creation of @artsy/stitch. Increasing overall development speed was another aim, and to that end we released @artsy/express-reloadable which automatically hot-swaps Express.js code without the restart. In this post I’d like to cover some of the issues we’ve faced since then, and in particular our solution to library code-sharing in Express apps.

Read on →