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.
Most of us have come across goal setting in one way or another, be that at work when your boss comes over and tells you that you have to reach a certain sales target this quarter, or when we make a new year’s resolution to learn a new language. But why do we constantly set goals? Does it even work? Can’t we just all try our best and be much happier? Turns out that setting effective and meaningful goals can have a tremendous effect, not only on your performance, but also on other aspects of your (work-)life. Why set Goals? Research on the topic of goal setting has been done for more than 50 years and a lot of it
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.