Mid-twenties

Congratulations! Welcome to your mid-twenties!

You now believe that your greatness is only limited by your own flawed being. For the next decade, your estimate of self-worth will oscillate between fraud and failure.

These feelings will continue until you realize that they are one of the common events of being a human being with the majority of its needs cared for. This acceptance will come slowly and be a relief from an omnipresent stress you stopped noticing you felt.

This acceptance will be difficult for you to distinguish from simply settling for less and leaving your talents to fallow.

Good luck!

The First Commitment

In the past few months, I’ve allowed myself to slip. I haven’t been making many public commits, nor discussing much where others can see. It has me feeling like a bodybuilder who hasn’t touched a set of weights in the same amount of time. My work and my writing has atrophied. My ability to maintain code that other people depend upon has suffered, and my ego has, as well. Time to sharpen up.

The first part of this new commitment is that I’ll be making a minimum of 3 commits a week to rFeedParser, no matter how small. This one is a stepping stone to taking on more of a workout, and It gives me time to reacquaint myself with the code base. rFP has weird and hairy parts in it because the problem it was solving was weird and hairy. However, there are a good number of ugly parts that were created because a) I wrote it with the Python version in the next window over causing me to write with a strong Pythonic accent; and b) I wasn’t as skilled in Ruby as I am now.

The module hierarchy alone proves I was diving in and not giving a fuck. At a certain point, I was just trying to get it to goddamn work and not caring what kind of hack-and-slash maneuvers I had to pull off to make it happen. With the distance from the problem and the clearer head I have now, I can piece together how it should be done.

The second part is a commitment to one commit a week to one of my public side projects. Right now, this consists mainly of the strictly-for-fun-and-I’m-keeping-it-that-way-fuckers framework I’m writing called Recess. Everyone writes a web framework, and I’m going to be That Guy, too.

I’ll try not to be too snooty about it, but if the framework turns out well (or, at all, really), I probably will be. Like I’ve said before, my ego knows no bounds. But, remember! It’s just for fun. Really. Really.

As my plans and projects grow and adapt and interests wax and wane, there will, of course, be a call to change this commitment. This two-part commitment is only the first of what will be a series of changing, and, likely, growing vows to myself. Look to see a lot more work from me.

rFeedParser on GitHub

Alright, it’s done. I’ve moved rFeedParser and rchardet to GitHub. Check out the rFeedParser and rchardet pages at GitHub and clone them with these URLs:

git://github.com/jmhodges/rfeedparser.git
git://github.com/jmhodges/rchardet.git

rFeedParser, of course, is a Ruby translation of the Universal Feed Parser in Python and passes 98.8% of its 3000+ unit tests. rchardet is a Ruby translation of chardet in Python and is used quite a bit in rFeedParser.

There are, of course, some things left to be done in both of these projects.

Off the top of my head, rFeedParser needs:

  • to be able to use libxml if the user prefers, instead of the Expat binding
  • to use version 0.4.1 of the character-encodings gem
  • someone to ask People Who Know if the way rfp strips out the bad stuff in the *\_crazy.xml tests is acceptable
  • to set up a git submodule for the tests in order to ease the merging in of tests from the feedparser repository
  • a fix up to some of the regexes and lame matching code in it, especially the time parsing code
  • resorting the incredibly ugly object hierarchy.
  • other things I’ve forgotten and am too lazy too look up

rchardet needs:

  • some information on whether using some gem-provided Tuple object instead of the giant Arrays would help the memory usage
  • fix the other encoding bugs that Mark fixed when he released the version of rchardet that cleared up the little endian UTF-16 bug I reported

There’s still a lot of work to do, and I’m listening to your concerns and taking your patches. Hit the mailing list and we can all make this better.

Special Note for People Who Want to Help: Run rake setup in your branch to install all the gems you need to run it.

Moving From Bzr to Git (or “Tailor is So Awesome I Cream My Pants”)

rFeedParser obviously has not gotten enough love from me. I intend to correct that.

The first order of business was to stop hosting its branches in bzr on this server. No one knew the repositories existed, they were sucking up tons of hard drive space, and, dammit, I’ve been digging git ever since Garry turned me onto it. Oh, and getting rFeedParser into a svn repository on rubyforge required bzr svn which required me patching svn on my Mac Book Pro. Too much damn work.

But I also don’t want to lose all of those commit logs. I’d feel guilty pretending that rFeedParser just magically appeared in its current state without showing off how many times it looked even worse. I decided that I needed just the main branch turned into the master branch of a new git repository and that I’d host it up on GitHub.

Enter tailor. tailor is an amazing bit of Python that can translate from most any version control system to most any other control system. Trying to describe all of the other crazy source control backflips it can do would take up too much space here, but, I assure, its worth checking out. Go do your googlings.

