I wanted to ask him why Guard is important. Paavo has been very enthusiastic about Rails Apps Composer so we created this interview. I swear a public relations firm didn’t edit this, it’s just Paavo’s natural enthusiasm that comes across here.
Why do you use Rails Apps Composer?
I work for Protoverstas in Finland which provides an agile three-week program to launch application ideas. Rails Apps Composer is an invaluable tool when prototyping and pivoting applications at a fast pace for demanding clients. It would be way too tedious to always start with “rails new” without any template. So Rails Apps Composer means less typing work for us and faster profits for our clients!
Tell us what’s on your desktop.
I do full-stack test-driven Rails development on OS X. I like to keep my environment as minimal and esthetically pleasing as possible. On my main monitor I keep two windows open side by side: MacVim as my text editor (using the Janus distribution with its amazing plugins) and iTerm2 as the terminal (running automated tests with Guard in one tab and using the zsh command line in another tab). I use the Solarized color theme in both, so they are easy on my eyes.
What is your Rails stack?
I’m very opinionated as a developer. I prefer PostgreSQL or MongoDB for most projects. I couldn’t imagine writing plain HTML again, so HAML is a necessity for me, as well as Coffeescript and LESS. Fixtures feel way too old-school, so the Fabrication gem is my choice. So is all the manual work needed for default forms, so please, SimpleForm for me. I like to deploy to Unicorn (and of course use it for development, too). These more or less permanent preferences are included in my Defaults file as described in Rails Apps Composer documentation.
What else do you need in a starter application?
Twitter Bootstrap is handy in some cases, though sometimes it’s best just to normalize CSS. Most apps I write require some kind of user management, so it’s cool that Devise and Omniauth provide most of the boring stuff right out of the box! Their routes and basic views are set up when using Rails Apps Composer, just how I like it.
What about testing?
I really want to encourage more developers to make test-driven development part of their practice. For unit testing I use RSpec and request testing I do with RSpec and Capybara. In my opinion Cucumber doesn’t provide that much value itself and in many cases acts only as a proxy to Capybara’s functionalities. In an ideal world, testing controllers, views, helpers, and routes all as single entities would be nice, but in the real world… just not worth it. Thoughtfully designed and well-written unit tests and request tests can make your test coverage rock solid.
How does Guard fit in?
When I edit and save any file in my Rails project, Guard keeps track of tests that are affected and runs them automatically. I see results immediately in my terminal window without needing to touch anything! It’s easy to keep track of which tests are passing already and which still need some more work.
On my second monitor I keep a browser open. Luckily I don’t need to touch it much, because automated tests do the boring and repetitious clicking work for me! Even when I need to touch it, I can do it without using the mouse, thanks to the Vrome plugin providing Vim-like controls for Chrome. Guard also restarts the Rails development server when needed, and monitors the Gemfile (automatically running “bundle install” as needed).
Keeping the development process streamlined and my environment beautiful helps me focus and keeps my quality standards high. Writing ugly code, copy-pasting or leaving features untested would feel just plain wrong. The right tools are important. So thanks, Daniel, for making my daily work more pleasurable with Rails Apps Composer!
Thanks, Paavo, for letting me know how it serves you, and for taking time to describe your work environment. And especially, thanks for contributing the Guard option to Rails Apps Composer.