News

Yes, unfortunately I still haven't released Ode. That's the bad news. The good news is that it still is coming AND I've decided to make it much more functional.

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.

Operating systems handle this differently left to their own devices, and its also possible to deal with this in the web server configuration, but after getting tripped up by a problem with case-sensitive paths myself recently running ode at robreed.net/weblog I decided to add a configurable option allowing the site maintainer to enable case-insensitive paths in ode.

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

Well not quite 4, but almost that long. So first an apology is in order for anyone waiting for this!

(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

Keep reading...

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.

Fresh Today: New addin interface - manipulate_request

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.

Ode takes requests pretty literally.

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.

You may notice that every page at ode-is-simple.com/home/ has the same title. That's very sad. :)

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).

It is now possible for an addin to have Ode dispense with building a page in response to the visitor request (and all of the work normally involved in generation of the page).

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.

Sitemaps are important especially for a dynamic site (at least Google, Yahoo, and Microsoft seem to think so). Even though Ode uses a simple URL/addressing scheme, left on it's own there are still some issues related to indexing that need to be cleaned up.

How does a search engine operation like Google find and index your site?

Here's a very short answer that ignores most of what's involved, including issues of relevance and rank:

The job of a seach engine is typically described in three parts

1. The crawl
2. The index
3. The runtime query processor

Of the three, only the crawler is relevant to this discussion.

A crawler (also sometimes called a spider) is nothing but a software program which when pointed at a page on the web moves from link to link recording all of the pages it finds so that they can later be indexed (maybe, all pages crawled are not indexed).

So essentially this is it:

• The crawler makes a request, in a way that's very similar to what you do when you request a page in a web browser.
• It hands the page returned off to be indexed
• and it makes note any links so that they can be requested and examined for links, and so on.

Links lead to links, lead to links etc.

In theory, the crawler can follow links from your home page to every other page on your site. In practice this is rarely the case, especially with dynamic sites.

Some pages may not be referenced at all, or more likely, pages will be connected in complex way, with the same page(s) referenced multiple times, often by different names, and at apparently different locations.

This is especially problematic for dynamic sites because it is usually not the case that there is a one-to-one correspondence between name, location, and page.

There are other issues as well, for example, dynamic sites may generate complex parameterized addresses that search engines simply avoid altogether.

This can lead to a couple of less the ideal outcomes:

1. Your site may not be discovered at all, or only incompletely discovered.
2. The site may be nearly fully indexed but in a confusing way so that results returned in response to queries at a search engine that do lead to your site, don't lead to the correct page or break altogether.

Again, the nature of a dynamic site is that content which in one place on a given request may be someplace else, or gone entirely, the next day, or even the very next request.

A concrete example of this is the homepage for a weblog.

Typically a weblog is essentially a collection of short posts listed in reverse chronological order.

Each new post added to the site starts out at the top of the list, which usually places it at the top of the homepage.

Because a site may have hundreds, thousands, or even hundreds of thousands of posts, all of them cannot be displayed on one page (because downloading and navigating that page would be exceedingly time consuming and tedious). So, only a relatively small number of posts are displayed on the homepage.

Each new post pushes the others down a place, until eventually they disappear from the homepage entirely (e.g. if the 50 most recent posts are displayed on the homepage then as soon as you reach 50 posts total, every new post you make will push one off the page).

If a search engine indexes your homepage, then someone who queries that engine may get a result that includes the information that was once, but is no longer there. That same person may click the link, arrive at your homepage, and be lost when the content they were looking for is nowhere to be seen.

Sitemaps are an attempt to avoid many of these problems.

They work like this:

You, as the maintainer, list all of the pages on your site in a single file (or a collection of files) in a format that is easy for a search engine's crawler to digest.

When the crawler finds your site it read the sitemap file(s) rather than or in addition to working through the links on the site directly.

Assuming the sitemap includes all of the pages on your site, and each page only once, you have made it easier for the crawler to find all of the pages you want included in the search engine's index ultimately.

The trouble of course is in generating the sitemaps.

Each time you add or remove a page you need to update the file(s) to reflect that change.

There are several tools available online that will allow you to create a static site map once (or more than once by repeatedly running the tool) but this isn't a solution to the problem.

Maintaining a sitemap manually, even for very small sites, is tiresome at best and most likely unworkable.

With the help of the sitemapper addin, Ode takes care of sitemaps for you.

• It generates the initial site map file and then (by default) updates it every 24 hours automatically.
• If you should accidentally (or intentionally) delete the sitemap file, Ode will recreate it for you.
• You're free to rebuild the sitemap more frequently if you like.

Simple sitemaps. Now I feel better.