Among other interests (network security, bushido and its application to modern business, and refinery IT), I’ve been working to learn Python. It’s a clean, easy-to-learn language with some syntactic quirks but extremely quick to get results.
To apply everything I’d read, I decided to write an IRC client. IRC (Internet Relay Chat) is a fairly straightforward protocol, and if you’re quick on the keys and can keep track of multiple discussions in your head, you can chat effectively with nothing more than a telnet client. Some of us, though, need a little help. There are many great IRC clients out there, but this was a nice DIY project.
There’s still plenty to do to make it perfect; there are a couple of minor issues with the message parsing, commands are still shown in their raw format, and so forth, but 1) it’s usable enough for me, and 2) programming in curses is evil. At some point the law of diminishing returns takes over, so that’s why this is 80% done.
The code includes the base engine for the IRC client, and a curses-based user interface. Right now, then, this only works on Linux machines. I may someday write a front-end for Windows, but see the previous paragraph. This is also released with a Creative Commons license (Attribution-NonCommercial, for those keeping score)
Thanks, and enjoy!
Download Python-IRC 0.5
From an IM session tonight:
Me: Not much. Enjoying married life, writing an IRC client in Python to keep from going insane doing documentation at work, the usual. You?
Ernie: most people get bored and IRC; you get bored and write the client
My work computer died today. I spent part of the morning backing up my files, something I rarely do. When I came back from lunch, it realized that it was now redundant and had lost the will to live.
Sometimes, Fridays suck.
My appearance on Pixeldiva’s portrait week.
That was an awesome night, and a great shot to boot. Ann and Dave are in many ways responsible for Christine and I getting together. Thanks for the nod.
I’ve been ruminating (there’s your SAT word for the day) on this for some time, and there are a couple of things that I’d like to see happen to blogs.
- Threaded Posts/Archives
I started thinking about this when Kottke redesigned and pointed out why he was unhappy with the archive pages. Date sorting is nice for posterity, but it doesn’t help me find things later. Categories are a step, but that’s only a filter on the date sort – the same problem exists.
What I’d like to see is a sort of threading model between posts. That way, I can follow individual conversations through the archives and find specific topics more readily than with categories. Also, it would enable interesting analysis, like seeing thread convergence and visually mapping the content of a blog.
There are a few ways that this could be implemented; specifying the parent post(s), incestuous trackbacks, and the like. It needs to be explicit parent-child relationship, though, and not just a “related post” thing in order to maintain the structure.
- Variable-length RSS(/ATOM/whatever) feeds
I admit it, I’m lazy and use an aggregator at work. You’re all wonderful designers with beautiful sites, but I couldn’t keep up with everything if I had to run through a list of bookmarks every day. Unfortunately for me, my aggregator can only pick up whatever is published in the latest feed file, usually a set number of items (say, 20). That’s great, but what about when I’m away from my work computer for a day or two? I’ll pick up the last 20 posts and then lose whatever was in the middle.
What I’d like is some way (query string? SOAP service?) to pass along the last item I received and get a feed file for everything since then. What makes this better?
- I can change the update frequency to whatever I want. If I only want a daily or weekly digest of a site, I can get that without losing information.
- Reduction in traffic and bandwidth usage. If nothing has changed, I’m not re-downloading the same file, and if I choose to only update once a week, that’s many fewer requests than every hour.