Rick Mercer's Camelot Skit
Terry Mileski's Investigative Journalism on the changing justice system in Texas
I was out supply teaching yesterday and had a fabulous time! I met some great kids in a Law 12 class and we had an awesome discussion about Prisons and Money and Canadian Politics with the Stephen Harper Government. Curious what resources we used? Try these videos for starters. And, yes, I informed the students that the CBC is known for leaning somewhat to the left. :-)
Rick Mercer's Camelot Skit Terry Mileski's Investigative Journalism on the changing justice system in Texas
0 Comments
Celebration time! I've finally finished the 12 chapters of the RailsTutorial.
Of course, he finishes off the video series with 2 things:
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] |
Author: Graham RichTechnology teacher.
Contact Mr. Rich Currently employed with New Brunswick's Department of Education (also known as EECD) Experience: - IT/BBT/Graphics (10 years) - Visual Arts (2 years) - Woodworking (2 years) - English 123 and Gr.9 (1 year) Latest Purchase: - Raspberry Pi (bought here) Favourite Software Tool: - Scratch (from MIT) - Vizwik (from AgoraMobile) Favourite Software Language: - Python Archives
November 2016
Categories
All
|
Copyright © Graham Rich 2010-2023. Site made using Weebly.com.