After all of that, I’m feeling relatively comfortable with it. I got to finally try out JUnit. I did some work with sockets (java.net.Socket and java.net.ServerSocket), which felt pretty familiar having used sockets in C.

Also, I feel like I learned a lot of the “correct” ways to do things from Josh Bloch’s Effective Java. I don’t think I can give this book enough praise. It’s really, really fantastic for learning the intricate ways that you can mess up when writing Java software.

So… about Clojure. I’d still like to spend more time with it, but I’m not sure when I’m going to schedule that in.

[All apologies if this sounds a bit like an incoherent rant... I haven't been sleeping nearly enough and I really need to get caught up on that too]

He talks quite a bit about the indicator lights on his home theatre being quite mismatched. Some are red, some green, some amber, some devices showed multiple, and there was no real consistency to it. Strictly, he’s right; this isn’t the most usable situation.

The part he misses is that the indicator lights on his equipment doesn’t really play that big of a role in the big picture. Most of the time when I’m using my TV, I’m not all that concerned about whether or not the red LED on the front is lit. All I really care about with my TV is that there’s a picture on the screen, tuned to the correct channel.

He brings up the TV settings menus as well, mentioning that these don’t ever really make-or-break the sale when a person is shopping. I agree with him here too. It’s very rare that you need to venture into the settings menu (say, because the contrast needs adjustment). If it’s really that difficult, there’s probably a bright 9-year-old nephew that can do it.

The really important part of the usability of a TV is the ability to change the channel and to control the volume (in my experience). I’ve used TVs before that took several seconds to change the channel each time, and the experience was brutal. I channel surf quite a bit, and it’s really tough to do when it takes 2 minutes to get through all of the channels I don’t care about. Some remote controls have very slow repeat rates; when a loud (R.I.P Billy Mays) commercial comes on, I want to turn the volume down quickly. If I have to hold the Vol- button for 30 seconds to get the volume low enough… well, I’ve missed my opportunity.

I think the most important usability idea that we need to focus on is this: “Don’t get in the way of what I’m really trying to get done.” If there’s an activity that I need to do twice a year, it’s not a big deal if it’s a bit tricky. If I want to do it 40 times an hour, though, it had damned well better work.

A great example of getting this wrong was one of the first IPTV boxes that SaskTel rolled out (if I recall, they were Pace?). The on-screen guide was sloooooowwwwww. Really, really slow. It would show 4 channels, and going to the next screen took a few seconds to refresh and redraw. Navigating around the guide had enough latency that you’d notice it (maybe 300-500ms to move from box-to-box?) This left a bad taste in a lot of people’s mouthes, and brought quite a bit of criticism.

They’ve since addressed this in two different ways: first, navigation is quite a bit quicker in the guide; second, they’ve added a picture-in-picture showing the channel that you were on when you launched the guide, giving you a good distraction to keep from noticing that it’s still not quite as snappy as it should be.

THIS is the kind of usability that matters; the in-our-face-everyday usability that you don’t notice. Really, I think that is the true mark of great usability: when you can use a product naturally, without even thinking about its usability.

A programmer has to be able to demonstrate that his program has the required properties. If this comes as an afterthought, it is all but certain that he won’t be able to meet this obligation: only if he allows this obligation to influence his design, there is hope he can meet it. Pure a posteriori verification denies you that whole-some influence and is therefore putting the cart before the horse, but that is exactly what happens in the software houses where “programming” and “quality assurance” are done by different groups. [Needless to say, those houses deliver without warranty.]

The man never ceases to amaze me.

Some choice quotes:

Frankly, the ability to be deliberate is the mark of a professional. Professionals do not rush. Professionals understand the value of cleanliness and discipline. Professionals do not write bad code — ever.

Or how about:

If you want to be a professional, if you want to be a craftsman, then you must not rush. You must keep your code clean. So clean it barely needs comments.

Today I start a new journey. I’ve left my otherwise fantastic job at VendAsta to start my M.Sc. in Computer Science. I’ve been working in industry for 2.5 years now, and I figured I’d like to spend more time focused on learning and growing.

I haven’t picked a thesis topic yet, but it’s likely to be related to distributed computing. I’m going to be working in the DISCUS lab at the University of Saskatchewan, with my long-time friend and mentor, Dwight Makaroff.

It’s the first day of class, and I’m just getting settled in. I don’t have desk space yet (turns out that no one is around the DISCUS lab at 8:00am…), but I’ve snaked a table in the lab and already it feels like home.

I’m going to try to be more organized this time around (some know about the chaos that was my undergrad career). I’m going to try to incorporate some of the principles from the excellent Study Hacks blog; in particular, I’m going to do The Unsinkable Student Organization System. For time management, I think I’m going to give The Pomodoro Technique a shot, especially for writing assignments.

Also, like I mentioned before, I’m going to start my Language-a-month plan, and I think I’m going to start with Clojure.

Well, to all the students, here’s a big “Cheers!” to a good year.

Here’s what a typical script looks like:

import logging
logging.info("Hello world")

Of course, when you run this, you get no output. You need to make a call to logging.basicConfig() first:

import logging
logging.basicConfig(level=logging.INFO)
logging.info("Hello world")

This time, I do actually get some output:

INFO:root:Hello world

This is ugly though. The second thing I always forget is that you need to pass the format parameter to it. All together:

import logging
logging.basicConfig(level=logging.INFO,
                    format="%(asctime)s - %(levelname)s - %(message)s")
logging.info("Hello world")

This finally produces some nice output:

2009-08-19 14:18:37,161 - INFO - Hello world

def something(request):
    if condition_a and condition_b and condition_c:
        lots
        more
        and_even_more
        etc
        if something_else:
            etc
            etc
            etc
        etc
        etc of code here
        return True
    else:
        return False

The “return False” is pretty far-removed from the set of conditions that will cause it to execute. An easy way to restructure this code (while still having the exact same functionality) would be to use the set of conditions as a guard:

def something(request):
    if not (condition_a and condition_b and condition_c):
        return False
 
    lots
    more
    and_even_more
    etc
    if something_else:
        etc
        etc
        etc
    etc
    etc of code here
    return True

Preemptive comment: I’m fully aware that some people feel very strongly about only having “single return point” for a function. I disagree. I’d rather minimize the number of return statements from a function, but in this case I think it adds clarity.

Starting in September (coincidentally, the same time I start school), I’d like to learn a different programming language each month, to the point where I can comfortably write a blog post about it. I don’t plan on learning it in huge depth, but sufficiently that I could write a reasonable simple app. In particular, I want to focus on the pieces that make the language special.

I want to have some significant breadth in this. Some classics, some contemporary, some obscure, some mainstream. Off the top of my head, here are some possibilities:

• Lisp (DrScheme maybe? or ELisp?)
• Forth
• Ruby
• Clojure? (Is this similar enough to Lisp/Scheme that it’s not necessary?)
• Haskell (I missed CMPT 340 going through my B.Sc.)
• Fortran
• Erlang (this is cheating a bit… I’ve done Erlang in the past, but I just want an excuse to go through the Erlang book in more detail)
• R
• XUL/JS (for Firefox plugins)
• Lua

I’m going to have to think about some more. Anyone have any recommendations? Maybe for entire classes of languages that I might have missed?

[Edit: added XUL/JS, July 21, 2009 @ 7:55AM.]
[Edit: added Lua, July 21, 2009 @ 9:25AM.]

>>> def foo():
...   name = "Kevin"
...   bar()
... 
>>> foo()
Hello, Kevin

You have to ask what kind of evil person would write such an unmaintainable piece of code. I found it sufficiently fascinating though, that I figured I’d share. If you ever decide to use something like this in production… well, I’ll leave that to you and your conscience.

>>> def bar():
...   print "Hello,", sys._getframe(1).f_locals['name']

* nasty: unmaintainable, confusing, unobvious.

• Guide: Writing Testable Code
• PDF version

This document is such a fantastic, succinct explanation of how to write code that will be easy to work with (and test!).

[I try not to make too many posts that only consist of links, but this is so good that I couldn't help myself.]