themorgue.org

There is an epidemic of bad design in this world that is more than just annoying, it’s dangerous. I’m not just talking about bad aesthetic quality of devices, obviously. I’m mean that their behaviors are badly designed as well. I think Steve Jobs nails it when he talks about design.

Design is not just what it looks like and feels like. Design is how it works.

So how could this possible lead to “danger?” I’m glad you asked. I’ve been dealing with safety devices in the home lately. Safety has taken on a new meaning to me since I moved to Tornado Alley last year. The weather in this area pretty much mandates that you have a weather alert radio to notify your of impending danger (especially at night). The other badly designed device I’ve dealt with recently is a smoke alarm. Let’s start with the smoke alarm since most people are familiar with them.

There is a smoke alarm installed in my kitchen that was there when I moved in. It works well. Too well. Any hint of smoke in the air from cooking sets it off. What happens when it starts going off for that reason? I get annoyed and remove the battery. This isn’t necessarily dangerous while I’m cooking, but I have to remember to put it back in when I’m done. That doesn’t always happen. To try to remedy this situation, I bought a new smoke alarm made for kitchens that has a “hush” button. This is a button that you press when you get “false alarms” due to cooking. Great idea! Except that it was badly designed.

I was cooking today and created a pretty good amount of smoke (no, I’m not a bad cook, some things just create smoke when you cook them). The new smoke alarm went off, and rightfully so. I pressed the hush button, and it stopped! YEAH!! Then it started to annoy me. Every minute or so, the smoke alarm let out a small chirp (basically like the chirp most smoke alarms let out when the battery is low). After a few chirps, this annoyed me enough to take the battery out. So I’m right back where I started!

If fire isn’t bad enough, weather in Tornado Alley can be even more dangerous. I purchased a weather alert radio to alert us (mainly at night) about severe weather. The first one I purchased in a very simple model and pretty well designed. It has three lights on it to indicate different levels of alert and a screen that displays what type of alert it is. It can be plugged in or can run on batteries. So what’s wrong with it? It’s too dang loud! It has the option to alert you in three different ways: light up the display, voice alert, or siren. Obviously, the light won’t do much at night; it’s not that bright. The siren is absolutely obnoxious and is loud enough to induce a heart attack in the middle of the night, so voice alert was my choice. The problem is that “voice alert” only means “partial voice alert.” Before the voice alert comes, you get about five seconds of the horrendous siren first. I’m a light enough sleeper that the voice is plenty to wake me up. I think the danger of having a heart attack by having the siren go off in the middle of the night is a bigger danger than facing whatever it is that the radio is alerting me to. Here comes weather radio number 2.

The new weather radio was much more technologically advanced. It has base station and a hand-held portion. I liked this feature because it made it handy to take into the storm shelter during an alert. Both the base station and the hand-held portion have a clock on them. Since the hand-held radio is battery operated, it isn’t affected by power outages. However, the base station doesn’t have battery backup, so when the power goes out, the time goes back to 12:00. This wouldn’t be such a big deal if it just took the word of the hand-held portion (which still has the correct time since it’s running on batteries), but the opposite occurs. The hand-held radio takes the bad time from the base station so that they are both wrong! Now I should explain that the base station is supposed to sync with the atomic click in Colorado, so it should always have the right time. But that is only true if it can actually connect to the atomic clock which brings up another design flaw.

The sensor for the atomic clock must be placed outside so that it has a clear shot at Colorado. There are conditions though. It can’t be in direct sunlight, it can’t be subject to direct moisture, it can’t solid objects between it and the atomic clock in Colorado. So it must be installed under something that gives it protection from sun and rain, but that would block the signal to the atomic clock. I give up…

I’ll definitely be sticking with the second weather radio because it has a much more sane alert than the first radio (although it does automatically turn itself to maximum volume when an alert occurs), but it is far from perfect. I haven’t even gone into the other issues that I have with it. The point is that each one of these devices annoys me enough that I consider not using them at all, which puts me in the path of danger whether it is fire, severe thunderstorms, or tornados just because of bad design. While bad aesthetics probably will never cause any real danger except to my sense of taste, design of safety devices that cause you to quit using them is dangerous.

Growing up in Michigan, the only real choice of ginger ale was Vernor’s. As I would find out later in life, this wasn’t such a bad thing. After moving to North Carolina for graduate school, I discovered that not everyone knew what Vernor’s (or ginger ale in general) was all about. The grocery stores there usually only stocked Seagram’s, Schweppes, Canada Dry, and some store brands. I had never had anything but Vernor’s growing up, so I assumed that they probably all tasted about the same. I couldn’t have been more wrong. All of the other brands that I tried tasted like Sprite with the slightest hint of ginger. This is totally unlike Vernor’s which has a strong ginger flavor and a lot of bite to it. There is even a “You know you might be from Michigan” joke that goes “You know you might be from Michigan if you can drink Vernor’s without coughing.”

