Victory?

Today is Martin Luther King day, one of those random federal holidays that always seems to leave me wondering just what's open and what's not. It's usually safe to assume that the mail won't be delivered (lazy gits!) and that banks won't be open. There's no holidays at work since we're always supposed to be on site, so that's easy enough to keep track of. We have fewer employees come in, which is nice since that makes things much quieter.

The question I wind up asking all the time is "do the buses run today?" Our city attempts to be modern with a website that has the bus schedules posted among a number of other things, but the days when there's no service is hidden somewhere non-obvious and I always wind up having to hunt for it.

When I found it today, I decided that I was done looking and thought I should just keep the list of days in a convenient place. But, being a dork, I went and wrote a simple CGI script to determine if the buses were running and put it on my webserver. I reasoned that just having a simple link that I could check for this information would be rather handy.

It was maybe 15 minutes to put together. In the process of writing the thing and looking up when various holidays were, I became just familiar enough with the list of days that the buses don't run that the program doesn't seem quite as useful now that it's mostly in my head.

Figures.

2010

'Cause it's gonna be the future soon
And I won't always be this way
When the things that make me weak and strange get engineered away

--Jonathan Coulton, "The Future Soon"

---

In the scheme of how we actually live our lives, a new year doesn't really mean a whole hell of a lot; it's another trip around the sun for Earth and all the forms of life clinging to its surface. Not that we can really tell, but we mark this as significant anyway. Time to pull down last year's "Hooter's" calender and move on.

But hey, by our calendar it is 2010. And that's just neat.

I guess that the last year has had its ups and downs... For me, the good parts have been overshadowed by the general stress, depression, and so on and I haven't really been able to see them easily. So while I did post that I was glad to be done with 2009, it seems that further contemplation may indicate that this was a hasty conclusion.

However, rather than spend more time considering this, I'll move forward. Forward to THE FUTURE!!!

Lets see if this works

Python : The Good, The Bad, The Ugly

Recently, I started to really jump into learning Python. I'd been interested in it before; the live interpreter was awfully handy and it seemed like another good language to pick up. For whatever reason, I wrote a couple trivial programs in it and never really got back into it until a few months ago. Since then, I've wound up rewriting a couple Perl + shell scripts in the language and really liking it a lot. What follows are my impressions after trying the language out for a little while.

The Good

Python is really easy to learn, almost stupidly so. Much like my early days with BASIC on an Apple II, I can jump right in and try new things in the interpreter to see if they work as planned. This interpreter is also a very nice way to play with and test a half-complete script in pieces before letting the whole thing run, which is terribly handy.

Overall, Python seems to go out of its way to be really helpful; even if you don't have documentation handy, it isn't difficult to dissect a module and figure out how you can use it thanks to the dir and help keywords. Most documentation I've run into is surprisingly useful -- informative without being stupidly verbose.

Speaking of being verbose, I can't help but draw some comparisons to Java here. Python is certainly object-oriented, much like Java and C++ but it lacks those languages' distinction of being wordy and obnoxious. Yes, lots of things are objects, but you really don't notice unless you want to. Python doesn't seem to care what paradigm you use when programming.

I've also noticed that the various libraries available in Python are really helpful; tools like Mark Pilgrim's Feedparser make handling RSS and Atom a fucking breeze. You give it either a url or a file name and it figures out what you mean on its own and parses it into a homogeneous data structure. This saves me a lot of time compared to poorly-maintained junk like XML::Simple or some of the other XML parsing tools out there. This seems largely prevalent in the community as a whole; APIs are ridiculously easy to use I've found. pyAudere is another example; in roughly three lines of code, I can have a sound card initialized, an audio file (most formats supported, and it'll figure out what you mean on its own) loaded into RAM, and played back. I don't know that I've replicated such a feat with other tools.

Which brings me to something else I've really liked; the functional programming primitives that are readily available in Python. Tools like map, reduce, and filter and of course lambda are all just sitting there waiting to be utilized. These are awfully useful if you're hacking at Project Euler for fun, but quite handy for more typical usage.

As a new user of the language, I don't think that I can escape commenting on whitespace. For the most part, Python's whitespace rules are exactly what you should already be doing in the first place and as such I don't really see them as an issue. Lately, I wish that Java had a similar mechanism for when I have to read other people's code.

The Bad

