I intended to check out the Tune SQL Server Like a Guru precompiler session being presented by Kevin Boles (@thesqlguru) but I was so enthralled with Ruby that I holed myself up in my room for 10 hours going through Pluralsight courses and messing with Ruby on Rails.
I went through the course Ruby on Rails – A Jumpstart for .NET Developers by Dustin Davis (@prgrmrsunlmtd) to get my environment completely setup for Rails development first. Once I got setup I went to 1.6x speed through the rest of the course, and managed to not feel too overwhelmed by anything. Everything from my initial foray into Ruby was still in my head. I was in the zone and feeling a little cocky, so a simple blog site was no big deal…on to bigger and better things.
Next I hit the course Ruby on Rails 4: Getting Started by Samer Buna (@samerbuna). This was creating more of a “full featured” web application than the blog site in the first course, but many of the concepts covered in the first are repeated which isn’t necessarily a bad thing. Thankfully I did them in this order, because I don’t think I would have been able to get everything setup quickly if I had done this course first, as this requires a higher version of Ruby and Rails – more on that later.
Amazingly any error encountered in the rails console spit out the URL necessary to fix the issue and even more amazingly it actually worked the first time every time. What did cause me some issues was when I attempted to download the course files for the first tutorial and run them without actually doing the development work. I now know that upgrading/downgrading Ruby and/or Rails versions is not necessarily a trivial task for a “newb” such as myself.
I attempted to upgrade the Rails version for the blog site created in the first tutorial without doing my due diligence – which proved to be a painful, but useful learning experience. I spent roughly 3 hours figuring out what gems worked in 4.2 and why, as well as diving into some of the core pieces in 4.2 such as the HTML Sanitizer and DOM Testing.
As I spend most of my development time in the world of SharePoint, I made the quick realization that the Rails upgrade should be treated with the same level of “care” as a SharePoint migration. Fortunately, Ruby on Rails has documentation for just such a task, and there were a plethora of blog posts (I really liked this one from Justin Weiss on upgrading to Rails 4.2). Many of the same high level concepts apply to SharePoint migrations and Rails upgrades:
- Plan upfront
- Know what the changes are to the version you are upgrading to
- Know your “customizations”
- Upgrade incrementally
- Test everything
It’s very similar to when I was a little kid tearing apart the old Betamax (Yes, those were a thing young ones). If you want to know how something truly works, tear it apart, put back together, tear it apart again, then try to make it better.