Tag Archives: code
At Redbubble, we are dependent on artists uploading new designs and illustrations. Naturally, we’d like to make this as easy as possible. Previously, the process to do this was to download a template, position their work offline, upload, save, check the final product and repeat. For designs that need to be in a particular position this could be an extremely painful process! In order to lower the hurdle for new users and decrease the frustration level for our long-time artists, we introduced a new uploader which takes away the need for templates and allows for preview and positioning of the design on the product before upload.
The success of Ruby has always been dependent on high quality open source libraries. The best known example is of course Rails. The codebase at Redbubble is mainly a monolithic Rails application with very few independent modules. While looking at possible architectures to move forward (which is outside the scope of this article) we also decided to start open-sourcing some of the code, small and large, that make our site run. We’re happy to present our first couple of open-sourced gems, KeyVault and ConditionalCapistrano.
Redbubble has been around for a while now and we haven’t made any efforts to give our visitors on phones and tablets an awesome experience – a better experience than looking at a full sized page zoomed out! So to that end, we recently spent a decent amount of time to make Redbubble more mobile friendly. Responsive or Native? When developing a mobile site, there are basically three options available: Build a native app. Create a separate mobile site. Convert the existing site over to a responsive design. Since we didn’t have the expertise to build a native app and a separate mobile site would only mean we had to support two codebases, we decided pretty early on that the responsive way is the
We’ve previously posted about measuring what’s happening on Redbubble, but with NewRelic’s new plugin system our lives just got a bit easier. We’ve been using NewRelic for a while now and frequently make use of it’s application and server monitoring for diagnosing problems. Generally the timescales it keeps data for are sane, integration with other tools is good and the UI is easy to use. There are already a plethora of plugins waiting for you to install, although NewRelic’s definition of a plugin is not what we expected. The plugins are small applications (agents) that poll your apps and report back to NewRelic using your licence key and an agent_guid for identification. So installation isn’t all that straightforward, depending on what you want to monitor.
A little while ago, we realised that at having information about what was happening on Redbubble right now would be useful for many things; including tracking and alerting us to the sorts of issues that wouldn’t necessarily be caught by more traditional means (such as Airbrake alerting). Having come across this post by Etsy, we looked at statsd as a way to collect this information in a quick way without adding much processing overhead.
The task Here at Redbubble we’ve been running Ruby on Rails since day one. We’re a small development team, so keeping up with even the latest stable release has been a struggle. Earlier this year we had a gap in product development and took the opportunity to move our stack forward. We’d been on Ruby 1.8.7 and Rails 2.3 for a year or two. After some investigation we decided we’d first move to Rails 3.0 which would make Ruby 1.9 an easier option. After significant library updates and code compatibility changes, we were ready to release Rails 3.0 on Ruby 1.8.7.
Over the past few months the team had been getting enthused over the idea of a Hack Day and there had been much discussion on how to make it happen. Very few of us had first hand experience with the concept so taking the philosophy of walk before you run, we decided to do a small-scale run within the Engineering team before moving onto a bigger event. So we nominated a date, started listing some projects and come the day, ended up with three teams of two to get going. The day started with a brief kickoff session whereby each team gave an outline of their project and what they hoped to achieve, taking feedback from the rest of the
Recently we’ve been working on upgrading the version of Ruby the Redbubble site runs on, from 1.8.7 to 1.9.3. We’re doing this for a number of reasons, including improved performance, new language features, and trying to stay relatively current with our tech. Things went fairly smoothly until we hit a problem where we could get one of our rspecs to segfault (i.e. actually crash the ruby interpreter) every time we ran it on our (OSX Lion) development machines:
This is a tale of one of those times where it is actually useful to do code profiling and benchmarking. A bit of background: We’ve been in the process of upgrading our Ruby on Rails stack here at RedBubble, going from Rails 2.3 to 3.0, with an eye to moving forward to 3.2. Through this, to minimise the amount of change happening at once, we’ve stuck with Ruby 1.8.7, instead of jumping right to 1.9.3. When we rolled out Rails 3, we noticed a significant slowdown in the general performance of the site, even though the benchmarks we had run at the time indicated that it should be okay. It has been widely reported that Ruby 1.9.3 has in general,