During Artsy’s recent 2017 Hackathon we tackled making all of our editorial content accessible. The idea was hatched at Berlin JSConf this spring, where Laura Carvajal gave a talk following the Financial Times’ experience implementing better accessibility requirements, and how they built these considerations into their testing process.

What does accessibility mean in a browser? Generally the term refers to supporting the wide range of assistive technologies for users with vision or motor impairments. These include screen readers, as well as mouseless navigation using a keyboard, eye tracking and other devices. Interestingly these technologies are implemented at the OS level rather than the browser itself. Mac’s OS includes a built in screen-reader, and JAWS is the most popular application in this vein. It is also notable that browsers do not track users who employ assistive tools.

Two users on WebAIM’s forum excellently present the case for accessibility as a developer’s responsibility:

“Users may be highly resistant to having their disabilities identified as they go throughout the web. Most persons with disabilities would really just rather that the Web just work for them.”

“Looking at accessibility as a way to serve a specific population is missing the point that accessibility is about inclusion of all people.”

A central tenant of Artsy’s mission is to ‘make art as accessible as music’. By expanding accessibility for the visually and motor impaired to writing on art and culture, this projects allows us to follow through on this statement in a very literal way. Furthermore, there’s no reason to ignore this audience; accommodating use of assistive technologies is an ethically responsible thing to do.

Read on →

We have a few apps now, but one of them isn’t really used by anyone other than developers. This is our React Native host app. We built our React Native components as a library to be consumed by our other apps. Our development environment for these components is a unique app that acts as a host for the React Native components. It’s effectively a long tableview.

This app is often updated for developers, but never deployed to beta users inside Artsy. So I automated it. Using Travis CI and fastlane. This post covers how I got that set up.

Read on →

About 3 years ago, dB. announced that Artsy had a public API.

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.

We’ve wrapped up some legal work around the developer API terms and services, the PR is here and I’m happy to announce that the API is ready for non-commercial production use.

The TDLR Terms and Conditions today for using the Artsy API is:

• Non-commercial use only.
• You only get access to public-domain artworks.

The API:

• Is a Hypermedia API.
• Covers Artists, Artworks, Genes, Shows, Partners and more.

If you have a great idea for an app that can use public-domain data, then the Artsy API is the right place to look: https://developers.artsy.net.

I’ve worked on a few large-scale OSS projects, and I believe that people find it easier to just leave a comment and rely on a contributor to explain a problem rather than consulting the documentation. I consider doing everything you can to make people find their own answers a strong part of defensive open source.

For the posts I write, I have an even lower tolerance for comments. For example, I added the ability to turn off comments per-post and haven’t allowed comments on any posts I’ve written here. A lot of transitory discussion around an article happens on twitter via @ArtsyOpenSource.

I’m willing to give it another shot though, and so I got around to creating a simple system for allowing opt-in comments on posts using GitHub Issues. The rest of this post will be about how you can do it also, and a bit about why I think GitHub Issues are a happy medium for the comments.

Read on →

React Native is a new native library that vastly changes the way in which you can create applications. The majority of the information and tutorials on the subject come from the angle of “you are a web developer, and want to do native”.

This makes sense, given that the size of the JavaScript/web audience is much bigger than native developers, and far more open in the idea of writing apps using JavaScript. For web developers it opens a new creative space to work, however for native developers it provides a way to work with different tools on the same problem. Considering that most developers with a few years on the platform will be comfortable with the Xcode suites of tools, recommending a change this drastic is a tough sell.

We’ve been using React Native now for about a year and a half, and have started to slow down on sweeping changes inside the codebase. This is great because it means we’re spending less time trying to get things to work, and more time building on top of a solid foundations. Now that we’re settled, it’s time to start deeply understanding what happens with React Native.

I’d like cover a lot of the common questions we get asked about from the perspective of native developers:

• What is React Native?
• How do you use React Native?
• When is React Native a good technology choice?

This article covers an awful lot, so free up at least 45 minutes, make a tea and then come back to this on your computer. It’s worth your time if you’re interested in all the hype around React Native.

Read on →

Danger came out of two needs. One from the needs of a growing dev team working together full-time, and the other from the needs of a completely asymmetric large Open Source project.

A work environment dev team is a complex place. You naturally grow, and to grow safely you add process. Process is a mixed bag, it’s a net benefit at the trade-off of individual’s time vs team cohesion. You want to grow your team guided by smart applications of process.

On the other hand, working on a large open source project, it’s easy to feel overwhelmed at the amount of work that needs to get done on a daily basis. The growth of your OSS team probably doesn’t tie to the amount of work that needs to be done. Especially if you’re like me, and you don’t want to be maintaining OSS as a 2nd full-time job.

So what do you do? Well in a work environment you don’t really have a choice, as a team you hold each other to the rules that you set. In OSS, you sacrifice your spare time or you can find time at work, you could stop or you could burn out.

And this is the environment in which the idea of Danger was incubated.

Today mark version 1.0 of the second version of Danger. I’m going to cover what they are, how they continue to grow and what I see their trajectory as.

Read on →

After examining the data stored in one of our high-throughput systems, we realized it might include sensitive user data. To reduce the number of people that are technically able to access the data and reduce the risks associated with a potential data theft, we decided to encrypt certain database fields.

Our Goal

Encrypt sensitive fields without any downtime.

Read on →

In the 1990s, Harvard researcher Amy Edmonson made the unexpected discovery that in hospitals, higher performing teams reported making more mistakes. This is unexpected because one would assume that better performers would make fewer mistakes. In fact, the number of mistakes isn’t what distinguishes higher-performing teams, but rather it’s their attitude towards discussing – and learning from – their failures.

I’ve spent the past eight months reading more about psychological safety: the shared belief that team members won’t be punished for speaking up with mistakes or questions or ideas. As a result, I’ve been trying to operationalize psychological safety on my own team, and part of that includes discussing and learning from our mistakes. At Artsy, we candidly discuss site outages or production bugs on the web, but haven’t historically been great at communicating about iOS problems.

I want to start doing more retrospectives after things go wrong. So this week, I held my first iOS retrospective.

Read on →

Hey there everyone, it took us two years to make our GraphQL implementation support any mutations. We opted to keep it read-only for quite a long time because we use GraphQL to consolidate multiple APIs, but as we start new projects as GraphQL + databases then understanding mutations becomes much more important.

Last month, I talked with the team at Graph.cool about having them talk through Relay mutations comprehensively as a guest post on the Artsy Engineering blog. So, I’m really excited to introduce this great post on the topic by Nikolas Burk.

– Orta

The Magic behind Relay Mutations

Relay is a powerful GraphQL client for React and React Native applications. It was open sourced by Facebook alongside GraphQL in 2015 and is a great tool for supporting you with managing your app’s data layer.

In this post, we are going to explore how Relay mutations work by looking at a React Native app. The code can be found on GitHub. Our sample application is a simple Pokedex, where users can manage their Pokemons.

Note: We’re going to assume a basic familiarity with GraphQL in this article. If you haven’t heard of GraphQL before, the documentation and the GraphQL for iOS Developers post are great places to start. If you’re interested in learning more about Relay in general, head over to Learn Relay for a comprehensive tutorial.

Read on →

How important is a single artwork within the artist’s body of work? At Artsy we try to answer this question by extracting and scoring a set of features across roughly one million artworks. We call it an iconicity score and we calculate that in Apache Spark for the entire dataset in under 5 minutes.

Read on →