We have a lot of Open Source code. For engineers without considerable experience in the open source realm, understanding some of the copyright issues around code ownership can be tricky. I’ve been working with our CTO dB., and our senior counsel Yayoi Shionoiri on creating an open-source FAQ for engineers.

What is Open Source?

Open Source code is code that can be freely examined, used, adapted, and shared by all through a license that sets forth these principles. The only potential limitation that an Open Source license is likely to impose is that future copies of the code (whether in adapted or un-adapted form) be themselves licensed in a manner consistent with the original license. At Artsy, we are committed to making our engineering work Open Source by default. A list of our Open Source projects can be found here.

Read on →

tl;dr You can try Artsy on your Amazon Echo now, say “Alexa, enable Artsy” or see alexa.artsy.net for more info.

With its powerful automatic speech recognizer, accurate natural language understanding and outstanding text-to-speech capabilities, the Amazon Echo, nicknamed “Alexa”, always impressed me. While not the first in its category and introduced in late 2014, Alexa was the first consumer device in my home to truly enable the conversation between human and machine. It was stationary, always listening for a wake word, and clearly outperformed all previous attempts when it came to the ability to receive commands from the other side of the apartment.

Alexa knows about the weather, but it doesn’t know much about art.

In this post I’ll dig a little inside the Alexa software platform and go over the technical details of bringing Artsy to the Echo, starting with a very simple “Ask Artsy about Norman Rockwell.”

Find the Artsy skill in the Alexa app and the complete Skill code on Github. And if you just want to learn to write a skill quickly, watch @dblock live-code a skill in this video.

Read on →

Getting to grips with the entire JavaScript ecosystem is a tough job when you’re getting started. Coming from the native mobile space, there’s a lot to learn. I’ve spent a few months immersed in the environment now, and can try summerize a lot of topics. This should make it easier to find more information when you need it. This post is semi-opinionated, with links for further reading so you can get a different perspective too.

This post focus specifically on the JavaScript tooling around React Native projects, but is applicable to all JavaScript projects.

Read on →

This past year, our team started using a GraphQL orchestration layer that connects various APIs with multiple front-end apps including iOS. It also handles caching and extracts some business logic out of our client apps. This helped us not only to be more consistent with the way we fetch data across apps, but also improved developer happiness and even bridged teams by having our web and iOS developers work with the same API layer. This got me thinking what other problems GraphQL could solve at Artsy.

I work on the Publishing Team at Artsy, and we’ve recently been focused on page speed as a KPI. With so many ways of measuring speed, it’s a daunting task but for this post, I’ll focus on the way we handled things on the server-side and how integrating GraphQL on our API improved page speed.

Read on →

At Artsy we currently have thousands of client applications hitting our API and requesting authentication. When a user successfully authenticates through one of these clients, we want to embed basic user and application data in the resulting token rather than have to look up a session ID in the database on each request. For that we want to use JWT.

JWT (JSON Web Token) is a self-contained, secure and standard way of transmitting data between applications and clients as JSON objects. Using JWTs lets us use a standardized technology to cut our authentication workflow down by one round-trip.

We’ve recently switched our authentication flow to use JWT, and I’m going to cover what they are, how we’ve used them and how we’re handling the transition.

Read on →

In the last few months twice I’ve wanted to access the source code of our application. The first time I did it I came up with a pretty neat hack, but it wouldn’t really work in many places. The second time however, I asked the internet, and the internet replied.

TLDR: You can use your project’s scheme to expose derived Xcode environment variables to your source code.

The rest of the blog post is a little bit about why I wanted to do that and what I did with it.

Read on →

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’m happy to introduce the next in the Dev Interviews series - Maxim Cramer.

Maxim has been at Artsy for 6 month, working on our mobile app Eigen. Our interview covers how being a remote developer, advice for people at a HQ working with remotes, her work with React Native and what the future holds for the Artsy mobile team.

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

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 →