Monthly Archives: February 2012

Season of Ruby – Iteration 4 Retrospective

Iteration 4? Wait, shouldn’t I be on Iteration 5?  Yes, but as expected work reared its ugly head and the Season of Ruby got pushed to the back of the line.

I am now through Chapter 8 of the Ruby on Rails Tutorial.  I wish I had tracked the actual time spent on the tutorial, that would have been useful information for anyone wishing to follow the same roadmap.  I would estimate I have spent around 14-16 hours through the first 8 chapters.

What Went Well

  • In the interest of trying to get as much as possible, I am resisting the urge to cut-and-paste from the tutorial.  You learn a lot from mistakes, big and small, so there is a lesson to be learned when you type “name” or “@name” when what you really needed to type “:name”.
  • I still think one of the strengths of this tutorial is the focus on TDD.  As I have started to get more comfortable with the environment, I have also been trying to implement solutions on my own after writing the tests from the tutorial.  That makes me feel like I am starting to get more of a lay of the land.
  • Used the FactoryGirl gem to simulate model objects for testing.
  • Got my shiny new MacBook Pro and have switched all my Ruby and Rails development from Windows.  It was really cool once the environment was set up to grab the repo of github and pick up right where I left off.  BTW, I used the thoughtbot laptop project to get my system all set up for Rails development.  Went pretty smoothly.

What Can Be Improved On

  • I feel a little like how I felt during the Ruby Koans, that I am gaining a false sense of knowledge by following the tutorial.  It has been really helpful to get me moving forward with Rails, but you are still following a well-defined roadmap.
  • I want to finish the tutorial because I think there are several more lessons to learn and it will be a great reference to look back on, but I am anxious to start from a clean sheet of paper and make a ton of mistakes.  That is when the real learning will happen.
  • I have been pretty good about not doing a lot of cut-and-paste from the tutorial, but at times it is hard.  Just need to keep forcing myself to resist doing that.
What Am I Going To Do To Improve
The most learning has come in cases where I have tried to implement my own solutions after using the tests as provided from the tutorial.  From this point on, that will be the approach I will use.  Then when I have a passing test I can look at the tutorial and compare my solution against the tutorial solution and take that as a refactoring exercise.  It may take longer, but it will pay dividends down the line.

Iteration 5 Stories/Tasks

Chapters 9 and 10 of the Ruby on Rails Tutorial, implementing my own solutions first after using the tutorial tests to get to “red”.

New Startup Accelerator Program Coming To Boston

There is a new startup accelerator looking to set up shop in Boston this summer.  The thing that caught my eye is that this accelerator, Bolt, will focus on connected devices.  Real…physical…stuff.

I think that this is great for the Boston area.  We already have a lot of energy and effort in the area around startups for mobile, web, and software services, but I think this will help bring other engineering disciplines into the Boston startup community.  The ability to iterate in the mechanical/electrical world has improved a lot over the years, especially with the widespread use of 3D printers, electronics prototyping, and OTS platforms like Arduino.  It will be interesting to see how lean startup principles come into play in the physical world (yes, I know that’s where they came from initially)

As someone who has spent most of his career doing software for robotics, automation, and medical devices this will be something to keep an eye on.

Season of Ruby – Iteration 3 Retrospective

I am now a month into the  Season of Ruby, so aside from the usual retrospective, it is a good time to reflect on what I have learned to this point.  In the last month I have made the following strides:

  • Set up a github account and pushed code up to it.
  • Re-familiarized myself with git and got more practice using it on a day-to-day basis, creating and merging branches, as well as pushing code to github and heroku.
  • Learning the basics of Ruby and used it to develop an implementation of the Conway’s Game of Life
  • Picked up a little Rails with the Ruby on Rails Tutorial

What Went Well

  • I am really enjoying the Ruby on Rails Tutorial, not just for how it teaches Rails, but as much for the developer practices that it encourages.
  • Gave some thought to the overall roadmap of where I want to go for the next few months.  I thought this website gave a good picture and though I will customize it a bit, I think a lot of the areas I want to build on are covered here.  For me the areas that I want to focus on in the next few months are a strong foundation in Ruby along with a better understanding of JavaScript (and CoffeeScript), and CSS.  I have a few ideas about an app I can put together that will provide an opportunity to strengthen those areas.

What Can Be Improved On

  • Practice, practice, practice.  The tutorial is really helping me put all this together, but I need to keep repeating the lessons to make sure it sinks in.  Similar to what I went through with the Ruby Koans, I don’t want to develop a false sense of understanding, so I need to keep writing code and making sure to dig beneath the surface.
What Am I Going To Do To Improve Things

To make sure I am really grokking the lessons from the tutorial, I think it would be a good idea to take a few hours at the end of this iteration and write a simple app.  Something similar in complexity to the micro-blogging example in the tutorial. It doesn’t need to be a complete application, but the parts I get to need to be “right”, so I will time-box it at 3 hours. Does not need to be visually pretty.

Iteration 4 Stories/Tasks

Keep chugging away on the Ruby on Rails tutorial.  I am through chapter 5, but this is going to be a long week at work, so I would like to be able to get through chapters 6 & 7 this week.

