Pug’s Place

So, I decided that now that I have a proper laser printer I want to be able to print professional envelopes again in Linux. I define a professional envelope as having three parts: return address, to address and the delivery point postnet (that barcode-like thing in the bottom right corner). In reality, printing the delivery point postnet speeds up postal processing by a day since it guarantees no human being has to look at the envelope until it reaches the destination street, and I always am a fan of efficiency.

So, what’s a delivery point postnet? It’s 12 numbers, the 5-digit zip code, the 4 digit +4, the 2 digit delivery point code and one check digit, printed in a height-varying barcode-like symbol on the bottom right corner of an envelope. Those numbers, taken together, indicate a specific mailbox in the United States. Theoretically all you would need to get a letter from A to B would be a delivery point postnet and a return address. I might try that sometime…

Back on track, I decided I wanted to print these things in Linux so I went tracking down free software to do it for me. I found Gregory Spath’s useful perl script called “envelope”, available on his website. It works like a charm - I expended 10 envelopes getting the margin values set right in my ~/.enveloperc file, but from then on it worked like a charm. It even prints postnets in the bottom right corner of the envelope! The only problem with this is that in order to print a full delivery point postnet it requires that I provide said delivery point value, in addition to the zip+4. Well, that’s a pain!

So, armed with the determination of being lazy in the future, I sought out something to locate that delivery point value for me. After several non-starts I realized that the USPS had several tools on their website to provide this value. One of them is even made to be used by programs (it has its web-based API)! Oh, that’s too good to be true, I thought! Indeed it was, the USPS requires a lengthy registration procedure to be permitted to use this API. Luckily, there still is another tool: a web-based query intended to be used by human beings. Unfortunately, programming something to use a web page intended to be used by human beings is generally another serious pain. Fortunately for me I found that Gregor Purdy wrote a perl module called Scrape::USPS::ZipLookup to do just that for just this script. Unfortunately again, it was slightly out of date. Fortunately, I fixed it and have emailed the changes to Mr. Purdy for release.

So that leaves me with a tool that can take a provided address, ask the USPS to correct it and return the full zip+4+delivery point code. What could I do next? Oh, it’s obvious, I wrote a GUI.

So now I have a small Gtk2 frontend to “envelope.pl” which you can see to the right here. It’s fairly simple: the address fields and four buttons. In brief, here’s what they do:

• Fix: Lookup the address with the USPS and fill in / correct fields
• Cancel: Close
• Print Preview: Show a preview of the envelope in GGV, GV or whatever you’ve configured to show postscript
• Print: Print the envelope using LPR

If you notice in the first screenshot I’ve put in a somewhat incomplete address. After pressing the “fix” button the USPS filled in the rest of the information for me, and that’s visible in the second screenshot.

Once that’s done I clicked the Print Preview button and the Gtk GhostScript viewer (GGV) opened to show me vaguely what the envelope would look like once printed. That’s the third screenshot.

Finally, the last screenshot shows the envelope I printed by clicking the Print button.

Not bad for a lazy Sunday morning, eh?

Source is available here: http://downloads.pugsplace.net/tree/envelope-maker-0.1.tar.gz. It contains the updated Scrape::USPS::ZipLookup module and Gregory Spath’s envelope.pl. You’ll have to install Perl-gtk2 and the dependencies for Scrape::USPS::ZipLookup via CPAN, but that’s described in the included INSTALL file.

I had a hard drive on my computer here have a complete head crash last weekend. Luckily, I’m a paranoid freak who runs his desktop with a RAID array, so no important data was lost. However, I realized over the week (while waiting for the replacement drive to arrive) that I have several places on the Internet to where I could do offsite backups of my most critical data if only I trusted them with the data.

Well, I had a bit of a brainstorm yesterday and I wrote a series of BASH scripts which I am actually rather impressed with which I’m titling PEBS: Pug’s Extensible Backup System.

Features:

• Written in BASH with minimal dependencies
• Provides a simple scripting language for defining what you’d like backed up
• Can be used on a multi-user system with each user defining what files they would like backed up via the scripting system (this is unsecure, presently, though)
• Uses GPG and your public key to encrypt the final backup archive before transmitting it to the remote host

