I've been meaning to roll the rest of the posts in my FlatPress blog centered on Debian into this Ode site.

In the past, I've moved quite a few of them in here, but there were about 30 or so from the early days of the FlatPress blog that I had yet to move.

I plowed through about 20 today and have 17 more to go. Rather than taking HTML source from FlatPress, I'm copy/pasting regular text from the FlatPress blog into text files and using Markdown to re-create the links and bolding.

Read the rest of this post

Through the Ode forum, I just found Jim's graphic design and history site, Codex 99 Annex.

It's nice to see what you can do with Ode when it comes to design. (hint: just about anything).

This guy lost it all when he didn't backup a decade of web content: http://www.craiglockwood.co.uk/

Level of difficulty: Medium to high

Description

A utility that will crawl the Ode documents folder and create a list of links by year and month that can be used in the sidebar of the blog as an archive. Another possible archive listing (which I had in Movable Type and quite liked) is a single page with a list of every individual entry by title.

While this could be done with its own Ode addin, this functionality could be folded into the Indexette addin. In this case, the "reindex" call would also build the year/month and full-archive index HTML, which could then be inserted in the appropriate places in the theme file (for the year/month index) and a single "archive" page for the full archive.

Discussion and questions

Am I missing something, or is this an easy project? It's possible to reuse code from Blosxom, PyBlosxom, or just about any blogging system that offers this functionality.

I love Pencil Revolution. That is all.

Rob and I have been talking about licensing a bit over the past month or so, and I'm listening to a lot of discussion and debate about software freedom and licensing courtesy of the Free as in Freedom podcast.

So I decided to license the content of this blog. It's possible to use a software license like the GPL for written, "creative" content, just as it's possible to use a license like those from Creative Commons, which were written with "creative" works in mind, for software.

But since what's here is, for lack of a better word, prose, I am choosing a Creative Commons license: the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0) license, the full text of which you can read here.

It means you can use what you see here for non-commercial purposes if you attribute it and share it under the same (or a like-minded) license.

If you do want to use what you see here in a commercial (read: moneymaking) setting, contact me at steven (at) stevenrosenberg (dot) net. We can probably work something out.

What licensing is (and isn't): A lack of a license on your code or content -- seemingly giving no rights -- doesn't "protect" it more than having an actual license. Nor will a license in and of itself keep others from doing things with your content that are in violation of the license.

As Bradley Kuhn often says on Free as in Freedom, sometimes enforcement is required. If you find somebody violating terms of the license under which you have made your work available, you might have to get out there and do some enforcement. The license gives you a legal framework under which to do that enforcement.

Updated: Question -- Should cached HTML be prioritized over dynamic CGI? (see Discussion and Questions below)

Level of difficulty: High

Description

Over the past few years, there has been a trend away from dynamically delivery blogging systems like WordPress and Ode to static-site generators like Pelican, Nikola, Jekyll/Octopress and others.

Everybody is worried that their potential web host won't support the technologies that create and deliver blogs, such as Perl, Python, Ruby on Rails, Node.js, etc., and that dynamic delivery is "costly" in terms of CPU time on the server and actual financial cost for those resources.

Feeding into this is the worry (real or imagined) that goes something like this:

What if my site is Slashdotted, or somehow gets wildly popular, or I become the toast of the Internet? Will Ode/whatever-I'm-using be able to keep up with my overwhelming popularity?

It's generally assumed that a static HTML site with no dynamic elements will hold up the best under this "I'm so popular, I have to wear shades" scenario.

But in the "real" world, we're not all so darn popular. But we want to be ready. For our moment.

WordPress, which features dynamic delivery via PHP, solves this problem with caching plugins. These plugins generally take PHP requests that have been made in the recent past and turns them into temporarily cached static HTML files on the server. In Ode's case, posts and indexes are delivered via Perl/CGI.

When a "popular" (aka recently requested) query is made for an entry or index, the plugin delivers the static file, potentially reducing overall CPU load for the system and better handling increased traffic for a few of the many entries in the filesystem/database. And since the likelihood of a "Slashdot"-style traffic onslaught being limited to a single entry (or very few entries) is very high, this sort of scenario (caching as HTML of recently popular entries) has a high likelihood of making the overall blog site much more efficient.

An Ode caching addin would probably always create cached versions of the main index page (i.e the Home page) and maybe the page that delivers the second 10 posts.

It would also cache any individual posts or category requests that are made in the course of the blog's operation over a given period of time (say a day, hour, week or ??). The addin would write these "popular" requests as static HTML.

With the caching addin active, a request for any Ode content would go "through" the addin. The addin would check a list of static files it has created. If the request matches, that file would be delivered. If the request does not match, the request would be processed via Perl/CGI, and that CGI output would be cached as HTML and added to the caching addin's list.

The caching addin would "flush" the cached HTML and the list on a periodic basis. This could be accomplished via HTML request with the addin flushing based on pre-set rules, or via a timed interval, with time determined by a request to the server.

Discussion and questions

• Would a caching addin require more CGI overhead than it would save? (There would still be some CGI required to run the addin and determine whether a request could be delivered via static HTML.)

• Maybe the caching code and the resulting static HTML files should be "baked in" to Ode a little more than a traditional addin. By this I mean that an initial request for an index or post could immediately check either a list, or the filesystem itself, for static HTML. If that file is not present, the CGI request would be initiated, and the page would be delivered dynamically and subsequently added to the cache. This way, Ode would "favor" the cached HTML and only initiate a "full" CGI request when necessary.

The posts below this one in the queue represent the notes I've made over the past few months on features I'm thinking about that could potentially be added to the Ode blogging system either as addins or core functions.

Some are simply calls for documentation that I would be very comfortable creating myself, in case you are wondering.

Others represent Perl development work.

These entries are here more to encourage discussion among current and potential users of Ode than anything else. So please do.

Level of difficulty: Medium

Description

Modify the HTML and CSS in the main Ode theme so it is fully "responsive" and scales on mobile devices.

Notes and questions

• Hans Fast's Surfacemarkup.com Ode site has a responsive theme. The changes could be incorporated into the main Ode HTML theme, and perhaps Hans would allow his theme to be incorporated into the Ode files and/or offered as a downloadable theme.

• This is a great Ode development project, as would be the creation or modification of any theme. It's one of many learning opportunities that involve working with HTML and CSS and don't require knowledge of Ode's core programming language, Perl.

Level of difficulty: Low to medium

Description

Pagekite is a Python-based service that allows you to maintain a home server and offer material on that server over the Internet via tunneling without exposing your server directly to the network.

This is a potential solution for those who want to run Ode on their home server but are uncomfortable exposing that server directly to the Internet.

These instructions would build on the Ode installation documentation by showing how to set up a home server and integrate it with Pagekite. The instructions would detail the requirements for hardware, software and Internet connection, as well as how to start and configure a Pagekite account to tie it all together.