Witty.ca - Graham's Professional Archives

Celebration time!  I've finally finished the 12 chapters of the RailsTutorial.

Of course, he finishes off the video series with 2 things:

• a Chapter 13, where he discusses all the differences in the tutorial between Rails 3.0 and 3.1....  like I didn't just go through and figure it all out!!!!
• a list of all the things he DIDN'T cover in the tutorial.... and now I'm back to feeling overwhelmed again. 
  

But, on the bright side, he has done a lovely introduction so that RailsCasts now make some sense.  And, hopefully, the future will be much brighter now that I know what a :scope is!

As a Rails newbie, trying to wrap my head around JQuery (the new default on Rails 3.1) has been a bit of a chore.  This isn't because it's hard to use, or because the RailsTutorial.org is hard to follow.  Actually, the opposite is true: because it's so easy to use, that means it is harder (for me) to figure out what is going wrong if (aka "when") something does go wrong.

Take, for instance, my latest trials with the RailsTutorial.  It should have been easy enough to type in exactly what we were told.  Except that this didn't work!  And, where do errors go if you're using a JavaScript button?

Enter FireBug.  It's not entirely intuitive, but at least it gives some pointers and displays the error messages that would otherwise fail to be displayed.  At first, I thought FireBug would just start spitting out the error messages, but I needed to configure it first.  Again, it wasn't much, but it did take me an hour of searching the web to just give up and try poking around.  The "Console" button was what I wanted.  Displayed nice error messages so that I could track down the bugs.  (Not that they're all fixed yet, but at least I have a direction to look!)

Very valuable!  Thanks so much.

By the way, if you're developing in Rails 3.1, you should be told that the JavaScript code might be running twice if you have assets:precompile as a setting.  (In development mode, it runs once as the raw code, and once as the compiled code.)   To fix this, in your config/environments/development.rb file, put config.serve_static_assets = false and then you're stuck with the precompiled assets only.  I found that answer here.  Thanks, StackOverflow!

Yes, I'm an old fuddy-duddy.  I started programming back in the 80's and learned Turbo Pascal and Modula-2.   

I still remember that making code readable was about using helpful names for variables and functions... and ALWAYS make sure those names were visually different so that you wouldn't confuse them.  (e.g.  $user,  $users,  $Users)

Well, welcome to the world of Ruby on Rails.

if Michael Hartl's tutorial is any indication, then this world is chock full of references to things that all look the same.  So far, I've discovered that the following are very VERY different, yet they look so similar.  These are all variables, instances or classes.  (I get so confused!)

user
users
User
@user

micropost
microposts
Micropost
@micropost

And yes, I do find all this hard on my tired old eyes.  While it might "read more like English" I have to wonder at what cost.  I'm sure someday I'll lose hours trying to find a bug that was more about a missing (or extra) "s" than anything else.

If being readable means that my code is hardly debugable, then maybe we've "swung the pendulum" too far!

Sure, we all have to learn something new at some point.  But what I hate the most is the solution that you can't learn from.

So, I spent yesterday working on Chapter 11 of the Rails Tutorial.  It's been great, but there was a "re-factoring" section in the middle that I knew was going to haunt me.  There were too many changes, too many RSpec test added and and the development was just too much.  My code "blew up" on me.  I had at least 14 tests go red, and the solution that should have been obvious was completely hidden behind all my attempted fixes that only made things worse.

So, I blew away all my Chapter 11 work ("git reset --hard" takes you back to your last commit).  I started again, and when I got to the "too busy" part, I broke it down into smaller chunks and went by baby steps (with a complete RSpec run after every step).

Did I find my problem?  NO!!!!!

Every RSpec test passes now with flying colours.

The big step (I had thought) was to move "def authenticate ..." from the users_controller to the sessions_helper.  I moved the code, ran the test, held my breath, ... and it ran green!   For once, I really wanted my code to blow up (so it would justify all my pain from yesterday).  What I had spent an hour researching and 2 hours repairing... was not a problem ... at all.  (groan)

So, I have no idea where my code went wrong yesterday, so I have nothing to learn from my mistake.

However, maybe my biggest mistake was to "follow the instructions" when my gut said, "Take it slow or you'll get lost!"

So, that's the lesson of the day.  Take your TDD in baby steps (and don't worry if it feels slow, because the alternative is ... ARGGG!)

[TDD = Test Driven Development]

What is happening when your code runs fine, the tutorial shows that your code should be "RSpec green", but it isn't? 

For me, it's time to go to StackOverflow.com again.  The hardest part was searching for the right answer.  But once it was found, it just works!

