How We Deal with Failed Resque Jobs
The Grouper Engineering Blog posted a good description of what it’s like to host Resque on Heroku:
The Grouper Engineering Blog posted a good description of what it’s like to host Resque on Heroku:
We call it “Old Admin”. A basic admin interface (similar to Rails’ Active Admin) built by an outside team before the current engineering team arrived. For a time it ran our whole business. One of the first tasks of our original engineers was to replace it with something more sophisticated. However, limited as it was in many ways, it inadvertently taught us some good lessons about designing internal systems.
I am excited to announce the newest addition to the Stitch Fix algorithms team, Jeff Magnusson. Jeff will join us as the Director of Data Platform, and will be primarily responsible for developing the architecture on which the Stitch Fix algorithms will run.
We use Resque at Stitch Fix…a lot. For background processing or getting work out of the web request/response loop, Resque is our go-to technology.
The ability to quickly create and deploy an application is crucial to avoiding a monolithic architecture. I touched on this in my talk at RubyNation, as well as my post here, but a key part of that ability is to script the actual creation of the application so that it’s ready for your infrastructure and your team. At Stitch Fix, we use Ruby on Rails for most of our applications and, fortunately enough, Rails provides a handy feature called application templates that allows you to script the creation of a new applications with whatever boilerplate you need.
Like most good Rails developers, we use presenters at Stitch Fix. We typically implement them using delegation, but I’ve been finding that the time savings of this approach over just making a struct-like class is negligable, and results in code that’s harder to change and harder to use.
Stitch Fix is the third startup I’ve worked at, and the second where I joined at a fairly early stage. So far, we’ve been able to avoid creating a single monolithic application, and have been consistently delivering and deploying solutions to our users. I believe this is because we’ve developed a set of “super powers” which have been extremely helpful, and I believe these powers will keep our team and technology healthy for years to come.
An old post from Linus Torvalds about using git popped up on Hacker News today, and reminded me of the complex gitflow workflow, as well as Scott Chacon’s post on “Github Flow”, both of which are excellent reads.
At Stitch Fix, we outsource pretty much all of our hosting and technical needs to Heroku or their add-ons. Given where we are now as a company, it makes total sense: we don’t need to hire an admin, we don’t need to adminster actual boxes, and we can easily add/remove/change our technical infrastructure. If you are a small startup and you are messing with Linode slices, you are probably wasting time.
Tonight Jon Dean will be giving a lighting talk at the Pittsburgh Ruby User Group to talk about why business logic in Rails applications should be moved out of the model and into pure Ruby classes. If you’re in the Pittsburgh area be sure to stop by and introduce yourself!