Normal artsy10


New York, NY

About Artsy Engineering

Art meets Science.
At its core, Artsy is a technology company. In addition to the engineering team, both the CEO and COO have technical backgrounds (Computer Science from Princeton, and Mathematics from Columbia). Our ultimate goal is to create Artificial Intelligence with the qualities of the world's most omniscient art advisor. If Skynet ends up winning, at least it will have good taste :).
We are solving very hard problems. To make art historically relevant recommendations, you can't rely on collaborative filtering alone. We do real-time search in 800 dimensional space (one dimension for every art historical category). We are also working on semantic search, fuzzy full-text search, visual similarity search, and high-resolution image tiling and security among others.
We write our own open-source projects and contribute them back to the community.

Unknown author on

How to Win with React

Craig Spaeth from Artsy talks about React internals and how to use it to your best advantage. Craig shares how to get started using React and showcases how React is integrated with Backbone at Artsy to make managing complex UI a pleasant experience.

This talk was recorded at the N Languages in N Months meetup at the Ladders in NYC.

Small brennan moore Brennan Moore on

Monolithic to Distributed: How Artsy Transitioned from Ruby on Rails to Node.js and Isomorphic JavaScript

Artsy transitioned from a monolithic Ruby on Rails stack to a distributed system with Node.js apps that share code and rendering between the server and browser and have open sourced their learnings into a boilerplate project called Ezel.

Artsy’s Developer Craig Spaeth and Director of Web Engineering Brennan Moore cover how the transition was managed as well as dive into some code showing how Ezel and these new isomorphic apps work.


This talk was hosted at the nodejs meetup at Shutterstock.

A couple days ago Artsy open sourced the frontend. More info here:
If you want to ask Brennan a question, you can submit it in the comments below the post.


Small 5e6ceef905d14ade228ea22c445d57bc Aidan Feldman on

Anatomy of a Ruby Gem - & Magickly

While building, there was a need for applying transformations and effects to images in a way that would work across devices.  The Magickly app was built as a stateless image effects API.  To demonstrate its flexibility, the app was converted into a gem and used to power Mustachio - better known as  In this talk, Aidan Feldman, education hacker at Github, will cover some of the architecture decisions for Magickly, some fun findings about ImageMagick, and the internals of both gems. This talk was recorded at the Anatomy of a Ruby Gem meetup at Artsy.


Small daniel doubrovkine Daniel Doubrovkine on

DevOps Best Practices: Artsy

Hi all! We are launching series of Best Practices interviews with companies, that are known for their innovative approaches in "DevOps". The first short interview is with Daniel Doubrovkine, Head of Engineering at Artsy.

How does your team/organization approach automated testing?

Everything is tested with automated testing and there's no manual QA. We spent a lot of energy to make writing tests easy.

What do you think automation is especially *not* suited for?

Automation is not suited for natural human processes, such as user experience.

What are your perspectives on continuous integration tools? Are you using any?

We use Jenkins and Travis-CI, heavily. We fully rely on them.

What kind of individual's profile makes the best systems engineer? (assuming automation is key)

The best systems engineer is a developer with a passion for operations. This means that they are contributing to the codebase, but focus on areas that are less about "business logic" and more about "runtime and operations".

What tools/training do you suggest that a more traditional systems administrator acquire in order keep his/her skills relevant (assuming systems automation will increasingly become the norm)?

Learn to code, start with Chef (which is Ruby), then move up the chain.

Which engineering teams/individuals do you watch for cutting edge tips, tools, and architectures when it comes to systems automation?


Small daniel doubrovkine Daniel Doubrovkine on

Good Practices In Software Development

We recently sat down with Daniel Dubrovkine, head of engineering at Artsy to chat about some software engineering good practices, and to learn from Daniel what tips he can share from his experience building Artsy from day one to its present size of around 50 employees.

Technical Debt

As engineers, we are used to objective yes or no answers. But the topic of technical debt is quite fascinating because there is no real yes or no answer or a formula for how much technical debt is ok to accumulate before it begins to damage the business. And there is no business that has absolutely no technical debt.

Daniel talks about two kinds of technical debt. There is the technical debt that occurs from having engineers who are not too qualified to create a particular part of the application, and make architecture mistakes. The danger of having such technical debt is that when you add features upon features on top of a poorly architected foundation, at some point it all crashes and the software just doesn't work.

But technical debt does not have to be all bad. Yes, there is good technical debt. Good technical debt is planned by the software architect to leave ambiguity and unimplemented pieces of the software because the business case has not been completely defined. Once the business case has been completely defined, engineers can then go and write the code to get rid of that planned technical debt. Here is Daniel's video about technical debt.


Join Us