So, for those of you stuck in (Michael Hartl's awesome Rails Tutorial) chapter 10 and wondering why you now have RSpec giving you 7-10 errors, don't worry!

I had suspected all along that this was just one of the differences between Rails 3.0 and Rails 3.1, and it appears that I was right!  When searching for "test_sign_in" the 4th hit took me here, and the answer redirected me here, where I received the bizarre but efficient changes that needed to be made.

In sessions_helper, find def sign_in

• old:
  current_user = user
• new:
  current_user = user
  @current_user = user

Also in sessions_helper, find def sign_out

• old:
  current_user = nil
• new:
  current_user = nil
  @current_user = nil

Even the author is left guessing why this works.  But it's small, efficient, and keeps the tests nice and small.  After all, each test should test one and only one thing, right?!


[TDD = Test Driven Development]

When I first sat down to learn Rails, I thought, "A week, maybe two... ." 

Yeah, right!

I've now learned that watching a 1hr 20min tutorial video from Michael Hartl will take me about a day.  That's including:

• pausing and rewinding to catch up (typing) and to be sure I understand.
• verifying locally and on Heroku that everything is working right
  (I'm still leary of Heroku, see my previous posts.)
• flipping back-and-forth between the video and the PDF versions (especially where there might be large CSS to copy-and-paste.
• taking regular breaks to shake my head (and make sure that I can remember what I just read/did).

So, I'm learning that patience (with persistence) is my best combination.
... that and keeping a window to StackOverflow.com open for any weirdness that creeps up!

RSpec seems to make such intuitive sense, and now that I've started to wrap my head around TDD, I am starting to see the benefit.  Sure, initial development may be slower, but the overall development approach should help over the long-term maintenance of your code.

But then, RSpec completely stumped me. 

Thanks to the folks at StackOverflow, because this post, explains my problem exactly.  After multiple tries, my test just wouldn't work.  But with this explanation, I started wondering how the "click_link ...." test was working.  Then it hit me:  each "click_link" represents a user click, so the following test is now looking at the new page (just "clicked") and not the path I had specified above.  AHA!

Very interesting (and, sadly, unintuitive for the newbie).

Small victory dance.  (My Heroku solution was here.)

Knowing how much more there is to come, I'm a little overwhelmed.

By the way, big kudos to the people who provide answers at StackOverflow.  For all the scouring of the web that I've been doing, the best answers keep coming from there.   Thanks to you all!

Now, back at the tutorial!

I've read all over the web that "deploying to Heroku is totally painless!"  Wow.  2 days later, and my best answer was to start over, line by line.

Now, granted, I'm a complete newbie to Rails, so I'm sure to make every mistake possible.  But, wow, Heroku has been a complete pain in the ass!

First, I'm discovering that Heroku doesn't believe in error messages.  They simply state:

• "We're sorry, but something went wrong. We've been notified about this issue and we'll take a look at it shortly."

Now, maybe I'm supposed to "tail" the log files to find out what's happening.  But more specific error messages might be nice!!!!!  Oh, and the whole "we'll take a look at it" is completely bogus.  In my 3 days, I've seen this fail screen so many times, and I've never even had a popup in my "My Apps" page to say, "Hey, see there's a problem."  (At this point, I'd even take a trained professional's advice, if they were offering $50/hr to give me some tips.  They already have my credit card number...)

Second, Git is a newbie nightmare!  Seriously!  All I wanted to do was back up 5 commits!  How hard should that be?  I wanted everything I had done in those 5 commits to be UNDONE.  Isn't that the point of a versioning system?  Yeah, well, if there's a way to do this, then please let me know.  After searching all over the web and trying a number of "solutions", I ended up starting the tutorial over from scratch.  (Write one line of code, git commit, git push, git push heroku, test/verify.)  All the TDD that RSpec uses is great, and all the local testing passed with flying colours!  Then, upload to Heroku and watch it fail! 

So, now I'm trying to figure out what exactly is the cause.  I'm completely baffled, but so pissed off that I won't give it up.  Maybe I'll post more here as I go.

For those of you who are curious, here are my Heroku failures to-date (all of which yielded the exact same error screen described above):

1. If you use an undeclared variable. 
   e.g. <%= link_to "Home" home_path %>  # Better specify home_path!!!
   
2. Use coffee-rails.
   I'm still trouble-shooting this one, so I'll have to post more later.
3. No, coffee-rails, which I think serves my JavaScript, isn't the problem.  The problem is that my "assets" aren't "precompiled".  Yeah.  In the olden days, compilers were for C, and so I guess I have much to learn.
4. Am currently going through my "heroku log" files, after reading about them here.  I chose to use the following to get the last 200 lines into a local log file:
   

• heroku logs -n 200 > log/heroku.log
  
  This is where I discovered the "precompiled assets" issue.  How to solve this one?  I will wait and look for that tomorrow... or maybe Monday...
  
  Note: Yes, it took until Monday, and I finally found my solution!  Why this wasn't more obvious, I'll never know.  See Jeppe Liisberg's solution.
  

And, in searching for this answer, I discovered the instructions that I should have started with (Rails3 on Heroku/Cedar and Rails3.1 on Heroku/Cedar).  I can't remember why I decided to invoke "--stack cedar" but somebody somewhere in the Internet suggested it because it was "better".  Should I spend the time to figure out why "cedar" is better than "bamboo"?  Nah.  I think I'll just go with it.  (A little overwhelmed with all the decisions right now.) 

One final thing:  I spent hours trying to figure out how to setup the database config for the production (i.e. Heroku) site.  Then I found the link describing how to get this.  But there's not need to post it here, because then I found out that Heroku re-writes your production database config on upload (i.e. git push heroku).  So, there's no need to worry about this after all.  [...sigh...]