I recently presented to the Bankwest Solutions Delivery Group on the processes and technology we use that allows us to deploy our sites up to 10 times a day.
A couple of months ago I presented at LoneStarRuby 2013 in Austin, Texas. While I’ve done a few presentations for work and locally in the past, I’ve never presented at a proper developer conference before. I knew from experience that the standard of presentations at Ruby conferences will tend to be pretty high, so rather than risk being the token crappy presenter (that you occasionally see - and feel sorry for), I set out to do a bunch of research on what makes a decent presentation. Watching videos by such presentation luminaries as Ben Orenstein and Scott Hanselman, as well as reading old favourites like Presentation Zen and Confessions of a Public Speaker. In the next few paragraphs, I’ll show you my talk as well as try to distill everything I learned and hopefully save some fortunate developers hours of effort in the future.
Last week the Envato Marketplaces reached a milestone: for the first time we handled over 70 million page requests on our Rails stack in one week … that’s 10 million a day!
Our Rails app powers seven separate Marketplace sites, the most well-known of which is Themeforest.net and based on this article it ranks in the top 5 Rails sites in the world by traffic. The marketplaces are for buying and selling a wide range of digital items, and we sell an item roughly every 10 seconds. A couple of our sellers–we call them authors–have sold $2,000,000 worth of items and another six have sold over $1,000,000.
Not so long ago, cross-browser testing meant firing up different versions of Internet Explorer, Chrome, Safari, Firefox and (possibly) Opera on multiple operating systems. Add in the ever-growing multitude of mobile devices now available, and it can be a real challenge developing your site to deliver a consistent experience to all.
We’ve been big fans of SMACSS for a long time, however a pure SMACSS approach works best with plain old CSS on a brand new project. On our marketplace sites, we write style sheets in Sass and have several years’ worth of legacy CSS to deal with.
We’ve recently been refining the way we do CSS to make it easier for our growing team to maintain our style sheets without throwing away our existing front end & starting from scratch.
What we’ve ended up with is an approach loosely based on SMACSS that still solves the problems originally tackled by SMACSS & OOCSS, but with a few modifications and some ideas cherrypicked from places like BEM and Toadstool.
At the first Australian Ruby Conference, Keith Pitt and I were lucky enough to present a talk on Fast Websites. We were joined by over 20 other Envato developers attending the conference, in the sunny city of Melbourne.
We wanted to demonstrate all of the performance gains that could be made using a real application, so we created Giftoppr: a site that lets users share animated gif images using Dropbox. We also created a website benchmarking tool called WBench, which we use together with other existing tools throughout our presentation. We released both Giftoppr and our WBench tool as open source software.
In our presentation we take our slow loading Giftoppr application (initially it loaded in around 9 seconds) and set a goal to reduce the loading time to be under 2 seconds. Using a variety of simple techniques we slowly chop away at the loading time until we reach our goal.
The Envato marketplace sites recently upgraded from Rails 2.3 to Rails 3.2. We did this incrementally at full production scale, while handling 8000 requests per minute, with no outages or problems. The techniques we’ve developed even let us seamlessly and safely experiment with mixing Rails 4 servers into our production stack in the near future.
We wanted to be able to confidently make the huge version jump without having to do an all-or-nothing cutover. In order to achieve this we made a number of modifications that allowed us to run Rails 3.2 servers side-by-side on our load balancer with all of our 2.3 servers. This let us build confidence in our upgrade to the new version gradually with far lower risk of our users receiving a bad experience.
If you are still stuck back on a Rails 2.3 app, this should help kick start your upgrade progress to Rails 3 (and beyond to 4 if you’re ready).
This post will go into the technical details around making this upgrade as smooth as it was.
Charlie Somerville and I presented a talk at the Melbourne RORO (Ruby on Rails Oceania) meetup regarding the recent Rails 3.2.10 security hole, as well as the Slow HTTP Read Attack and how it affects certain Rails stacks.
We decided to experiment with the structure of the talk by weaving in a narrative. We called it “chendo’s 11”, parodying Ocean’s Eleven. The story follows us planning and executing a revenge heist against a fictitious illegal gambling website called “Casino King On Line”.
On Thursday the 10th of January at around 3:25am AEDT (UTC+11) the Envato Marketplaces began suffering a number of failures. These failures caused searches to stop working, buy now purchases to be charged but not recorded, newly submitted items to not be processed, our review queues to be blocked by error pages and the site to be generally unstable.
We’d like to take the time to explain what happened, why so many seemingly unrelated areas of the app failed simultaneously and the measures we’ve put in place to try to prevent similar problems from occurring in the future.
How do you change around pretty much everything in your search backend, but still remain confident that nothing has broken? (at least not in a way you didn’t expect).
We can use statistics to do that. In particular, a technique called Spearman’s rank correlation coefficient. Let’s have a look at it, and see how we can use it to compare search results before and after a change to make sure relevancy rankings haven’t gotten screwed up in the process.