(In the future I'm planning on moving to a dated versioning scheme.)

I'm going to start by asking everyone interested in the project send me an email. It can be as long or short as you want and you're welcome to write anything you like. I would appreciate at least non-empty title and body. I'd prefer a short introduction and maybe at least a little information about why you're interested in the project. Eventually, even this minor requirement will be dropped and the script, addins, and documentation will be available on the site to download.

The purpose of this isn't to track your use of the software. The idea is to encourage you to contact me with any questions or problems you may have after you download and install the project. (Consider it an icebreaker. The second email is always easier to write than the first). Furthermore, I'd like to see a supportive community spring from the project, and a short introduction is the first step toward realizing that goal.

Of course I will never sell, spam, or otherwise use your email address in any systematic or profit-making way. I may reply to your email directly, but will do nothing else without your express permission.

Send an email to rob at this domain to be contacted as soon as Ode is made available with a link to download the source and related documentation, themes, etc.

Until now, all posts were simple text files (including html, and markdown formatted text, and just about anything else you can insert using text). All of these text files are with themes to generate the site dynamically in response to visitor requests.

Now these text files are just one the possibilities for a post under Ode. I've added an interface which will allow addin developers to define content type handlers so that Ode can be made to work with more sort of files.

So for example an addin developer could easily assume responsibiliy for .jpg content and then maybe scale a full size image and wrap it in a block of meta data pulled from the image file itself, with the resulting content added to the page along with all of the other posts.

The idea is still the same. Let's define a website as what is essentially a bridge between the browser and the file system by defining styles and behaviors that describe how we want our content displayed on the site. All we need to do to make our content available to visitors is to copy the files where we want them and we're done. There is no need to special tools and techniques for working with

Because all content are discrete files, an Ode site is simple to manage. How's that? Well, how do you manage all of your other files? You can do the same things to manage your website. You can add, edit, and delete content simply by working with your files as you normally do. Edit posts directly using your favorite applications (or using whatever apps are available when you're away from your computer).

And of course I haven't compromised the "simple means you know how it works" philosophy that makes Ode, well Ode (and unlike anything other weblog platform).

I hope to have Ode released real soon. Until then feel free to send me an email or join the discussion group if you're interested. I'm happy to discuss the project with anyone who might want to know more about it.

If you'd prefer to handle this issue in some other way just leave the option disabled (the default).

(Luckily there aren't many of you and I'm purposefully not doing anything to promote ode until I have something released.)

I have been steadily working on Ode, primarily on the documentation. In fact, I've spent as much time on the documentation as I have ode itself. Why? I'll start by with why not.

It's not because Ode is complicated. I feel compelled to say again that anyone wanting a complex application should adjust their expectations or look elsewhere. While ode is intended to be genuinely useful as a legitimately practical online web publishing platform, it is not intended to be some kind of a riddle. For experienced programmers, the challenge will not be figuring out how ode works by wrangling with 'clever' (read obfuscated) code. If you are looking for an opportunity to test your programming mettle, you should look elsewhere. On the other hand, You will be able to understand how Ode works, every nook and cranny, and you will be able to do wonderfully interesting things with Ode in a matter of minutes. You can then spend the rest of your time doing still more fun things with Ode, or you could do other things.

So why then am I spending so much time on documentation. The answer to this question is two-fold.

1. Ode is intended to be accessible to anyone with a genuine interest in learning how to program. To this end I have been careful to use syntax and constructs that a student is likely to learn in an intro programming course, or read about in an intro to programming book. Moreover I have purposefully tried to avoid being terse and overly idiomatic. Ode is written in Perl, and while it is true that Perl can look like a very unique (and uniquely difficult) sort of language, there is no reason why we can't, in most cases, write Perl in such a way that it is recognizable to people coming from other languages, and to do so in a way that is not inefficient. This is true in part because of the interpreter which is very good at recognizing and optimizing code to run efficiently, regardless of how it is written in many cases. I chose Perl because it is widely available, mature, and stable, and not for any other reason. I'm not particularly concerned about writing clever Perl code.

   Anyway, if we are going to serve the needs of people very new to programming, in addition to writing obvious code, we need to describe what is is doing in some detail. After all, programming languages are exceedingly concise by design, in comparison to natural language prose for example. Given this fact, it has always been somewhat surprising to me how little time and effort most programmers put into documenting their code. More surprising is how little documentation is emphasized in college CS programs, but that's a topic for another post.

2. The second reason is best described by a presentation I put together related to topic of documentation for a software architecture course I took recently (Spring 2008). Essentially, the presentation expresses that I feel strongly that documentation is a critically important part of software development. Feel free to take a look at the presentation if you're interested.

Other than documentation I've continued to tweak the code (much more than I anticipated I would) while working toward releasing the project.

Finally, I've added some new features and functionality. I'll write separate posts describing this work and I'll try to do a better job of posting about this sort of change going forward.

