3 Technology Components to Learn in 2010
Posted by: Justin in Programming, Rails, tags: lists, Programming, RailsSass/Compass
I spent a good chunk of the last few months of 2009 completely immersed in Haml, and having spent time using both ERb and the templating language that ships with ASP.NET MVC, I have no intentions of ever turning back. That being said, Sass seems like the next logical choice for cleaning up my html/css, and while I was a bit confused as to the point of Compass (other than being a Sass compiler – which I already get for free through the Haml gem), Chris Eppstein finally gives up the goods about 15 or 16 minutes into his Compass screencast (the first 15 minutes are great too, but if you already have a grasp on Sass, they’re a bit redundant).
Long story short: I’m tired of sucking at CSS, and short of completely immersing myself in the spec, learning the idiosyncrasies of which browser supports which feature, and then somehow retaining all of that information, Compass with Sass seems very appealing.
Related Technologies: Blueprint, YUI
RSpec
While I’m still not quite a ninja in Test::Unit, I finally feel at least proficient in it, and though I’d like nothing more than to proclaim my love for Shoulda from the highest peak of the highest mountains, I feel that I at least owe it to myself to check out RSpec before I consider the book closed on testing frameworks in Rails.
Related Technologies: Cucumber, Factory Girl, Mocha
Hudson
I spent the first three or so years of my professional life completely immersed in the .NET world (ignoring that first year spent looking at COBOL mainframe code), and in that world, CruiseControl .NET is king of the continuous integration castle. So, when I came into the Rails fold, I naturally turned to cruisecontrol.rb for my continuous integration needs. Unfortunately, either I haven’t yet fully grasped the extensibility of cruisecontrol.rb or the community simply hasn’t yet matured to the level of CC.NET, but I am so far underwhelmed by the Ruby version of this popular continuous integration solution. Luckily, while first learning Rails, my initial confusion over cruisecontrol.rb led me to stackoverflow where someone suggested checking out Hudson … six months later, I think I just might give it a try.
Runners Up
Git – Git is an incredibly popular SCM solution in the Rails world, so I will eventually need to learn it. For now, I think I’ll wait and hope that the tooling matures a bit more.
E-TextEditor – If it weren’t for the need to drop down into Cygwin to run rails apps, this would have been a no brainer. Unfortunately for e, Netbeans still has a much, much shallower learning curve. Unfortunately for Netbeans, it can be very, very slow, so e is something else that I will eventually need to learn.
Additional Resources
This list is still (by far) the best resource I have found for identifying new technology avenues to pursue.
Entries (RSS)
Sadly, the Ruby world still hasn’t caught up with the Java world when it comes to IDE support. Other than that, all is good. It seems from your post that you’re actively developing on Windows. Any particular reason why (or did I musunderstand)?
For CC.rb, what features were you looking for that CC.NET has? (I have exactly one commit to both, but still, maybe I can help
)
Yes, I’m still mostly developing on Windows, with the main reason being that I’m still much more comfortable with Windows over Linux, and I haven’t yet been able to justify the purchase of a Mac (though that day is eventually coming — I can feel it).
In terms of CC.rb, honestly, the things that I miss most from CC.NET are the robust documentation and the community. Sadly, unless I’m missing something, both of those things seem to be missing from CC.rb.
Hey. You’ve got a blog! Cool.
Yes, I do!
Unfortunately, nobody bothered to tell me that “having a blog” and “writing a blog” are two different things. I assumed that by simply throwing up a blog engine, it would magically start filling up with interesting and relevant postings.
Compass and SASS _can_ help you to abstract away browser rendering quirks but that doesn’t mean you shouldn’t take the time to understand why the quirks exist in the first place. Understanding things a few levels below the abstraction is a core characteristic of being a good developer
If you dig a little further into Compass/SASS you’ll find the true power lies in the ability it gives you to truly separate the presentation layer from the structure layer; that is: separating your HTML from your CSS. When your HTML is purged of presentational classnames and ID’s you preserve the life of your markup by making a clean separation between style and structure. Simply put, using SASS allows developers to code using patterns that enable you to swap out the style layer the way that CSS was intended to. You _can_ do this with pure CSS but Compass and SASS make this far easier with abstractions, mixins and variables.
Dave, I agree 100%. One of the things I’m looking forward to in using Compass/Sass is spending less time building the basic skeleton structure of a site and more time understanding _why_ a particular structure works.
Unfortunately, right now, I spend probably 90% of my time in CSS building up the basics to work in Chrome/Firefox, and then 10% trying to run around fixing small bugs/quirks. I’m hoping to leverage Sass to drastically cut down that 90% so that I can spend more time trying to understand why those small bugs/quirks are appearing in the first place (and how to fix them in such a way that I’m not just applying a band-aid).
Nice blog, by the way. I just subscribed.