Since we originally built Eidolon – an auction bidding kiosk app – the project has largely remained in maintenance mode. Eidolon was one of the first projects that we used automated deploys for, and the deploy process has remained largely unchanged. I believe this stability of the deploy process is a testament to how well the automated deploys have gone.

This post is going to detail the mechanics of automated deploys for an enterprise-distributed iOS application, discuss lessons we learned and applied to other projects' deploy processes, and describe some of the changes we'd like to make. Our project is entirely open source, so you can check out any part of the code on your own or open an issue with questions.

Read on →

In considering an offer to join us at Artsy, one of our newest incoming engineers asked me a great question: How does the tech team do professional development?

As I thought about it, I began to realize that the answer is “a lot”! Most of our efforts evolved organically. Someone had an idea, and people rallied around it. I thought it would be useful to share, in case others are inspired by what's caught on here. Here are some of the things we do.

Read on →

I’ve lived in NYC for 2 years now. I’ve been around long enough that some of the people I helped when they started learning have begun to feel like they’re not “Juniors” anymore.

They have begun feeling confident in their code, their responsibilities at the company and wanting to improve both. It's a feeling that maybe, just maybe, you're not struggling to stay afloat anymore.

This post aims to be technology-agnostic, and if you sit somewhere at 1.5 - 3 years of programming experience then you’ll probably get something out of it. On top of that, I’ll give some pragmatic JS and iOS specific tips at the end.

Read on →

The main website for the desktop, Force, was our first Artsy application to open its source code, Craig and Brennan did it back in 2014. Force's public offering laid the groundwork for the iOS OSS projects to come afterwards: Eidolon, Eigen, Energy and Emergence.

Though Force wasn't quite Open Source by Default, it represented a really important step for Artsy's OSS perspective but was not the end goal. We were opening our source, but not opening our process.

This month both Force, the desktop version of and Microgravity, the mobile version - moved to being built entirely in the open. Read on to find out how.

Read on →

Hey all, I was asked to talk internally about ways in which anyone can improve their day-to-day computer usage. For me, using keyboard shortcuts shows a greater level of control of your machine - and more importantly can be considerably faster.

I have all of my notes, annotated with images inside a personal GitHub repo: orta/keyboard_shortcuts. We covered:

  • Pressing menu items via keyboard
  • Window Management
  • Text Management, e.g. jumping between words etc.
  • Searching for text
  • Taking Screenshots
  • Slack and Chrome
  • Using a Window Manager and Clipboard History Manager

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

Read on →

I arrived fashionably late to the React Native party in Artsy. I had been a part of our Auctions Team, where we worked in Swift with some light-FRP. We were not affected by the 4 months of simultaneous work on moving to React Native, at all.

It was a quiet revolution. I did not have to install npm, I made zero changes to the code for auctions and the whole app's infrastructure barely changed. Yet we moved to making all new code inside our 3 year old iOS app use React Native. What gives?

Well, first up we weren't planning a re-write, we don't have that kind of luxury and the scope of our app is too big compared to the team working on it. Second, we reused existing dependency infrastructure to support JavaScript based apps. Read on to find out what that looks like.

Read on →

I'm an old school TextMate user, who has also been using Xcode for the last decade. These two sit at a very opposite ends of an "editor" spectrum.

TextMate is extremely bare bones at the core, but introduced the idea of bundles as plugins. Making it really easy for others to build their own plugins for their own contexts. Xcode on the other-hand includes a 3D scene editor, the best interface builder I've seen, super rich debugging tools and close to zero support for improving it yourself.

As we agreed on moving to React Native, we needed to decide what the team should use for working in that environment. After experimentation with many editors, we decided on Microsoft's Visual Studio Code.

We wanted to keep a lot of the best features from Xcode, while working in a completely JavaScript environment. For example: debuggers, inline errors, auto-complete, symbol mapping and to ideally have them all inside a single editor.

Let's dig into the principals of how Visual Studio Code works, what makes it a better option for us, and what parts of it really shine.

Read on →