To make sure I am really absorbing the tutorial lessons, develop a simple application without referring back to the tutorial documentation.  Going through other documentation is OK, e.g. StackOverflow, Ruby Core Docs, Rails Guides.  Time-box it at 3 hours, and follow good developer practices, i.e. use TDD, git/github.  Application is TBD, but should be similar in complexity to the micro-blogging example.

Halftime Review of Michael Hartl’s Ruby on Rails Tutorial

I am a newcomer to Ruby and Ruby on Rails, so when I wanted to get started with Rails I looked around quite a bit for a good starting point.  I finally settled on Michael Hartl’s Ruby on Rails Tutorial.  I am about halfway through with the tutorial, and I am really pleased so far.  This is a great tutorial for a lot of reasons, but the aside from just teaching Rails, he is also teaching good development practices such as:

  • How to use git effectively.  The tutorial starts out with git basics and then quickly moves on to integration with github, working on branches when adding new features, and merging changes back into the master.
  • Focus on testing.  We start out with RSpec writing unit tests, but then also add in integration tests.  He also follows a TDD approach for a lot of the tutorial where the tests come before the code, a practice that I believe strongly in.
  • Stresses good developer practices like running your tests before and after merging a branch.  Sure the merge probably went fine, but be a good citizen and test it before you push it up to github.
  • Refactoring your code to reduce duplication and make it more readable and maintainable.
  • Shows how to deploy your code up to heroku
  • Introduces real world work practices like sketches and wireframes.
The focus on testing, refactoring, and general good developer practices is important to me.  These are practices that I have been using for a long time, but it is great to see them so much a part of Ruby on Rails.  Just seeing that standard project hierarchy includes a place for tests tells you it is ingrained in Rails.  I really loved this quote from the tutorial

If you ask five Rails developers how to test any given piece of code, you’ll get about fifteen different answers—but they’ll all agree that you should definitely be writing tests

As far as the Rails side of the tutorial goes, I think after my initial environment snafu (that’s all on me), things have been going great.  I am starting to see more of how Rails implements MVC.  MVC is obviously not a new concept, it’s been around for a while, but each framework and environment uses it differently.  I also really enjoy the ordered structure of a rails project and can see what an advantage it is to have this kind of common project structure.  I know ASP.NET MVC also tries to use a standard project hierarchy, but rails felt a little cleaner and more intuitive.

After some simple applications to get your feet wet and make sure your environment is good to go, the tutorial uses a micro-blogging application to slowly walk through the different capabilities in rails.  The tutorial also explains some of the “magic” that goes on under the covers that Rails provides for you.  This has encouraged me to route around (pun intended, thanks) to understand more of the magic.  Aside from routing, we have also hit a bit on database integration and migrations, some CSS, and partials.

One thing this tutorial will not teach you is a lot of Ruby, and the author is quite clear about that.  He provides some good references for learning more Ruby, but the focus here is on Rails, and he keeps the amount of Ruby necessary to a minimum.

I am about halfway through and am hoping to finish up in the next 2 weeks.  It is a little slow going because as I learn I often go off to investigate different aspects of what I am learning.  Finishing the tutorial will not be the end of the journey, but it certainly has helped get it going in a good direction.  I recommend it highly to anyone interested in getting started with Ruby on Rails.

Season of Ruby – A Bad Day Of Fishing

I have been really excited to get going with Michael Hartl’s Ruby on Rails Tutorial.  Skimming through the table of contents and the introduction, I liked that he makes testing such a focal point of the tutorial.  I also liked the Comments for Various Readers section.  I fit into the “Experienced programmers new to web development” camp, and after reading the introduction I knew  that this would be a great tutorial for me.

The first section was well laid out, and focused on getting your environment set up.  It also touched on using git and github which is starting to feel like old hat for me, but then it ended with deploying the sample app to heroku which was a new thing for me.  As someone experienced in software development, but new to web development, it was great to have the heroku deployment so well explained and easy to do.  I was feeling quite full of myself.

Then came the 2nd chapter…

Someone once said “A bad day fishing is better than a good day at work”.  Oh yeah, tell that to Captain Quint, he looks like he is having a pretty bad day fishing.

A Bad Day Of Fishing

Now you could argue that he’s actually just having a good day at work, since technically, as a fisherman, he is at work.  But I digress. Up to this point my Ruby experience has been all pie and ice cream, but today was a bad day of fishing with Ruby.

The author goes to great length to explain that the tutorial uses an older more stable combination of Rails/Ruby versions and that is what you should install.  But I am sooooooo much smarter than that and besides, I want to use the newest stuff.  To say the least, I ran into a lot of problems with getting the right combinations of Ruby, Rails, sqlite, etc, etc working.  I learned a lot about gems and bundler along the way.  I think things were further complicated by running on a Windows box as well.

After a lot of time fighting my environment, I realized I was fighting the wrong battle and the smart thing to do was to get the environment set up as the author intended to be able to get the most out of the tutorial.  Once I made that decision I was back on the happy path and am looking forward to moving on to more in-depth parts of the tutorial.  I don’t feel like it was a wasted experience, because I did learn quite a bit digging around.  I imagine this can be a significant issue for Rails projects, especially as new versions of Rails, Ruby, or different gems roll out and that the correct dependencies need to be addressed.  It reminded me a lot about the “DLL Hell” days of Windows before .NET.