Python is constantly evolving. Right now, there are two major branches of the language, the Python 2 version family and Python 3. Within Python 2, there seem to be three significant versions (2.4, 2.5, and 2.6). Here's where the fun begins; I wrote a program on my netbook which had Python 2.6 installed as that version seems to be both current and well-supported by major libraries. Python 3 has some nifty changes, but it seems that a good number of libraries don't support it yet. This will undoubtedly change in time, but right now I only play with Python 3 a little bit and tend not to use it for anything I'm trying to really work on.

Normally when there's multiple versions of a language, it would seem a simple task to just avoid other versions. I did however bump into issues with this, and while it isn't Python's fault, it is annoying. I wrote a script on my netbook, tested it and everything, only to have it crash when I ran it on the Debian box at home. The problem? I was using a string formatting method that wasn't supported in 2.4 (the default version on the system) but was most certainly present on the copy of 2.6 on my portable machine.

I'm also not a fan of how bugs just seem to lie in wait with Python scripts. Because Python scripts don't get compiled at runtime like Perl, I've been bitten by the occasional bug hiding down an obscure branch of a program, such as a syntax error or type mismatch that I never noticed before. Being new to the language, I often make late discoveries about things returned by objects, or member functions that are apparently missing in today's version of the language. This is highly irritating to me.

While I haven't run into this, I have heard tales of poorly-behaved editors in collborative projects utterly wrecking a script because one was using tabs and another turned the tabs into spaces (and so on). It's a little alarming to me that an editor can break a build that badly, but this isn't something I've run into in practice.

The Ugly

That multiple versions problem I mentioned? It can rapidly escalate into its own special world of pain and suffering. Again, this isn't really a problem that I pin on Python's tail, but it has been a bit of a headache. While downloading and building a version of the Python interpreter isn't an arduous project, it seems that the standard library isn't assembled for you in the process. My current installation of 2.6 on Debian 5 is halfway braindead because at no point in the configure script did it bother stopping to say, "hey, you need a current version of simplejson for this to work!" or anything like that. Even better, the instructions supplied when I attempted to make these things were not accurate. I think I know how to fix it, but I'm bothered that this should be an issue. Oh well, it could be worse; evidently there's problems getting it to build at all on OSX 10.6.

Conclusions

I'm really liking Python as a tool, and have barely looked back at Perl for the most part. I like Perl regular expressions better and how they just flow into the code as opposed to Python's re module, but that's mostly an issue of culture shock for me. Otherwise, I'm finding that a lot of my projects just work better, and seem to do so with less work on my part, which is really the important thing.

Internet down since 0945 today. Mediacom cant send a tech until thursday - when im in michigan. Useless.

Everything is Better With METAL

I think that they should run this clip by Mastodon before movies.

PSA

Parents, remember to talk to your kids about black metal before somebody else does.

Or else!

Movies : Primer

If you don't have time to read my blathering today, take one thing away from this post : See Primer if you haven't already.

---

I've been watching more movies lately as I finally broke down and got a Netflix account. While I have seen a fair number of pretty good films, I am reminded that Sturgeon's Law is in fact quite true. Not to mention that in an era where "science fiction" seems to mean "tits and explosions, but they're in space" it seems that really good science fiction has been hard to find, at least in the cinema. Still, there are good movies to be found if you look hard enough, and one of the best that I've seen recently is an obscure independent film called Primer.

Primer is about a couple engineers producing computer parts out of their garage and then trying to take things to the next level. They attempt an experiment with superconductive materials and are surprised by anomalies in their test results; further examination of the data reveals that they have created a device that may well allow them to travel through time. Once they've confirmed that this is the case, they ask themselves "what do we do with this?" Instead of bewildered disbelief and grandiose plans, they approach the use and circumstances surrounding their time machine in a fairly convincing manner; they're actually aware of time travel stories in popular culture and approach the situation as carefully as they can.

Also, the fairly natural dialogue of the movie is something I appreciated; people interrupt each other. They speak in jargon without explaining it to the audience. Between this and their fairly believable reactions to the situation as a whole, the character became very human and believable. It's also nice to see that the entire story was moved along by the characters instead of increasingly implausible situations. There's no villain or monster waiting to devour them. There's no plot to assassinate a famous leader or anything like that -- it's all about the people and one great big "what if?"

Anyhow, I really liked this movie and don't want to go into it too much for fear of revealing the plot. Suffice to say, I really liked it and recommend taking the time to watch it twice.

138/84 we are good to go!

If I worked in human resources, I would change my name to Giger.