Spree is the webshop solution for Ruby on Rails, and Heroku is the place to host your Rails-applications – especially if you like free hosting :)
Finding myself in the need of a webshop, I decided to try to deploy Spree to Heroku. It wasn’t too hard, but it did take a few tricks to get Spree running on a server that doesn’t allow you to write to the file system.
I can’t say I have too much hands-on experience with Spree yet, but it seems to be have borrowed its extension concept from Radiant CMS, which happens to be one of my areas of expertise. So I put together an extension for Spree that will easily allow you to deploy the e-commerce system to Heroku.
Just follow the instructions in the README on Github.
If you are a Rails-developer, and you don’t know about Heroku, now would definitely be a good time. Heroku is a platform for hosting web-based Ruby applications in “the cloud”, in this case Amazon EC2, making you able to scale your application in an effortless and cost-effective manner without worrying about the hardware behind. Heroku differs from competition by offering by far the fastest and easiest way to deploy your Rails-application. You simply create your application from Heroku’s web interface or using their API, and then push your git-repository to Heroku’s git-server. Heroku takes care of the rest, and you can get back to coding.
I use Heroku for Capistrano, once that has been setup with the right recipes and the server has been setup to corporate and serve our web application properly. But that can also take some time, especially on a brand new server.
When I recently started development of a new, big Rails project, I spend some time researching and considering the many different testing frameworks that are available in the Ruby community today. I have grown very satisfied with the fail/pass rhythm of test-driven development (TDD) – write a test that fails, then write just enough code to make it pass. I also like RSpec a lot, so some would say that I am fact doing behaviour-driven development (BDD) – to me, the only real difference between TDD and BDD is the syntax, and I tend to find RSpec’s examples slightly more readable TestUnit’s tests. TDD gives me a small gratification – a sense of accomplishment, albeit on a small scale – every time a test passes in my autospec terminal.
Howver, TDD’s basic rule of always writing a failing test before writing any new code, doesn’t always leave me feeling very productive. For this reason I have mostly abandoned testing views in isolation (as made possible by RSpec’s view tests), as well as testing Rails helpers with the exception of complicated helper methods with some business logic in them. I still tests views by, behold, viewing them in the browser, and I haven’t been swept away by Cucumber, Webrat, Selenium and their fellow high-level test frameworks yet – but I am open.
Hello, I'm Casper Fabricius. I have developed for the web for 10 years, and have been enjoying Ruby on Rails for the past 5.
My experience covers communities, shopping solutions, multi-language sites, heavy back-end lifting and a wide selection of more traditional websites. I like to integrate Ruby with Java and .NET through JRuby and IronRuby when it makes sense. I am passionate about test- and behavior-driven development, but at the same time I am pragmatic and believe in getting things done.
I live in Copenhagen, Denmark, where I work for a fantastic company: Podio. I do not currently take on freelance assignments.