Planet Egocity

Over the past couple of days, I've implemented a private URI shortener service for myself, which I have named "Rshrtnr". The derivation of the name is left as an exercise for the reader.

My main motivation for writing it was a criticism of public URI shortening services that I have been seeing in blogs for a long time: if the service has some downtime or suddenly disappears, all of the links that you have created with it are useless. With my approach, I regain some control of where my shortened links point to, and if the service has downtime and/or disappears, I have more options for restoring it.

The code itself is written in Python. SLOCCount says that the core module runs at around 100 SLOC. Most of my time, however, was taken up by working around problems relating to my webhost's Python installation. The supported Python version is 2.4.x, which is ridiculously old (for reference, Gentoo was the last major Linux distribution to switch from Python 2.4 to 2.5, around July 2008). Additionally, for some reason, if I attempt to change the sys.path variable (i.e., the "include path") to use locally installed modules (I am on a shared host), the entire script breaks with zero logged messages anywhere. It runs fine via the command line, but in FastCGI mode, the strangeness occurs.

The two third-party modules that I used were Paste and mysql-python. I store the URIs and their associated aliases in a simple SQL table, and I use Paste for various WSGI/HTTP-related utilities. I "manually" handle routing via parsing the PATH_INFO environment variable.

There are two ways to specify an alias: either explicitly send a custom one as a query parameter with the URI, or let the app make a random one for you. With the latter behavior, it hashes the URI to generate an eight character "unique" alias. Since there are (in theory) 64^8 possibilities, I don't think I'll run out of aliases any time soon, especially since custom aliases can be anywhere from 1 to 15 characters long.

In my opinion, the most interesting feature is that adding URIs requires one to send an OpenPGP-encoded query string, which needs a public key recognized by the app for the operation to succeed. To write this, I simply parsed the output from sending the OpenPGP message to the gpg binary.

Finally, mod_rewrite magic is used to prettify the shortened URIs. Nothing too exciting about that part.

I had thought about hosting a version of Rshrtnr on Google App Engine, but a key component is missing - OpenPGP support.

If anyone wants me to release it, please comment below. There's currently a bunch of webhost-specific things that I would need to abstract out before I release the code to the general public, and unless someone gives me a very good reason, it will be licensed under the AGPL version 3.

One of the more interesting areas in software development, to me at least, is language bindings. Being able to interface with a library written in one language in another language is kind of satisfying, as it allows me to develop without having to reinvent the wheel. There are two specific projects that I use and work on so that I can enhance the software that I develop: GObject Introspection (G-I) and python-spidermonkey.

GObject Introspection

As a quick overview, the goal of this project is to give C libraries the tools to provide enough metadata about their API so that bindings can be written with minimal effort. Given the time and effort that I have put into maintaining the Awn bindings, it is not very surprising that I would be willing to help out getting this framework working for Awn. My ultimate goal is to eliminate the bindings/python folder in the Awn source tree. It is basically a mixture of a Scheme definition file plus a very bizarrely formatted "override" file for custom definitions, all integrated into autotools to produce a C library that is ready to be dynamically loaded into python via import. To meet this goal, I am contributing to the PyBank project, which is a prototype Python module that interfaces with the GObject Introspection library to read compiled library metadata files (called "typelibs") on the fly so that classes, functions, etc. can be loaded and called at runtime. In addition to myself, a Google Summer of Code student and a Sugar Labs developer are also working on the module, with Johan Dahlin overseeing it all. So far, I've contributed a unit test suite, ported from the gjs project (JavaScript bindings for GLib-based libraries based on the Spidermonkey VM) and working type bindings for various simple types (e.g., int64 and float).

I have also put some coding effort toward G-I integration in Vala. Vala supports G-I by both reading GIR files (the XML serialization of G-I metadata) to produce VAPI files (short for Vala API files), and writing GIR files when producing a library written in Vala (e.g., libdesktop-agnostic). I have contributed mostly what amounts to workarounds in the GIR reading code, with regards to Vala/G-I behavioral inconsistencies. Didier 'Ptitjes' has done much, much more solid work than I have on both fronts, which I greatly appreciate.

python-spidermonkey

This project, as the README states, lets you [execute] arbitrary JavaScript code from Python[, and allows] you to reference arbitrary Python objects and functions in the JavaScript VM. As I've stated in an earlier blog post, I use this in my custom website build system to both validate and pack my JavaScript code, via JSLint and Packer, respectively. Since I published that post almost two years ago, that project was revived twice - once by a Mozilla employee (and co-founder of Humanized, which is quite awesome) named Atul Varma, and the latest incarnation is on github. Since it is based on the original implementation in C, and not the Python-based ctypes version, the Base2 recursion problem does not exist, and so I have happily written modules and scripts which wrap the two JavaScript utilities. Recently, I have made them available in a public project on Launchpad called python-jsutils. I haven't really announced it until now because it currently relies on a change I made to python-spidermonkey which allows one to iterate over a JavaScript array, instead of having to write "unpythonic" code like for x in range(0, len(foo)): #.... While it is in my fork, it has not been merged to the "official" repository.

I need something to get myself blogging again, so I figured that I should write about how my website is written. I'm going to start with one of the parts written in JavaScript: the Tag module. It's comprised of a simple JavaScript object with static methods and properties, no instances. Its main purpose is to create (X)HTML nodes for use in what used to be known as "dynamic" HTML. Incidentally, it's also part of my "old projects" series: I originally created it for an Intel-sponsored research project that I was working on during my time in university. (For more details on the project, please see my curriculum vitae.)

In practice, calls using Tag.create() don't look too horrible. Consider the example of building a minimal HTML5 document:

