Hoptoad and Javascript, Sitting in a Tree, S-E-N-D-I-N-G – GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

Hoptoad and Javascript, Sitting in a Tree, S-E-N-D-I-N-G – GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS.

I’m really excited about this new feature of HopToad.  I’ve played around with ExceptionHub but it was missing some important features like team management.  Leveraging HopToad to do this kind of JavaScript/browser level error tracking really cleanly combines two useful and similar tools for debugging a running system.

I should add that I echo the concerns of some of the commenters on the linked to blog post about security concerns.  It would be helpful if ThoughtBot followed this up with a post to address this concern in a bit more detail.

All in all though, this is nice

Podcast.local – localhost podcasting

Last week I discovered a set of mp3′s covering Lean practices and principles.  You can access them here.  I’ve been on a bit of a management optimization stint lately and Lean is a very natural extension of Agile software development in to a broader management context.  It largely predates modern software techniques and represents one of the early generalizations of the Toyota Production System.

In any case that is not what I’m here to talk to you about.  In looking through these mp3′s the list of webinars was not collected in to any sort of podcast format.  This is frustrating because this would be ideal commute time listening on my iPhone.  Out of this frustration came podcast.local.  Podcast.local is a simple Rails application (really simple) that allows you quickly create a podcast through a series of forms.  The name comes from the naming convention provided by the Passenger preference pane on OS X.  If you set it up through the pref pane you will just need to go to http://podcast.local.  From there you can create your podcast one episode at a time and then subscribe to them through your iTunes.  The coole thing is that because it’s on the web iTunes just picks it and starts downloading episodes.

Like I said above, this application is too simple to go in to much detail.  I used it to do some experimentation with a few technologies that I haven’t had much time to mess around with.  Namely Blueprint CSS, jQuery, jQuery UI, and Paperclip.  Enjoy!

Should I use an instance variable?

No.

If you are in a position to ask this question I humbly recommend you default to: “No, I do not need this as an instance variable right now.” There is a tendency to plan for every potentiality when doing software development and this is a prime example of such a situation. Resist the temptation.

Instance variables represent state associated with an object in memory. When you declare an instance variable you are saying to all future developers: “This piece of state needs to last for the life time of this object because it will be used elsewhere.” Think very hard about that. We are saying loudly here that this variable is coupled to other fragments of code. Which code? Dunno, do a global search ;) .

This is called tight coupling. I will go so far to say that coupling is the source of all evil and complexity that we deal with as programmers. With every step that we, as programmers, take in building a system should be with an eye to reduce or at least not increase the coupling in the system that we are working on. The fewer instance variables that we have in a Rails controller the smaller the potential coupling between the view and other method calls that have access to those instance variables. Each method, each action in a controller, should be as self contained as possible. The less leakage of state out of a function the better. Generally your view doesn’t need to see that temp variable of the calculations that you made to set a model attribute keep it local, drop the “@”. Worst case scenario you go back and refactor your code to include that “@”.