If you feel like breaking ruby:

1
2
3
4
5

class << nil
  def nil?
    false
  end
end

I was recently telling lispy about some Haskell I was trying to write. I decided I'd try porting one of my Python scripts to Haskell. The script is used in emacs when composing e-mail replies and needs to do things like format citation text. One function I wrote computes the largest common prefix of a list of strings. He ended up reducing it about threefold from my original Haskell; here was the result:

1
2
3
4
5
6

commonPrefix :: String -> String -> String
commonPrefix a b = map fst $ takeWhile (uncurry (==)) (zip a b)

commonPrefixLines :: [String] -> String
commonPrefixLines [] = ""
commonPrefixLines lines = foldl1 commonPrefix lines

I think that's pretty elegant. Thanks, lispy.

Seriously? The winter weather is especially persistent in the northwest this year. This is only the second day in the last month that it has been sunny AND warm (where warm is defined as "above 60 degrees") AND dry. It's a great day for biking, and it's the sort of day that brings the whole city out to walk, skate, run, bike, and play on the river waterfront in downtown Portland.

Last night I had the great pleasure of seeing Jonathan Coulton in concert, along with the extremely talented and hilarious Paul and Storm. Thanks go to keturn for getting me tickets and even saving two seats for D and me (the show was sold out). Coulton played Still Alive and a bunch of other great songs. It was a great opportunity to be able to see him perform.

In other news, I finally got a Twitter account. Anyone that knows me probably knows that I wait until a new web service is no longer new before I start using it, if I use it at all. (When will I learn? People always take my preferred username...)

Last Wednesday I took my first Violin lesson with Wendy Goodwin. It went really well and I'm excited to start sounding like total crap! I love Violin music and look forward to learning to play some. I think my music-reading skills will come back pretty quickly. Getting my left hand to adjust to the fingerboard will be another matter entirely.

Oh, and I have asparagus!

Finally...

We sold our car.

We've been thinking about doing it for about a year. D has been using TriMet almost exclusively since she started attending graduate school, but I drove to work at my previous job and for the first year of my current one. Last April, after learning too much I decided I was going to start taking the bus as often as I could. Since then, we've driven our car only two or three times per month, and with that transition complete, it was only a short jump to getting rid of the car altogether.

Now, we'll save on insurance, maintenance, gas, etc. And using TriMet and other services when we need them will be vastly cheaper, to say nothing of the other benefits.

When we need a car we can always use ZipCar or even rent one, but one of the great things about Portland is that if you live relatively close in, you just don't need a car. The key is realizing that.

Not having a car is really liberating. Woohoo!

In migrating my web services to a new server, I went ahead and upgraded the OpenID library that parsed.org and my other services use. Now they support OpenID 2 (in addition to OpenID 1), so if your identifier is served by a compliant provider, you can just enter your provider's URL into the input box to make login seamless. For example, myopenid.com identifier users can simply enter myopenid.com into the input box. For other features provided by OpenID 2, (maybe) read the spec.

I run a computing tips website, parsed.org. I originally created it so xinu and I could store IT tips in a central place. The tips cover everything from SQL tricks to command line tips to code samples in various languages.

The site has been online since Fall of 2004, and xinu and I created most of the initial content. I changed jobs and implemented OpenID support on parsed.org and added it to the myopenid.com directory. Since then, it has seen a few account creations per day. But new content wasn't rolling in: the site wasn't keeping people around.

So I decided to ask the users; many of the users that signed in chose to supply an e-mail address, so I kindly asked them what I could do to make parsed.org more compelling as a computing tip site.

So far I've gotten some really good suggestions and ideas from the people who responded:

