Chad Perrin: SOB

30 June 2007

how microframeworks happen: three reasons I’m building one

Filed under: Geek,Liberty — apotheon @ 05:10

I’ve bitten off a big old chunk of side project, again. This time, I’m working on Copyfree, something of a cross between the Free Software Foundation’s What is Copyleft? essay and Free Software Definition, the OSI’s Open Source Definition and list of “approved” open source licenses, and the Creative Commons Frequently Asked Questions page. There’s a bit of similarity to the OpenBSD Copyright Policy page thrown in there for good measure, too.

I threw together a quick placeholder page with some information about what Copyfree is all about, and let the people who were aware of the idea at its earliest stages of conception (before I even knew for sure there’d be a website or that I’d be using the term for anything) know that it was there. I did so with a single-page index file so that I wouldn’t be locked into a particular choice of back-end technology by incoming links, should someone discover it and start linking to it. If, for instance, I had started out using static XHTML pages with the .html filename extension with multiple pages on the site, and people started linking to the various pages, I would then — when I settled on a back-end technology, say for instance SSI+Perl/CGI with .shtml filename extensions — have the problem of either maintaining a redundant set of legacy static pages (or redirects) or breaking incoming links. The answer was simple: don’t create anything at first other than an index page, and only refer to it by the site root URL, because all that’s needed to access the one and only page is the domain name (copyfree.org).

I had a fire lit under me last night when Sterling linked to Copyfree (see the “people who use it” link) at Chip’s Quips. The content on the placeholder page at least doubled in volume, I set up a Subversion repository, I thought about the options for back-end technology in earnest, and started experimenting with writing the back end for the site. The latter two comma separated values in that sentence manifested as follows:

I started fiddling around with options. Right off the bat, I rejected the notion of a content management system — I have very specific needs for Copyfree that in no way fit into the approach of any CMS I’ve ever seen, to say nothing of the fact that I wanted the option for a more unique, customizable appearance to the site. I very briefly considered constructing the site with PHP, but really, I’m trying to stop mistreating myself like that. I briefly considered eRuby for PHP-like markup-embedded Ruby, and even more briefly considered Rails (as briefly as “Rails? Nah, that’d be overkill for this!”). I then “settled” on Perl/CGI, with SSI to embed script output in pages with URLs using the .shtml filename extension (and without “cgi-bin” in them). I decided that, doing this, the only smart way to do it was to use CGI.pm (aka the Perl::CGI module) to generate valid markup. Alas, I haven’t used CGI.pm in quite a while, and needed to refresh my knowledge of it. After puttering around, grousing inwardly about the ugly, bolted-on Frankenstein’s monster OOP syntax in Perl 5, I started to rethink that assessment of the use of CGI.pm as “smart”. (Granted, Perl’s OOP features blow PHP’s out of the water, but it’s not difficult to outdo that POOHP*.) I had already constructed an exact duplicate of the index page of the site using CGI.pm to generate markup, at this point, and was about to embed it in a sane URL using a simple SSI statement, and was pretty much over my initial enthusiasm for refamiliarizing myself with the module. At this point, there was only one other option open to me:

I could create my own microframework (and no, I don’t mean the .NET Micro Framework) as I go. Sure, it’s sorta “reinventing the wheel”, because there are tons of frameworks out there already — but most of them are kinda huge, and would require as much familiarity with their inner workings as CGI.pm even if I wanted to use them. Worse yet, most of them aren’t readily available in a form that fits into a shared hosting account’s restrictions, and of those that are, one is CGI.pm and another is basically just a collection of core PHP functions with a few unified function-collections. There’s that PHP microframework I already created a while ago (and keep changing every time I use it), but again, I don’t want to punish myself like that this time around.

End result: I came back to eRuby. That’s what I’m working on now, though I may end up discarding that for SSI+Ruby/CGI (but without the woefully out-of-date Ruby CGI module) by the time the Ruby-based microframework is complete enough to actually migrate the live site to it. Either way, I’m building formatting functions and planning the data model. I’m building a microframework in Ruby.

So, to sum it all up, this microframework is happening for the following reasons:

  1. PHP is hurty (for anything more complex than duplicating SSI functionality).
  2. Ruby is fun (and provides excellent OOP capabilities).
  3. I’m too damned lazy to refamiliarize myself with CGI.pm this week.

It’s even possible that this microframework will one day have a tidy enough codebase to bother offering it as a publicly available alternative to PHP for (extremely) simple website development — all under a Copyfree license, of course.

Frankly, I’ll pretty much consider it subject to the terms of a Copyfree license anyway, except that I’m unlikely to share it as a whole with the world unless and until it’s no longer an embarrassment to display. License terms only really come into play when someone can actually see the licensed work, after all.

Just for the heck of it, I’ll share a single method that I’ve already written (it’ll probably need tweaking for edge-cases, but it works for now):

def fixfullstops(passage)
  passage.gsub(/  /, '  ')
end

There are about half a dozen others, and there have been about half a dozen that I’ve written and thrown away, in the course of a couple hours’ worth of playing around. I wrote that particular method right after I decided to stop screwing about, and start taking a more systematic approach to planning the development effort, but before I actually started employing a more systematic approach. Whee, fun.

(note: you may find some of the acronyms/abbreviations on this page instructive)

(edit: * POOHP is a term first publicly coined in a guest blog post by Sterling of Chip’s Quips, and first privately coined by him before that in IMs.)

5 Comments

  1. Excellent! What will you be calling this microframework?

    Comment by Sterling Camden — 30 June 2007 @ 10:36

  2. Shortly after posting this, I decided to name the file in which I’m collecting utility methods “werkframe.rb”. Assuming it becomes worth officially naming and publicly releasing, I think I may stick with Werkframe as the framework’s name.

    I’m thinking, actually, of making sort of a simplified meta-framework of it — a toolset for creating custom microframeworks, if you will. Maybe. That’s pretty ambitious, though, and at the moment all I really need is a bunch of methods and a class or two for a single website.

    Comment by apotheon — 30 June 2007 @ 01:55

  3. […] Chad Perrin is building a microframework in Ruby for his new Copyfree site: I very briefly considered constructing the site with PHP, but really, I’m trying to stop mistreating myself like that. […]

    Pingback by Chipping the web - Memphis -- Chip’s Quips — 30 June 2007 @ 03:44

  4. Was Why’s Camping (http://code.whytheluckystiff.net/camping) considered? I understand it to be a very small framework, but I’ve not used it myself.

    Comment by Sammy Larbi — 4 July 2007 @ 11:36

  5. Was Why’s Camping (http://code.whytheluckystiff.net/camping) considered?

    Actually . . . no, not really. I knew it existed, but I didn’t bother considering it because I didn’t think I’d have the option to install my own gems with the webhosting account I’m using. Now that I look more closely, I see that there is in fact capability to install gems with the account. Maybe I’ll kinda start over with Camping after all.

    Still . . . it might be nice to have something that doesn’t require use of gems or (alternatively) a degree in computer science for installation. We’ll see which side of the laziness coin wins out in this case, I guess, as I look into Camping a little more closely.

    Thanks for the suggestion.

    Comment by apotheon — 5 July 2007 @ 01:28

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License