Thank you Steve

by Rob Kitson


As someone who has experienced very little death, the loss of Steve Jobs has had quite an unexpected impact on me. Part of me knew it was coming, while another part had convinced myself it was a couple years off. Quite frankly, I'm not sure how to deal with it and there will be some crying involved at some point.

My career started in the late 90's and I worked exclusively on Windows. The average Mac users that I knew annoyed me. They were always complaining about incompatibility and they typically knew less about computers, in general, than Windows users. As it turned out THAT was kind of the idea. Steve didn't want the average user to know about the specs of their machine, he just wanted them to have the best experience possible. It wasn't about specs, it was about experience.

I didn't fully grasp that until October 2008, when I gave my wife an iPhone 3G for her birthday. I had the AT&T Tilt at the time and was pretty damn excited about the prospects of writing apps for the windows mobile platform. One problem though, I couldn't take my hands off her iPhone (literally) and it actually sparked a few arguments (sorry babe). I quickly made the decision to switch to the iPhone and have never been happier or more confident in a decision.

That iPhone purchase led me to other iPhones, my first MacBook, a MacMini, a couple Apple TVs, and an iMac. I couldn't be happier with ANY of those purchases. I didn't feel that any one of them was overpriced; in-fact, I priced out my iMac against the same computer (if assembled from mid-range parts at a very reasonable online retailer) and my iMac ended up being cheaper, after OS/software licensing fees.

Steve Jobs changed my life in the 80’s, but it took 20+ years for me to find out. He had a vision, he sold it, and he delivered. I will be forever grateful for the influence he had on the industry, the world, and eventually me.

I am deeply saddened by the loss of this truly remarkable man. I was not ready to see him go. My deepest condolences go out to his family and loved ones.

Thank you Mr. Jobs.


My Error/Exception Handling Philosophy

by Rob Kitson


Exceptions should be exceptional. They should signal a major problem within the application, or one of it's dependencies. They should be handled in the scope that is as close to the source of the error/exception as possible and only passed on when truly un-handleable. A system that throws a lot of exceptions, when functioning correctly, will make it very difficult to spot actual problems when they arise.

Errors/exceptions should be descriptive and specific.The more (relevant) information you can give me about what's going sideways, the better. I think custom exception classes play a critical role in providing this information. You can load them up with data that's relevant to the error and they can bubble up with that information until they are caught and at that point the the data they're holding can provide hints as to how to fix the problem. If you use the standard errors/exceptions, just changing the message of the exception, you will find yourself doing a lot of string comparison/manipulation in a catch block in order to figure out what the error is, and wether you can handle it.


My Testing Philosophy

by Rob Kitson


Whenever possible I write my tests first. I try to keep my tests small and focused on a particular behavior of the SUT (System Under Test, a.k.a. the class I'm currently testing). I tend towards unit tests that exercise my SUTs in isolation, using mock objects to control the interactions it may have with it's dependencies but also wrapping those interactions in helper methods within the SUT to avoid creating tests that have too much knowledge about the implementation of the method being tested.

Integration tests are crucial to ensuring that the system is working from end-to-end, but should be used sparingly due to the fact that they typically are: long-running, more difficult to setup, more brittle, and quick to increase in number and complexity. My typical integration test suite includes 1 happy-path test and 1 sad-path test (the most critical), while every 'contract' between classes will have tests for the interesting pre/post conditions.

On occasion, I'll write a throw-away test fixture who's sole purpose is exploratory testing of a new 3rd party library/module that I want to get familiar with before adding it to my project.


Better living through favicons

by Rob Kitson


I use tabs, lots of them, and usually in more than one browser window.  Recently I've found myself hunting for the specific tab that has the site I'm developing/testing locally, testing in a staging environment, or verifying in the production environment, and I’ve gradually been getting more annoyed with the friction.

Last night I had an epiphany: What if I provided a different favicon for each environment instead of the same one for each? A little research and I discovered that I didn’t have to have a file name favicon.ico, I could name it whatever I wanted AND you can use file formats other than .ico.

I grabbed the actual favicon.ico and converted it to a .png.  Then I made 2 distinctly different versions for my ‘development’ and ‘staging’ environments and saved with a naming schema that will allow me to quickly figure out which one to use.

These are the 3 I'll be using on one of my current projects:

favicon.png

 favicon.png

favicon-staging.png

 favicon-staging.png

favicon-development.png

 favicon-development.png

Next, I added this:

<link rel="icon" href="/favicon<%= ("-" + RAILS_ENV) unless RAILS_ENV == "production" %>.png" type="image/png">

to the HEAD block in the /views/layouts/application.rb file.  So now, when the site is loaded from production it uses favicon.png, but favicon-development.png and favicon-staging.png for the development and staging environments, respectively.

In hindsight it seems obvious, but this little hack reduced my tab hunting time drastically.


localhost:3000 friction

by Rob Kitson


If you're like me, you probably have more than a few rails projects on your machine. And, if you're like me, you probably don't worry too much about setting the port when you spin up webrick to test your stuff.

Recently I've been increasingly annoyed by my browser trying to autocomplete my http:://localhost:3000/ urls to paths that are relevant to different projects.  I think I've found a simple solution that's been working for me for the past few weeks. I edited my /etc/hosts file to include entries for project names that point to the localhost, like this:
127.0.0.1 new_project
127.0.0.1 other_project
127.0.0.1 sandbox
Now, when I'm working on 'other_project', the url is http://other_project:3000/ and the browser doesn't try to autocomplete paths for http://new_project:3000/ or http://sandbox/. Of course, I have to be cognizant of the fact that any of my hosts entries will contact the webrick instance that is currently running on the port I'm designating in my url, but that's a bit less annoying than getting my url schemes mixed up between projects.

 


My Podcastroll

by Rob Kitson


5by5: http://5by5.tv/

TWiT Network: http://twit.tv/

This Week In...: http://thisweekin.com/

Other sources:

 

It's a lot of listening, good thing I have a dog that likes to go on walks...


StackOverflow exploiters considered harmful

by Rob Kitson


As a developer, I've come to expect a certain number of search results from StackOverflow.com per query. But recently I've noticed that the google juice, which rightfully belongs to StackOverflow, has been picked up by a few 'competitors' who have figured out how to monetize the Creative Commons Data Dump, that SO provides on a fairly regular basis. They've leveraged the dump to populate pages with relevant data without keeping it current, and sometimes not even providing a link back to the actual SO question (making it even more stale).

If I were Jeff and Joel, I'd be pissed. And though I understand that they want to be a community player; I think that taking a step back, they'd see that allowing these sites to use the data dump this way is clearly not in the best interest of the community.

That being said, recently Joel posted a link to a chrome extension which (upon loading a site which is shamelessly using the data dump) will redirect you to the appropriate StackOverflow page. Here's the link https://chrome.google.com/webstore/detail/gledhololmniapejefjfocffkhoamlll# and it worked like a charm for me. Hopefully it continues to do so.