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
Image: sand clock by valeo5 Let’s assume you’re working in an a team. An Agile team (of course). Chances are you’re doing daily stand-ups. Perfect, right? Not quite. Here’s why: 4 out of 5 times you don’t need daily stand-ups in your team. Disclaimer: Lots and lots of other team leaders / scrum masters / engineering managers / etc. think like me, which means there’s hundreds of articles out there covering this particular topic. So if you’ve been reading about stand-ups for a while, a lot of what follows might sound familiar. When to try stand-ups In my opinion, there’s only two situations a stand-up is worth trying and might add some value, at least for a little while. (Almost) every
How to survive the consultation process when everyone has an opinion You have been charged with getting two proposals off the ground. The first proposal is for a Nuclear Power Plant. The second is for a new Bike Shed. Way back in 1956, a gentleman by the name of C. Northcote Parkinson described the above scenario to illustrate a concept now referred to as Parkinson’s Law of Triviality. The thing is, nuclear power is complicated. It requires a lot of specific expert knowledge. So much so in fact, that the average person cannot really understand it all. Consequently, when faced with a proposal for a power plant, most stakeholders will assume that someone else has checked all the details before
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
Image: A Look Back by Michael McClendon This post comes from Iran Rajakaruna, a junior engineer who came to us through the Tin Alley Beta internship program. Last summer was a big turning point in my life. I still remember the day that I came for an interview with Redbubble the same way that I remember any other first days in my life. I was excited, anxious and happy at the same time. My first impression of Redbubble was a beautiful experience, like love at first sight. I loved the funky office with bean bags, foosball table and free beers. Let me go back a few months and start from where it all began. Last November, I was at RMIT University
Image: “Surfing kangaroo and friends” by pixbyrichard The Australian-English dialect is unique in many aspects, with a large number of colloquial terms that are often impenetrable to non-Australian English speakers. This phenomenon extends to technical terminology as well. This document is an attempt to assist non-Australian English-speaking technical professionals when communicating with their Australian counterparts. For a guide on pronunciation of Australian English, see https://en.wikipedia.org/wiki/Australian_English_phonology bludger, n. a sleep command (suggests a sub-optimal practice) e.g.: “Bugger cron for a joke – sling a bludger in there” meaning: “I do not believe that scheduling a command will be worth the effort. Let us instead call sleep.” bordit, v. draw something on the whiteboard e.g.: “Bordit, mate!” meaning: “My friend, I am struggling to comprehend your
“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.