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.

Kevin Stock has written an OS/X applescript for googlevpn as well as bit of basic information on Google Secure Access:

• Google Secure Access uses PPTP
• Login/password/gateway are reported by a request to https://vpn.google.com/getpass/

Which suggest a couple of things to be aware of:

• If you're behind something that blocks GRE, you're not going to use GSA.
• PPTP isn't exactly security nirvana. In fact, I'm not sure how much better it really is than WEP or even WPA for wifi users.

With the schema_generator, you can generate the MySQL/Postgresql/Sqlite schema files from your rails project migrations:

$ gem install schema_generator

then, in your rails project:

$ script/generate schema 
Found 14 migration classes
Starting migration for AddTableUsers
Starting migration for AddTableItems
Starting migration for AddTableFeeds
Starting migration for AddTableTags
Starting migration for AddTableCategories
Starting migration for AddTableRoles
Starting migration for AddTablePermissions
Starting migration for AddTableCollections
Starting migration for AddTableCollectionsFeeds
Starting migration for AddTableFeedsTags
Starting migration for AddTablePermissionsRoles
Starting migration for AddTableRolesUsers
Starting migration for AddTablePosts
Starting migration for AddTableComments
Migrations complete.
  Tables found:   14
  Indexes found:  0
  Records found:  0
        exists  db
        create  db/schema.postgresql.sql
        create  db/schema.mysql.sql
        create  db/schema.sqlite.sql

That is from my current "Rage" project migrations.

Thanks Scott! I'd use Typo myself, but I'm using this opportunity to learn rails from the ground up.

Instead of building your own SQL schemas, you can use ActiveRecord::Migration to handle this in a database agnostic way:

script/generate migration add_table_users

This generates a new db/migrate/1addtable_users.rb script with a basic structure:

class AddTableUsers < ActiveRecord::Migration
  def self.up
  end
  def self.down
  end
end

The "up" method gets called as the schema is updated forward, and the "down" method gets called as the schema is rolled back. Migrations can be used both to create/modify schemas, and to do bulk database updates based on a schema (or other) change.

I'm attempting to use GUIDs rather than auto_incrementing IDs, so here is an example of a structure I'm using:

class AddTableUsers < ActiveRecord::Migration
  def self.up
    create_table :users, :id => false do |table|
      table.column :guid, :string, :limit => 36
      table.column :login, :string
          # This column will contain an MD5 hash.
      table.column :password, :string, :limit => 32
      table.column :email, :string
      table.column :fullname, :string
      table.column :created_at, :datetime
      table.column :modified_at, :datetime
    end
  end

  def self.down
    drop_table :users
  end
end

Now you will still need to edit your config/database.yml to point to the appropriate data sources, and the databases themselves will need to be created (this only creates the database schema, not the database itself):

mysql -e "create database rails_development"
mysql -e "create database rails_test"
mysql -e "create database rails_production"

Once that is out of the way, you can apply the migration to the default environment as defined on your config/environment.rb:

rake migrate

to apply to another environment like production, you can implictly migrate using:

rake environment RAILS_ENV=production migrate

it is also possible to roll back to previuos revisions using VERSION:

rake migrate VERSION=0

Note: an additional table schema_info is created in your database that holds the current migration version applied to that database.

No more fiddling with database schemas directly, use any SQL backend, and keep your test and production databases in sync during each stage. Wonderful!

There are a few others out there talking about a tagging filesystem of sorts, but I haven't seen anyone jump into creating an actual filesystem to this end.

With FiST, it is possible to build a cross-platform stackable filesystem for Linux, Solaris, and BSD.

Rather than wedge this into cornfs, I'm thinking about writing a FiST implementation that can overlay any filesystem.

The goal of TagFS is to build a filesystem that treats files the same, but allows you to "drill down" into a file structure to narrow down the search for any given file. Instead of a heirarchical filesystem with subdirectories of files, the path components become a "tag search".

For example, to find a "blog.rb" source file tagged as "ruby rails blog project", you might use the path:

/myfs/ruby/rails/blog/project/blog.rb

or /myfs/ruby/blog/rails/project/blog.rb

If you were to list the files in /, you would see a list of the tags:

$ ls /myfs/
ruby rails blog project

As you change directory into each sucessive path, the tags listed would narrow down to the remaining tags available for files to be recalled:

$ ls /myfs/ruby/rails
blog project

Any files with the path component tags will also appear in this directory listing. This means that all files appear in the / directory.

There are a few side effects to this idea.

• Tab completion suddenly becomes incredibly useful, as all available tags would be enumerated by your shell.
• "Directory permissions" are nonexistant. In this model, anyone would have the ability to add new tags to any file.

The underlying storage for this filesystem would rely on a single-instance store of every unique file. To do this, we would want to use a hashed store:

$ echo ruby.rb > /myfs/ruby/blog/rails/project/blog.rb

would end up being stored by blog.rb's MD5 sum 3ffc2093a970589830618707f35e41d3, with a anti-hash collision measure of using the SHA1 sum for the actual backend filename 02aad48cd7889d2bccc4c4b3c773c09a95af8986:

/data/tagfs/myfs/store/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986

The reason to break the MD5 sum into words is to limit the directory size to 65k for each subdirectory component. Unix filesystems fall apart with large numbers of entries in directory structures. If it weren't for b-tree structured filesystems like XFS and ReiserFS, I'd want to break them up by octet to limit the entries to 256 per subdirectory.

The tags would be created for each path element, both by tag:

/data/tagfs/myfs/bytag/ruby/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986
/data/tagfs/myfs/bytag/blog/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986
/data/tagfs/myfs/bytag/rails/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986
/data/tagfs/myfs/bytag/project/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986
/data/tagfs/myfs/bytag/ruby.rb/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986

and the reverse, by file:

/data/tagfs/myfs/byfile/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986/ruby
/data/tagfs/myfs/byfile/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986/blog
/data/tagfs/myfs/byfile/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986/rails
/data/tagfs/myfs/byfile/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986/rails
/data/tagfs/myfs/byfile/3ffc/2093/a970/5898/3061/8707/f35e/41d3/02aad48cd7889d2bccc4c4b3c773c09a95af8986/ruby.rb

This is an incredible waste of inodes to be sure. Each file ends up having 1 inode for the actual store, and 18 inodes for each tag!!

When looking for a specific path, TagFS will need to do the following:

For each element of the path given to a file,

• Build a list of all files with that tag ("bytag")

then, narrow down the list using one of two methods:

• Narrow down the previous list of files (with the previous tags), filtered against the list of files with the new tag.

or

• Enumerate the tags for a given file ("byfile") and make sure the given path components exist for each file.

When building a list of files in a path, do the above same stemps, but additionally:

• Enumerate the "byfile" tags for all files that match the path components, building a union set of tags that "remain" (excluding the path components used so far).

Moving/renaming a file will change the tags for a file. Well, create new ones anyway.. should you ever remove tags based on a rename? I don't think so.

Deleting a file will remove the single-instance store for a file, as well as the tags for that file.

Modifying a file will changes its hashes. In this case, we would work out of cache until the file is closed, then do the following:

• Copy the new file from cache to the new file hash store.
  • If the file already exists, we have a collision.
• Create the new tags for the new file hash.
• Remove the old tags for the old file hash.
• Remove the old file store by old hash.

Permissions are a toughie. I don't see how to accomplish this with the above scheme.

Last but not least: hardlinked single instance stores behave differently than users are accustomed. When you modify a file so that it "becomes" another file (a hash collision of sorts), that file suddenly inherits the tags of the previous file. More importantly, both files "become" the same file - users may unwittingly modify another file accidentlly, just because both files have exactly the same contents. In a heirarchical filesystem, those files would be protected from one another. It is possible to "de-dup" a heirarchical filesystem using hardlinks to tie identical files together in different trees (this is a wonderful thing for backups, for example - dirvish uses rsync's --link-dest to this end) - however there are real concerns with backups being corrupted if a user were to modify one of the hardlinked files (all other backup trees would then have the modified file).

This is just an initial brainstorm, but I think this has some real uses as a cornfs overlay.

More to come...

The acts_as_taggable mixin makes tagging a trivial addon to any Rails project.

Virtuozzo has gone opensource:

OpenVZ.org

Redhanded has whipped out a RailsFS in a couple of minutes while beginning to play with FUSE... beat me to it, damn ;)

This is what we're looking to do with an internal project (of sorts).. migrating from a directory config structure to a relational object model for future Rails development.

The question is wether to:

• Expose a FUSE/WEBDAV filesystem of the "new" relational ActiveRecord and make it replace the existing directory config structure for scripts.
• Throw an ActionModel overtop the existing directory config structure.

The former seems better for a number of reasons.

Glad I'm not the only one looking for this. There is some debate about replacing the autoincrementing primary keys in Rails with GUID/UUIDs.

With this, I should be able to make my blogging engine distributed - offline postings from my laptop while on the road synchronizing with the main site when I come back online. This would negate my primary reason for using a filesystem based blogging engine like blosxom.

If you're a Rails developer who hasn't bought a copy of Agile Programming with Rails yet, I strongly suggest you do. It's a wonderful book! Just starting to really dig into it myself.

A great RSS2 rxml template from code snippets from blinksale.com.

Getting Ruby on Rails working on my powerbook, I ran into the need to install mysql. Why not get the latest version directly from Mysql, I thought. So I did:

mysql-standard-4.1.14-apple-darwin8.2.0-powerpc.dmg

Run through the installer, and it puts mysql into /usr/local/mysql/, and follow the install documentation:

Mac OS/X Installation

Once you have MySQL up and running, and in your StartupItems, the next fun bit is talking to it.

Unfortunately, all of the client GUIs like CocoaMysql I found do NOT work with 4.1, they're linked with 3.x system client libraries. Gah. I'm much more fond of phpMySQL anyway. Unfortunately, php 4.3.11 as installed under OS/X 10.4.2 by default is linked with that 3.x client library and will NOT connect to the running MySQL 4.1 server.

The solution? Why rebuild php from source, of course! The first step was finding the command line used to build the default OS/X libphp4.so. With a simple phpinfo() call, it becomes immediately apparent:

'/SourceCache/apache_mod_php/apache_mod_php-18/php/configure' \
'--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' \
'--with-apxs' '--with-ldap=/usr' '--with-kerberos=/usr' \
'--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' \
'--with-xml' '--enable-exif' '--enable-ftp' '--enable-mbstring' \
'--enable-mbregex' '--enable-dbx' '--enable-sockets' \
'--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' \
'--sysconfdir=/private/etc'

Now I know nothing of the Darwin build environment, or how /SourceCache/ is built, but I do know where to grab the Darwin source tarballs

The source for Darwin 8.2 corresponds directly to the source for 10.4.2, so I grab the tarball:

mkdir -p /SourceCache/apache_mod_php/apache_mod_php-18/php
cd /SourceCache/apache_mod_php/apache_mod_php-18/php
curl -O http://www.opensource.apple.com/darwinsource/tarballs/other/apache_mod_perl-10.tar.gz

Step two: make the path and extract the tarball:

Step three: build php 4.3.11 with the same flags as before, and add the newer mysql path of /usr/local/mysql for the newer client libraries:

'/SourceCache/apache_mod_php/apache_mod_php-18/php/configure' \
'--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' \
'--with-apxs' '--with-ldap=/usr' '--with-kerberos=/usr' \
'--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' \
'--with-xml' '--enable-exif' '--enable-ftp' '--enable-mbstring' \
'--enable-mbregex' '--enable-dbx' '--enable-sockets' \
'--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' \
'--sysconfdir=/private/etc' --with-mysql=/usr/local/mysql && 
make && make install

Now check your phpinfo() call. The mysql client library now uses that 4.1 version that allows phpMySQL to work.

You know, there might be an easier way than all of this. But it works just fine for me.

This is precisely the kind of thing that Microsoft will never get. Build from source. From the vendor. Directly. Apple largely gets it. Sun is starting to. Here's to hoping they keep the faith.

FUSE has been merked into the 2.6.14 vanilla kernel tree. Yay!

Much like TinyMCE, FCKeditor is yet another JavaScript WYSIWYG editor that integrates with any webpage.

Step 4 - Create your Ruby on Rails project with the rails command:

rails myproject

Step 5 - Start a WEBrick web server instance:

cd myproject
ruby script\server

Step 6 - Open a browser to the page:

http://127.0.0.1:3000

You are now running Ruby on Rails!

Step 2. Install Ruby Gems

# wget http://rubyforge.org/frs/download.php/3700/rubygems-0.8.10.tgz
# tar xvzf rubygems-0.8.10.tgz
# cd rubygems-0.8.10
# ruby setup.rb
# rake

Step 3. Install Rails

# gem install rails
Attempting local installation of 'rails'
Local gem file not found: rails*.gem
Attempting remote installation of 'rails'
Updating Gem source index for: http://gems.rubyforge.org
Install required dependency rake? [Yn]
Install required dependency activesupport? [Yn]
Install required dependency activerecord? [Yn]
Install required dependency actionpack? [Yn]
Install required dependency actionmailer? [Yn]
Install required dependency actionwebservice? [Yn]

Done.

WARNING: I had issues building as root (permissions checks in the rubygem test scripts). If you have problems, try building this as a user.

Step 1. Build ruby.

For recent Debian/Ubuntu/(dpkg) servers, it's as easy as:

# apt-get install ruby

For my Debian webservers, I must backport ruby1.8.

# apt-get source ruby1.8
# apt-get build-dep ruby1.8
# cd ruby1.8-1.8.2/ ; dpkg-buildpackage
# dpkg -i ../ruby*.deb

My old Mac laptop used Fink:

# fink install ruby

My new Mac laptop uses Darwin Ports:

# port install ruby

My home boxes run Gentoo (portage):

# emerge ruby

From another Unix/POSIX box:

# wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.2.tar.gz
# tar xvzf ruby-1.8.2.tar.gz
# cd ruby-1.8.2
# ./configure --prefix=/usr
# make install

That covers every environment I use ;)