I did finally find Vernor’s in North Carolina, but it was very expensive (probably twice what it cost in Michigan). My parent’s would also bring some with them whenever they made a visit to see me, which made it a little expensive as well since Michigan has a 10 cent deposit on all pop cans and bottles. I did come across some other ginger ales in the Whole Foods store in Raleigh by Reed’s. While Reed’s is better than the weak stuff you get in regular grocery stores, it goes a bit overboard. The herbs and spices are too strong for my taste.

I found inexpensive Vernor’s again while living in Colorado, but alas, I was only there for a few months. Now that I’m in Oklahoma, it’s difficult to find again. However, when I discovered Pops on Route 66, I was introduced to a much better selection of ginger ales than I had ever seen before. In my first visit, I selected Dr. Tima’s Honey Ginger Ale as my first ginger ale experiment.

I didn’t hold a lot of hope for Dr. Tima’s Honey Ginger Ale due to my previous experiences with other ginger ales, but I didn’t hold that opinion for long. Dr. Tima’s Ginger Ale not only has honey in it, but that is the only sweetener in it. There are no refined sugars or corn syrups. The first taste was very pleasant. It didn’t have quite the bite that Vernor’s does, but it had a great ginger flavor. The honey introduced a warmness to offset the tang of the ginger. Overall, it’s a great ginger ale and I enjoyed every sip more than the previous one. I’ll have to sample a few more bottles of it (and the other 20 or so brands of ginger ale at Pops) to see how the taste wears on me, but at the moment, it reigns my top choice of ginger ales.

I know that nobody thinks there is any reason to go to Oklahoma, and for the most part, you’d be right. Yeah, there is a wicked cool museum of banjos in Guthrie and there is even a canal area of Oklahoma City a lot like the one in San Antonio, but nothing I knew about prepared me for what I came across this weekend. I didn’t even know it, but there are more miles of Route 66 in Oklahoma than any other state. We decided to do a bit of touring around and see what there was to see. For the most part, Route 66 is just a highway like any other, but there are some interesting sites along the way. We went to the Rock Cafe and the round barn, but those were nothing (as far as I’m concerned) compared to a newer attraction: Pops.

The construction of Pops started in 2006. It is a store like nothing I’ve ever seen before. We actually drove by it a couple of times not even realizing what it was, but decided to go back and take a closer look. Boy am I glad we did. Pops is a Route 66 attraction that is basically a gas station and restaurant, but the real feature is pop (that’s coke for the Southerners). They have nearly 500 kinds pops and bottled waters. They don’t stock everything all the time, so you have to come back more than one time to see them all. The entire front of the building is covered in glass and has glass shelves lined with thousands of bottles of pop, just for decoration. Every bottle in the store is glass. If you aren’t a pop connoisseur, this is the only way that pop should be enjoyed. For me, this was a dream come true. They had pops there that I have wanted to try for years, and lots that I had never even heard of. They even had more than one kind of strawberry rhubarb pop! If you are looking for a reason to come to Oklahoma, this is it. But you’ll probably want to stop by and see the banjos too…

I’ve been working on a MooTools class for the past couple of days that makes large data tables scrollable. When the page loads, it checks to see if any data tables are larger than the scrollable area of the window. If there are tables like this, it puts the table into a scrolling div and copies the header and footer areas above and below the scrolling div, respectively. It also has the options of making the rows alternate colors and making the table rows sort when the headers or footers are clicked. I had it working quite well, but there were some performance issues.

The table I was testing with had 429 rows of 16 columns. This is a total of 6864 cells. I was taking advantage of MooTools’ getElementBySelector in many places because I needed to find th and td cells within the tbody, thead, and tfoot elements separately. This created some problems when the page unloaded. On Firefox, it was taking over 7 seconds just to leave the page. This obviously was unacceptable.

I was having trouble figuring out what the exact problem was. I’m having done a lot of Javascript debugging, and have done even less performance profiling. Luckily, the Firebug plugin to Firefox was a huge help. In fact, I don’t know how I would have figured out the problem if I hadn’t had it. I turned on profiling then refreshed my page. Firebug told me that the ‘remove’ method of the MooTools Array object was taking up all of the time. I wasn’t using the remove method, so I figured there must be some sort of garbage collecting going on in MooTools. After posting to the MooTools forum, I got the answer. Apparently, whenever you use any of the MooTools that returns a DOM node, it extends those nodes with the special MooTools methods. This means that if you use $, $$, getElementsByClassName, or getElementsBySelector, every node that is returned is extended by MooTools and must be garbage collected.