Beyond the source code itself I'm working on several themes to accompany the software, some of which are necessary to accomplish some of the things I want Ode to be able to do, e.g. syndication, in-browser editing of posts, presentations. All of these things require unique themes. Beyond these 'utility' themes, I want to include several weblog style themes with Ode.

Also, I'm putting together 'stub' addins in hopes of avoiding any confusion about how addin interfaces work.

So, none of this satisfactorily makes up for the fact Ode is not yet available to download and use but 1) I promise that will happen, and 2) I promise it will happen soon.

My personal weblog is now running on Ode. Maybe that is at least something in the way of proof that I'm aggressively working toward the goal of releasing Ode publicly.

In the interim I'll do a better job of keeping up with the Fresh Today posts, because I still like the idea.

If you have any questions for me, don't hesitate to ask. If you're wondering if Ode might be appropriate for something you have in mind, I may be able to answer your question(s) directly.

Thanks for your patience,

Rob

The presentation includes 29 slides that attempt to address the first questions you might have, i.e. the what and why of Ode (from basics to design goals).

New addin interfaces

I'm always trying to think of things I can't do with Ode that seem like something Ode should be able to do. I'm happy to say that I can usually find a pretty efficient way of getting an idea done. But from the beginning I've held back on a couple of addin hooks that I finally decided to go ahead with.

• manipulate_request

New addins

• Futz_request

Improvements/new features

• Better page titles
• Bypass page generation

More updates and improvements are in the works and I am working to make Ode available here very soon. Thanks for your continued (if unenthusiastic) patience. The good news (for all of us) is that I only have to launch the project once :)

I remain as committed to Ode as ever. Feel free to check back again for more updates.

The manipulate_request routine, as it's name suggests, allows addin developers access to the request (url, path, and parameters) very early in the execution of Ode. Before it is decided which posts satisfy the request.

As you might expect I think this new capability has some practical value. I've already put together one addin that takes advantage of the new interface.

http://ode-is-simple.com/home/about_ode

Is a request for a post file with the name 'about_ode' (which does not exist) and not the category (directory) .../about/ode/ (which does).

Note the absence of the trailing forward slash. Though Ode is technically doing the right thing here, this is an easy mistake for a visitor to make.

Taking advantage of the new manipulate_request routine, this addin will

1. Notice that the request:

   http://ode-is-simple.com/home/about_ode
   

doesn't match a post on the site.

1. Determine that there is a directory at:

   http://ode-is-simple.com/home/about_ode/
   

2. Change the request so that it resolves to the directory with the same name.

Of course, this could work in the other direction as well. (Though that mistake is far less common.)

We can change the request sneakily without notifying the visitor of the change or we can do a proper redirect, which issues a new request on behalf of the visitor, updates the address in the browser's address bar, and issues an appropriate HTTP status code (301, 302, 303).

By the way, the name of this addin is very likely to change.

Ode should do whatever it can to make sure that your content is easy to find and use for human visitors, search engines, other sorts of web services, etc.

This is a very broad statement involving a number of different considerations, including among many others: standards compliance, reliability, and design. Somewhere in there are page titles.

Ideally each page should have a unique title and right now Ode is the opposite of that (i.e. each page has exactly the same title). That's the bad kind of simple (stupid simple). The trouble is that by the time Ode accesses the content of a site, the page title has already been committed (finalized).

A little reworking of Ode takes care of that problem. Now:

• The home page title is the site title.
• Category page titles agree with category names.
• Pages for individual posts take there title from the post title.

Of course, this is only the default. You're free to do anything you like with page titles. The key thing is that it's now possible to have all of these different page titles and before it wasn't.

You won't see this change at ode-is-simple.com until I cut over to the new version of Ode on the site. I'll figure out some way to make it obvious when that happens (other than the page titles I mean).

What's the purpose? I can think of two. The first is somewhat theoretical, and the second very practical.

1. Without Ode's page to get in the way, you could generate any kind of page you like.

Of course building and serving a page from scratch is exactly what we're trying to avoid with Ode, so I'm assuming that the 'page you like' would be something other than a static HTML page. This might be good for a custom media page (e.g. a photo gallery).

Of course it would be easier and more efficient to just not run Ode if all you want to do is bypass it (Note: that it may actually be a little tricky to bypass Ode depending on how you've set it up).

Also, you can get pretty fancy without bypassing Ode.

So, I don't initially see an immediate need for this.

Also, you can get pretty fancy without bypassing Ode. So, at least initially I don't see an immediate need for this.

1. It takes far less time and effort not to generate a page.

The bulk of what Ode does is related to page generation. Of course that is normally justifiable. But if we are doing something like a redirect then it is far better to cut Ode off and save the server the bother.

Although I had been thinking about this for a while I couldn't justify the interface before manipulate_request.