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.
Tag Archives: ruby
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?
Every programmer knows that when you meet a problem that you don’t know how to solve, you just search for the answer online. And this works 99% of the time. But occasionally you don’t find a solution, and you have to figure it out yourself. Hopefully this blog post means some other programmer doesn’t have to do the hard yards we have done. Our problem was simple. We wanted to show artwork on a hoodie where the drawstrings hang over the artwork.
It is well-known that it’s a poor idea to store your application secrets in plaintext files, especially if they get committed to version control. So what should you do instead? Previously, we have attempted to solve this problem by having a file that only exists on the live environments, but that is tricky to support. In this post, we describe how we use Amazon’s Key Management Service to safely encrypt our precious secrets…
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.
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.
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,