The website is finally back up after crashing hard for 4 hours straight.

Recently AWS decided to reboot a few of your servers for a critical update. It didn’t seem like it was going to be a big deal, except that the schedule was only accommodating if you were in the Pacific Northwest. The first reboot took out a secondary replica of our MongoDB database. Unfortunately the driver handled that poorly and spent the first 400ms of every subsequent HTTP request trying to reconnect to the missing instance. That server came back up, but failed to find its storage volumes because of a human mistake in a past migration and the alerts were mistakenly silenced by someone monitoring the system. A few hours later the primary was being stepped down and rebooted, sending the driver into panic over another bug. The site went down.

None of this was obvious while it was happening as the rate of automated alerts grew. Engineers communicated to the team that they are actively focusing on bringing the systems back up. This helped to fend off a large amount of instant messages, e-mails, texts and phone calls from various people on the team that were in the middle of demoing something to a very important prospective customer on the other side of the planet. It was also the middle of the night in New York.

Now that all the systems are back up, lets write a detailed outage post-mortem.

Read on →

For the past few months, Artsy’s mobile team has been working on Eidolon, a bidding kiosk for Artsy’s auctions platform. While we’ve written a retrospective on the process of making Eidolon from the software side of things, we didn’t really touch on how our software is being used.

Read on →

In the Summer of 2014, we began developing a bidding kiosk for the Artsy auctions platform (code-named Eidolon). Typically, the iOS team here at Artsy worked on two main apps: a consumer-facing iPhone app and an iPad app used by art galleries. For Eidolon, we followed Artsy’s standard practices for building our software and use GitHub issues as our canonical source for bug reports and feature requests. Many of the components used in our apps are open source, but the codebases themselves remain in private repositories.

Initial planning for Eidolon began over the Summer. Our designer Katarina had the main features sketched out. I was scheduled to work on it at first, with Orta and Laura joining me near the end of the project. We had a rough scope: the app would be able to list artworks at an auction and allow prospective bidders to learn more about these artworks. The user would be able to register to bid and place bids using the Kiosk, including credit card processing for identity-checking.

Read on →

This post is about how, in a week, we switched from Solr to Google Site Search and customized it into a fast, beautiful search service. Search is a difficult problem – a really difficult problem. For small companies and startups, the common solution to search is to launch a custom search service based on Solr or Elastic Search. While these services are very appropriate for private data, we think Google Site Search should be considered in addition to these services for a public website. It is often not considered because users search on a dedicated site with different intent than they search Google. We found that while this may be true, it is not necessarily a good reason to roll your own search service for your public site.

Read on →

Many established companies have bug bounty programs, including a recently publicized Twitter Bug Bounty. Some use services, such as HackerOne or BugCrowd. In early September 2014 we quietly launched our own Security Bug Bounty. Since then we have fixed 14 issues reported by 15 security researchers and paid $750 in bounty. In the process we have learned a ton and wanted to share some things that would have probably done a little bit differently, knowing what we know now.

In this post I will focus on both technical and non-technical takeaways, and will provide an extensive list of vulnerabilities that should have been dealt with before launching our bug bounty.

Read on →

Introduction

The Indianapolis Museum of Art (IMA) recently shared thousands of high-resolution images from its permanent collection with Artsy, including 5,000 images that were in an un-cropped state. These images contain color swatches, frames, and diverse backgrounds, as shown below. The clutter in these images made them inappropriate to display to end users, and invited an approach to automatically crop the images. This post explores some fully automated techniques to locate the piece of art within each photo. If you’re eager to jump straight to the code that worked best, you’ll find the implementation of the ‘Rectangular Contour Search’ section here.

Read on →

Artsy’s API requires something called an XApp token in order to perform requests. The token comes back with an expiry date, after which the token will no longer work. A new token will have to be fetched.

{
	"xapp_token": "SOME_TOKEN",
	"expires_in":"2014-09-19T12:22:21.570Z"
}

In our previous iOS apps, tragically written in Objective-C, we have a lot of code that looks like the following. getXappTokenWithCompletion: checks to make sure that there is a valid token. If there is, it invokes the completion block immediately. Otherwise, it fetches a token, sets it in a static variable, and then invokes the completion block.

[ArtsyAPI getXappTokenWithCompletion:^(NSString *xappToken, NSDate *expirationDate) {
    [ArtsyAPI getSomething:^(NSDictionary *results) {
       // do something
    } failure:^(NSError *error) {
        // handle herror
    }];
}];

That’s kind of ugly. A better approach might be to embed the token-requesting logic within the getSomething: method. But that kind of sucks, since we’d have to reproduce that logic for every network-accessing method. If we have ten methods, that’s ten times we need to duplicate that logic.

With our new app (written in Swift), we’re using a network abstraction layer we’ve created called Moya. Moya sits on top of Alamofire and provides an abstraction for API endpoints. Instead of having ten different network-accessing methods, there is only one method to which you pass one of the ten different possible enum values. This means you have compile-time safety in your networking code, but that’s not really what we’re here to talk about.

Read on →

Today we are happy to announce that we’re making a new public API generally available, along with over 26,000 artworks from many of our institutional partners.

The Artsy API currently provides access to images of historic artwork and related information on artsy.net for educational and other non-commercial purposes. You can try it for playing, testing, and learning, but not yet for production. The scope of the API will expand in the future as it gains some traction.

If you just want to use the API, you can stop reading here and head to the developers.artsy.net website. (The developers website itself is a classic Rails + Bootstrap example and is also open-source.)

In this post we will step back and describe some of the technical decisions made during the development of the new API.

Read on →

Today we’re happy to announce we’ve open sourced the entire Artsy.net web app, Force.

Over the past few months, we’ve rewritten our web front-end to move off Rails and on to a Node.js stack that shares Javascript code and rendering between the server and client, otherwise known as Isomorphic Javascript. After migrating to this new stack, we open-sourced our boilerplate, Ezel, and have now gone a step further and open sourced Artsy.net.

Read on →

As Ash said earlier we like using Continuous Integration. Today I spent a large amount of time migrating us to use the new CocoaPods caching system in Travis CI. To make up for my lost time I’m passing on what I’ve learned and also showing how we do CI at Artsy with Objective-C apps. If you’re interested in how we do it in Swift, you can just check Eidolon.

Read on →