I will be describing ExpanDrive for the Mac but there is also a Windows version available.

Before I talk about ExpanDrive I want to be sure to say that there are any number of applications that work much like ExpanDrive. In fact ExpanDrive is based on the open-source MacFuse project and Macfusion is one freely available open-source front-end. There are options available for other platforms as well. (I've already mentioned the Windows version of ExpanDrive.)

The utility allows you to define connections to remote servers (using SFTP, FTP, or Amazon's S3 online storage service) and then mount and access those connections in the same way that you would a locally mounted volume (a volume on a locally attached USB hard drive for example.) This means that you can interact with files on a remote server as you would local files and folders, both in the Finder and other applications. For an Ode user, this means that you can manage your site as if you were working with a collection of files and folder on your computer, without the need to explicitly push anything to the server. It's an intuitive, efficient and elegant solution. What's more because working with an Ode site primarily involves text files, which are relatively small in size, ExpanDrive and Ode work work beautifully together (in terms of responsiveness and performance). ExpanDrive itself seems remarkably fast, in comparison to other, similar products. According to the developers 'the SFTP core' has been rewritten for version 2.0. This means that uploading photos, videos and other media (and even playing these files directly from the mounted volume through ExpanDrive) should be quick and efficient too.

!--jump--!

Other features:

Any connection can be configured to reconnect automatically...

...so that it seems as if the remote drives are always available. From the website

'Our robust networking core ensures that if a connection is available, your drive is available'.

Easy install

Download the .dmg from the website. Mount the disk image (which should happen automatically, or you can double-click the downloaded file). Drag the app itself to the Applications folder.

Configuration is as straightforward as it can be.

Enter your login credentials for the remote server and you're done.

Localizations

According to the website, ExpanDrive is available in: Deutsch, Nederlands, Français, Español, 日本語, 中文, Dansk, Norsk, Svenska, Suomi, Română, Lietuvių kalba, and Tiếng Việt.

If you're interested in ExpanDrive, I recommend taking a look at the short video introduction/demo on the product website.

ExpanDrive is not free, though there are free alternatives. A single user license is not especially cheap at $39.95. There is a 30 day unrestricted demo available.

As you probably know, I like to say, 'Ode is simple'. More than a promotional tease, 'simple' is an inspiration, and the project's primary design principle.

Among other goals, I hope that keeping Ode simple means blurring the distinction between developer and end user.

Moreover, Ode is intended to allow us to take advantage the capabilities of modern text editors - some of the most sublime (robust, and polished) software applications ever written. With Ode, we use a text editor to manage all aspects of your site(s) (content management, design, and development).

When it comes to writing code, including markup languages like HTML, a monospaced font is your best friend - which is certainly not to suggest that they are not useful for any number of other purposes as well.

!--jump--!

Chank Co, an independent type foundry specializing in 'cool fonts for smart designers and free fonts for instant download' (as well as custom fonts), has a brilliant monospace font called Sarcastic Robot which I highly recommend. It's available now for the bargain price of only $1.99.

It's not going to replace Monaco in terms of utility, but there is a lot to like about it. For all it's zaniness, straight characters are straight, curvy characters are (extra) curvy, and all are easily distinguishable.

Some notes:

Great letter heights (in my opinion)

Doesn't work well at very small size (12 pt is perfectly legible/and plenty small for most purposes)

Character set is western languages only, and (maybe) somewhat limited

Tags are bits of text inserted into directly into post files either by Ode itself or the installed addins. They can be used to used to store information relevant to the post, and instructions to control the behavior of the script.

Individual tags are a single line of text and have the following the general form:

tag prefix literal : tag source/addin name : tag name  : tag value

!--jump--!

tag prefix literal - All tags start with the string 'tag'

tag source/addin name - All tags should include the name of the source addin so that it's easy to match each tag with the associated addin.

tag name - Addins may support more than one tag. The name identifies a specific tag. Though more than one add may use the same tag name(s), the combination of addin name : tag name should be unique among all addins. This correctly implies that no two addins should have the same name. (For the time being we'll resolve naming conflicts a case by case basis.)

tag value - the corresponding value of the named tag.

Earlier today I posted about tags related to two addins:

1. Indexette
2. Twitterer

To see these tags in action watch this screencast I recorded while creating this post (and publishing it to twitter).

This is just a little of what can be done with addins and tags. Ode will be released soon. In the meantime, I'd love to know what you think.

By the way, I'm considering changing the name of this feature from 'tags' to something else because the term 'tag' is strongly associated with another idea. In fact, I'm planning on implementing this sort of tag myself. If only for that reason I'd like to refer to this as something else. Any suggestions?

UPDATED 2010/0111 9:35 am: Fixed some typos and made some grammatical changes.

Just made a small change to fix the way that date-based permalinks work, as part of a final sweep to take care of all the nagging little issues before Ode is released.

I'll quickly discuss the change before reviewing date-based permalinks.

!--jump--!

The Problem (before)

When determining whether any one post should be included in response to a particular request, Ode would compare the full path of the request against full path the the post.

If the path to the request were contained in the path to the post (i.e. a part of the string that representing the path to the post), then the post should be included on the page returned.

Example 1:

Given the request:

http://sample.net/cgi-bin/ode.cgi/technology/apple/some_post.html

and the corresponding path:

'.../technology/apple/some_post.txt'

The response should include all all posts in the 'technology > apple' category titled 'some_post.txt'.

The problem is that when we use date-based paths the same comparison will fail.

Example 2:

Given the request:

http://sample.net/cgi-bin/ode.cgi/2010/01/01/some_post.html

The post 'some_post.html' should be included as part of the response, assuming it's dated Jan 01, 2010.

In this case the path to the post still looks like:

'.../technology/apple/some_post.txt'

But the path of the request, after we take away the date elements (which are not part of the filesystem path), is:

'/some_post.txt'

The path of the post is not contained in the path to the request and so 'some_post.txt' would be excluded from the page returned.

We could work around the problem by leaving off the name of the post file.

Either of the the following two requests would work:

1. http://sample.net/cgi-bin/ode.cgi/2010/01/01/  

2. http://sample.net/cgi-bin/ode.cgi/2010/01/01/index.html

Because these specify any post dated Jan 01, 2010 regardless of location. Furthermore, remember that we can specify dates to the sec. So, the requests above might have been something like the following:

(A request for all entries with a post date of: Jan 01, 2010 11:59:59 pm)

http://sample.net/cgi-bin/ode.cgi/2010/01/01/23/59/59/ \  
index.html

It's probably fair to say that this is a good enough permalink because it's very unlikely that any two entries will have identical dates (to the sec). However, it's less than ideal because it doesn't actually specify the post itself.

The Fix (after)

To fix this problem I've changed how the path of the request is compared against full path the the post.

Now the script splits the comparison, looking at the filename portion of the request (if there is one), and the path portion of the request separately.

Let's revisit the example above to see how this addresses the problem.

We've said that there is a post titled 'some_post.txt', with a post date of Jan 01, 2010, in the 'technology > apple' category on our site.

Given the request:

http://sample.net/cgi-bin/ode.cgi/2010/01/01/some_post.html

The post 'some_post.html' should be included as part of the response.

The path to the post still looks like:

'.../technology/apple/some_post.txt'

If we disregard the filename portion of the request, the path of the request, after we take away the date elements (which are not part of the filesystem path) is:

'/'

The path to the request is included in the path to the post, so we do match.

We compare the filename portion of the path to the post and the request separately and in this example we have a match.

                                  match  
                                    |  
/                           |   some_post   |  .html  
.../technology/apple/       |   some_post   |  .txt'

Because both comparisons are satisfied, the post fits the request and is included as part of the page returned in response to the request.

Now date based permalinks that specify inividual posts by name will work as expected.

For example, the following is a suitable permalink for 'some_post':

http://sample.net/cgi-bin/ode.cgi/2010/01/01/some_post.html

As are all of these (depending on how specific you want to get):

http://sample.net/cgi-bin/ode.cgi/ \  
    2010/01/01/23/some_post.html  

http://sample.net/cgi-bin/ode.cgi/ \  
    2010/01/01/23/59/some_post.html  

http://sample.net/cgi-bin/ode.cgi/ \  
    2010/01/01/23/59/59/some_post.html

More about date-based permalinks

In addition to a few date related parameters (documented elsewhere), Ode supports a path-based date restriction mechanism that allows us to create requests that treat dates as something like dynamic hierarchical categories, such that the dates corresponding to content returned in response to a request must match the date specified as part of the path.

OK, that's confusing. A few examples will be help:

Example:

http://sample.net/cgi-bin/ode.cgi/technology/apple/2008/03/01/

'2008/03/01' is a path-based date restriction, which instructs the script to limit content returned to entries with a post date of March 3rd, 2008.

Considering the rest of the path, the request targets posts dated March 3rd, 2008 which are also found in the category:

'technology > apple',

(including subdirectories of technology/apple/)

Example 2

http://sample.net/cgi-bin/ode.cgi/2007/

Is a request for entries with a post date in the year 2007.

Because the address specifies the site root, and not some more specific subdirectory (i.e. subcategory), any post matching the date restriction will satisfy the request.

Ode's path-based date restriction mechanism recognizes:

year,
month,
day,
hour,
minute,
second

Example 3

http://sample.net/cgi-bin/ode.cgi/2008/12/28/23/59/59/

This very specific request targets all entries with a post date of March Dec 28 2008, 11:59:59p.

Of course we might expect that at most a single post would satisfy this request. The script allows for these very specific date restrictions (down to the sec) to support very precise date-based permalinks.

Why date-based permalinks?

Category-based permalinks work just fine, and because Ode depends on the file system as its content database we know that category-based permalinks are always unqiue.

We cannot accidentally create two posts with the same name
in the same category because the operating system won't allow it. (i.e. The OS won't allow us to create two post files with the same name in same directory.)

Because of this, any specifier which includes both the filename and path is a suitable permalink.

The trouble is that these permalinks will break if the posts are moved. It's reasonable to assume that just about every site maintainer will, at some point, need to relocate at least a single post.

Yes, we can handle those changes through some sort of redirection, but

• Setting up the redirection can be a pain,
• Because it's a pain, some people won't bother, and we should
  strive to avoid breaking the web (even just our own very small corner of it) whenever possible.

Date-based permalinks should prove to be robust under Ode because of steps taken with the script to ensure that post dates do not change unexpectedly (even if a post is copied, moved, etc.)

A post date is intended to be the date when the post was first
added to the site. Because a post can never be added to the site first a second time, this date should not change.

Unfortunately, date-based permalinks are not guarenteed to be unique the way that category permalinks are.

Though we can't force the OS to allow us to create two identically named files at the same path even if we wanted to, it is technically possible to create two posts with the same name and post date.

(Note that this will probably never happen unintentionally in practice.

Post dates are computed automatically, and it seems highly unlikely that an author -or even multiple authors working on the same site- will create two identically named posts at exactly the same time - to the second.)

UPDATE 2010/0109 5:54pm: Fixed link to text_page theme.

The description that follows is intended to serve as an overview of the project. It's quite long. If you intend to read it in a browser I highly recommend you switch to the .textpage theme.

Note: This is only part of a much larger document, which explains why you will see references to various other sections among other oddities.

I've developed a web-based program which is intended to take advantage of the appeal and utility of the web, and designed both to serve as a suitable introduction to programming and also to bridge the gap between what students must learn early on in their studies and what they might imagine they want to do with a CS education.

The project is an extensible personal publishing platform, which is flexible enough to be used for any number of unique applications, but without modification is similar to a weblog or wiki. That is, an app designed to dynamically generate a website from individual posts, which are collectively the content of the site. The presentation of this content is determined by one or more themes, which dictate the overall look and layout. This sort of application speaks to the original design goals of the web.

There are quite a few open source dynamic publishing platforms available. The project I am proposing is unique in that it emphasizes the key introductory concepts (e.g. flow control, data structures, etc.) that a new student would be expected to be responsible for as part of a first programming course. The entire project is written using only these basic constructs; as such, new students can be expected to understand the application in its entirety. Moreover because it's extensible, it allows for literally unlimited creative freedom for students to explore their own interests, and can be used to bridge into more advanced topics. For example, because this is a web publishing platform, there are any number of difficult challenges involved related to communications protocols, distribution, inter- process communication, addressing, open standards, etc.

Additionally, the project is intended to support some of the activities which occupy our time in academia (e.g. creating and sharing presentations, note taking, and discussion). The simple idea here is that by creating a software system that is generally useful and one that can be easily repurposed, students may spend more time in contact with the project, and thinking creatively about what they might want to do with it and how to accomplish those goals.

!--jump--!

The application is written in Perl. I chose Perl for several reasons. First because it is a mature and stable language and particularly adept at text processing, which describes the bulk of what we need it to do. It is well established as a web programming language but general purpose and adaptable enough to be used for other types of applications as well.

The fact that Perl is a high level language allows us to emphasize higher level concepts from logic and structure to design, documentation, and even architecture. I contend that this will allow students to practice conceptualizing the whole of a project and anticipate problems with design and implementation, from security to efficiency and scalability, even as new programmers. I believe that this will help students appreciate the importance of low-level issues and prepare them for the sort of work that awaits should they choose to continue on in the field (e.g. architecture, data structures, algorithms, theory of computation, and advanced work that builds on these topics). For students who choose not to continue with CS, this sort of introduction to programming should provide a good understanding of computer technologies which may play an important role in whatever they choose to pursue. An intro course featuring a high level, widely available language like Perl should allow students to apply their knowledge of programming to their other work.

As for Perl's shortcomings, that it is a permissive language, has a tendency to result in unstructured programs, that it is overly idiomatic; these weaknesses can be overcome simply by adhering to good coding practices. There's certainly nothing about Perl that prevents code from being well-written. The sourcecode for the project should be as explicit and accessible as possible as opposed to being terse and overly idiomatic, except where the idioms are more efficient. Wherever idioms are preferred, liberal commenting should be used so that people who are unfamiliar with the eccentricities of the language can follow along. As I've said, the application should be designed so as to make it accessible to the widest possible audience. To this end, documentation is also critically important, and this is another feature that distinguishes my project from others.

Let's consider several different aspects of Ode in order to develop an understanding of the character of the program.

As was discussed in Section 2, Ode itself is a Perl script.

Content is a collection of simple plain-text files.

The look and layout of an Ode site is determined by a theme that is nothing more than standard (X)HTML and CSS.

Posts

Because posts are plain-text files, users are free to choose any editor they like. There are many fantastic editors available. Some of the best are open source apps, and of course there are also some great commercial applications.

These editors are as varied as the people who use them and the jobs they're asked to do. I daresay if you were to ask enough people the question, "Which editor is the best?", the total number of different answers is likely to equal the number of viable choices. One thing is for sure; editors, as a class, are some of the most mature, subtlety brilliant software applications available. Why then, when it comes to writing online, are we asked to abandon these finely honed tools in favor of the blunt instrument that is the HTML form?

Adding and Editing Content Part 1: Writing

The purpose of XHTML and CSS is two-fold.

First, to allow the developer or designer to control the structure and layout of a site, and secondly to style or format content. The structural bit is the responsibility of XHTML and the job of formatting and style falls to CSS.

The past several years have seen a lot of work in this area. From those efforts we have the emergence of standards based on CSS and the formalization of HTML as an application of XML. Combined, these technologies make a solid architecture for publication, but they're terrible authoring or writing tools. They're just not simple enough for the job.

• The syntax is (necessarily) formal which results in a lot of overhead; far too much for efficient writing.

  While complexity helps a markup language to be expressive and precise, it leads to a laborious and error-prone writing experience.

• Syntax errors break the interpretation of the markup and detract from content.

• The burden of slogging through syntax discourages content creation.

• Mistakes in syntax with XHTML tend to cascade through documents in odd ways causing unexpected and often difficult to diagnose errors.

• Noisy markup distracts from and complicates writing and editing. Working with XHTML directly, it is not unusual for the amount of syntax to exceed the content itself!

For these reasons various lightweight markup languages have been developed for the purpose of implementing a minimal syntax, which is intended to facilitate a more natural style of writing. These languages are typically implemented as both a syntax and a program capable of translating between its own grammar and XHTML.

These lightweight syntaxes are intended to address many of the problems associated with writing on the web by:

• Simplifying plain-text formatted source documents so that they are as readable as possible, even without being converted and rendered.

• Encouraging the appropriate use of formatting to improve the readability of the resulting XHTML as displayed in the browser.

• Avoiding the problem of mistakes cascading through a document. Broken syntax simply does not translate and does not disturb the rest of the document.

The unofficial but preferred syntax for Ode is Markdown. There are a few alternatives, most prominent among them, Textile, which is another very nice implementation of a lightweight language.

Why Markdown?

Because more than the others, Markdown emphasizes readability of the plain-text document and that seems very much in agreement with Ode's own design.

The other reason to choose Markdown is that it is written first in Perl, and Ode is itself a Perl program.

Are we limited only to Perl when working with Ode? No, but keeping as much of what is distributed with Ode in Perl will simplify things for new developers (more on development later).

I'll let the author of Markdown explain its advantages and raison d'etre:

Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Thus, 'Markdown' is two things:

1. a plain text formatting syntax; and
2. a software tool, written in Perl, that converts the plain text formatting to HTML.

The overriding design goal for Markdown's formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions.

While Markdown's syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown's syntax is the format of plain text email.

Does that mean that users of Ode are limited to working with Markdown? No, Markdown is implemented as an addin. They are free to replace it with some other syntax using Ode's addin architecture (more on addins and development upcoming).

It does mean that Markdown is distributed with Ode, that you should expect Markdown to work, and that discussion of Markdown is considered relevant to this project.

In addition to Markdown, posts support HTML. Just keep in mind that they are contained within a larger page structure. So for example a body tag () should never find its way into posts.

Adding and Editing Content Part 2: Content Management

It has already been hinted at that Ode uses the filesystem as a content database, which of course is different than saying that there is no content database. Decades worth of development speak to the effectiveness of filesystems at storing and organizing files and the data they contain. Modern filesystems are made to handle the rigors and requirements of modern operating systems and include numerous features designed to ensure the scalability, security, integrity, and availability of data. That's good enough for Ode.

It's true that a filesystem is different than a relational database and we need to take advantage of its strengths rather than railing against its limitations. For example, filesystems are strongly hierarchical so we should take advantage of that organization.

Posts are organized according to a hierarchical, topic-based categorization scheme. For example, the root of the site may contain any number of folders, which are interpreted as categories, e.g. 'Technology', 'Politics', 'Music', 'School', etc. Each of these categories may contain any number of posts as well as subcategories (i.e. subdirectories). For example, 'School' may contain subdirectories for each of a number of different courses. Within each of these subcategories there may be more posts and additional subcategories.

As long as we are willing to organize posts hierarchically, there are numerous advantages of using the filesystem as content database.

For example, a user who knows how to manage and organize other types of files, already knows quite a bit about managing the content of a site based on Ode. Even for new computer users it is true that the skills required for working with Ode are unavoidable and applicable to many other aspects of working with a computer.

That's just one aspect of Ode's simple content management. Here are some others:

• Adding, editing, and deleting posts

  The operating system's file manager and/or an editor are all that's required.

• Importing and exporting content

  Because posts are discrete text files, there are no distinct import/export procedures. With plain-text files, data can be freely migrated to any other platform at any time. There is no need to be concerned about getting 'locked into' Ode or losing access to content.

• Backing up and restoration

  Again, posts are ordinary discrete files which, as far as the operating system and backup applications are concerned, are indistinguishable from any of the other accessible files. In fact the same is true for the rest of an Ode installation, and not just content. Users are free to choose any backup procedure whatsoever, or continue to use the solution they may have already implemented. What's more, an Ode site can be backed up and restored incrementally at the level of a single file.

• Permissions

  Permissions for Ode are governed by the file and folder permissions and access controls dictated by the underlying operating system. There is nothing separate and specific to Ode to be concerned about. For users who may not be expert at managing permissions, a simple 'recipe', i.e. a straightforward set of easy to follow rules, should be sufficient.

• Interacting with a remote server

  This is no more complicated than file transfer. Users are free to use SFTP/SSH/WebDAV/HTTP or any other file sharing protocol suitable for their environment.

• File synchronization

  Let's say that a user wants to maintain an instance of an Ode site locally on a laptop and also run a publicly available server with the same content. For those times when she has her laptop but no internet access, she would like to be able to create and edit posts locally. At other times, she may not have her laptop, but does have access to the internet from some other computer. She would like to be able to sync the local and public sites.

  This is the sort of thing that is very difficult to do with other packages and trivial with Ode. Taking advantage of best in class file synchronization utilities for her platform, the user can easily mirror changes in either direction, either manually or automatically.

• More about the advantages of hierarchical organization

Because Ode sites are organized hierarchically (by date or category) they play nicely with search engines like Google. Just as simple posting means that we can write more efficiently, simple content management means that what we write can be shared and discovered by others more efficiently.

Finally this approach to content management, in combination with Ode's themes, allow us to syndicate the entire site and every category separately. Maybe one of our visitors is interested in everything we write and another only in what we have to say about 'technology', or just technology/Apple. Ode has the flexibility to do that automatically.

Date handling

In addition to the hierarchical categorization scheme that results naturally from the organization of files and directories, Ode is capable of interpreting date based requests.

Path-based date restrictions.

Path date restrictions function as something like dynamic date-based quasi-categories. They limit the entries returned in response to the request to only those items with a post date matching the specified date.

Example 1

http://sample.net/cgi-bin/ode.cgi/technology/Apple/2008/03/01/

'2008/03/01' is a path-based date restriction, instructing Ode to limit content returned to entries with post dates of March 3rd, 2008.

When we consider the rest of the path, we see that the client is requesting posts in the 'technology/Apple' category with a post date of March 3rd, 2008.

Example 2

http://sample.net/cgi-bin/ode.cgi/2007/

This is a request for entries with a post date in the year 2007. Because the address specifies the site root, and not some more specific subcategory, any post matching the date restriction will satisfy the request.

Example 3

http://sample.net/cgi-bin/ode.cgi/2008/03/28/23/59/59/

This very specific request targets entries with a post date of March 28, 2008 11:59:59 pm.

Of course we might expect that at most a single post would satisfy a request like this.

This scheme, which is ideal for date-based navigation and browsing, is built into Ode. Furthermore these date-based 'paths' function as perfect permalinks, allowing an Ode site to be reorganized at will without breaking links, and in so doing violating one of the key tenants of the web, namely "Cool URIs don't change".

Path based date restrictions are only one of two mechanisms the program employs related to date handling. There is also a parameter- based date range feature.

Date range parameters

There are three recognized date range parameters:

1. start_date
2. end_date
3. date_pattern

These can be used individually or in combination. When used in combination they should be flexible enough to specify very nearly any date range you might want.

start_date

(Example: ?start_date=20080128)

When only the start_date parameter is used, the response includes posts from (and including) the specified start_date going forward. Partial dates are allowed and match the beginning of the specified period, e.g. 'start_date=2008' is equivalent to 'start_date=20080101'

end_date

Example: ?end_date=20080128

When only the end_date parameter is used, the response includes posts to (and including) the specified end_date and before. Partial dates are allowed and match the end of the specified period, e.g. 'end_date=2008' is equivalent to 'end_date=20081231'.

The start_date and end_date parameters can be combined. The result is a range of dates bracketed at the beginning by the start_date value and at the end by the value of the end_date parameter.

Example 1:

?start_date=20070420&end_date=2008_0420

Matches entries with post dates starting on April 20th, 2007 and ending on April 20, 2008.

Example 2

?start_date=2008_0101&end_date=2008_1231

Matches all entries in 2008.

Example 3

(Note that the following values match exactly the same set of posts as the example above.)

?start_date=2008&end_date=2008

This is not a special case. It follows from the rule that partial start_date values match the beginning of the given period and partial end_date values match the end.

date_pattern

(Example: ?date_pattern=2008_0214)

As the name suggests, date_pattern is a pattern match mechanism (albeit a very simple one) which greatly improves the flexibility with which we can specify dates.

date_pattern is an 8 character string of digits and a single wild card, '*'. Digits are literal characters in the string, and the wild card will match any single digit.

Let's look at a few examples:

date_pattern=****0214 - All posts from Feb 14th in any year.

date_pattern=******14 - All posts made on the 14th of any month and year.

date_pattern=2008**** - All posts from 2008 regardless of month or day.

date_pattern=****03** - All posts in the month of March, regardless of year or day.

Themes

Themes allow for customization of an Ode site.

The most remarkable thing about Ode's themes is that they're almost completely unremarkable. Themes are pure HTML and CSS. The entire page layout is described by a single file that looks like any other (X)HTML file to a text editor or web design and development app.

There is no need for a user to change how she works with HTML/CSS for Ode. Repurposing existing themes for use with Ode or reworking Ode themes to function with any other platform should be relatively straightforward, assuming the other platform includes some reasonable templating scheme.

Here is the complete structure for the default theme at ode-is-simple.com

theme/  
    content_type.html  
    date.html  
    page.html  
    logic.css  

    images/  
        cod_header.png  
        ode_tag.png  
        ode_title.png  
        xml_badge_bw_sml.png

Of these files, page.html and logic.css are almost entirely responsible for the look and layout of the site.

What's more, page.html starts with a doctype declaration and ends with the closing html tag. Everything a user already knows about HTML and CSS is applicable. In fact, there is almost nothing new to learn, and it is not necessary to hop around among dozens of files inserting bits of HTML interspersed between sections of PHP and Javascript. Not only is this beneficial for users new to HTML and CSS, but experienced designers and developers can quickly implement a theme under Ode, work out the kinks, and then repurpose it for any other platform without unwinding or otherwise removing the Ode specific elements (because there are virtually no Ode specific elements).

The fact that Ode themes are so simple does not imply that they are limited. On the contrary, Ode's theme mechanism is quite robust, supporting several features lacking in more established, mainstream dynamic publishing packages. Users can create and apply any number of different themes to an Ode site and switch among them at will, on a per request basis.

For example, any page can be presented using any installed theme without changing the configuration of the site. Furthermore, different default themes can be applied to any category (subdirectory). Themes associated with a category apply to all subcategories, but can be easily overridden. Whenever it is the goal to create a consistent look across an entire site, it's possible to establish a default theme for the entire site simply by associating one with the root category. However, let's say that a site includes both 'Technology' and 'Music' categories, and these should have unique themes. We can easily override the default for each of these categories separately, and without affecting the rest of the site.

Themes are stored alongside posts under the site's document root. In addition to the document root itself, any subdirectory may contain a 'themes' directory. Each of these may contain one or more subfolders, each dedicated to an individual theme.

There is no limitation on the number of individual themes per 'themes' directory, except that no two directory entries at the same path can share the same name. (Of course, you will probably recognize that this is not a limitation of the program, but a fundamental characteristic of the structure of the underlying filesystem).

How do themes work? There isn't a single answer. Instead there are several variations corresponding to several different cases only one of which applies to any given request.

Essentially there are two 'modes' of operation related to themes: non-dated and dated. A configuration option controls which of these two modes is in effect at any one time.

Non-dated themes

With the non-dated theme mode in effect, when a visitor requests an address Ode determines which theme to use by starting at the most specific path to the request and working back toward the root. As soon as it finds a theme that matches the request (or a default if no theme was explicitly specified), it stops looking.

Themes which are closer to the request will always override themes with the same name higher in the content hierarchy, i.e. further from the request. This simple design idea allows us to define different themes for different segments of the site and then apply them in a way that ties the theme mechanism to the filesystem structure, which is consistent with the natural organization and categorization scheme for the content of an Ode site.

For example, let's say that the following is the partial structure of an Ode site.

As you can see, the root, as well as many, but not all, of the children, grandchildren, and later descendants of the root contain a 'themes/html/' directory.

When a client submits a request for some page at this site, Ode starts by looking for the specified theme closest to the request. If the given theme cannot be found, the program works backwards, up toward the root until it finds the theme it's looking for, or runs out of places to look.

+ /entertainment/  
|   + movies/  
|   |  
|   + themes/  
|   |   + html/  
|   |  
|   + tv/  
|   |   + themes/  
|   |       + html/  
|   |  
|   + video_games/  
|  
+ /operating_systems/  
|   + themes/  
|   |   + html/  
|   |  
|   + apple/  
|   |   + macosx/  
|   |  
|   + linux/  
|   |   + themes/  
|   |   |  
|   |   + redhat/  
|   |   |   + fedora/  
|   |   |       + themes/  
|   |   |  
|   |   + ubuntu/  
|   |  
|   + microsoft/  
|       + themes/  
|       |   + html/  
|       |  
|       + vista/  
|       |   + themes/  
|       |       + html/  
|       |  
|       + xp  
|           + themes/  
|               + html/  
|   
+ /themes/  
|   + html/  
|  
+ /travel/  
    + usa/  
    + western_europe/  
    + france/

Let's look at a couple of examples:

Example 1:

.../operating_systems/microsoft/xp/some_post.html

Given this request, the routine starts by looking for an html theme at:

/operating_systems/microsoft/xp/

There is a 'themes/html/' at that path, and that is the theme used in response to the request.

Example 2:

..../entertainment/tv/index.html

The routine starts by looking for an html theme at:

/entertainment/tv/

You can see that there is also a 'themes/html/' directory at that path, and again, the script will use that theme in response to the request.

Note that it is different than the theme used in the first example.

Example 3:

.../travel/western_europe/some_post.html

Given this request, Ode will start at the directory closest to the request. Failing to find an html/ theme there, it will search in the next directory closet to the root, and so on.

The routine will fail to find a theme at:

/travel/western_europe/france/

/travel/western_europe/

/travel/

Before eventually finding the '/themes/html/' directory at the site root.

This is the same theme that would be used for a request of the site's homepage, and also for every other branch of the hierarchy, at any level, that does not have its own html theme.

This arrangement allows us to create custom themes for any portion of the content hierarchy we wish, simply by creating the necessary 'themes/html/' folder and defining a theme which is appropriate to that category. Alternatively, we can maintain a consistent look across the entire site by defining a single 'html' theme at the site root.

Dated themes

As described above, individual themes are defined by directories included in container directories titled 'themes', and these containers exist alongside content under the site's document root.

For example:

/technology/apple/macosx/themes/html/

The 'html/' directory in 'themes/' defines a specific theme that can be applied to requests for posts in the '/technology/apple/ macosx/' directory, and subdirectories of '.../macosx/'.

Dated theme archives work much the same way, except that the names of the individual theme directories must include a date suffix, specifying the date when the instance of the theme was created.

These dated themes work with the sitelookdate parameter to allow clients to request a previous version of a named theme.

The value of the sitelookdate parameter specifies a target date.

It is a request for the version of the theme in use on the specified day.

For example

http://sample.net/cgi-bin/ode.cgi/technology/apple/macosx/ \  
some_file.html?site_look_date=2008_02_01

This address is a request for the post at '/technology/apple/macosx/some_file' It also indicates that the response should use an 'html' theme, and more specifically the 'html' theme that would have been the current theme on February 1, 2008.

Ode must work through all of the (potentially many) matching named themes between the path to the request and the site root, and determine which was the theme in use on the specified day. More specifically, the program must find the dated theme with the latest date that is earlier than the requested sitelookdate. Dated themes and the sitelookdate parameter are discussed further in the Related Work section of this report (Section 4).

Addins

Addins are modules that extend or redefine how Ode operates. You may be familiar with other projects where this same sort of thing is referred to as a module, addon, plugin, or extension.

I chose the term addin because:

1. 'add in' describes more accurately than the other terms how extensions work under Ode. They are installed simply by adding (i.e. copying or moving) them to a specified directory.

   The term 'addon' seems somewhat disparaging, as if the extensions are of lesser importance than the program itself. Moreover, because it's possible to directly replace core subroutines and not just 'add on' new functionality, the term seems not entirely accurate.

2. addin is not as commonly used as some of the other terms. It is less likely that references to Ode addins in documentation or tutorials will be confused with something else, for example Perl or Apache 'modules'.

Essentially addins allow anyone familiar with Perl and Ode to redefine almost any aspect of the program by redefining key subroutines, or extend the functionality of Ode in an infinite number of ways by introducing entirely new routines.

To install an addin, simply download and copy it to Ode's addins directory. Each addin is completely self-contained. There is no need to worry about becoming confused over what goes where.

These individual addin directories are referred to as bundles.

Addins are managed by directly manipulating corresponding files via the filesystem, in much the same way as posts, themes, and virtually every other aspect of the program.

Interacting with the addin files directly avoids the problems and confusion that can result from using an intermediate interface, e.g. a web form, to manipulate or manage the state of extensions.

A short example may help to illustrate this point. With Ode a site maintainer will deal with addins in exactly the same way whether the program is operating normally or there is some error. With many other packages, if an extension malfunctions, the user may lose control over it from the administration interface, or what's worse a malfunctioning or misconfigured extension may prevent the software from running at all, which often means that the admin interface is inaccessible, and as a result, it may be difficult to fix or remove a problem module.

Ode's addins are disabled by appending a trailing underscore to the bundle or addin name. The advantage here is that it's possible to see at a glance whether one of these extensions is enabled or disabled. Disabled addins do not affect the behavior of Ode and do not impact performance in any significant way.

Without talking too much about development here, I do want to make a couple of points about the philosophy of addin development under Ode:

• Addins should be self-sufficient with a minimum of dependencies.

  External dependencies are problematic because they add to the minimum requirements necessary to use the software, and while adding one or another library may not be a problem for some installations it may be very nearly impossible for others. Furthermore, external dependencies complicate installation, configuration, and documentation.

• Internal dependencies among addins should also be avoided.

  Things get tricky when, as an end-user, I can install the addin I want but not some other addin the script requires because of a conflict.

• addins should be single purpose (in the interest of minimizing internal dependencies)

  If, as an end user, I'm installing an addin to pick up one feature, it can complicate things for me if a bunch of other (unwanted) routines come along for the ride.

  Small, single purpose extensions should result in faster, more reliable development, and finer granularity of control for the end user over what's running on her site.

• Ode does not use a package manager (like CPAN).

  Why? Doing so adds an external dependency, potentially fractures support and maintenance issues between multiple projects, and complicates initial setup and configuration, especially for users new to both Ode and the package manager who must, at the outset, contend with multiple new projects.

Upgrading

Upgrading Ode involves replacing a single file. Because configuration details are kept out of the .cgi itself (and your content, themes, and addins are unaffected by an upgrade) all that's required is replacing the current version of the ode.cgi with the new one.

Configuration

There is a single configuration file. All of the configuration options are well documented and include sample settings to help resolve any ambiguity in the description of what these options do and how they should be set.

What's more, you won't find dozens or hundreds of options. Expect to spend no more than 5 - 10 minutes configuring Ode, the majority of it reading through the descriptions of the various settings. That time will save you potentially many hours trying to resolve problems due to misconfiguration.

Security

Let's be honest, security isn't simple. Realistically, the best we can do with Ode is to add as little, possibly exploitable, overhead as possible. Any extraordinary steps we take with the program, other than sanitizing input and other best practice defensive coding strategies of course, is unlikely to improve the security outlook and in fact may introduce more risk. Instead, let's rely on some trusted friends: SSH, SFTP, and SSL.

SSH is a network protocol that allows for secure data exchange between computers. SSH is a well tested, widely distributed, open standard and is very well regarded. What's more, it is very flexible, making possible a wide range of communications from remote administration through a secure console, file transfer, and tunneling of other protocols (whereby unsecured applications and their protocols are redirected through the SSH to a remote host over the encrypted SSH connection).

SFTP is a file transfer protocol which is typically implemented on top of SSH. Using SFTP is no more difficult than using FTP; in fact its all too easy to confuse the two from a usage standpoint. Chances are that your file transfer client supports SFTP (if not, it's time to get a new client).

Both SSH and SFTP are relatively easy to use. The details of how they work to establish and maintain a secure channel are actually quite complex. Support for SSH and SFTP is built into most modern mainstream operating systems, and available for every one.

Last but not least there is TLS (Transport Layer Security)/SSL (Secure Sockets Layer). If TLS is unfamiliar, it is an update to SSL intended to bring SSL into the fold as a standard internet protocol (under the auspices of the IETF), while introducing some new features and resolving outstanding issues with SSL.

These protocols provide for secure transactions between browser and server on the web, i.e. secure HTTP transactions. HTTP is the application protocol of the web and is itself not secure. SSL is a secure lower level protocol which can be used to encrypt and transport HTTP data. Support for the protocol is included in all mainstream web browsers in such a way that it is easy to secure transactions between the browser and a web server using SSL. Like SSH and SFTP, SSL is easy to use. Unlike SSH and SFTP, it can be somewhat of a challenge to configure a web server properly to use SSL.

Summary

Of course this brief discussion only begins to describe Ode but it has touched upon many of the program's key features and characteristics. The remaining parts of this section, including the diagrams (Section 3.2), source (Section 3.3), annotated source code (Section 3.4), example addins and themes (Section 3.5), thoroughly detail the program in its entirety.

I would be remiss if I didn't clearly acknowledge Blosxom.

From blosxom.com, (which is currently up and running though the site has not been active for some time):

Blosxom (pronounced "blossom") is a lightweight yet feature-packed weblog application designed from the ground up with simplicity, usability, and interoperability in mind.

Once upon a time (and does seem like a very long time ago, before Values of N and the ill conceived, in my opinion, 'Stikkit' and 'I Want Sandy') blosxom made a big impression on me. In fact it was blosxom that started me thinking about web development in a serious way, and the nature of the Web today, and its history and original design goals. I'd go so far as to say that blosxom had more than a little to do with my decision to go to grad school for Computer Science. Not that it takes a CS Master's degree to figure out blosxom, but I wanted to explore what it was that I thought that app got so right (compared to say services like Stikkit, Twitter and so many others). What exactly do I love about weblogs and hate about Facebook? It it simply a matter of personal preference or is there in fact an important distinction?

!--jump--!

Blosxom led more or less directly to Ode, and got me thinking about the value of simple and the ineffectiveness of easy.

Ode owes a lot to Blosxom.

Recently I received an email from a Blosxom user inquiring about the status of this project and idea of transitioning to Ode. I'll post some of that exchange because it is relevant to the question of how Ode relates to blosxom. (I'm posting without asking for permission, I hope you don't mind. Let me know if you want me to remove the bits quoted from your email):

Are you planning to release Ode? I would encourage you to.

Absolutely. You might not know it from the lack of updates to the blog but Ode is alive. I'm actively working on it.

I've really never stopped thinking about it. For a while now I've been a day away from releasing it. Knowing that there are people ready to put it to use certainly pushes me in that direction. For what it's worth, when it is released, I can tell you that it will be stable and exceptionally well documented (that is to say, exceptionally documented, whether or not you think it's well documented is a matter of opinion I suppose :). Let's just say if you wanted to know how it works there's plenty of information including what's essentially a narrative approach to the source code, execution diagrams and just about anything else you could imagine. That may be overkill but it's a good place to start and utterly unlike virtually every other small project like this.

I like Perl and have some 5000 Blosxom entries. The concepts you describe make sense to me. Wordpress, posterous and the like are good, but creating your own add-ins and having control and responsibility are better. In a way, Ode could be an upgrade path for Blosxom users.

I agree with all of this. Perl gives you so much. To some extent I understand why everyone gets excited about Ruby and other languages with their webcentric frameworks, and whatever else is good about them, but Perl is just plain excellent. It gets just about everything right, for example two things that are very related to this project are its regular expression handling and unicode support. It's like there's magic elves somewhere making sure that you don't have to worry that something fundamental isn't done exactly right. I thought of using another language and I still think about porting Ode but I'm happy with the decision to stay with Perl.

About Blosxom, I would say this is absolutely true. Blosxom users will feel right at home as will their blogs (posts, themes, addins) with some changes. (Oh yeah, under Ode extensions are called "addins" instead of whatever blosxom called them which I can't remember at the moment.) Personally, Ode is my successor to Blosxom and though everything has been rewritten, it works in very much the same way. Don't get me wrong, there are some changes; for example, I always thought Blosxom was peculiar in how it handled themes, requiring separate head, post, and foot files. With Ode there's a single page file. What's the advantage? Well for one thing, you can open that page file in something like Dreamweaver and be looking at a full html page, something that not only displays properly but will also validate as standards compliant (assuming you've written it that way). But if you're repurposing a Blosxom theme, you can basically just combine those three components into a single file and have a working Ode theme. Don't get me wrong, if you had an addin it would need to be rewritten. But for every Blosxom interface you'll find an equivalent Ode interface that you can substitute and pretty much keep the same thing as it is.

One thing worries me a little. Do you plan to ban date-based paths? Or did you say that you won't force them on users? I need date-based paths because my entries are date-related, not topic-based or category-based. Blosxom abhors date-based paths but I am working around the restriction (which, in turn, affects searchability with Blosxom's permalinks.)

I would say the reason why most people would want to avoid explicit date-based paths with Blosxom and why Blosxom doesn't support them is because it includes built-in support for date-based permalinks. You probably know that already. So most people wouldn't see the need to create a folder structure that looks like: /2009/10/31/ because if you have a category based directory structure you can still type in a request that's something like: sample.net/cgi-bin/blosxom.cgi/2009/10/31/ and end up with all of the posts that you might have put in that folder. That way you essentially get both. Date based permalinks work particularly well because they are unlikely to change and that's the idea with permalinks. On the other hand, somebody might reorganize their site and change the categorization scheme, breaking anything but a date-based link. I'm sure most of that you already knew.

With Ode, I added a parameter-based date mechanism in addition to the path-based date restrictions because the path version is pretty limiting. For example, with paths, you can do something like /2009/10/31/ to pick posts from a specific day or /2009/ to get all posts written in that year but not all posts in any October. With Ode's parameters you can do that. There are three parameters that can be used in combination: a start date parameter, an end date parameter, and a date pattern parameter. With start and end date you can specify a start date or end date, or a range. The pattern lets you do something like the first of every month, or every post written in January or every post written on Halloween, regardless of year.

With regard to your question, I could make the date-based paths optional using a configurable setting which would still leave the parameter mechanism. That's what I'll do.

There are some other features that are different from what you might be used to in Blosxom. I already mentioned that themes are different in the sense that there's a single page file instead of individual head, post and foot component files. There are other differences as well. Like Blosxom, themes can exist at any level of the content hierarchy, and this can be used to provide different looks for categories. Unlike Blosxom, themes are contained in a themes directory. Every category may contain a themes directory that may contain one or more theme(s).

Also, Ode supports dated theme variations/archives. Let's say that your site has a particular look now, and in the future you may change it. Either by something as simple as changing a header graphic or completely changing the look and layout of the site. Using the permalinks or date restrictions, you can construct a request that will show you what your site looked like as far as the content is concerned. I wanted to make it possible to view your site as it existed not just in terms of content but also appearance/design. You can do that. If you make a change, you can just archive the old version and essentially both new and old are available. You can construct a request that returns the old version of the theme. You can have any number of dated archives per theme and of course any number of themes at any level of the content hierarchy. I don't think any other weblog package allows you to do this, i.e. recreate a site exactly as it looked in terms of content and design on the fly.

There's a separate config file. Of course the benefits are fairly obvious. It decreases the chance that a user might break the script by changing a setting, and it means you can update the script or that upgrading the script is just a drag and drop replacement of the cgi without requiring that you remember to carry over your configuration.

There's a general purpose mechanism that addins can take advantage of to store config details or other info related to posts in the post files themselves.

For example, I'm sure you know that Blosxom and Ode too are heavily dependent on modification times. I always found that to be too fragile an arrangement and difficult for new users who are unfamiliar with file management. I've written an addin for Ode that saves the post date within the post file in human readable form. Not only can you tell what Ode thinks the post date is by just looking at the content of the file either through a text editor or in a web browser but you can modify the post date by updating the date in the file rather than using touch or something like that. Optionally, the updated post dates can update the modification time in the file itself. So if you stopped using the addin you wouldn't have to worry about your posts getting out of order.

As another example, I've written a twitter addin that saves the ID of the tweet in the post file and allows you to delete or retweet a post directly from the file. The twitter addin allows you to automatically tweet a new blog post with a link back to the permalink run through a url shortener. It takes care of making sure the 140 char limit of twitter doesn't break in the middle of a word and that sort of thing.

Anything can be disabled by simply appending a trailing underscore to the name including theme, posts, and addins. This allows you to disable stuff without having to move it and then keep track of where it came from and where you put it which is something that I always struggle with. I've also put together an addin that allows you to create and edit posts in the web browser. And it includes a live preview of what the post will look like, which supports html and markdown and could easily support other syntaxes. That's not all that Ode can do, but I'm this is already more than you expected in a response and maybe more than you wanted to know.

In a recent post I talked a little bit about the annotated source code.

An excerpt from the post:

It's important to understand that though the annotated source does contain the source code, and is executable, the emphasis is on the annotations and not the code. Please don't make the mistake of disregarding this as nothing but obfuscated code. It's an attempt at a narrative approach to the task of developing the software. As such, it is an integral aspect of this project. It captures design-time decisions, serves as documentation, and represents a foundation for future work. (It is also a little unwieldy in its present form.)

Though I believe the annotated source is legitimately useful as-is, if you can resist the temptation to rail against it and take it for what it's worth, it is admittedly cumbersome. Furthermore, it's not intended to be an end in itself. Rather, as suggested by the excerpt above, it represents a narrative description of the project. It's a thorough description of the script, but utterly inflexible.

!--jump--!

Think about it as something like Google Maps Street View. For all of it value, Street View is only useful when looking at a very small area of the map. Imagine how difficult it would be to negotiate a map if Street View were the only view available.

There must be some other, better documentation model that affords this level of detail when appropriate (when we want), but allows to 'zoom out' to get a broader view of a system, and then narrow our focus on a particular component abstracting away all of the other details, in such a way that we could still appreciate how the component fit.

I've put together a presentation talking about this issue and sketching out a proposed architecture documentation model that would allow us to manipulate documentation as described above.

Eventually, assuming I have to opportunity to work on it, I'd like to explore these issues further using Ode as a case study.

Have a look if you're interested.

It's a complicated question with an equally complicated answer but I'll spare you most of the details.

Some of you may know that after working in IT for quite a while I went back to school to get a Masters in CS. That was umm... successful on paper (I officially graduate in February and I did well enough). But, did I get what wanted from the experience? No, I certainly did not. In fact I'm a little miserable about the whole thing. Anyway, long story short, after kicking around a bunch of ideas related to The Semantic Web, the project that would become Ode turned into my primary preoccupation. In one way or another, it was the inspiration for much of what I ended up doing beyond the required coursework.

As a result, there are are really two different aspects of this project:

The first is Ode itself, i.e. the extensible publishing platform running this site.

The second is the theory behind it, which explores two issues I believe to be crucially important (and our approach to them woefully lacking):

1. Software engineering and documentation
2. Education (particularly CS education)

Though the emphasis of this site will be the software itself, I am also planning to post about some of the thought behind it. Ode's motto is 'simple means you know how it works' and toward that end, I'd like to provide as much insight as I can into not only how the the software works (what it does), but why it exists at all (why it does what it does).

!--jump--!

I realize that many of you may be uninterested in this aspect of the project. I'm going to make it possible for you to push this sort of content aside when you visit the site. There a bunch of ways I might do it. At this point I'm undecided. So, for now I'd ask that you tolerate it. Thank you for your patience.

On the other hand, if you are interested, especially in the education piece, please do contact me. I'd be interested in seeing Ode put to use as the foundation of an introductory programming course or something similar (and I'd be willing to help make that happen).

As far as the theory is concerned, I'll be posting a lot of this sort of thing as background material initially. As I'm no longer actively working on this aspect of the project, the theory will soon give way to a continuing discussion of the software going forward.

(By the way, I'm going to pull a lot of material from academic work I turned in for school spending an absolute minimum amount of time altering it to remove references academic paper, other coursework, etc. This explains why you some of what you see may seem somewhat out of place and disjointed. I apologize in advance.)

There are any number of ways to create (and edit, and delete) a post under Ode. Posts are nothing more than plain-text files. Any method you can think of for generating plain-text should work just fine. Think about this creatively and the possibilities are endless.

In this demo I'll show you three (3) common techniques that should feel immediately familiar to anyone with experience a web browser, and working with text files using modern operating system (e.g. Linux, Mac OS X, Windows).

!--jump--!

1. Create your post as a text file and then copy it to your site.

This is a very basic demo but I invite you to take a moment to think about how much flexibility this provides.

Because we're editing a file locally we can take full advantage of all of the functionality provided by the OS and installed applications. Additionally, creating and managing drafts couldn't be more straightforward (i.e. just delay uploading to create a draft and sort and categorize these using the file manager provided by your operating system.

1. Create the post in a web browser (in this case the script takes care of creating the text file for you).

The benefit is convenience. With the editedit addin (which will be the subject of a future post) and Ode it's as easy to publish to your Ode blog as Twitter or Facebook (and you get live previews, markdown and HTML formatting, and other goodies).

Post anywhere you have access to an internet connected device with a web browser.

1. Connect to your website remotely using an SFTP client and create the post on the server using your text editor of choice.

I'm using an app called Coda in the video. Using Coda this way we can keep a local copy of the site in sync with the hosted version. This would be a great way to manage a site (or more than one).

Because Ode is so simple, we can take advantage of other applications, like Coda, to create sophisticated solutions that are more than the sum of their parts.

These are the first in a continuing series of demos. I'll try for at least a few each week. There's a lot I'd like to show you.

Note: I'll return to the subject posting in future demos to take a closer look.

Rob