I've just added the Script.aculo.us AJAX.InPlaceEditor for the administrative backend of Rage. Now I can edit messages in place as I view them. Title, body, and tags. Neat.

I love Rails and AJAX.

Rage, my Rails based bloxsom replacement, is production ready. This is a test article publish using the new interface.

I'm finishing up the final import script now. Rage should be installed production shortly...

Weee!

Instead of separating the comments and trackbacks in Rage, I've merged them together. The "0 trackbacks" link at the bottom of any article display will dynamically open a form for entering a "manual trackback", AJAX style.

This unification of code should simplify things a bit for now. Eventually, a threaded comment system might be fun to implement in addition to trackbacks.

So very close. Almost there.

I've been working on "Rage", a Rails replacement for my blog. The function is identical from a URL perspective thanks to some creative Rails routes.

Rails likes to have URLs consisting of a /:controller/:action/:id style scheme by default. Thankfully, this is configurable using "routes".

Bloxsom uses a file path with a "flavor" extension that tells how to render a given node.

Rather than keep with a "path", Rage converts the path into a set of tags, and keeps a record of the "file" component (think of it as a node name), while processing requests to handle the flavor extension as a case statement for alternative renderings of the same article.

By doing this, my new blog will appear initially to be identical to the previous blogging engine. All indexed pages and bookmarks people may have to my blog will continue to function.

As a side-effect, tag searches of articles are as simple as stacking them into the URL path (think "TagFS" as I blogged about earlier, and you'll get what I'm talking about).

http://ian.blenke.com/software/linux/

Will return a list of articles containing the tags "software" and "linux". Order does not matter.

Additionally, I've added routes to handle the /YYYY/MM/DD/ style archives, as well as the taged paths. For example, to find all "software" and "linux" tagged articles I posted in 2004, you could use:

http://ian.blenke.com/2004/software/linux/

Neat stuff.

There will be a search function to do tag/title/body searches as well (though it is a bit slower as it is a de-dup'ed result set of a few SQL queries). The search function is currently AJAXed to have auto-text-field completion based on the tags of all articles (it updates the list of tags as you type). Rather than throw away the above tagfs goodness, the plan is to work it in:

http://ian.blenke.com/search/tagfs/goodness/

would search for the exact string "tagfs goodness" just as this would:

http://ian.blenke.com/search/tagfs%20goodness/

I've added a few new flavors to handle RSS 0.91, RSS 1.0, RSS 2.0, and ATOM 1.0 feeds:

http://ian.blenke.com/index.rss
http://ian.blenke.com/index.rss1
http://ian.blenke.com/index.rss2
http://ian.blenke.com/index.atom

These flavors can be used with the above paths as well:

http://ian.blenke.com/linux/software/index.atom

If you only want to read articles from my blog about linux software, that would generate a feed just for you.

There are also 4 new paths for the same that use a more Rails-ish schema:

http://ian.blenke.com/blog/rss/0.91
http://ian.blenke.com/blog/rss/1.0
http://ian.blenke.com/blog/rss/2.0
http://ian.blenke.com/blog/atom/1.0

You can add tags after those paths to limit the feeds:

http://ian.blenke.com/blog/atom/1.0/linux/software/

which is functionally equivalent to:

http://ian.blenke.com/linux/software/index.atom

The big problem with overloading the paths this way is that you get potentially unwanted behaviors for tag searches if you happen upon the exact sequence of tags that happen to trigger the rails action to handle one of the above requests.

The /blog/ path is a leftover side-effect of running bloxsom dynamically for a while using that URL, and using pre-generated static content for the root (/) content. That experiment caused more headaches than it solved (static content loaded quickly, but there are real issues with a number of the bloxsom plugins I was using when generating the static content). Rather than toss it out entirely, I've added rails routing to handle /blog/ prefixed requests in parallel to the root requests.

The moral of the story: Rails routes can do just about any URL schema you can think of with some clever planning.

Current status of Rage:

• Migration scripts from the bloxsom tree to the rails models is working. No content will be lost.
• Site content for projects and media are transparently passed through to the public/ tree in the rails project. No need to handle that special case.
• Blog markdown rendering and feeds are 100%.
• Received trackbacks are working perfectly (need to add anti-spam protection)
• AJAXified Comments are currently under development (with anti-spam)
• Posting and sent trackbacks are a nicity for me, and will wait 'til the end ;)
• GUIDs instead of auto_incremented IDs are working perfectly! Next step: get replication working between two engines (one on my laptop, one on my main site - offline posting and blog management using the blog itself.. think of it!)
• Caching: I'm still trying to get expire_fragment to release the cached fragments, but the basics are there to make this a responsive site (much more so than bloxsom)

The best part of this entire endeavor: I now have complete understanding, control, and responsibility for my blog. If it doesn't work, my code is at fault. If something new comes out, I learn by implementing it. Like google's sitemap, which I threw together a solution to in 5 minutes:

http://www.google.com/webmasters/sitemaps

Rails is simply incredible. I hope to have the new site up shortly. You probably won't notice the switch. Stay tuned.