On 21 November 2016, I joined Redbubble as a web intern. My first surprise was meeting two other interns, Kirsten and Nick, who were starting their internships on the very same day, and Xinyi, who jumped on board as a data science intern the following week. At Redbubble, diversity is celebrated and individuals are welcome. Over the last few months, I have met people from all walks of life who work towards a common mission: to support independent artists and bring more creativity into the world. It is my personal belief that software is our most powerful means of achieving these goals. Through software, we are building more than just another online marketplace. Redbubble has grown into a community for
Introduction Hello. I thought it might be nice to share a story from the trenches, about how we identified a severe performance issue, and worked around it. This work relates to one of our background services called the Feed Service, which acts as our interface to Google Shopping. Each day Redbubble handles anywhere between 100K and 500K updates to art works, which need to be reflected in our Google Shopping catalogue. The catalogue currently contains tens of millions products, so the data to be processed and the number of API calls we need to do are non-trivial. We were having performance issues, where the message processing would periodically grind to a halt, running much slower than we would expect given our MySQL
Lucas Wilson-Richter, one of our Senior Engineers, spoke at the July Devops Melbourne meetup about our experience moving from Continuous Delivery (where the main line can potentially be deployed at any point) to Continuous Deployment (where the main line gets deployed automatically on every update). The video is now available on YouTube, or you can watch it here: Video by Andrew Jones, used with our thanks.
Image: “Delivery Dog” by AnimalCrew We’ve been doing Continuous Delivery for a while at Redbubble, and we’ve learned quite a bit, so I thought I’d share a few questions you should ask when making the transition from Continuous Integration to Continuous Delivery. Hopefully our experience can help you, whatever stage you’re at. But first, a quick refresher on what exactly Continuous Delivery is. When we are doing Continuous Delivery, we are doing Continuous Integration by definition. In addition to having an automated build, Continuous Delivery requires that any passing build can be deployed at any time, at the push of a button. This is more advanced than Continuous Integration, in which we always know whether our software builds
“Learnings of online customer behaviour for Make Benefit Glorious Product Development” Background At Redbubble, millions of users browse through independent artwork in the pursuit of that elusive unique art, which they want to own on a high quality product like a t-shirt, cushion cover or phone case. At any point there are lots of ideas to improve the customer experience, most of which are unquantified, backed by lots of unvalidated assumptions. From a product development point of view, this is understandable. All great ideas have to be seeded on some assumptions. However, we strive to validate assumptions, so we can get a better idea of impact and opportunity size. The real questions we want to answer are: What are the
Recently at Redbubble we have encountered a very interesting colour matching problem: Given a “target” colour and a set of colours, we have to determine which colour in the set is the closest one to the target colour. In order to understand why such a solution is needed, let’s analyse a scenario that actually happens on the website: An artist creates a work which he wants to sell on a t-shirt, and chooses the colour white as the default background for his work. A user browsing the website sees this work and wants to buy it as a hoodie, so the user chooses ‘Hoodie’ as the clothing style in the work page. Unfortunately we cannot print white hoodies, so we display the
Redbubble is not unique in expecting interview candidates to be able to analyze and design a model for a complicated problem on the fly. It’s a useful and interesting mental exercise for developers, and it gives us an amazing insight into how candidates go about solving problems. But it can also be stressful for candidates who aren’t used to it. The interview will begin like this: We will give you some ‘business rules’ for a system we would like designed, maybe also a few constraints, and then we will ask you to design it for us. The final design you come up with will be different for every problem-person combination, so I can’t tell you what the answer will be.
It started with some dates. An important aspect of the online shopping experience is that you cannot immediately receive your purchase. In Redbubble’s case it has to be both manufactured and shipped before reaching the buyer. Our customer service department frequently handles requests regarding arrival dates and possible late items. As such, we felt we could give customers a clearer understanding of the delivery time frame by providing this information (previously only on the shipping & delivery page) in more places. We decided we would build a new application that would take an item, shipping time and delivery location and return an estimated delivery date based on that data. Why build a new application? As part of the work page (where
There are some tasks in a programmer’s life that come up again and again. Creating classes in an often-repeated pattern. Adding entries to some boring but important list defined in code. Those tasks that make you think “This is so tedious! I do this over and over! There has to be a better way!” Fortunately, there is.
I have a love and hate relationship with Cucumber. I’m not talking about cucumbers we see on a dining table, but the one that we see when we’re talking about software testing! I’ve worked with Cucumber on a number of projects since I started working as a full-time Ruby developer back in 2009. It could be a very useful tool when we needed a tool to aid us in keeping our written requirements (that are also executable) to make sure the software behaves the way business intended. This kind of testing is often called User Acceptance Testing. We asked ourselves, is this the best approach?