Sporkmonger

I just released version 1.0.0 of my Addressable library. The most useful change is the addition of a new heuristic parsing method, similar to how most browsers handle URIs entered through their address bars. Passing “example.com” to the heuristic_parse method will end up returning a URI that is equivalent to “http://example.com”. The URI can then be further normalized as necessary.

In addition, there are several minor changes that might cause compatibility issues (although probably not). The path component of a URI is now guaranteed to never equal nil. The code in the parse method for handling the feed pseudo-protocol has been removed and placed within the heuristic_parse method where it belonged in the first place. The to_h method has been renamed to to_hash so that coercion will work. There were also a couple of small bug fixes, mostly related to routing.

All of that stuff is great of course, but the main reason I’m slapping the “One Point Oh” sticker on this thing and calling it “done” is that now, in addition to having 100% code coverage, Addressable can now manage to go through the heckling process with no surviving code mutations. That’s a pretty high bar to get over, so I think it’s fair to call this thing finished.

Get me rewrite! Again.

I’m not certain exactly how many times I’ve rewritten the base stuff for GentleCMS now, I’m pretty sure it’s been at least 5 times now, and every time it gets better and cleaner and simpler and better specified. I just finished up writing the code for managing resource properties (arbitrary file metadata). This time around, I (re)wrote the whole thing as a fancy subclass of Hash. Complete with 100.0% C0 code coverage and a fairly respectable 1.37:1 spec:code ratio. I’ll probably begin writing the specs for the ResourceNode class (the most important class in GentleCMS) in the next couple days.

I’ve been making a few evolutionary improvements to the URI class lately. (Which, by the way, is now at 100.0% C0 code coverage and 1.63:1 spec:code ratio. Ultimately the goal is to have 100.0% C0 code coverage for every single piece of GentleCMS and at least a 1.0:1 spec:code ratio for every file.) The improvements were mostly related to escaping. I misread parts of the RFC related to escaping certain characters and I had to go back and improve the specs for that. I’m pretty sure there’s still some edge cases that need to be better specified in my RSpec code. Whenever there’s some section of the RFC that supplies an example, I’ve been adding it verbatim to the RSpec code with a comment to allow easy cross-referencing between the executable specification and the RFC. I almost wish RSpec had some functionality similar to RDoc that would merge the comments with the generated HTML specification somehow. The generated stuff tends to be fairly bland (though still somewhat useful), but it would be really cool if it could be fleshed out a bit.

Anyways, since the properties code was what I just finished up, I thought I’d explain a bit about how the feature works exactly. Properties in GentleCMS are loosly modeled on Subversion’s metadata system, which is really quite simple. Metadata in both systems is basically represented as a set of key-value string pairs, which is why it makes a lot of sense to code it up as a Hash subclass. Namespacing is dealt with by simply prefixing the key’s name with the namespace string followed by a colon. So for example, Subversion uses “svn:mime-type” to store the mime-type of a file, while GentleCMS uses “cms:mime-type”. There’s really nothing special about the way namespacing is done, it’s actually not much more than a style convention.

However, GentleCMS’s metadata system is significantly different in one respect from Subversion’s. GentleCMS allows properties to be auto-generated. GentleCMS has a special class called ResourceAdaptor. Subclasses of ResourceAdaptor are able to selectively alter the behavior and state of ResourceNodes depending on the ResourceNode’s state. For example, if you wanted to auto-detect the encoding of an XML file in order to eliminate many of the problems that crop up as a result of RFC 3023, you could write a ResourceAdaptor subclass that only accepts XML file ResourceNodes. The subclass would add a generated property to the ResourceNode, “cms:encoding” whose value was obtained by inspecting the ResourceNode’s content and determining the XML file’s encoding. GentleCMS knows what to do with the “cms:encoding” property and will automatically supply the correct HTTP headers when a representation of the resource is requested.

I’ve been up to no good again. I keep changing my directory structure around. Nothing feels quite right, but each time I change it, it seems a bit better than the last time. In any case, my svn repository for this project is now something of a mess. :-(

Anyways, I decided my URI implementation still had a weak spot that needed to be taken care of.

I figure I’ll fill out the missing chart on Sam’s list with the results of Ruby’s two URI implementations:

testuri.1.rb produces:

http://example.com/          http://example.com           true
HTTP://example.com/          http://example.com/          false
http://example.com/          http://example.com:/         true
http://example.com/          http://example.com:80/       true
http://example.com/          http://Example.com/          true
http://example.com/~smith/   http://example.com/%7Esmith/ false
http://example.com/~smith/   http://example.com/%7esmith/ false
http://example.com/%7Esmith/ http://example.com/%7esmith/ false
http://example.com/%C3%87    http://example.com/C%CC%A7   false

testuri.2.rb produces:

http://example.com/          http://example.com           true
HTTP://example.com/          http://example.com/          true
http://example.com/          http://example.com:/         true
http://example.com/          http://example.com:80/       true
http://example.com/          http://Example.com/          true
http://example.com/~smith/   http://example.com/%7Esmith/ true
http://example.com/~smith/   http://example.com/%7esmith/ true
http://example.com/%7Esmith/ http://example.com/%7esmith/ true
http://example.com/%C3%87    http://example.com/C%CC%A7   true

The extract method is basically done. I’m sure it could be improved a bit more, but it seems to be fairly effective. I added a few extra features beyond the original URI class’s capabilities, such as supplying a base uri to resolve relative uris against. You can also have it return the parsed URIs instead of the strings. At no extra processing cost since it has to parse each URI internally anyways. Tried it out on Sam Ruby’s feed (as you may have noticed, currently my favorite chunk of text to try just about everything out on) and it seems to have gone ok:

Read the rest of this entry…

FeedTools 0.2.25: Now with 625 lines of monkey patching, and all the same terrible performance you’ve come to expect!

I decided to extract all of my REXML monkey patches out into a single file instead of leaving them all in feed_tools.rb for this release. Tests should all pass on Ruby 1.8.4 now. And Sam Ruby’s feed should be handled correctly again. His use of ”.” as his link uri caused one of the parser’s heuristics to throw a hissy fit and misreport the feed’s uri as nil and the value of the feed’s link as the feed’s uri. Weird stuff. Anyways, that works again. (NetNewsWire was breaking on Sam’s feed last I checked.) HTTP redirection handling has been changed in that FeedTools won’t barf if a relative Location: header is supplied. And the parser should generally work a little bit better with FeedUpdater.

I’ll probably make another release when I get around to integrating my new URI code. After that, that will likely be the last release for quite some time. Virtually all of my free coding time will be being spent on GentleCMS instead. Just a heads-up.