Executive Summary for Interested Parties (Read!)

PEBS provides an infrastructure for remote, encrypted backups. Proper use of PEBS is going to require you to be comfortable with the “tar” command and have a basic knowledge of how to edit a shell script.
What PEBS does is takes care of backup naming, data encryption, data transfer to the remote server and verification of successful transfer. It also provides some logging of the results. If you’ve questions, look at the script example below for an idea of how to use this tool.

Download:

• PEBS (tar.gz)

Read more

For those of you who regularly read my blog, you can skip this entry. It’s just a compilation of what I’ve said so far about SCHUA so that I can have one post which covers everything. At Dr. Fishwick’s suggestion, I’m going to post SCHUA to the Processing exhibition page.

My CAP 5805 term simulation project was SCHUA, my Schooling User-Interactive Aquarium. Yeah, the acronym sucks, but it’s pretty. SCHUA is a simulation of fish, dolphins and sharks (and fish food) in a 3D spherical aquarium. All entities have agent-based artificial intelligences and school, hunt, eat, avoid other species and generally stay alive.

This simulation showcases emergent behaviour - complicated behaviour made up of a blend of simpler sub-behaviours. It is an extension of Boids, a bird flocking simulation created by Craig Reynolds in 1986. SCHUA is drawn in 3D with OpenGL, has multiple species with unique characteristics, Newtonian physics and additional behaviors such as hunting.

The sliders on the left change the coefficients which blend different behaviours of the fishes, and the smaller buttons on the right add more agents of various species to the aquarium.

It’s rather cool to watch. The fish school around, trying to avoid predators and unfamiliar species. When you add fish food, they go up and feed on it. The dolphins streak around the aquarium eating fish, and the sharks lurk around munching on living targets of opportunity (including dolphins). I’ve faked underwater lighting with texture maps, so light ripples across their bodies as the agents move. You can rotate the aquarium around and zoom in/out.

Further stuff you can look at:

• The project’s demonstration video is online at Google Video. You’ll need Flash to play it: SCHUA Demo on Google Video If there’s demand, I can put up a DivX and MsMpeg4 copy on Archive.org within about a week.
• The final report has detailed pseudocode of all of the algorithms involved as well as more details on how everything works. It’s online here: SCHUA Final Report (PDF).
• The source code can only be compiled and run with Processing, a Java simulation package. Luckily, Processing needs nothing more than a java environment to run, so it’s easy to install and easy to work with. Just uncompress SCHUA into your processing “sketch” directory, which defaults to “My Documents\Processing” in Windows. Processing is very simple to use, so even people with only a basic knowledge of using a compiler should be able to make SCHUA work. This FAQ entry and its links may be helpful for anyone giving Processing a try. SCHUA Source Code Release 1 for Processing, released under the X license.

a useful tool for filling CDs/DVDs/Mp3 players with what IMMS already knows you like.

IMFavorites queries the Intelligent Multimedia Management System database to figure out your favorite songs, then symlinks them to a place of your choice.

What the?

If you’ve used IMMS for more than a few days, it’s already gotten a decent idea of what kind of music you like and what kind of music you do not like. That information is stored within its database, dripping with desire to be useful. This program simply uses that information to find your favorite songs (as IMMS knows them), and then do the hard work of compiling a CD, DVD, Mp3 player full of your favorites for you.

• IMMS Website: http://www.luminal.org/wiki/index.php/IMMS
• IMFavorites Website: http://www.cise.ufl.edu/~jcjones/src/
• Pending Freshmeat Entry: http://freshmeat.net/projects/imfavorites/

Anyway, that’s what I was doing last night when I should have been doing more homework.

So this project joins my GKrellM Countdown Plugin, my University of Florida customized replacement perl script for the GKrellWeather plugin for GKrellM, and P-Guide, a WYSIWYG UI generator for PUI as being >95% PugCode. Of course, HID-commander will be an important one once I get it working. As will Gpremacy… Some day…