At Artsy we <3 TypeScript. We use it with React Native via Emission and on the web via Reaction. Until recently, however, projects that required the use of Babel had to implement convoluted tooling pipelines in order to work with the TypeScript compiler, increasing friction in an already complex landscape. (An example of this is Emission’s use of Relay, which requires babel-plugin-relay to convert graphql literals into require calls.) Thankfully, those days are over. Read on for an example project, as well as some advice on how to avoid common pitfalls when working with the new beta version of Babel 7.
I don’t revert code changes often. Usually, I’m a fan of “rolling forward” with a fix, rather than rolling back. But sometimes, revert-and-fix is just the ticket. I had to do so recently, and it brought up some interesting challenges, so I thought I’d share.
C4Q is is a non-for-profit hacker school based in NYC. We’ve had members of the Artsy team help out by being TAs, running committees and steering the curriculum as Engineers in the industry for many years. C4Q recently reached out to arrange a meetup between Artsy engineers and students who are learning Android and Web development.
We thought it would be cool to have a talk from dB, our CTO, on what Artsy is and to also host a Q&A panel with our engineers. For a lot of the students it was their first time meeting a team of engineers, so we anticipated a lot of question time.
In prepration for the event, I reached out to the internet for ideas on what sort of questions juniors would be interested in hearing about, and people said they were also interested in hearing what we ended up being asked, and what our answers were. This post has the youtube video of the opening talk, and our panel’s Q & A session.
It was really awesome to talk about how far we’ve grown as individuals, and what is important in our engineering lives.
With the often overwhelming and downright discouraging reality that the tech industry isn’t a diverse and inclusive environment, I felt compelled to share what a productive, empathetic, and nurturing environment for female and female-identifying engineers looks like.
I have just shipped a post over on the Life at Artsy blog about how: Our culture of empathy, our hiring process and our company values provide a competitive advantage. This all contributes to ensuring that all engineers regardless of gender feel valued.
A few weeks ago, every engineer at Artsy went to work for a different team for two full days. We called it DevSwap. In this post, I’ll go over why and how we did it.
Force is Artsy’s main website, artsy.net. In the three years since it was open-sourced, it has provided a solid foundation to build features on top of without a lot of the costs associated with growth. It is an early example of Isomorphic (“universal”) JavaScript, built on top of Express, Backbone, CoffeeScript, Stylus and Jade. It is also highly modular, adopting patterns laid down by its parent project, Ezel.
When first developed these technologies made a lot of sense; CoffeeScript fixed many of the problems with JavaScript pre-ES6, and Jade / Stylus made working with HTML / CSS much more elegant. As time progressed and new technologies became a thing these solutions starting feeling more burdensome to continue building features with and many of our developers longed to start using next-generation tools like React.
Once Danger Ruby was stable enough for everyday use in 2015, it became obvious that running Danger on CI was both a positive and a negative. On the positive side, Danger has access to all artifacts created during testing - and on the negative side it takes a long time to get feedback. It was obvious that Danger could run on a server, but it was a big unknown what that could look like.
Eventually, I came to the conclusion that we would need a JavaScript replacement of Danger - and so I applied constraints to Danger JS that made a server-side version of Danger a possibility. It was a stroke of luck that around the time Danger JS became usable for day to day usage, that GitHub introduced GitHub Apps - so I started work on Peril. Peril is server-side Danger. The rest of this post talks about how we use it Artsy today, how you can use it yourself and where it’s heading.
Artsy has always had a focus on Art meets Science, and we hosted a meet-up in July that really hits on both. We had a collection of Artsy Staff, members of Art + Feminism NYC, the CocoaPods Peer Lab, New York Arts Practicum and volunteers from Wikimedia NYC all helping out.
We came with two aims:
- Help anyone interested in contributing to Wikipedia get started.
- Use The Art Genome Project(TAGP) to improve Wikidata entries for women Artists.
I helped out with the second part, and the rest of this post will be about the lessons learned during this editathon.
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.
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.