I haven't used these programs in many years, so no guarantee bit rot hasn't taken place.
After noticing lots of extra garbage (dozens of zip codes) in the weather program I regularly use, I re-wrote the it in Go as weather.go. It's twice as big as the Expect script version, but I had to use a lot more explicit error checking. It was a good exercise on spawning remote processes, with bi-directional, unbuffered I/O through pipes, regular expressions (matching and replacing), timeouts, and a minor bit of concurrency. It's not a bad language.
I wrote a simple 1-person bananagrams-like program in Python and GTK. The tar-file is here. Current version is 1.2 (updated Nov. 14, 2013).
I worked with others on a project that used git and github, and its built-in bug-tracking system. It was clunky to use their web interface, and I wanted to import the bug database into a spreadsheet. So this is a simple Python program that uses GitHub's web API to dump a bug database into a comma separated value (CSV) list.
Here's a weather script in perl to connect to the wunderground weather server and print useful information. It's the back-end behind xforecast, mentioned above.
This script gets aviation weather reports (METARs and TAFs) for U.S. airports using airnav.com (Updated Oct 24, 2013 to use aviationweather.gov).
I wrote an address book program to manage addresses as well as remind me of birthdays. Here is a page that documents the program. Once, when I was stuck at an airport and out of touch, electronically, I realized I needed a way to print a hardcopy of the address book. So, I wrote a script to print a "little white book". It generates postscript output and requires that you have this postscript header file too.
Altavista was a cool search engine. I like google better. However, babelfish was very cool. So I wrote a script that provides a command line interface to babelfish, suitable to be use with pipes as a filter.
I'm working on a web based adventure game. I've got the basic engine done and the world will be created based on a story Pierce and I wrote. Unfortunately, I haven't had much time to put into this in a while. At some point there'll be a link to it.
As part of the GIAC Certified Forensic Analyst (GCFA) practical exam, I wrote a tool to help investigators conduct experiments on the effects of different archiving programs. The tool is called tar2d2 and (sort of) stands for "Testing of Archivers for Reference of Restored Disk Data," but in fact it is just "a little helpful droid."
Pretty much all of the code running MyCause is mine. That is not public, at the moment.
.mailrcfile are automatically added to the list.
It seems to do a pretty good job filtering mail. But then I wondered, exactly how good of a job was it doing? So I modified the script to automatically add an entry to a log file for each message it processes. Of course, it sometimes gets things wrong. So then I write the jmlc (Junk Mail Log Corrector) Program. Run it and cut-and-paste the "From " (note: not the "From:") line of the mail message as standard input and it'll mark the proper entry in the log file as being misfiled.
Then I wrote the jstats (junkmail stats) program. It takes two command line arguments, a start time and and end time, both of the form: MM/DD/YYYY [HH:MM[:SS]]. It prints out:
Sample output is:
$ jstats.pl 09/01/2003 09/17/2003 23:09
1329 total messages
201 filed as good, 1128 filed as junk
18 misfiled as good, 5 misfiled as junk
188 actual good, 1141 actual junk
Junkmail is 85.85% of total mail
False positive is: 2.66%, false negative is: 1.58%
Not too bad. On average I get 60-80 pieces of junkmail a day and this makes it manageable (under 3% failure rate).
acpi(1)command to provide a visual indication of the battery status using Perl/Tk. Below is an example of what it looks like.
It indicates the percent battery power, shows a graphic, showing 1-10 rectangles (1 rectangle=10 percent power, 10=100 percent power), and the rectangles change from green, blue, yellow, and red, to indicate full, good, low, and critial levels of battery power. Below the graphic are optional messages that indicate how much time is left on the battery (e.g., "03:14:34 remaining") or how long till it's fully charged (e.g., "00:15:35 until charged").
An appropriate entry in /etc/X11/fvwm2/system.fvwm2rc or one's own
personal .fvwm2rc file to put it in the Button or Menu bar
would be something like:
*FvwmButtons: (Swallow FvwmXbattery 'Exec battery.pl -name "FvwmXbattery" -geometry +0+0 -padding 1 -bg rgb:91/ae/d6 &')
Here's the source for battery.pl
As an aside, I was at a conference (Usenix 2008) when I started writing this, as I wanted to know how much battery power was left when I was working while not plugged in. Within a few hours, my battery died—we're talking fried, going from working fine to totally holding no charge. Nothing I did, really (calling acpi won't damage it), but the timing was amusing. I was very tempted to simplify this whole process by just displaying a permanent "0%" in red in a window and being done with it.
Configuring an Intuos4 tablet under VirutalBox
I got a Wacom Intuos4 pen tablet and wanted to use it on my Windows XP VM
under VirtualBox (with Ubuntu Linux as the host) on my laptop. This is
the description of how I got
it to work. Sort of.