I finally came across a mostly uncut video of Larry Page's keynote from CES 2006. Make sure to watch both of the parts with Robin Willams for maximum effect.

I've found that the most difficult part of the Summer of Code has been refraining from working on too many other projects at the same time in order to keep focused. However, I have a few projects in mind that I am planning to put some time into when I get back to RIT. My class schedule for the Fall has no classes on Friday so I figure that will be my project day.

I spent a good part of the weekend catching up on Hak.5 and am really pleased with the progress they've made since the first episode. It has also gotten me thinking about a vidcast that I would like to produce. They spend a lot of time on Hak.5 showing software and projects that you really need a solid home server/network setup to get anywhere. It has come to my attention that the knowledge of how to get a geek network running is not widespread. Following that thread, I want to produce a vidcast that shows how to setup and maintain your own network for geek related activities.

I envision the first few episodes being about selecting network equipment and running cables in order to get the infrastructure up and running. Following that, I'd start with good network security on the cheap (read: OpenBSD) and a few cool tricks like VPNs and possibly an IPv6 tunnel. Next, I'd start building servers... One Linux box, one Windows (or a virtual server setup). The Linux box would run a basic LAMP setup (done right) and the Windows server could run game servers and possibly SharePoint.

That would complete "Season One" Season Two would build upon those basic components to do increasingly cool things such as a MythTV box, a Jabber server, rolling your own web environment for the cost of an internet connection. Hosting a blog, building a community (using something like Drupal or a Wiki), setting up an authentication server, etc. A show like this could probably go on indefinitely.

If somebody reads this and thinks it's a good idea, drop me a line and we might be able to get something going. I could probably get started on my own but I just don't have the time/skills/resources to do that sort of production in a reasonable amount of time. Not to mention that this sort of thing is always more fun if you've got friends involved. Perhaps some other CSHers would be interested in helping out?

Switching to another train of thought, I've ordered parts to build a CMoy pocket amp in preparation for getting a decent set of headphones (Something in the range of Sennheiser 555 or 595 if I can afford it). The CMoy design is simple and shouldn't be too difficult to get working. Just in case, I ordered enough parts to build at least two of them. I'd like to build one of the more complicated amps at some point, but we'll see how I do with the CMoy design first.

Yet another project I've started is a Hipster PDA for the purpose of collecting all of these random thoughts and other scraps of information that have become important. I used the "Classic" size (half a letter sheet) because my handwriting tends to be sloppy and I like to have lots of space to work. My primary motivation for doing making a Hipster PDA was because the Stickies app that comes with OSX was really starting to clutter up my desktop and most of the information is only useful when I'm away from the computer.

Moving along to the next idea, I saw the FTIR Touch Sensing display and was inspired by the simplicity of the design. I'm planning to build something along those lines eventually...

I'm also trying to come up with a good way of building a portable server/network setup. I ran into some pictures of an audio rackmount case filled with some 1U servers at HOPE and thought it was a pretty good idea. The problem is that most of my boxes could not be transplanted into anything smaller than 2U so I'd probably have to buy new hardware. Unfortunately, new hardware tends to get expensive fast. Still trying to come up with better ideas here. Perhaps I could machine some custom cases...

Other projects I've had on my mind: A hex editor for EEPROMs built out of bunch of seven-segment displays, fix the formatting of &thinsmp; in the Gecko engine, an open source implementation of the Atom/XMPP stuff coming out of the atompub working group, a magstripe reader built out of a cassette tape head, and a RJ45 jack that lights up the connector with an LED when certain conditions are met (DHCP acquired, HTTP request received, etc) instead of just putting the LED next to the connector.

I hope you enjoyed this core dump of ideas... Perhaps you might be inclined to take the initiative and do one of them?

I realize that I haven't posted an update on ietfnotify in a while but I felt that it was more important to spend more time focusing on the code than writing about focusing on the code. I've made quite a bit of progress toward adding a bit of polish to the daemon and web interface and am getting ready to start implementing a templating system for notifications.

I have moved almost every aspect of the notification data into the database to aid in more automated operation. New fields will now be detected automatically and added to the database where they can be marked as hidden or visible to users of the web interface for setting up filters. This allows us to add new fields to the notification format at any time without any maintenance to the notifier application.

Debugging is now much easier with a log module. I will later implement syslog through Python's builtin logging module for general operation. I moved some of the formatting code for various notification types into a new message module that will later be replaced with the templating system.

After evaluating a few possible options for templating, I have narrowed it down to Django's template system. It seems to be the easiest to work with under the circumstances. I attempted to implement a Python dict formatting based approach but it just isn't flexible enough for some of the things we need to do. Not until Python 3000.

