This past week has found me working on a brand new Rails project. Now, if I was building this project for my personal needs, I would without a doubt deploy it to Heroku – for both the ease of use and the high level of abstraction that Dynos afford. But I'm not building this for myself, I'm building it for my team.
I was really excited about CircleCI 2.0, especially the workflows features. It seemed to me that with the work they had done here, really complicated builds would be able to be configured in a way that made more sense than on 1.0. This was something that was causing me grief on one of our projects so I upgraded to 2.0. It was pretty hard to get green and once we did, we decided to downgrade back to 1.0. Here's why.
C4Q is C4Q 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. In 2017, C4Q reached out to arrange a meetup between Artsy engineers and students who were learning Android and Web development. This year we ran a panel for the other half of the C4Q students who study iOS and Web.
We got an entirely new set of panelists to cover similar topics as last time - so if you're wondering what it's like in the industry, and what makes an Artsy engineer. The video is after the link.
In Modernizing Force we discussed some of the tools we've been working with to modernize Artsy.net's development environment, from introducing Babel and React to the creation of @artsy/stitch. Increasing overall development speed was another aim, and to that end we released @artsy/express-reloadable which automatically hot-swaps Express.js code without the restart. In this post I'd like to cover some of the issues we've faced since then, and in particular our solution to library code-sharing in Express apps.
Hello! My name is Ash and I work on the Auctions team at Artsy. I like to blog, and I like to tell people they should blog, too (you should blog btw). I've been trying to increase how many blog posts get written by Artsy engineers for six months or so, but have only seen modest results. I've been holding weekly office hours to help with writing, but it's not often attended. So I started reaching out to team members individually to suggest they write something, but they're very busy and often can't spare the time. Hmm.
A simple solution came out of a discussion with other engineering teams surrounding how to build team culture. Sonam Dhingra of UsTwo solves the problem of "not enough blog posts are getting written" simply by providing templates that can be used to compose blog posts very quickly. Even if someone was in a hurry or not a confident writer, they could still contribute to the engineering blog. What a marvelous idea!
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.