In my table, I had thousands of cells that I was accessing to implement various features. Every one of those cells was being extended and had to be garbage collected. By the time my script was finished, I had over 7,000 objects to be garbage collected when the page unloaded (as seen in the Garbage.elements object under the DOM tab in Firebug).

While the getElementsBySelector method is very handy, it wasn’t going to work for me because of the extreme number of cells in my table. I ended up rewriting much of my code to use the standard getElementsByTagName method to get around the issue. This made the code quite a bit uglier, but I guess most optimizations do. The lesson today is to be careful when using methods that extend nodes in MooTools. While MooTools is really nice, there can be too much of a good thing. I’ve heard that MooTools 1.2 does memory management in a very different way, so hopefully the severity of this type of situation will be reduced in the future.

It’s been a while now since I’ve started using the MooTools Javascript toolkit, and I haven’t regretted that decision once. MooTools still doesn’t have a following as big as Prototype or jQuery or maybe even Dojo, but it just seems to fit my code aesthetic the best. I love how non-invasive MooTools is when the HTML is concerned. Applying a function to elements based on selectors is fairly easy.

$$('.myelem').each(function(item) {
    myfunction(item);
});

This idiom is actually the way that you deal with arrays in general. Another highlight of MooTools is the Class object. This object lets you program classes in Javascript much like in other class-based languages like Java or Python. I couldn’t possibly do a better job of demonstrating classes than this tutorial on //clientside. When I originally started using MooTools, I didn’t think I was going to use the Class object much, but it has ended up being one of my favorite things.

Last but not least in the world of MooTools is the effects library. You can get a good feel for the quality of the MooTools effets simply by going to their web site. It’s hard to ignore the slick animation effects that MooTools gives you access to. The only trouble with effects is that it can be pretty easy to go overboard and start to make some really tacky web sites; however, in moderation, visual effects can really make your work stand out.

There are lots of other cool things about MooTools such as custom events and introspection of style attributes. If you use MooTools, I’d like to hear what your favorites idioms and features are.

I’ve been playing around with writing web applications lately and have been looking for a good Javascript library to help with Ajax and web browser differences. After doing a little searching, two libraries floated to the top: Prototype and jQuery.

Prototype was definitely the most popular, partially because of the script.aculo.us user interface library. Prototype is definitely extensive and fairly well-documented. On the other hand, it plays a lot of dirty tricks under the covers to do it’s work. I wouldn’t count it out just for that reason, because it is very popular and well-tested in the real world. I do find the script.aculo.us web site to have absolutely horrible navigation, which is very odd since it is claiming to be the premier user interface library.

The other problem I have with Prototype is that is is fairly large (~100k). I want to make my web application usable by people with dial-up access, so file sizes are very important. Through compression and other techniques, you can minimize the download time, but it is not something that can be ignored.

jQuery was the next candidate. jQuery seems to have a somewhat different focus than Prototype. Prototype is more of an application building framework, whereas jQuery seems to be more of a quick-and-dirty query-and-modify toolkit. I really liked the idea of jQuery and can see why it has a large following. Being able to use CSS selectors to locate elements and chain functions is very powerful. So powerful that I almost chose jQuery as the toolkit to use for my projects. What stopped me was the somewhat ugly API. The method names and arguments seemed to be somewhat inconsistent and overloaded to excess. It felt more like an accident than a design.

While deliberating over whether to choose Prototype or jQuery, I came across a forum of Ajax developers where MooTools was mentioned. I didn’t really want to research any more tools especially ones that didn’t have that big of a following. After seeing the MooTools web site though, I thought I’d give it a shot.

I really like the look of the MooTools web site. This may sound superficial, but I figure that if they have a good aesthetic for their web site, they probably care about what their code looks like too. Looking at their API confirms this. The API is very consistent and powerful. In addition, it is also modular so that you can simply include the pieces you need rather than having a monolithic library.

MooTools seems to be a happy medium between Prototype and jQuery. It has enough application building tools and extensions of native Javascript objects without getting too invasive or outrageously large. It also has the power of jQuery’s CSS selector method of locating document nodes.

If you haven’t figured it out yet, I’ve decided to use MooTools for my applications. I’ve been playing around with it for the past couple of days and am quite happy with the results. The API is very easy to work with and extremely powerful. It’s not all a love-fest though. I have had some major problems with getting the correct keys for key-based events, but I think that has more to do with the inconsistencies between browsers than anything else. Hopefully, they’ll come up with a fix for these problems soon. Until then, I’ll continue to learn more MooTools tricks and idioms and let you know how it goes.

