Yesterday I wrote a blog post about why Rails needs a better story for CoffeeScript development. Today, I'm going to describe a solution (not THE solution) for making it much nicer. We will be using CSpec and CSpec-Rails. CSpec CSpec is a RSpec-inspired library for CoffeeScript. The nice part about CSpec is that you are writing your tests in CoffeeScript for your CoffeeScript files. There is no need to compile either the specs or the code down to JavaScript. CSpec runs on top of NodeJS. I realize that this is a large dependency for CSpec and is one of the...
more
In Rails 3.1, CoffeeScript was introduced as the default language for client side interactions (and with vociferous discussion from all sides). I was very excited by the choice made by the Rails team and have been gnashing at the teeth to get my hands on a project with Rails and CoffeeScript working in gorgeous harmony. What I found was that for production code Rails and CoffeeScript work together swimmingly, but the development story is, at best, incomplete. Writing a feature in CoffeeScript A thought experiment: let's walk through the development of a feature. Let us try GitHub's "Command-T" functionality to...
more
Grab a beer. I did not intend for this to be as long as it is, but I geeked out a little. Hopefully you'll find this as entertaining as I did. There is a coffeescript implementation that runs on top of the Rubinius virtual machine. Without getting too into why that tingles my geeky insides, that's pretty cool. It started to get me thinking about the future of Rubinius, languages and the forthcoming platform race. Virtual Machines All code manages to get compiled down to machine instructions. These machine instructions are based on the architecture of your processor but look...
more
Team Foundation Server (TFS) from Microsoft is an application lifecycle management (ALM) solution that is deployed across many development teams and organizations. After working with TFS for 3+ years, I have come to the conclusion that organizations are better off without it and should look to adopting best of breed tools (of which, I claim, TFS is not part). This post addresses three topics: the technical flaws of TFS and its subsystems, the culture TFS encourages and strategies on how to get out. TFS Sucks For developers, tooling can inspire almost religious dogmatism and fanaticism. This is understandable. We work...
more
I am currently playing around with a NodeJS stack where I am writing Coffeescript for my application. To render my views, I am using Haml. HamlJS only used javascript. So, here is a quick and dirty plugin that lets you use coffeescript in those views! I apologize for the lack of tests and please let me know if there are any errors that you find.
NPM Registry
GitHub
more
The Hacker Chick (Abby Fichtner) wrote about continuous deployment (edit: almost 2 months ago.. my bad!) and posed the question about whether it makes sense. She presents 2 possible options: 2 week iterations and continuous deployment. There is a middle ground[1] between the 2 week iterations and continuous deployment. The idea behind continuous deployment has two proposed benefits. First, there is the technical benefit that consistently running through your whole deployment stack makes it less cumbersome and more reliable. Generally, continuous deployment encourages automation and 'hands off' deployments where very little human interaction is involved (usually just a push of...
more
This one took a little bit for me to figure out and I thought that I'd share the solution. it "should route root to home page" do opts = { :controller => 'home', :action => 'index'} assert_recognizes opts, '/' end If you read the testing Rails guide you'll notice that they make a brief mention of the assert_routing. That code takes the hash key and composes a route based on the parameters. This doesn't necessarily work for the root, though. In order to do that, you need to compose the route hash from a relative URL. That is what assert_recognizes...
more
The last mile of a marathon is always the most difficult. You've run 25 miles and you just need one more. You can see, smell the finish line. It's right there in front of you. It is the most difficult (and dangerous!) part of a marathon. In software development, the last mile problem is a big one. You've decided on a product, designed the user interface, architected a great technical solution, executed on delivering business value and passed a testing suite that ensures quality. Now you just have to release. Releasing is the most difficult and dangerous part of software...
more
Testing software is one of the primary roles of software developers. In the developer's day to day, tests can use up as much time as any other activity (including writing features). Yet, so little seems to be known about the properties of tests. What qualifies as a good test? What classifications are there? What does tool X accomplish in testing? These are big questions that I may take a stab at later. This post is going to focus on one area of testing: unit tests and fake objects. Unit Tests Unit tests, from the perspective of mocking, fall into two...
more
Updated the about page. It is rather lengthy. I also updated the look of the site. I actually reverted back to the Google Font API because I like the look better. Impact isn't good for readability.
more