tailor made it drop dead simple to move rfeedparser over, but I had some significant help making that happen. Bryan Murdock’s post on this exact same topic was a great boon, but not perfect. In the time since he posted, either the config file for tailor changed, or some kind of bizarro bit rot occurred.

In any case, I munged up the config file, looked up some more docs and, now, I present you with a simple way of moving your current bzr branch into a brand spanking new git repository. (How lucky you are!)

First things first, you’ll need bzr, git and tailor. The first two I had installed via MacPorts (verions 1.3.1 and 1.5.5.1, respectively) while the latter was a bit of a pain. You can install it via MacPorts, but by default it tries to run in the Python 2.4 environment when bzr is installed over in the 2.5 one. Bleh.

What I had to do, was grab the tailor code myself (version 0.9.30), unpack it (say, to ~/src) and run it with python2.5 explicitly. For those of you on Macs, substitute python2.5 ~/src/tailor-0.9.30/tailor for tailor when I write it in the commands below. The rest of you can be blissfully unaware that there is any problem at all because your package management system probably doesn’t suck as much as MacPorts.

First things first. Find your bzr branch while I, for the sake of this post, it’s at /path/to/bzrbranch. Next, decide where you want the git branch to exist which, again for the sake of this post, I’ll pretend is /path/to/gitrepo.

Now, anywhere at all, write a file (which we’ll call bzr2git.conf) containing:

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = bzr:source
target = git:target
start-revision = INITIAL
root-directory = /path/to/gitrepo
state-file = tailor.state

[bzr:source]
repository = /path/to/bzrbranch


[git:target]
git-command=/opt/local/bin/git

Notice the git-command line at the end. That’s only for lame-o MacPort users because tailor doesn’t seem to understand $PATH or something, freaks out about not being able to find the git command and leaves us questioning our ability to manage our own systems. Leave it out, or change the path to right one if you’re one another system.

Finally, run

tailor -D -c bzr2git.conf

and you’ll have a happy new git repository at /path/to/bzrbranch with your history intact. Oh! And it’ll have the .bzr directory in it but you can feel free to clear it out. The old bzr branch will still have all that info in place.

And you’re done. I’ll be following up with information on what’s up with rFeedParser in the next post.

Update: Now see this: rFeedParser on GitHub.

Ruby and Rails Compete for Love

A thought: In the beginning, I wrote in Ruby because I liked using Ruby on Rails. But recently, I’m using Ruby on Rails because I like writing in Ruby.

I think it’s time to start looking at the options again.

Rob Pike Knows How To Scratch His Itches

Found in lex.c of squint, the Unix implementation of Newsqueak (referenced from Rob Pike’s bio):

if(fd<0 && s[0]!='/' && s[0]!='.'){
    sprint(buf, "/usr/rob/src/squint/include/%s", s);
    fd=open(buf, 0);
}

That’s an hilariously awesome way to personalize your tools.

While I’m on the topic, trying to google up a copy of squint (or any implementation of Newsqueak) is a serious pain in the ass. And I’ll be the 50 kajillionth programming nerd to link to Rob’s excellent talk on Concurrency and Message Passing Newsqueak. You might have to watch it a few times to catch all of it, but it’s worth it.

For those of you wanting to play along on Mac OS X, be sure to add the code that Jeff Sickel talks about on the plan9 mailing list.

Oh, and for your information, I’m trying to figure out why squint will ignore the last line in a source file. If you append a blank line to the end of the file, everything runs fine. Very weird.

Building CouchDb on Mac OS X

I, like Sam, *really* want to play with CouchDb. But I’m a MacOSX box that I barely understand after 3 months of ownership.

Install MacPorts and run:

sudo port install erlang icu subversion

Add these two lines to your .bash_profile (or .profile if you’re running tcsh).

export ERLANG_BIN_DIR=/opt/local/bin/
export ERLANG_INCLUDE_DIR=/opt/local/lib/erlang/usr/include/

Run those two commands in your current shell or open a new one. Now, back to the install.

cd ~/projects
svn co http://couchdb.googlecode.com/svn/trunk couchdb
./build.sh | tee couchdb_svn_build.log
./build.sh --install=$HOME/sys | tee couchdb_svn_install.log
mv couchdb_svn_*.log ~/sys/log

Now, for convenience, we set up an easy way to start the CouchDb server. This assumes that $HOME/sys/bin is in your $PATH. Make a file called couchdb in $HOME/sys/bin containing:

#!/bin/bash/
cd $HOME/sys/couchdb && ./bin/startCouchDb.sh

Next, fix its permissions:

chmod +x $HOME/sys/bin/couchdb

