Monitoring your application is important - full stop. When the response time plummet’s you want to know before your customers do…and certainly before you bother to check your twitter feed. There are lots of options here, and a lot of them require a ton of upfront investment in terms of time and effort. However, a simple way to get started is to simply log total request durations and track the number of successful and failed responses.
I generally find that most developers are fairly aware of and willing to apply the DRY principal on their main codebase. However, when I look through people’s tests, I find that the old copy/paste habit has found it’s way into their workflow (again?). I’m using “their code” to save face here…I found this in my own code and started looking for ways to clean it up. So, let’s take a look at an example of how we can remove some duplication from our specs.
Last night I attended my first Ruby Brigade Meetup in Toronto and I have to admit…it was kinda fun! It was graciously hosted at Influitive’s downtown office on Adelaide St. When I got there I was happy to see some fancy boardrooms and a bunch of pairing stations for us to use. All in all, a great location. We got a little caught up in some general technology discussions so as expected we got started a little late.
I recently started playing around with EmberJS. While I was insanely impressed with how easy it was to get a single-page app up and running, I was having difficulty getting QUnit setup correctly. After some finagling I was able to get it working. In my particular case I’m using Ruby 2.0.0 and Rails 4.0.0, though I’m sure this same setup would work with previous versions with minimal (if any) tweaks.
Frequently I find myself creating basic rails apps to demonstrate a new feature, or prototype something for a spike test. Every time I created an app, I would run rails new -T, then add RSpec, Cucumber, Haml, possibly Bootstrap, etc. After the 10th app in a month, I decided that there must be an easier way. Then I saw this post: http://everydayrails.com/2011/02/28/rails-3-application-templates.html I started reading up on generators and application templates, then I thought I’d write my own, to see how it works.