var html = Tag.create('html', {children: [
    Tag.create('head', {children: Tag.create('title')),
    Tag.create('body')
]});

Or, a data table:

var table = Tag.create('table', {
    attributes: {summary: 'MLS Statistics'},
    classes: ['sortable', 'centered'], // uses sorttable
    styles: {border: '1px red inset'}, // use CSS style names, not JS ones
    children: [
        Tag.create('thead', {children: Tag.create('tr', {
            // text is automatically converted
            Tag.create('th', {children: 'Team'}),
            Tag.create('th', {children: 'Goals For'}),
            Tag.create('th', {children: 'Goals Against'})
        })}),
        Tag.create('tbody', {children: [
            Tag.create('tr', {
        Tag.create('tbody', {children: [
            Tag.create('tr', {
                classes: ['west-coast', 'usa'],
                children: [
                    Tag.create('td', {children: 'Seattle Sounders FC'}),
                    Tag.create('td', {children: '9'}),
                    Tag.create('td', {children: '3'})
                ]
            }),
            // add more teams here...
        ])
    ]
});

I recently modified the function so that it deserializes an object (originally a JSON string) into a DOM node tree. This is particularly useful when you're sending partial HTML documents as JSON strings (which I prefer to sending HTML strings and dealing with that mess). So, the first example would look like this:

var html = Tag.create({
    "name": "html",
    "children": [
        {
            "name": "head",
            "children": {"name": "title"}
        },
        {"name": "body"}
    ]
});

Interestingly enough, I created this without the knowledge of the existence of JSONML or any of its bretheren, although I suspected that JSON-HTML converters already existed.

Three of the functions in the module are basically wrapper functions. Tag.createWithText() creates an HTML element with a text child node, and Tag.createHeader() creates an HTML header element (e.g., <h1>...</h1>) with a text child node. Tag.text() is shorthand for the DOM's document.createTextNode() method.

In the current iteration, nearly all of the event-related code is commented out, as there are far more competent JavaScript libraries out there which deal with cross-browser events. The only event-related function left is Tag.dispatchEvent(), which sends a "synthetic" event for a given HTML element. If I remember correctly, I coded for both the W3C and Microsoft models, but I don't remember testing it on browsers other than IE6/7 and Firefox 2. At some point, I'll probably reintegrate event support to Tag.create() at minimum, using Base2.

The remaining function is a utility function. Tag.inXHTML() determines whether the document in question is in XHTML mode, using a variety of heuristics. I'm sure there's a better way of doing it, but I couldn't find one when I was researching it.

This module has been tested in IE6/7, Firefox 1.5/2/3, Safari 2/3, and Opera 9.5 - although not all in the same time periods. It's licensed under the Apache Licence (version 2.0) and is currently somewhere in my compressed JavaScript file. If there's any interest, I'll put up the non-compressed version somewhere and update this post.

I mentioned on Twitter that I wanted to blog about some old projects. The first one is more than a year old, but it still may be useful to someone.

Back during college, I was implementing a file sharing client with Twisted - the GUI was first written using wxPython, and then rewritten in PyGTK (the reasons for the rewrite I can expound upon later, if anyone wants to know). It's not publicly released, mostly because it never got past being a chat client. Anyway, a part of the file sharing protocol involved tiger tree hashes to verify the data as it was downloaded. I couldn't find an implementation in Python (and attempts to write it myself failed), so I found some C source code and manually bound it to Python (via its C extension API). This was my first exposure to extending Python via C — I later used some of this knowledge to fix up the Python bindings for Awn.

The Python part is licensed under the Apache License v2, the tiger (tree) code is public domain-ish. (see COPYING for details)

The code can (as of the publication date) be found in a junk bzr branch on Launchpad. If you wish to continue work on it, I can move it to a full-fledged project — just contact me about it via the comments.

Edit (2009/03/24): Due to interest in the code, I've created a project for pytiger at Launchpad.

Benjamin Otte recently wrote about desktop-web integration in the GNOME desktop. It's kind of interesting that he calls himself "not web enabled", given that he's the main developer of the swfdec library and associated applications. I agree with most of what he wrote, but there are a few comments I would like to make.

Benjamin asks:

Why does dconf (or GConf) not store my settings in the cloud so it uses the same settings on my university login?

As I understand it, this is one of the features of Conduit. There's a bug in Awn regarding config synchronization via Conduit. I'm probably going to look into how that works when I resume work on the config interface for libdesktop-agnostic.

There is an erroneous statement in his post:

We don't even have a http library that knows cookies.

libsoup has had (non-persistent) cookie support since 2.23.1, and persistent support will be in 2.26.0.

And then there's the main point:

[GNOME is] doing a very bad job at integrating the web into the desktop. Apart from epiphany (and the weather applet), what application does GNOME ship that speak http?

I believe there are two main reasons for this: One is GNOME developers are not "web-enabled". [...] The other, related reason is that we don't have the software to do this.

In Awn-land, we have several web-enabled applets:

• arss
• comics
• digg
• lastfm
• meebo
• pandora
• rtm
• weather
• webapplet

In particular, webapplet is a work in progress framework, which will allow what is essentially an applet version of Mozilla Prism. It currently uses WebKit as the backend, although there is also a Gecko-based backend planned. The rest of the applets listed are written in Python. In particular, the digg, meebo, pandora, and rtm applets use the gtkmozembed Python bindings to view the respective websites. Here lies one of the problems of the web-enabling the GNOME platform. This library is acknowledged to be less than ideal. If you look at the source code of the applets, you'll see that there are some ugly hacks in order to make them work properly on Ubuntu systems. Webapplet is slated to replace that ugliness.

One of my side projects is a status aggregator applet. It's supposed to aggregate all of these social networking status feeds and also to sync all of your personal statuses. One of said social networking websites returns complex, site-specific HTML that obviously needs to be sanitized/canonicalized. The easiest (but not necessarily most memory-efficient) method of performing that task is to use the DOM. There is not currently a DOM library for the GNOME platform. There is a libgdom3 project (written in Vala) which I believe is being / will be used by the gnome2-globalmenu project, but it is unfinished. There is also an old, unmaintained library called gdome2 based on libxml2. I'm not even sure if anyone actually uses that library anymore (its last release was in 2003). I avoided using gtkmozembed and friends based on the experiences described above. I settled on a promising feature request for WebKit: a GObject/C DOM binding. (As an aside, the WebKit bug linked is a fascinating case study on several levels: conflicting coding standards, conflicting developer personalities, and some interesting coding/reviewing.) It's very nice - I can manipulate document fragments as if I were using JavaScript in a web page, among other things. I eagerly await that feature being committed to WebKit trunk.It is an important stepping stone when it comes to working with the web.

Another side project that I'm currently working on is a developer dashboard applet. It's kind of like the previous applet, except as applied to software projects. I was originally going to write it in Vala, which meant that I would have to write an interface to (at least) the Launchpad API, which meant implementing at least three specifications in Vala: OAuth, URI templates, and WADL. I finished the first two (I haven't yet decided whether to release my URI templates implementation as a separate library - the implementation plus the test app is 451 source lines of code), and WADL is a very complex specification. So, I decided to postpone working on the WADL library and instead am currently working on a prototype applet using Python and launchpadlib. Implementations for those three specifications and many others (including AtomPub) should be included in the GNOME platform if it wants to be web-enabled.

Mike Rooney (Awn Extras developer, among other things) posted an article on this "webhooks" idea. As I understand it, it's essentially a customizable, web-based version of the "Subscribe to future XYZ via email" features (e.g., blog comments) that are currently around. The key phrase in this sort of thinking is "push technology". Mike asks:

So will webhooks replace the current paradigm that I'm using here, or complement it?

I believe that it will complement the current paradigm. We need to have a transitional period (à la the old, rigid deadline for the US digital television transition) between the current "polling" techniques and the "new and shiny" (and arguably bandwidth-saving) push techniques. Take, for example, Twitter [1]. Let's assume that they didn't shut down their XMPP service, and they built upon it an (XML-based) API so that a client (for the purposes of this thought experiment, let's say my currently-in-vaporware Status Aggregator Awn applet) could connect to a specific JID (AKA user name + domain + "resource", or specific client) and listen for any new tweets, responses to my tweets, etc., replacing those messy timeout callbacks with messy async socket callbacks. The main benefit that I see is a savings in bandwidth for both the consumer and the producer. It avoids sending network requests every X minutes, which would add up, given the number of services/feeds that a user subscribes to (including mail). This actually leads me to my answer to Mike's other question:

Are webhooks the next step of this evolution, or something else entirely?

As evidenced by my thought experiment, I'd like to see XMPP as the next step, or at minimum, the step after webhooks. While I love HTTP, and am a big fan of the whole REST concept, it's hard for me to see it used as a facilitator for pushing data, as opposed to pulling it. In fact, given the way that ETags and the like are designed, HTTP is inherently a pull technology. The Comet model feels like a big kludge to me for that reason. XMPP, on the other hand, is designed to be a push technology, and its supporters are actively marketing it as such. It's also scalable, as servers like ejabberd and services like Google Talk can attest. I suppose the bottleneck here is a catch-22: you need both services and apps to buy into this particular implementation. Maybe when I finish one of the myriad projects I have going at once, I'll take a crack at adding a push-based web service client. Ideally, for configuration, all a user would have to do is set their app-specific JID (e.g. foo@example.com/bar_app) in both the web app and the client app, and it would "just work" (well, you would also have to set the JID password somehow as well, but that's beside the point).

Update (2009/02/18): It seems that I was subconsciously channelling a presentation on XMPP PubSub that I read over six months ago.

For the past week or so, I've been working on various web services-related libraries, in the hopes of writing some sort of Launchpad dashboard applet for Awn. I think it would be nice to have new/recently changed bugs in Awn/Awn Extras at a glance in the dock, among other things. The first somewhat complete component is an OAuth client library. I finished the initial implementation (plaintext signature only) in under nine hours, and after the Awn 0.3.2 release (and a bit of frustration), I added HMAC-SHA1 signature support with the help of RFCs 2104 and 2202 (using GLib's checksum API). I've tested it with both the OAuth example Python server and the Launchpad API.

Also included in the source are two small test programs: one tests the HMAC-SHA1 implementation, and the other tests the OAuth implementation in its entirety. The latter uses .ini-style config files to define keys/secrets/URIs/etc. for a service.

There are a few things that still need to be done, in order for it to be a "complete" implementation. I probably want to replace my handwritten HMAC-SHA1 implementation with a libgcrypt-based one (although I'd have to figure out how to create bindings for Vala), which would also enable me to add RSA-SHA1 signature support. Additionally, I should probably add an asynchronous equivalent to the current synchronous API. Finally, it would be nice if it integrated better with libsoup's existing authentication structure. Currently, I just generate an Authorization: header to be manually added.

The next component I'm working on is a WADL dispatcher library. I don't like the idea of a library generating code (as I presume wadl2java does). We'll see how this turns out.

For those of you who don't know what a postmortem is in this context, it's essentially a reflection of what happened in this release: what went right, what went wrong, and what we'll try to do next time.

Before I begin, a lot of the history is from memory, so the facts may not be 100% correct.

Background

Back around July 2008 or so, we essentially had two branches: stable/bugfix-only (0.2.7) and trunk (0.3.1). A few developers wanted to release from the bugfix branch for the sake of the distributions, but since work was well on its way in trunk, there were not many volunteers to lead the effort. I volunteered to do so, and began merging bugfixes to the stable branch, with the goal of releasing by around the end of August.

Unfortunately, there were three big roadblocks in my way: the infamous make distcheck, Bug 194018 (an intermittent problem with launching launchers on docks not built with GNOME libraries, and Bug 194431, "the trash bug".

For developers, I would guess that one of the most annoying things about releases is the dreaded make distcheck command. This command makes sure that if you run make dist to generate a tarball, that it compiles correctly out-of-the-box. It took what felt like dozens of iterations to make sure that certain files were in the tarball, ready to be installed by the build system. But the most annoying part of the process was the part dealing with internationalization (i18n). I18n is handled by the intltool/gettext packages in Awn, and they expect files to be "just so", or else make distcheck fails with a semi-comprehensible error. With some help from Qball, I managed to more-or-less get the trees into a releasable state.

The desktop-agnostic launcher bug was a pain to debug, as all it did was spit out a cryptic error message to the console instead of launch the application, and this only occurred with some launchers (varying between machines). Fortunately, moonbeam managed to write a fix for it in early August.

The trash bug was more complex in its own way. In GNOME 2.22, GNOME switched virtual file system (VFS) libraries from GNOME VFS to the more desktop agnostic GIO (part of GLib). Part of this conversion was that the trash directory changed from $HOME/.Trash to the more complex Freedesktop.org standard of $XDG_DATA_HOME/Trash. In comparison to the old trash directory, which was just an intermediary directory prior to "permanent" deletion, the new standard added a trash metadata directory (e.g. for the "restore this file" feature). Now, the trash applet did not have a maintainer. As I understand it, Neil ported it from the GNOME applets package as one of the proof-of-concept Awn applets. By this time, Neil was (and still currently is) very busy with his awesome (but unrelated) work at Canonical. Thinking that this was a desktop-agnostic issue, I decided to take the bug. My first attempt, merging in the new trash implementation from GNOME applets, failed badly. My next move was to rewrite the entire thing in Vala. My reasons for doing this were twofold: I wanted to work on my skills in C#-like languages, and I wanted the applet to be a bit more readable/maintainable for the next person who would take up maintainership. Unfortunately, it took way to long to write (through no fault of Vala's). The main problem was that the algorithm to determine the number of files in the trash (an important part of the original applet) is ridiculously complex in non-GIO libraries. This is due to the fact that multiple volumes can have trash cans. By the time I figured out about half of it, it was the end of August. Given the number of people subscribed to the bug and commenting on it, plus the comments I saw on the forum, this was a showstopper bug. I couldn't very well release without it in there, so the deadline came and went, and there was no update to Awn in the fall Linux distribution release.

I should note that there will be a happy ending to this bug - last month, I managed to get trash support into libdesktop-agnostic, and as soon as I convert Awn to use libdesktop-agnostic, I will commit the Garbage applet.

Releasing 0.3.2

Fast forward to last month (January). One of the core developers (mhr3) suggested that we do a snapshot release of trunk, since work on the rewrite was well underway. Somewhat surprising to me, more developers agreed to help with this release. This time, mhr3 was release manager (for obvious reasons). For the rest of the month and the first week of February, bugfixes were committed to the trunk branches of Awn and Awn Extras. There were also some features added (I admit that I added at least one of them), but the most notable one was the merging of the AWNLib 2.0 branch. I'll get back to that shortly. People were testing applets and noting their functionality on a wiki page, which helped with finding bugs.

By around February 6th, preparations were underway for the actual release. mhr3 and gilir were busy making sure that make distcheck worked for both Awn and Awn Extras, and I was working on the release notes. DBO, a developer for GNOME Do/Docky, suggested that we put some effort into doing a little marketing, like they did with their recent 0.8 release. So, I started a wiki page with a list of volunteers who would post to various news/forum websites.

The day of release was interesting. Throughout, various people (including myself) were in and out of the IRC channel doing stuff In Real Life. I managed to finish the release notes (and get screenshots) with the help of the folks in the channel, and gilir stayed up way past midnight local time to sign and upload both the source tarball and the PPA packages. As soon as mhr3 gave the go-ahead signal, the release announcements were sent to their respective news sites. I filed bugs in Gentoo for version bumps for both packages, to head off any overzealous Gentoo + Awn users. I also notified the Mandriva packager of the release, since I had his contact info handy. A few hours later, I remembered that I had an OSNews account (for commenting on some article which was probably tangentially related to Awn) and decided to submit an article. In the morning, I was informed via IRC (on a non-Awn channel, no less) of its publication, with a surprising addition: a mini-review by one of the site's editors, which was positive.

As of publication, my blog post announcing Awn/Awn Extras 0.3.2 has received almost 5,500 pageviews (see screenshot). To put numbers on the data points in the graph:

• Sunday: 312
• Monday: 2,783
• Tuesday: 953
• Wednesday: 1,008
• Thursday: 367

What Went Wrong

We should have reverted the AWNLib 2.0 branch merge. It caused more problems than it solved: it was inevitable that applets would break, and that at least one API change would be missed before release, especially given the amount of time between the merge and the release.

Coordinating the news/forum releases went OK, but we ended up having two Digg links, which probably spread out the total number of diggs, thereby lowering the chance that it would hit the Digg front page.

I was naïve enough to think that Debian/Ubuntu users wouldn't immediately file version bump bugs as some Gentoo users are prone to do. I was wrong.

Additionally, too many Ubuntu users did not read that we already provide binaries for Feisty through Jaunty (inclusive) - they seem to want to install from source, which we do not recommend (unless they plan on doing development).

What Went Right

The release coordination in the channel went fairly smoothly, especially given that we were all in different time zones.

Posting to OSNews was definitely a good thing. As you can see from the screenshot, it was the highest referrer to the post.

It was nice that someone not associated with the project posted to reddit - it was the second highest referrer. It was posted two days after the release, but beggars can't be choosers.

Next Steps

• First and foremost, prepare for a 0.3.2.1 release for Awn Extras.
• When we have a target date for 0.4.0, we should immediately branch, and said branch should only contain merges approved by the release manager.
• A 250-character summary of the new version (complete with reminders of what the packages are) should be written for news sites, in addition to the summary and the release notes.
• Make sure to highlight that Ubuntu users do not have to install from source.
• I need to get a Slashdot and a reddit account. I'm doing this under protest.
• We need to make sure that there's only one "official" Digg post.
• I should look into one of those omni-share-to-social-networks buttons, but only for the big announcements. Those "share" buttons make me feel a bit dirty.
• We need to get some contact information for at least the packagers for Fedora and OpenSUSE.
• If I remember and have time, I need to learn how to use the OpenSUSE Build Service.
• Explicitly mention in the release notes that there is no need to file version bump bugs in Debian/Ubuntu. Although, given past experience, I doubt that the people filing these bugs would read that. On the other hand, it's due diligence.

The Avant Window Navigator (Awn) and Awn Extras teams would like to announce the release of version 0.3.2. This represents a year's worth of bugfixes, performance improvements, and new applets. Note that the 0.2.8 release was cancelled, due to lack of developer interest. Our next major release, 0.4.0, will be a complete rewrite of the dock and applet API.

Avant Window Navigator is a dock for the Free Desktop which shows your launchers and open applications. It also contains support for extensions, via plugins for third-party applications, which communicate with the dock with DBus, and via applets, which allows for workspace switchers, system trays, clocks, etc., to be embedded in the dock. These applets can be written in C, Vala, or Python.

Awn currently requires compositing support in order to run. Window managers which support compositing include (but are not limited to) Metacity (part of GNOME), Xfwm4 (part of Xfce), KWin (part of KDE4.x), and Compiz. There are also standalone compositing managers, for window managers without support built-in: Cairo Compositing Manager and xcompmgr.

Awn Extras is a catch-all project which houses mainly third-party applets for use with Avant Window Navigator.

Avant Window Navigator Notable Changes

User-Visible

• We have made it easier to enable Awn to run when you log into your desktop - there is an "Automatically start Awn on login" option.
• If you start Awn without a compositing manager present, a pop-up dialog will appear informing you that compositing is not currently enabled.
• Most applet icons can now be customized by dragging and dropping an icon onto the applet in question. Note that this does not apply to tasks.
• Better compatibility with Metacity.

Packager-specific

• The (optional) Vala version dependency has been bumped to 0.5.4.
• The location of the applet metadata files has changed, at the request of Debian. We have included a script (awn-applets-migration) which will migrate users' settings to point to the new location.

Applet Developers

• You can now use cairo contexts/surfaces to paint text/images to AppletSimple-based applets.
• There is now a standardized applet context menu API.
• Advanced custom icon support via AwnIcons
.

Known Issues

These will probably be fixed in 0.4.0.

• Keyfile-based config is unstable. It works for the developer who wrote it well enough, but the GConf backend is currently the most stable configuration backend.
• Autohide is still buggy.
• Awn does not handle multiple screens very well.
• You cannot move the dock to any other edge of the screen. It is currently fixed to the bottom.

Awn Extras Notable Changes

New Applets

• Animal Farm: Various animals tell your fortune.
• Cairo Clock: a replacement for pyclock (due to license issues). It provides three themes, and (if python-dateutil and libgweather are installed) allows you to add additional clocks for different locations.
• Comics!: A flexible comic strip viewer.
• CPU Frequency Monitor: controls and monitors the CPU frequency (useful for laptops)
• Desktop Manager: manages the desktop wallpaper for GNOME and Xfce.
• Media Player: plays anything you drop on the applet.
• ThinkHDAPS: monitors the accelerometer for IBM/Lenovo ThinkPad hard drives.
• PyNot: a configurable notification area AKA system tray.
• Remember The Milk: A simple interface to the web service.
• To-do: A todo list.
• Tomboy: A simple interface to the Tomboy application.

Changes to Applets

• Battery Applet: rewritten, now requires HAL.
• Cairo Menu: various fixes
• Digital Clock: various fixes
• Media Control: various fixes
• Notification area: looks fancier now
• Quit Applet: rewritten; supports the GNOME 2.24 quit behavioral changes
• Shiny Switcher: various fixes
• Terminal: various fixes
• Volume Control: rewritten

Removed Applets

• cairo-menu-classic (use Cairo Menu)
• PyClock (license issues, use Cairo Clock)
• tsclient (license issues)
• Workspace Switcher (use Shiny Switcher)

Packager-specific

• Animal Farm: new runtime dependency on the fortune binary.
• Battery Applet: new runtime dependency on HAL via DBus.
• Cairo Clock: optional runtime dependencies on libgweather (for the Locations.xml(.gz) file) and the python dateutil module.
• CPU Frequency Monitor: optional runtime dependency on gnome-applets, for the cpufreq-selector binary.
• PyNot: runtime dependency on python-xlib.

Applet Developers

• AWNLib has been overhauled. It is now PEP8-compliant.

Known Issues

• Cairo Menu: Intermittent issue of submenus overlapping parents may still be present.
• Cairo Menu and Places applets: Certain fonts/locales are broken.
• Media Player: errors are not currently displayed.
• Shiny Switcher: Switching window managers tends to result in inconsistent behavior.

Download

Semi-official Ubuntu packages for various Ubuntu versions will be available at the Awn Core PPA. We are working with various distributions (Mandriva, Gentoo, Debian, Ubuntu) to update their packages. You can download the source code at Launchpad (Awn Extras) - instructions on how to install from source are at our wiki (Awn Extras).

About the Images

1. My dock, on an Ubuntu Hardy machine. I have running Cairo Menu, Show Desktop, Taskmanager/Launcher, Awn System Monitor, Animal Farm (with unfortunately a non-free image - this has been rectified for the release), and Digital Clock. The image is licensed under the Creative Commons 3.0-BY-SA (Unported).
2. mhr3's dock screenshot contains the Shiny Switcher, Weather, Taskmanager/Launcher, Battery, Media Player, and Notification Area applets. The image is licensed under the WTFPL.
3. h4writer's dock has Taskmanager/Launcher, Shiny Switcher, and Quit applets. The image is licensed under the WTFPL.
4. onox's dock screenshot contains the CPU Frequency Monitor, ThinkHDAPS, Taskmanager/Launcher, Cairo Clock, Volume Control, Battery, Weather, and Notification Area applets. The image is licensed under the Creative Commons 3.0-BY-SA (Unported).
5. mrooney's animal dock. This showcases the new, public domain images for Animal Farm, retrieved from the excellent Open Clip Art Library. Also in the dock are the Weather and Terminal applets. The image is licensed under the WTFPL.
6. triggerhapp's dock is running on Ubuntu Jaunty. He is running the Cairo Menu, Taskmanager/Launcher, Separator, Volume Control, To-Do, Quit, and PyNot applets. Note the transparency in PyNot - this was achieved because support was finally added to GTK+ in version 2.15.0, available in Jaunty. To use it yourself, you need to run the RGBA version of PyNot and Jaunty (or equivalent distro version). The image is licensed under the WTFPL.
7. h4writer's second screenshot contains the Cairo Menu, Separator, Taskmanager/Launcher, Separator, Media Player, Media Icon (Play), Media Icon (Previous), Media Icon (Next), Separator, and Cairo Clock applets. The image is licensed under the WTFPL.
8. moonbeam's dock screenshot contains the Cairo Menu, Places, Taskmanager/Launcher, Shiny Switcher, Awn System Monitor, Comics, To-Do, CPU Frequency Monitor, Volume Control, Weather, and Calendar applets. The image is licensed under the Creative Commons 3.0-BY-SA (Unported).

More Information

• Awn on Launchpad
• Awn Extras on Launchpad
• Awn Wiki
• Planet Awn

Yes, there is an Awn rewrite in progress. Here are the important parts (to me, anyway):

• I hear that autohide works better than before (thanks to mhr3).
• If I have my way, the desktop-agnostic parts of Awn will work much better, via libdesktop-agnostic (not integrated yet). Yes, code does exist!
• Taskmanager is now a separate applet. Launchers are still bundled with it.
• Drag/drop of tasks/launchers is in the works (thanks to h4writer). I still have my doubts about the usability aspect of it, though.
• For the most part, applets don't work, other than the taskmanager applet. Moonbeam informs me that the following applets work:
  • Cairo Menu (not classic)
  • Shiny Switcher (currently has issues with side orientations)
  • Awn System Monitor
  • Awn Notification Daemon (which, I must point out, is not a notification area or system tray)
• You can put the dock at different orientations.

I am not going to list the wishlist items, because nothing is certain to make it into the rewrite unless someone actually codes it in.

The priority at the moment is to get the taskmanager in working shape. That's not really my line of expertise, so my priority is to get libdesktop-agnostic ready to replace my second attempt at a non-GNOME-specific dock. Of course, all of this is contingent upon the amount of time the developers have available. It seems at this point in time, we are either consumed with (paid) workloads, schoolwork/exams, or both. (I currently fall in the first category.) So, as I say over and over, there's no timeline for when this will all be done. It will probably be ready for release when Neil says it is.

Given that this is pretty much a complete rewrite, we (the developers) are not yet comfortable building binary packages for it. If you want to test it, you're going to have to build it from source. Please pay attention to the entire build process (the "development" track) if you have not done this before. The branch information is on Launchpad.

Update: mhr3 has kindly supplied a screenshot (licensed under the WTFPL). This showcases the right-oriented dock, plus the action that happens when an applet crashes. No more white lines!

There seems to be something inherently wrong with how PEAR is packaged in Debian/Ubuntu (hence referred to as Debian, since Ubuntu doesn't modify the php5 source package with regards to PEAR). A bit of background: I'm currently trying to update the PHPUnit package to the current version (the Debian version seems to be stuck at 3.2.x — 3.3.9 was released the day this was written). I'm (re-)running dh-make-php to accomplish this, mostly because there doesn't appear to be a very obvious way of upgrading PEAR packaging for Debian (given package.xml, etc.). The problem is that PEAR is bundled with PHP on Debian, courtesy of the php-pear package. The one on Ubuntu's Hardy Heron is stuck at 1.6.1, whereas the current version (again, as of the day this was written) is 1.7.2. I can't use dh-make-pear to package the latest PHPUnit because the package.xml file requires PEAR 1.7.1 to parse it.

Now, Ubuntu's community documentation for PEAR recommends upgrading PEAR via the pear command. That seems counterproductive to me. Given that pear, by default, installs to the same location as the package, I presume that PEAR and any other "pre-installed" package that was pear-upgraded would be reverted, in particular if there's a security release. This makes the sysadmin's job harder, obviously. I can't seem to find any rationale for this packaging behavior (admittedly, I didn't look very hard). But other distros get it right - Gentoo definitely packages the non-bundled PEAR versions, and from a cursory search, it appears that Fedora does as well.

So, what's my solution (for now)? Backport the latest stable PEAR into the php5 source package.

According to Blogger, this is going to be post #100. I have no idea if that counts the various dead drafts in my queue or not.

Anyway, if you've been following my Twitter stream, you'll know that I've been playing with Pylons, and by extension, WSGI. One of the things that I'm interested in is OpenID-only authentication, mostly because I hate having to create new account names/passwords everywhere, and I'm too lazy/paranoid to use one of those password management extensions. After several attempts, here is a short Python script which runs a sample web app that requires OpenID authentication for the /private path (via the AuthKit middleware). The OpenID URL that was used to sign in is stored in the environ['REMOTE_USER'] variable. It was tested with AuthKit 0.4.2, Beaker 1.0.3, and Paste 1.7.2.

#!/usr/bin/env python
#
# Copyright (C) 2008  Mark Lee
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# For a copy of the GNU General Public License, see
# <http://www.gnu.org/licenses/>.

import os
from beaker.middleware import SessionMiddleware
from paste.auth.auth_tkt import AuthTKTMiddleware
from authkit.authenticate import middleware, sample_app
from paste.httpserver import serve

app = middleware(sample_app,
                 enable=True,
                 setup_method='openid',
                 openid_store_type='file',
                 openid_store_config=os.getcwd(),
                 openid_path_signedin='/private')

app = AuthTKTMiddleware(SessionMiddleware(app),
                        'some auth ticket secret');
serve(app) # opens a socket at localhost:8080

Zach Hale notes:

Should I choose RSS or Atom?

Who cares? I don’t. I bet if I asked everyone I had contact info for, only a few would prefer one or the other (though hopefully one in particular).

I've got a preference — Atom. This is mostly because of the fact that's it's one de jure standard, as opposed to the at least five de facto RSS standards.

More to the point, I agree with the underlying argument:

And that being so, it makes no sense to put both standards (if not different versions of each) in the auto-discovery tags, especially for big sites like Flickr and consumer blogging software like WordPress. [...] For the rest of us, our feed readers could care less. So please stop confusing us.

Sadly, I also know the history behind this. Back in the "bad old days", feed readers did not follow the robustness principle. So, websites had to deploy a sort of "inverse robustness principle", to make sure that as many feed consumers as possible could read the content. The good news is that today, any decent feed reader can read most feed formats. The bad news is that no one (or not enough people) have bugged the feed producers (e.g., Flickr) into fixing it. The solution? File a bug and remind them of Postel's law. Of course, only file said bug if no one else has already done so — we don't need to annoy the developers.

Source code management, or version/revision control, is one of the most useful tools that a developer has, especially if this person works with others on a shared code base. However, I've recently realized that some people don't understand what a good "commit"^[1] entails. (I'm not naming them, or whether they come from my professional or hobby "spheres of influence".) It doesn't matter whether you're using Subversion, Bazaar, or even CVS. There are a few principles that you should consider when you make a "public" commit (as opposed to a "local" commit, which is supported by distributed version control systems):

• Limit your commit to one discrete idea. This can be fixing a bug or adding a new feature. Obviously, there is an exception when you happen to fix a bug by creating a new feature, but these instances tend to be rare. The big reason for this principle is that developers are (generally speaking) not infallible. If it turns out that the commit introduced bugs and/or regressions, it is easier to revert an entire revision (through whatever means your SCM provides), than to comb through the differences between the revisions in question for the "tainted" code.
• Good commit messages are key. Due to the way that most source code repository viewers work, it is considered good practice to summarize the commit in the first line, and then give a more detailed explanation in subsequent lines. This is actually similar to how writing is taught (at least in the US): provide a topic sentence in which you summarize what you're going to write about, and then write your content. In this case, though, you don't need a summary/closing statement at the end.
• If your project management and/or your SCM software supports it, annotate your commit as much as possible. I'll give two examples as to what I mean:
  1. Bazaar lets you annotate your commit with a couple of metadata flags when you invoke bzr commit: --fixes=[BUG] and --author=[AUTHOR]. The flag --fixes lets you annotate which bug this revision is supposed to fix, and --author lets you specify the author of the code, e.g., if you are just committing a patch for someone else who doesn't have the proper permissions to do it themselves.
  2. There is a post-commit hook for Subversion, distributed with the Trac project management system, that allows tickets to be changed based on the existence of certain key phrases in a commit message. For example, the message Add foo. Addresses #12345 adds a comment to ticket 12345 with that commit message and a link to the revision, whereas the message Add bar (fixes #12345). performs the same task as the "addresses" phrase, plus it sets the ticket status to "closed". In my opinion, putting the "fixes" or "addresses" phrases at the end of the first line is preferable to putting them in the detailed explanation.

Hopefully, this is helpful to those who are new to using version control systems, and those people who are the "gatekeepers" of the repositories. Comments and criticisms are welcome.

¹: The difference between a "commit" and a "revision", in my view, is that a revision is a patch that has been committed to a repository, whereas a commit is the process.

This is in response to something that I read on an Ubuntu Brainstorm page.

Attention people who think that you need an expensive video card in order to run Avant Window Navigator, AKA Awn: I have a computer that I maintain with a Diamond Monster Fusion video card (tdfx Xorg driver) that runs Metacity + Awn 0.3.1 (on Ubuntu Hardy) just fine, with applets, on an everyday basis.

This has been a public service announcement by your somewhat friendly Awn/Awn Extras developer. You may now continue to go about your Interneting.

For the 1% of Open Source software enthusiasts who haven't yet seen this yet: Donate to support the development of free/libre/open source graphics software by helping developers meet in real time, in person, (etc.) at the Libre Graphics Meeting 2008! I'm a big fan of Inkscape, because it lets me, as someone who is not very artistic (nor has very good (precise) hand-eye coordination) to create and manipulate logos and icons with ease. My graphics programming skills are essentially non-existent, so I figured that I could be more useful by donating some cash to help a developer of one of the participating projects travel to the meeting.

And here's the shiny (but not flash-shiny) information-rich button that they're using to show how much more money they need to reach their goal: (I should note for the American-income-tax-minded that this is a tax-deductable donation.)

On a somewhat related note, I'm planning on going to LinuxFest Northwest 2008. Fortunately for me, both the conference and the transportation is free. People who have either followed me for at least a year or have read through the archives know that I went last year. I plan on going on Saturday again (this year, April 26), and I'm bringing my XO laptop with me. If things work out right (i.e., my stupid printer decides to work), I'll have a nice, big Awn icon (again, thank you Inkscape!) taped to my bag. It'll be an interesting experiment to see who recognizes it.

Obviously, I haven't done one of these in a while. There are a few reasons for this. For one, my workload has gotten a bit larger. Additionally, Super Smash Bros. Brawl came out recently...it's ridiculous how much time that game eats up, and I'm only halfway through "adventure mode".

But seriously...both the forums and the bug tracker have been relatively quiet. It's difficult to figure out exactly why that is. However, there have been a few things that have happened in the past month or so.

Moonbeam has a summary of what happened in the week following my last post. Additionally, he has been working on the framework for an applet that can use either the Gecko engine (used, most notably, in Firefox) or the WebKit engine (used in Safari) to render HTML. Hopefully, this will alleviate some of the problems that people have had trying to get some of the HTML-based applets to run properly. Unfortunately for us, moonbeam has become rather busy in real life lately, and so there may or may not be very much progress on the features/applets that he's been working on.

Andrewsomething, a longtime bug/answer triager for both Awn and Awn Extras, has finally taken the plunge (so to speak) and joined the Awn Extras developer team. His first contribution is the "Remember the Milk" applet, and for his next undertaking, he is seeing if there's any interest in a simple note applet.

It is interesting to note that two new, experimental branches have appeared for Awn recently. One, created by moonbeam, focuses on refactoring the launcher/task/applet effects framework so that it's easier to add new effects, and uses cairo's surfaces instead of Gtk+'s "pixel buffers" to manipulate the images. This allows for more complex effects to be used, while keeping the overall effect smooth (and potentially hardware-accelerated).

The other branch was created by longtime Awn contributor haytjes. He's working on fixing the "custom icon" feature. Currently, there are several bugs which prevent that feature from being very usable.

And finally, I'd like to give a quick Planet Awn roundup. Moonbeam has a very good post on the architecture of Awn and why it's not possible (currently) to have features such as parabolic zoom. Our fearless leader, Neil, has (finally) written a post about the recent Awn/Awn Extras release, and our upcoming plans for the projects. Hopefully, his presence on Planet Gnome will continue to give Awn more publicity :).

I'm taking a break from both trying to make a <tbody/> scroll vertically without a horizontal scrollbar present and playing "Link's Crossbow Training" to write up what's transpired in the past several days in Awn-land.

The Awn Curves branch was partially merged into awn-core-testing. I say "partially merged" because meek is merging it in parts, due to the complexity.

The big event was when Neil finished reviewing the awn-core-testing and awn-extras-testing branches and merged them into their respective trunks. Among the benefits is that users of reacocard's Ubuntu Gutsy repository can now use the shiny new features that those of us on the (very) bleeding edge have been using for a while now.

I should also point out that Neil has added both moonbeam and myself to awn-core, in recognition of our work on both the testing branches and our respective personal branches. This means we have commit access to Awn's trunk branch and more bug/blueprint triaging privileges.

As a result of the big merge, we now have a new roadmap. What used to be Neil's big rewrite for 0.3 (code-named fandabbydosy) has been spread out over several releases. See the roadmap link for details. One important item to mention is that we plan to release version 0.2.4 of both Awn and Awn Extras on Monday (02/18).

In Awn Extras, most of the changes have been bugfixes. A patch was added to the media-control applet for Quod Libet support.

Finally, I'm holding a contest for Awn users/enthusiasts. In the near future, I'd like to have a post with screenshots and videos showing off all of the new features and applets in Awn/Awn Extras. Unfortunately, I suck at doing that sort of thing myself. :) So, I'm giving the Awn community the chance to show off their customized docks.

The only restriction on the screenshots and videos is that you license them under a Creative Commons license. I will, of course, attribute all media to their proper creators :) Ideally, the screenshots should be as hi-res as possible, but any resolution is welcome. The same goes for videos.

The deadline is Feb. 21, because I'd like to write the post by the end of next week. I'll choose a set of media that looks the nicest (with the help of the people in #awn) and use that as the basis of my next Awn post.

So if you wish to participate, please post the URL to the media, the attribution information you wish to use (your name or nick), and which feature/applet you're highlighting on the forum thread or as a comment here.

(@flickr. Created at O'Reilly Maker [Via Ajaxian]. Under a CC-BY-SA license.)

Note to self: the OpenWrt wiki, particularly the dnsmasq page, is a very useful resource for understanding why my XMPP server won't talk to the GMail or LiveJournal XMPP servers. (Hint: filterwin2k is a very bad configuration option for XMPP servers. Stupid default option.)

I switched my DNS host from zoneedit.com to editdns.net, because ZoneEdit doesn't support DNS SRV records. They're needed for XMPP server-to-server federation support. My XMPP address is <${my_second_level_domain} at ${my_second_level_domain} dot com>. Note that this is different from my email address.

Political Donations of Seattle Notables

I has a diploma, or at least some sort of rolled-up paper with some signatures on it. They're the same, right?

(Part I of a multipart series)

Printers which cannot distinguish between one and three sheets of paper going through the spooling thing at once (I am not an expert on printer jargon), thereby printing 5% of the page on one page, 5% on the second, and 90% on the third. Which also screws up the double-sided print job you were trying to do in order to save paper.

There are currently a bunch (~20) of urchins in the Suzzallo reading room who walked in to take a look at the desk of former Senator Warren G. Magnuson. Why they did it, I have absolutely no idea. These were definitely elementary school-aged ones, and even during my tenure in the public school system, I didn't learn very much about the famous senators Magnuson and Jackson in Washington State History class.

I passed Brian AND Carl in number of tracks played on Last.fm. Go me!

...don't look at me like that, I have a right to be shallow every once in a while.

This one (particularly the last panel) describes me in general.

This other one also describes me (at times). It also describes sus7. I swear. I've seen it happen.

I am continuously amazed at people's (in this case, college students about to graduate, or those that already have done so) general incapability to follow simple directions.

Hot Job Market:

It seems that everybody I’ve talked to in the last little while has found a way to work it into the conversation: “Oh, and I’m hiring; know any good developers?” Plus, the pace of calls from head-hunters has picked up. It’s about as hot as I can remember it being, ever, including the bubble.

...yeah, I must be looking in the wrong place. Or maybe it's my lack of experience. It doesn't help that I don't:

1. Have any experience with .NET in particular — in glancing at the listings on craigslist, I see very little, if any, about Java, the one they teach here...not that I actually want to work with that.
2. Am unwilling to leave the Seattle area (don't get me wrong — I'm looking anywhere between Tacoma, Everett, and the Eastside, so long as I can get there by bus)

...bleh. This is just me ranting. One of these days, I need to publicly publish my resume.

Gah, election coverage consumed most of my night, just like it did two years ago. DAMN YOU, TELEVISION! At least it's less aggravating this year.

Yahoo! is in talks to buy Facebook, the social networking site for college- and schoolkids, the WSJ reports today.

The WSJ article (via ProQuest) noted that Facebook had held separate discussions with Microsoft and Viacom previously. Personally, if Facebook were to have sold out to Microsoft, I would have deleted all of my information as soon as it was announced. I think it's just as bad to let a company like News Corp. to have a hold of that much personal information. I'm not sure what to think of what will happen if Yahoo! ends up buying it. Yes, it's also one of those giant companies, but they seem to have made Flickr and del.icio.us (some of their other relatively recent acquisitions) better services.

Discuss.

It's a good thing I read the news (and look at the Electoral Vote feed), otherwise I would have completely forgot about my silly absentee ballot. I wonder what prompted them to add the "Signature Security Flap"...

In other news, Yarr.

It's too damned early for jackhammers outside my window.

Season 3 of House, MD begins in an hour. Hurrah!

It’s that time of year again! Every August, Seattle is treated to 4 days of being under attack by jet fighters in the form of the Blue Angels performing at Sea Fair. Aptly described by a friend as “sky NASCAR”, these giant wastes of taxpayers dollars whiz around the city at like 300 feet all weekend, scaring the bejeeezus out of everybody.

Tip: You know it's too damn loud when you can't hear the music you're playing when they're flying over.

Why don't they just stick to their area over I-90the Medina/Bellevue/Redmond area?

Yarn + Rolling Computer Chairs = NO

ELO + Gene Kelly = awesome.

Vietnamese sandwiches for lunch has got to be the best lunch food ever.

Note: some of this stuff is technical and should have gone here, but it also deals with LJ and I don't really feel like making yet another post.

• New discovery: Drafts in LJ → set to "Private" access


• Justice League Unlimited is ending. Sad.


• I read about some interesting ways to grab data from LJ. My mind already has its gears turning on how to create an über-PIM/social network aggregator thing... unfortunately, it ideally requires one to input some other-website passwords in order to get the extra-cool stuff. Privacy issues ensue. Maybe I'll make it just for myself.

A little background - I wrote this after receiving three emails from three different people in my mailbox (within the course of about three hours) that contained exactly the same content. I happened to forget that it was in my "Drafts" folder until now. Edited only to look better.

To Whom it May Concern:

I've just about had it with the way iSchool staff use the mailing lists that those that are in the school are "strongly encouraged" to subscribe to. It appears that a significant number of those who post to the lists are not aware of the social norms that should be followed when performing such a task. An example of one such occurrence was Feb. 11, when three different professors forwarded the same email to two mailing lists ^[1]. Utilizing Google, the iSchool's obsession, a set of useful links to mailing list etiquette pages can be found, but the first of which is sufficient ^[2]. In reference to the example occurrence, this particular paragraph is relevant:

Should I "crosspost" to multiple lists?

Almost always, the answer to this is no. Most mailing lists are topically disjoint, and there is very little that is equally appropriate for posting to a number of them. It can also be annoying, as usually subscribers will get a copy of your message for each list they're on that you post to -- more than two or three of those and you can have a lot of annoyed people knocking on your mailbox.

That said, there may be some occasional instances where it would be appropriate to post to a number of lists at once. If you think this is the case, then you should probably contact the owner of each list and make sure that they agree before proceeding.

Hopefully, this will enlighten some people as to how to "work smarter, not harder" with regards to mailing lists.

Thanks,

--

This is meant mostly for myself, as a reminder.

• MUSIC 331: History of Jazz
• HIST 310: Science and Religion in Historical Perspective (if offered)
• HIST 311: Science in Civilization: Antiquity to 1600
• HIST 313: Science in Civilization: Physics and Astrophysics Since 1850 (if offered)
• HIST 390: Colloquium in History and Science (if offered)
• HSTEU 402: The Reformation (if offered)