• Better RSS feed coverage for individual tags and individual users' posts
• Automatic code highlighting and formatting
• Bookmarking (think gmail's starring feature)
• An "About" page to clarify the purpose of the site (it's true...)
• Tag cloud on the main page
• Better search interface (it currently doesn't search tags)
• Commenting support
• A "tip of the week" feature
• Tip voting
• The ability to get e-mail when interesting tips are posted (e.g., with certain tags)
• (P)avatar support
• Extensions (Firefox, Eclipse)

As time allows, I'm going to boil these down and start working on a few of them. A lot of these will go a long way to making parsed.org better.

Woohoo! Brendon came over and helped me cook up a batch of beer tonight. I've been meaning to get into this hobby for perhaps a year. I recently went and picked up a homebrew kit from Let's Brew, a local homebrew supply shop. Photos of the event can be found here.

For some time now I've been thinking about how far goods travel from producer to consumer. I've been thinking about how some what I consume travels vast distances for my convenience. With the ever-rising price of oil and, by extension, oil derivatives like heating oil, plastics, jet fuel, etc., it's important to reduce my consumption impact in terms of petrochemical cost.

It all boils down to this question: what is the energy component to something that you consume?

This reasoning isn't transient; the cost of oil isn't going to decrease overall so this isn't something that should go out of style, so to speak. Much of our consumption infrastructure in the U.S. (and, indeed, the first world) is built on oil and that is an enormous liability. The only way to change that, as I see it, is to be a responsible capitalist (insofar as that is possible): decrease or eliminate the consumption of products that travel unnecessarily great distances.

The grocery store chain that I almost exclusively patronize, New Seasons Market, is a local grocery store chain here in Portland. They (along with some other stores) post the source of most products and make the information available upon request if it isn't posted. For example, I know where my oranges, apples, lettuce, and other produce are grown. The practical result of knowing that information is that I can make a choice when I buy an apple: I can get the one that came from California, or Washington State. Why not support the (relatively) local industries that I can?

But the same goes for any other product (or service) I consume: coffee from South America or Africa, beer or whisky from Europe, corn products from the U.S., shipping from UPS or FedEx, flights from Southwest Airlines. The consumption (purchase and use) has indirect effects -- indirect costs -- not only to me, but to the people and places involved in (or excluded from) the production process.

Implicit in this form of "boycotting" is the notion that if enough people stop consuming those Californian apples, fewer shipments of them will travel to Oregon. This may sound like the destruction of an industry, but if it isn't sustainable, it's eventually going to self-destruct anyway.

It's not always easy to choose local over remote. All too often I make consumption decisions based on what I enjoy eating, drinking, or doing, and sometimes this kind of change looks like a sacrifice. But the real question, I've found, is whether those things are important, and whether I have a sense of entitlement to consume something just because I have the money to purchase it: am I willing to take responsibility for the production process? Will I support and condone it?

Bound up in this discussion is a wide range of other questions and issues: consume less instead of differently, think about population and carrying capacity, think about land use and attitudes, redefine economic success and expectations. But I think I can save those for another day.

So, my next step in changing my consumption habits will be to consume beer made only in the Pacific Northwest (of which there is a great deal, most of it delicious) or beer I make myself. (Watch for an upcoming post on homebrewing, my newest soon-to-be hobby!)

With some help from xinu, I've seen the error of my ways and now the RSS on this blog is a lot more useful. It now includes the content of my posts, including IMG tags for all of that pretty . I also moved it from /rss/ to /rss.xml, so if you've subscribed, you'll have to re-subscribe. (This is to get readers to reset, since they store old entries in the feed, and they'll all be empty now.) Enjoy!

Given , prove that

• Using arithmetic arguments.
• Using combinatorial arguments.

The arithmetic proof is straightforward. Given the equality

then we have this expansion:

Multiplying by gives

which is the definition of . Can you outline a combinatorial argument? What I want to understand is what the RHS "partitions" of the LHS symbolize.

When it comes to math, the brain is no different from an ordinary muscle: without relatively constant strength training, it will eventually atrophy.

Ever since I finished my college degree, it has been increasingly clear that my math skills are lacking. I think back to what I was able to do in school, and I realize that I haven't kept up on math practice -- or even gone back to investigate things that weren't clear at the time -- and I can feel it. A full-time job and other obligations basically preclude the kind of focus that most degree-holders have realized.

Now that studying isn't obligatory, I'm actually more interested. Indeed, even things that weren't very clear in school now interest me, and I want to go back and re-learn things I never quite got. Two topics in math that interest me are Graph Theory and Combinatorics. My program didn't offer a Combinatorics course, and I lacked the Linera Algebra prerequisite for Graph Theory.

So, after a few failed attempts at re-starting a study habit, I'm at it again. This time, I've got some time blocked out each week and a few places picked out that meet my requirements (accessible by bike or bus, relatively quiet, food, etc.).

As I work problems from two books I have on these topics, I'd like to pick some of the interesting ones and post them here, complete with solutions if I can provide them, or provide a little discussion. If you're having trouble starting a study habit, I hope you'll find this interesting, too.

Today I finished a python module that wraps the jyte.com service API. I intend to keep this current with the Jyte.com API capabilities. Enjoy!

http://darcs.cprogrammer.org/public/blog/blog/main/jyte.py

Today, some co-workers and I did a little bit of code review, and it got me thinking about code review software; Mondrian probably comes to mind for anyone in this sphere. We do some code review at work, but not nearly enough.

In Guido van Rossum's Tech Talk on Mondrian, he called code review the "alternative to pair programming," which I think is a fair characterization. Pair programming isn't necessarily for everyone, and code review (either in a group or in isolation) is, as Guido points out, a non-threatening way to give feedback and criticism with the overall goal of finding ways to improve software, uphold standards of quality, etc. [1]

I already wrote a tool to track the status of Darcs patches. Its purpose is to scan the contents of locally-available Darcs repositories and store metadata about those patches in an independent database, which you manipulate through a GTK UI. I originally wrote it to track the porting status of patches, since at the time I was doing a lot of work porting our Python OpenID implementation to PHP.

Starting with the ideas from patchtracker, I started thinking about the requirements for a code review system that we could use at work. Here are the requirements I can think of:

• As one co-worker put it, make it hard to avoid code review. So, make it easy to know what hasn't been reviewed. One might even go so far as to prevent patches from being committed to a central repository until they've passed review, but how draconian you choose to be will depend on how much you trust your co-workers. I'd say our track record is pretty good.
• Make it reasonably easy to integrate the code review software with your code repositories. [2]
• Make it possible for reviewers to add comments on a per-patch (or even per-hunk) basis, in addition to general comments about a patch set.
• Make it possible for reviewers to indicate which of their patches amend the patches reviewed.
• Make it possible for more than one developer to review a patch set.

I think a web app would be pretty well-suited to this kind of functionality. Without heavy employment of an RPC interface, that means the web app has to run on the same machine where the repositories live, but I don't think that's a concern if your repositories are readable.

I'm going to let this simmer for a day or two, and then I might start hacking. If you have more ideas, please comment.

If you've never been to Utopia Cafe, you must go!

I often take screenshots, and send links to friends. Sometimes I want to capture something funny before it goes away. Sometimes I want to show something running in my development environment. Either way, I use a perl script, XWD, scp, and ImageMagick to take and store the screenshots on my web server. However, getting the perl script to run reliably on a new machine is always painful and error-prone. It doesn't help that Perl sucks.

In an effort to develop another small proof-of-concept service for fido, I built an image uploading service to make it easy to get screenshot images to (and from) my server in a platform-agnostic manner and facilitate the storage of extra metadata with the images.

The service's API lets a python client upload an image with a description and tracks other metadata like a thumbnail, image dimensions, content type, and time uploaded.

I'm interested in writing a wx or pygtk client to make the service usable with Windows.

To use the service, a python client need only supply a little code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from fido.client import Client
import socket

c = Client(host, port)
u = c.get('UploadService')

f = open("some_image.jpg", "rb")
image_data = f.read()
f.close()

image_id = u.upload(image_data, socket.gethostname(),
                    "descriptive text")

And, alternatively, this code to get image data:

1
2

images = u.getImages(source_host)
single_image = u.getImage(image_id)

Current line tally for the fido framework codebase:

Lines of library code: 1462
Lines of test code:    1521

There are few pleasures I enjoy more than hacking late into the night.

For a few weeks now, I've been pouring a lot of spare time into my fido RPC framework, which wraps the Pyro RPC library to make it easier to use. My goal with fido is to create a comprehensive RPC programming toolkit. I'm a big fan of Pyro, but over the past few years I've found that it's tedious to get a world-class Pyro application running quickly. Pyro provides a great infrastructure, but I want more:

• A convenient programming and system-level interface for creating and managing daemons
• A consistent and practical RPC object implementation that supports some key introspection operations
• A robust idiom for connecting to RPC endpoints, querying their contents, and getting object proxies
• A load-balancing, self-adjusting naming service that only hands out proxies that refer to real objects

When it comes to actually using RPC, it should be easy to do these things quickly:

• Define the interface for an RPC-capable object in an obvious, language-native way
• Create a daemon that hosts such an object
• Create a client program to begin calling methods on the object
• Register the object in a naming service to resolve its location

Furthermore, my ideal RPC framework would be:

• easy to configure, both programmatically and using config files
• well-tested and use standard components
• robust and make it easy for me to tell when failures occur
• native to the language I prefer (Python) and not ask me to write any middleware

So far, I think I'm on the right track. The fido naming service is completely independent of the core framework, which is how I think all services should be implemented. The unit tests are coming along nicely, and the daemon interface is easy to script. While configuration can be done programmatically, config files are encouraged since they are more explicit and persistent and make it easy to get information about a daemon using an external tool.

Fido is available in darcs if you want to take a peek or patch it. It contains no README, but the code is documented to the point of silliness. In the coming months, I'll make an official first release.

One of the best email sigs I've seen:

A: No.
Q: Should I include quotations after my reply?

After posting a patch to an OpenID plugin for Trac, it looks like I'll be taking over maintainership as soon as I get Subversion access! Sadly, the original author wants to use CardSpace. I look forward to improving the plugin. It currently employs Simple Registration and operates in stateless mode.

After a recent comment posted by rorek, I felt inspired to implement support for rendering blog posts to PDF by way of . Now, you can click the View PDF link available next to each post title to get a PDF.

• Fortunately, python's docutils supplies a ReST-to- translator, which I use to convert my ReST blog posts into .
• Blocks of highlighted source code are just translated into verbatim blocks surrounded by (decorative?) boxes.
• Inline and block math elements are preserved and rendered as-is.

If you have trouble viewing the PDFs or notice any glitches, please let me know!

After two days' worth of hacking on the blog code, three new improvements obtain:

• elements are now pre-rendered when posts are created or edited instead of being created when posts are viewed.
• The entire post body is also pre-rendered and served when posts are viewed, rather than rendering on demand.
• Comments are now supported, provided you log in with OpenID.

Not all is perfect, however. Some problems remain.

• Comments are plain text, and are rendered as such. You won't get to use any fancy filters available in the blog post processing logic. This is mostly because I'm not sure I want to make comment authors write ReST or . (It also has non-trivial implementation ramifications.)

• Comments aren't previewable. If you've ever posted a comment on a blog, you're probably too familiar with the uneasy feeling you get from not knowing how the blog's brain-dead internals are going to treat your input. I plan to implement comment previewing as soon as I come up with (or hear ideas about) a sane way to make that happen in the commenting UI.

• elements are not properly aligned with surrounding text. For any given generated image, the text baseline in the image may be any number of pixels above the bottom of the image. In the non-zero case, the image needs to be shifted vertically so its text baseline lines up with that of the surrounding text.

  The utility I use to generate PNG images from input, dvipng, claims to support an option to report the "depth" of an element. According to the man page section for the --depth option:

  Report the depth of the image. This only works reliably when the LaTeX style preview.sty from preview-latex is used. It reports the number of pixels from the bottom of the image to the baseline of the image. This can be used for vertical positioning of the image in, e.g., web documents, where one would use CSS [...]

  That sounds like exactly what I need. In practice, the reported depth values seem to be much too large, resulting in odd-to-just-plain-wrong placement of generated images. I've found a scheme that seems to work well for most elements, but it's a hack.

This proof to a math problem I posted was posted on rorek.org:

First note that trivially by their definitions.

Let be of minimal eccentricity, and be of maximal eccentricity. Consider the path from to continuing to . Then we have

Thanks!

I've added a new feature: syntax highlighting with enscript. Examples:

1
2
3
4
5
6
7
8

import os.path

class MyClass(object):
    def __init__(self, n):
        self.n = n

    def __str__(self):
        return "FOO"

1
2
3
4
5

import java.net.*;
import java.lang.*;

public class CoolClient extends CoreInterface implements Runnable {
}

1
2
3
4
5

<HTML>
  <HEAD>
    <TITLE>My site</TITLE>
  </HEAD>
</HTML>

UPDATE: The blog now uses pygments, as it is infinitely more flexible; thanks, pygments authors!

Tonight was a good night at the alley:

Current bowling average: 119
Tonight's session average: 151 (games: 140, 150, 164)

Here's something I've been working on. I'd like to see a concise proof if you can provide one:

Let be a connected graph with vertex set . Let be the length of the shortest path in .

For each , the eccentricity of is defined as

The radius of is defined as

The diameter of is defined as

Prove that for any connected graph ,

Every blog has to have a first post. This is mine. This is a blog package that I've been working on. It uses Django, docutils, , Python, OpenID, and PostgreSQL. Needless to say, it's a little rough around the edges. Some planned features might be:

• Comments (maybe, leaning toward no.)
• Extra filters for placement of elements.
• A filter to support syntax highlighting of Python code.
• Make it easier to package up for others to use.
• Pre-render elements rather than doing them on the fly, every time.
• Re-engineer filter implementation so order doesn't matter.

Blog posts are written in reStructured Text. The primary distinguishing feature of this package is its support for rendering. I've seen many wiki packages with support for it, but I haven't come across any blog software that lets you render it. Both inline () and block elements are supported. In addition, floating elements can be placed on the right margin. The idea of embedding in blog posts was somewhat inspired by Mathbin, but it's not a new idea.

If you're interested in the source, let me know.