The take-away is if you decide to do this tutorial follow the author’s advice and set up the environment as specified.  The lessons to be learned are more to the core of Rails and running the latest version of Rails or the application’s dependencies is not important.  And now that I am on the right track I am looking forward to moving on to more advanced sections of the tutorial.

Season of Ruby – Iteration 2 Retrospective

Things are coming together well with the Season of Ruby.  Getting out of my comfort zone was a driving theme and there has been some discomfort, but I am now establishing a new comfort zone, familiarizing myself with a new language and new tools.  There is still a lot of work to do, but I am really pleased with how things are going.  And with that, on to the retrospective.

What Went Well

  • Got to write more code this iteration.  I wrote a Ruby implementation of Conway’s Game of Life.  I really love to code and sometimes I don’t get to do that enough in my day job.  Solving a problem was a lot of fun.
  • I stayed true to TDD, which is my standard way of working, but given the new tools it is important to stay true.  So far I have been using test-unit, but I also got a look at some RSpec.
  • Played around with forking a project on github, starting to get more comfortable with the workflow.

What Can Be Improved On

  • I hit a roadblock with TDD when I got to a point where in .NET I would use a mocking framework.  The reason I wanted to mock was because I was interested in testing behavior and not state.  I wanted to know that the GameOfLife class was interacting with the Cell class in the correct sequence.  Need to understand how that type of testing would be done under Ruby.
  • I need to understand how to structure my projects in Ruby.  That will mean looking at more code and also learning tools like Rake.
  • Start thinking about the overall roadmap of this adventure.  I’m into it far enough now that I am starting to feel comfortable with the tools, now it is time to start doing some longer range (1-2 month) planning.
What Am I Going To Do To Improve Things

I still have some work on Ruby fundamentals, but I would like to get a simple Rails project under my belt to give me some context and also to start the long term thinking.  I was considering the Ruby on Rails Guides, but now think I will take a crack at Michael Hartl’s tutorial.  It seems a little richer and also seems to really focus on testing.

Iteration 3 Stories

“Stories” is a reach this iteration.  I am back into uncharted waters with Rails.  I don’t know what I don’t know yet.  Instead I will just put in at least 6 hours on  Michael Hartl’s tutorial

Season of Ruby – You’ll Always Remember Your First Fork

Forking the cocaine project gave me a chance to see a little bit more of Ruby style, at least with an ‘n of 1’.  The goal wasn’t to make any sweeping changes, just get it to run, see some of the style and implementation choices, and break through another barrier, i.e. forking a project on github.  Some of the things I took away from the exercise:

Keeping code lined up by column seems to matter from a style perspective:

def initialize(binary, params = "", options = {})
   @binary            = binary.dup
   @params            = params.dup
   @options           = options.dup
   @logger            = @options.delete(:logger) || self.class.logger
   @swallow_stderr    = @options.delete(:swallow_stderr)
   @expected_outcodes = @options.delete(:expected_outcodes)
   @expected_outcodes ||= [0]

I have followed this style in the past, but found it a pain to maintain. Not a huge pain, but you have to rearrange the whole set if you add something longer than what is already in there. I’ll keep poking around open-source projects to see if this style is prevalent, but it is not something I am militant about. I treat these type of style issues as you want to be consistent throughout the code, so if that is the way a project does it, that is the way you should do it.

Got a look at the begin/rescue/ensure syntax for exception handling, which is pretty similar to try/catch/finally in C#.  As I see the two languages side-by-side after I put those links in, somehow the Ruby feels more “natural” and easier to read.  Huh, have I already taken the red pill.

Got a taste of RSpec, which was good because to this point I have been using test-unit, and I have been really curious to see what other testing options are available in Ruby and where you would use one versus another.  It certainly looks more descriptive and seems something of a more fluent syntax, although I am surprised lines like these

  lambda { cmd.command }.should raise_error(Cocaine::CommandLineError)
  output.should match(%r{/path/to/command/dir})

Aren’t actually like these, i.e. the use of the ‘.’ is consistent

  lambda { cmd.command }.should.raise_error(Cocaine::CommandLineError)

Regardless, I have heard good things about RSpec and it is on my list of things to look at.  I am really excited about looking at different testing techniques with Ruby, especially BDD testing.

I had to futz around a bit with the rakefile to get it to run.  It was all path related issues due to running on a Windows box.  I’m sure if I wanted to put more into it I could have come up with a cross-platform, but that wasn’t the goal of the exercise.  Besides it just gives me more reason to treat myself to a Mac.

So again, another barrier broken through on the Season of Ruby.  Next github challenge will be to find a project that I can actually contribute to, so fork it, make some changes, generate a pull request, and see those go back into the original project.

P.S. Don’t tell the cocaine project they weren’t really my first fork.  My first was actually the Spoon-Knife project.  But that fork was over so quickly I barely knew what happened.