cms technical

Content Standards

Current State of CMSs

Most of the stuff on the internet that doesn’t involve transactions fits into a nice generic bucket: Content. Content that is provided by individuals (primarily on social networks and blogs) and then of course, media outlets and companies (primarily websites with supporting social media presence).

The market for providing Content Management Systems (CMS) is a competitive landscape that includes titans such as Adobe and Oracle. However, the market is big enough for a ton of players, especially for the SMBs (Joomla, Drupal and Alfresco to name a few…).

Unfortunately, everybody does stuff differently and switching between systems is a nightmare for all.

Standardize The Chaos!

Creating standards across all of these platforms would ease the data migration and alleviate vendor lock-in. There are two standards that have been developed to address these issues:

  1. Java Content Repository (JCR) (based on JSR-170) with Apache JackRabbit as its reference implementation
  2. Content Management Interoperability Services with Apache Chemistry as its reference implementation

JCR has been around for longer but wasn’t able to get the job done (partially due to politics within the steering committee and the spec’s tight coupling to a specific language: Java). CMIS addresses the issues better and aims to tackle the same issue of interoperability.

Hurray! Mission Accomplished!

Not so fast! If you take a look at the CMIS adopters, there are a lot of significant players with large market shares that are missing from the list.

If they already have a loyal customer base, what value do they get by providing their customers an easy path to migrate off of their systems?

I don’t see CMIS doing what it was meant to do, especially for the larger systems as there may be little incentive to adopt the standard and there is no cross-platform CMS governing body that can require and enforce all providers to adopt a standard.

If anything, customers could be made aware of the specification as the gold standard for interoperability so that they look for it from the get-go instead of as a line item in a complex RFP where interoperability gets a sufficient score for a crappy SOAP service.

ruby technical

Seeing with Ctags

Within all hackery, the road to mastery usually leads you to the nitty gritty low-level implementation details of what you are trying to grasp. Even though there are many books on advanced material, they only get you so far before you find that they are either no longer up-to-date or they don’t cover a particular edge case that is imperative for you.

To the source?! Uhh….

Despite the optimistic battle cry, reading the source code of a complex application/framework/language can be daunting, if not rather dry and immensely boring. Most of it isn’t intended to be read as a book and before you know it, you’re looking for the good parts. Just a specific portion that you’d like to understand instead of all that bloat in place to support stuff you don’t care about.


CTags to the rescue!

CTags will go through and create an index (or tag) file that allows you to search dynamically. I’m assuming that you’re using vim as your text editor – there are flavors for Emacs, etc. that may suite you better.



The easiest way is through homebrew.

brew install ctags


Suppose you’re interested in rails. Grab a copy of the source
git clone git://

Now you want to have ctags index those files but since vim will look for the tags file in the current directory and keep searching one level above, let’s run this command from the user home (or the root directory that contains all of your rails projects)

cd ctags -R ./path/to/rails/source

Add the following lines to your .vimrc file: filetype on set tags=tags;/

Use The Source, Luke!

Fire up a new shell and go over to any rails project. Over a rails method (for example, create_after), hit ctrl+] to see the definition in the source. You can toggle back to where you were before using ctrl+t. Pretty sweet, huh?

There are additional shortcuts to listing matches, etc. that you can see for ctags either through the man pages or online.

Blaze away and learn the underlying framework with ease, one method call at a time.

ruby technical

Rebuilding Rails

It has been a couple of years since I first dove into Ruby on Rails to build some side projects. However, there’s still an awful lot of magic going on with the framework.

With the release of Rails 4, there seems to be even more magic to make everything easier. Unfortunately, I’ve found myself in a tough spot whenever the magic ceases to work for whatever reason.

Look in to the source? Sure, but unless you’re very strong with your ruby, all the elegant, clever code isn’t exactly an easy read.

Turns out the creator of Thin, Marc-André Cournoyer has a class called Owning Rails that has you building “a mini version of rails from scratch”.

A pretty good deal for a little over $500, considering that you also get a copy of his book Create Your Own Programming Language (The starting point for CoffeeScript).

Unfortunately, the class seems to be limited and full, with a waiting list. I liked the idea of building a mini version of rails – luckily, someone else has a similar take on mastering rails.

Rebuilding Rails covers a similar challenge of building your own simpler framework on Rack to understand the internals of Rails. I went ahead and bought the book after going through the free first two chapters.

Understand Rails by Building a Ruby Web Framework

Gulp! Here’s to less magic!


Static Blogs

Static What?

Static blogs are blogs that are composed of just a bunch of HTML files. There’s no magic to it – No databases, WYSIWYG editors, etc. Just a bunch of files sitting on a webserver, waiting for a click or two.

That sounds pretty lame

You’re absolutely correct. Without any engine for the blog, there is no need for dynamic queries to the database. Whoa. There is no longer a need for a database.

Y U No Like Databases?


Well, you see – Databases are in the Spiderman camp. They come with great power but require an even greater responsibility. It’s amazingly simple to screw your infrastructure up without proper upkeep of the database. If you’re not keeping up with the security patches, a nasty exploit could be left open for all the horrible people out there to abuse your system.

But my web servers don’t get patched either

Compared to databases, web servers are simple, uncomplicated and lovable creatures. Sure, there are exploits even for web servers but they are far fewer than the ones out there for databases. If all you do is serve static pages that cannot and should not be modified by anyone, ever – It becomes a rather simple rule to enforce.

Is there any non-database related reason to get a static blog?

Alright, Captain DBA. There actually is: When you take the complexity of a database out, in addition to making the response times significantly faster (by avoiding a call to a data tier), your data becomes static. The beauty of static is that you cache as much as you like without worrying about the validity of the data. Long story short, it makes your site faster. Snappier. Moar Better!

Amazing! Can I pick one up at Walmart?

Unfortunately, not at Walmart. However, there are quite a few options available online. They differ in the language of implementation, how easy/flexible it is to theme, what comes out of the box and community plugins.

The ones that have made this highly vetted list are:

Don’t rush through that long list of two items. Let it soak in. Embrace the knowledge.

Cool tools to write?

One of my favorites is the ability to write in Markdown. On Mac OS X I use Mou to write the articles. Since everything can also be managed within your version repository of choice, I throw a copy of my blog on GitHub. GitHub has formatting for Markdown so it’s actually pretty easy to read posts right on Github. Check it out.

Some engines also provide syntax highlighting of code snippets through Pygments. Get your hack on!

Does this mean that I’m reading this on a static blog?

Why, yes. Yes, you are!


Migrated to in 2017. I still love the idea of static blogs but ultimately, it was too much of a hassle to deal with upkeep and doesn’t have the plugin community of WordPress – 23/2/17