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.

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: High

Description

If I'm not mistaken, there is more code in the EditEdit addin than in the whole rest of the Ode core. EditEdit -- which brings a web interface that allows creation of new and modification of existing Ode posts -- is complicated.

EditEdit is great in a Web browser on a traditional PC, but it performs poorly on an iPad (a lack of scroll bars on the post window makes it impossible to write and edit all but short posts) and on mobile devices. Turning EditEdit into a mobile-enabled app or site would solve these problems.

Notes and questions

There are two ways to go: HTML5 or native iOS and Android apps. Professional app developers often say the increased performance of native apps is worth overcoming the difficulty of writing to both of the major device families.

But HTML5 apps are independent of the various devices' ecosystems and potentially scale across all desktops, laptops, tablets and smartphones.

If the tasks performed by EditEdit are relatively light, HTML5 could be more than adequate.

• Security is a concern when using a Web-based app like EditEdit. It can be hard to establish a secure connection with the Ode filesystem on shared-hosting accounts that don't have their own SSL certificates. Strong passwords are a must. There is an element of "security by obscurity" at work here.

Level of difficulty: High

Description

Commenting for Ode is currently handled with a Disqus addin that integrates the popular hosted commenting platform with the self-hosted Ode system.

A native Ode commenting system -- also integrated via addin -- would either create its own text files, or add to existing post files, via a comment form that would appear at the bottom of individual entries.

Perhaps a native Ode commenting system could interoprate with Disqus, so a blog's Disqus comments could be converted to native Ode comments, and vice versa, like the way Disqus works with WordPress?

Notes and questions

• Is there anything in Blosxom or Pyblosxom that could repurposed for an Ode commenting system?

• Is there anything in the Chronicle Blog Compiler commenting code that could be repurposed for an Ode commenting system?

Level of difficulty: Medium to hard

Description

The latest (as of early 2013) thing for blogging systems is a site that draws its post files from Dropbox via the Dropbox API. The idea is to write posts in a designated folder/directory in your Dropbox and have those files automatically pushed to the web via an external blogging application.

This could seem counterintuitive at first, especially because the two other systems that I know are using Dropbox in this manner -- Calepin and Fargo -- are both hosted services, while Ode is self-hosted.

The potential benefits of creating and delivering posts via Dropbox for Ode are many:

• Write posts in a subfolder of your Dropbox folder and have them appear in your blog on demand (or after a re-indexing by those using the Indexette addin). Creating content is as easy as writing a text file to your local drive. No FTP application is needed.

• Posts are automatically synched across all of your systems using Dropbox and are automatically backed up (though additional backup measures are strongly recommended)

• A single Dropbox subfolder could feed multiple Ode sites. Or multiple subfolders in a single Dropbox account could feed multiple sites. Users could collaborate via shared Dropbox folders. This could simplify document management in potentially complex situations.

• Content is independent of the server hosting the Ode script. Whether this is an actual "benefit" or simply a consequence is open to debate.

Notes and questions

• Would this be implemented as an addin, or a series of modifications to the main Ode script?

• Development of this addin/added feature would depend on what is required by the Dropbox API.

One of the features of the Ode blogging system's links in post titles in the default Logic theme is that they lead not to the individual entry page but to the portion of the page including all of the relevant day's posts that includes the entry whose link is being clicked.

That's a complicated way of saying that the title links look like this:

http://stevenrosenberg.net/blog/2013/06/11/#2013_0611_hostgator

I wanted to see how the blog would work when clicking on the title of a post leads to a page that just includes that individual post itself.

By that, I mean this:

http://stevenrosenberg.net/blog/web_hosting/2013_0611_hostgator

That is the same result you'd get by clicking the Permalink tag at the bottom of each entry.

It was as easy as copying the permalink tag and replacing the original title tag in the page.html file in my current version of Ode's Logic theme.

It's a small change. Not a big deal at all. But it's so easy to do in Ode. Just about every part of the system is a text file that most users can understand and modify. So I figured I'd do it and see how it worked.

Read the rest of this post

I create a text file. Then I push it to the server with FTP.

Without the Indexette addin, that would be it. But since I do use Indexette (which time/date-stamps entries indepenently of the file's own timestamp), I re-index the site via the browser, and the post appears.

Thanks go to Rob Reed, creator of Ode, for coming up with the ShyPosts addin, which allows you to "hide" posts from your blog indexes yet have them available via their permalinks.

You can read about ShyPosts here and in the same place download the addin for your Ode site. The addin itself is small, and the instructions are short. For the most part they work, but I needed to refer to this forum post to figure out how to write a "rule" that lets ShyPosts know what to hide. If anything, the shyness_rules file is a great place to get a little practice in writing regular expressions.

Read the rest of this post

I've been changing my Ode body type settings over the past few days. I've switched fonts, sizes and line height.

I did take some inspiration from Rob Reed's Ode blog, especially on the line-height property in the css.

While I liked the Carme font I pulled from Google, it looked better on some devices (newer iPod Touch, systems running Linux) than others (older iPad, systems running Windows), and I wasn't crazy about the noticeable delay in text showing up on the screen while the client device pulled the font from Google.

So I went with Helvetica Neue, though I also like Arial and Verdana. Even plain sans-serif looks good. I might keep switching things up.

I still haven't yanked the Droid Sans Mono font I pulled from Google for code blocks. Since the rest of the type shows up on the page without delay, I don't think a late-blooming code font is much of a distraction. And I really like Droid Sans Mono.

The body type font size has been changing day to day. I went from 14px to 12px and now 13px.

I bumped the post headline font up six pixels to 22px. I could go bigger. I could go bold. Not just yet.

I spent much of yesterday fighting with WordPress to make it do what I want. Not having unfettered (or any) FTP access to the server didn't help.

Today I had a problem (caused by a previous experimental change) with my Ode site's RSS and fixed it in about two minutes. Before I started, I forked the theme by copying and re-dating its directory so I had a full backup. Then I removed the problematic line of code, and everything was as it should be.

Understanding how it works makes it easier to fix, modify, experiment and not lose your data in the process.

I'm not saying WordPress isn't a great system, but the simplicity of Ode is one of its strongest assets. Anything you know about HTML, CSS and Linux/Unix will help you. And Ode can help you learn about those things. Then you can apply that newfound knowledge directly to the rest of your work.