Now that I’m living in Oklahoma I thought it might be fun to try to organize a Python User Group. My friend Blaine has been running a dynamic language user group for a while now in Omaha, NE and it sounds like a lot of fun. I thought about doing something similar, but pretty much everyone that contacted here in Norman was only interested in Python. That’s fine with me since Python is my language of choice (although I do enjoy a bit of Javascript from time to time). Anyway, I met up with some people at the National Weather Center who had an interest, and it looks like it’s a go! We’ve set up a web site and we’re working on getting our very own python.org mailing list. So if you live in the central Oklahoma area and are interested in Python at all, keep an eye on our web site for meeting details.

I’ve been doing a lot of security work on my web server and email this past week and decided to update all of the passwords on my accounts in the process. I have to admit, that I’m really bad at coming up with good passwords. I guess that’s why password generators were invented. I did a quick search on the internet to find about 11,000,000 matches for the phrase “password generator.” Then I remembered something from a couple of weeks ago. I was adding a new account to my Mac and there was a little application that popped up next to the password field that generated passwords for you. I’ve been using OS X for years, and it’s probably been there all along, but I never paid much attention until now.

The window that pops up calls it the Password Assistant. It allows you to select from different types of passwords such as “Memorable”, “Letters & Numbers”, “Numbers Only”, “Random”, and “FIPS-181 compliant.” This is really cool, because some accounts limit the types of characters that you can use. The Password Assistant also lets you select the length of the password. It does this all while showing you a nice little gauge of how strong the password really is. Ok, maybe I’m getting a little carried away just for a freebie password utility, but I have to say that it has made coming up with new passwords much more enjoyable.

Bruce Eckel made some comments about the upcoming Python 3K (or is it Python 2.9)? While I respect the work that Bruce does and think he is very intelligent, I think I have to agree more with Guido van Rossum’s retort. Yes, the issues that Bruce brings up would be nice to solve. However, as Guido says these are mostly library issues not core issues, and more aptly

It’s open source. What are you waiting for?!

As far as the complaint about self, I realize that this is a religious war and has no clear answer. I do completely agree with Brandon Corfman’s comment about the confusing message TypeError: printString() takes exactly 1 argument (2 given) where one of the arguments is always self. Putting self as the first argument of a method has bothered me about Python since I started using it; however, I do not agree that Python user’s shouldn’t have to use self. when referring to an instance variable. I think Bruce is just plain wrong when he says that “parroting ‘explicit is better than implicit’ is a misuse of that maxim.”This is exactly the kind of thing that maxim is good for. There is no question in anyone’s mind where that variable is coming from when it has self. prefixed to it.

I also prefer things like self. to Ruby’s @, because self at least has a chance of being interpreted correctly without having to look up its meaning. Using an arbitrary character such as @ has no chance of correct interpretation without reading the manual. This is the main reason that I like Python: the syntax is consistent. Okay, it’s not as consistent as Lisp, but it’s pretty consistent. This is also the reason that I hate Python’s decorator syntax, but that’s a discussion for another day.

I think it’s pretty clear that Python 3K isn’t going to solve everyone’s problems and make everyone happy, but it is definitely a step in the right direction.

Day two of our trip got off to an early start. We can thank our cats for that. Our cats don’t like to be out of the house and decided at about 5am that they were ready to get out. Since they made sure to it that we couldn’t sleep, we decided to just get up and go. Not getting much sleep, and driving through Kansas is not exactly a good combination. This is made quite evident by the occasional road sign advertising free coffee at all Kansas rest stops. Unfortunately, neither I nor my wife likes coffee.

We drove for about an hour before stopping the first time. I was feeling pretty much awake by that time, but my wife was still having trouble concentrating on driving. Luckily, one of our cats decided that today was the day to create all kinds of noise during the entire trip to keep here awake. With Prairie Dog Town behind us, there didn’t appear to be any more sites to see in Kansas. The good news is that we soon hit I-135 and started heading south to Oklahoma.

I was excited to see the border of Kansas and Oklahoma. Every truck and rest stop that we visited had all kinds of Wizard of Oz stuff and I was just dying to see a big sign on the border that said “You’re not in Kansas anymore!”. I was, however, greatly disappointed. There was no such sign.

Northern Oklahoma was much like Eastern Colorado and Western Kansas, more nothing than I have ever seen before. However, after getting further south, the landscape got greener, and there were more towns. We stopped in Guthrie on the way through, which is the site of the Oklahoma International Bluegrass Festival in October. Being a banjo player, I’m definitely looking forward to that.

Less than an hour after Guthrie, we were in Norman, our new home. After picking up the keys to our rental unit, we were pleasantly surprised by our new home. It looked a lot better than either of us remembered it when we visited a couple of months earlier. We still plan on making quite a few changes to the place, but there’s no place like home even if we aren’t in Kansas anymore.