I am no longer committing new code to my local repository but am instead committing directly to the subversion repository on the SourceForge servers. Henrik and I have come up with a rough schedule for the remaining eight weeks of the Summer of Code and I am confident that I can complete the project in that timeframe.

The notifier is now available as an open alpha release. You will need to have an account on the IETF Tools site. You can register here. Once you've registered and verified your email address, you can login to the notifier web interface and set up your notifications. Please do not rely on the notifier at the moment. This is an alpha quality program, take it for what it's worth.

SourceForge has approved the ietfnotify project and I've moved my development infrastructure to the SourceForge servers. The subversion repository is available through SourceForge now and I will continue doing all development in that repository. My repository here on CSH will remain for a while but I will no longer continue active development on it.

In terms of development efforts, I spent a bit of time last night tightening up the security of the web app, eliminating a few SQL injection holes and a few other possible problems.

Good news! The web interface is done, subscriptions have been moved into a database, and the notification daemon is now completely modular. I didn't sleep much last night and got quite a bit of good code out of it.

I'm planning to open up the web interface for some beta testing sometime next week so you can look forward to that. Still waiting for SourceForge to approve the project... Their site shows that it's been in the queue for six business days, double the estimate of three days given on the submission page.

I decided to make the notification daemon a bit more modular after my experiences with building the web interface. I find that it's easier to maintain, debug, and add to existing code when it's split into smaller pieces. I built the various components of the daemon into a Python package called "notify". I'm trying to keep in mind that I may want to use this code for other projects in the future, so having things modular will also make it easier to steal bits and pieces.

I've spent the last few days building the web interface and I finally have something functional. With any luck, I should be rolling out a 'beta' within a few weeks. Still waiting for SourceForge...

I made a bit of visible progress today with the first working notifications. Things still aren't entirely stable, and I haven't even started thinking about the web interface. But, the Atom feed is working as are email notifications. Still waiting for SourceForge to approve the project.

I'm hoping to get a bit more testing done tomorrow morning and start work on the RSS feed. It shouldn't take much more work than the Atom feed did. Following that, I need to make things a bit more robust so that things like malformed fields don't crash the server. Once we've got some real events running through the system reliably, I'll start in on the web interface. Seeing as how I'm getting through things much faster than I had expected, I'll probably spend a bit of time making the web interface look nice.

I took a break yesterday from my Summer of Code project under the philosophy that I should allow myself the benefit of weekends that most jobs offer. I've talked to people that telecommute in the past, and they've mentioned that the biggest problem is separating work and personal life. In this respect, I've started to regiment myself a bit more in an effort to keep making progress.

Earlier this afternoon, I decided that I felt like writing some code and took a stab at extending my notifications interface. I found that it's almost a little too easy to write new notifiers. This type of plugin interface will definitely come in in handy when I try to do more exotic things. I have come across a few new obstacles though.

The most apparent problem is that everything is single-process and single-threaded. If a notification hangs (or is significantly slowed), all other notifications, and the event protocol hangs too. I'm considering just running all notifiers in separate threads, to keep things nice and parallel. On the other hand, it may only be advantageous to have a new thread for each notification type so that I don't end up pounding an already slow mail server. These will definitely be things to think about.

The good news is that even with all of the rather barbaric methods I used to parse some things, the program is still much faster than I need it to be. Memory utilization is kept to a minimum, and I expect that as long as the python interpreter can be loaded, I won't have much trouble on a high load server.

I'm still waiting for SourceForge to approve the project request, so I don't have that repository up yet. I'll post here as soon as it's up.

That's all I've got for now, take a look at the latest repository if you're curious about the code.

I've got backups from the old web server and have restored the recent blog entries to their bloggy goodness.

Good news! Google had a cache of the last few blog entries, so I have recovered and posted them here. Unfortunately, any links that existed inside the posts are gone (and a lot of the information is outdated already). Just a few quick clarifications: The subversion repository is up and running with more than just the ietfnotify project, I can be reached through jabber at synack@jabber.org until I get a new jabber server up, and I will be posting daily progress (with a few missing days) from now on.

A quick overview of what's been going on with ietfnotify:

• Domain and Inet sockets are working (selected via a config file)
• Incoming events are parsed into a usable structure
• Events are checked for required fields based on a config file
• A new UUID is generated for every event
• Files containing the processed event data are generated and named after their UUID
• Events are timestamped in proper RFC3339 format
• Packets are handled properly so that netcat can be used for debugging
• KeyboardInterrupts are handled properly

I was tired of waiting to get copies of everything off my dead server, so I used a slightly older backup of the site to get things going again on CSH's servers. I'll revive the old blog entries and put them back where they belong as soon as I can. Until then, you can get an idea of my Summer of Code progress by taking a look at the public repository. I will also be mirroring this repository on SourceForge as soon as they approve my project request. Hopefully, my site is here to stay. So update your bookmarks! (Again)