Then, start the server:

couchdb

(I follow this up with a ln $HOME/sys/bin/couchdb $HOME/sys/bin/db but that might not be best for you.) Finally, follow the rest of Sam’s post to get a quick introduction to CouchDb.

Bonus Round: Ruby on top of CouchDb.

There are two Ruby gems for work on top of CouchDb, couchobject and CouchDb-Ruby but couchobject seems the most promising. Why? Well, for one, its respository doesn’t include tests with syntax errors. And, two, it lets you write CouchDb views in Ruby, which is fantastic.

I haven’t gotten a chance to find its limitations, yet, but considering the deep magic involved and the 0.5.0 version number, I’m sure it has a few.

To get it, hit the site for the link to the tarball or grab the repository with:

git clone git://repo.or.cz/couchobject.git

I’m terribly excited. Enjoy!

Update: Now leaving Typo City.

erl_interface is Deprecated and I Hate the Erlang Docs

I’ve been learning Erlang in fits and starts for a few months now, and trying to play with the C interface to it. Unfortunately, it wasn’t until tonight that I learned that the best documented interface, erl_interface, is deprecated in favor of ei. (That link is not all of the ei documentation. See the end of this post).

Oh, but you’ll still have to include erl_interface.h in order to get your code to run since ei requires it. Be careful to put -lerl_interface before -lei.

And all of the docs about interoperability with C have you including both ei.h and erl_interface.h and make no mention of the relationship between them or the deprecation of erl_interface. Hell, they barely mention ei, anyhow.

This is the kind of thing that makes languages on the verge of true popularity spin down until they find themselves in the graveyard of “interesting but irrevelant”. There will be no fiery crash, no awe-inspiring fight to the death, no raging against the dying of the light. Nothing more than the slow frost bite of a crumbling community.

I love what Erlang can do, but if you’re going to make a language that proudly shows it roots in a Prolog interpreter, you’ve got to give the plebeians like me a chance.

Oh, and could we get a decent math library while we’re at it? I shouldn’t have to break out to C just to work with matrices. Combined with a quickly made mnesia database you could have some serious distributed work going.

You would probably have to move to a more lightweight data structure than what mnesia gives, but what a great way to write a proof of concept! Of course, you’ll first have to find documentation for mnesia that isn’t ages old.

Since the mnesia and ei documentation (along with everything else) is pretty much unGooglable in all of those frames, I suggest using the documentation tarball (lastest release). In the the current release, hit ./otp_doc_html_R11B-5/lib/erl_interface-3.5.5.3/doc/html/application_ei_frame.html for ei and ./otp_doc_html_R11B-5/lib/mnesia-4.3.5/doc/index.html for mnesia.

Blech. The things you do for love.

I’ll be writing up my experiences and some posts to help others with ei as I go along. Let’s hope I can be as productive as I am critical.

My First Earthquake

I just went through my first earthquake, a breezy 4.5 (initial estimate), and it wasn’t so bad. I’ve never really heard a description of a “light” earthquake and certainly did not expect what happened. Hell, it took me until after the worst of it to realize what it might have been and even then I wasn’t sure.

At first, I had thought somebody had just dropped something outside onto a truck with a wooden flatbed, but the sound just kept going. It took me until after the sound had stopped and the “shaking” was still going to really put it together. It was really quite a nice little ride, more like a well-damped oscillator than a real shake.

OpenURI, Exceptions and HTTP Status Codes

If you’ve needed the numeric HTTP status code from a connection created with either open-uri’s or rest-open-uri’s open method, you’ve probably noticed that OpenURI::HTTPError is raised on any thing other than a 2xx or 1xx status code and that the docs don’t really lay out how to get to the status code in that error. Some of you may have hacked up a the_error.to_s[0..2] solution, but that is bad and terrible. Don’t do it. Here’s the right way. (Good luck remembering it after a few weeks away, however.)

require 'open-uri' # or 'rest-open-uri'
begin
  io_thing = open(some_http_uri)

  # The text of the status code is in [1]
  the_status = io_thing.status[0]

rescue OpenURI::HTTPError => the_error
  # some clean up work goes here and then..

  the_status = the_error.io.status[0] # => 3xx, 4xx, or 5xx

  # the_error.message is the numeric code and text in a string
  puts "Whoops got a bad status code #{the_error.message}"
end
do_something_with_status(the_status)

There you go. You’ll notice that neither open-uri nor rest-open-uri use the Net:HTTP response classes like it claims you should in these cases, but you can map to them with the numeric status codes. All you need are the CODE_CLASS_TO_OBJ and CODE_TO_OBJ hashes defined in Net::HTTPResponse. The latter hash is probably preferable.

Update: Edited for stupidity.