Rain Pattern's Backend

A long story for those interested, but skippable

I started using Drupal a while back and became a big fan of using content management systems. I was even there to donate money when their servers went down and they needed funds to move to new servers. You can find my name in the big thank you image they sent out later. Since then I've been using Drupal for pretty much every personal blog I put up or wanted to play around with different ideas for community websites. Though in every case I had to learn the ins-and-outs of the newest version all over again only to stop updating the site six months later.

In general I realized I wasn't really using the full power and coolness of Drupal anymore. I was not looking to build community websites with lots of stuff going on, I was just trying to build a web presence where I can occasionally put things I feel are worth sharing. I considered branching out to other systems that wouldn't require much boot-up time but realized I don't even like the pretty looking templates all that much. And then I realized why I always had to customize these packages so much and spend all this time to make it work for me-- I didn't want to blog.

I occasionally would imagine me being one of those developers who posted everything they learned online so that others can find out how to write some chunk of code. In the six odd years of having a blog I only did that a handful of times and via emails I learned I did help a few individuals. Which is all great but I'm just really not that into keeping up on posting. Hats off to those that do it so well.

Still I want to share some random tidbits sometimes as well as point out projects in which I'm involved. I do like the notion of having my own house on the Internet and not just rent an apartment in the dorm called Facebook. I like the idea of using PHP and JavaScript to do nifty things, writing well formatted text documents, and pointing out topics meaningful to what I do.

WTF is my problem!?!

It's a funny thing, I do a ton of a requirements gathering and analysis for my job. I'm good at what I do because I understand how to do that and how to think through a system to actually design and engineer and not just write code. Yet at home for very personal things I just assume that using something out-of-the-box will be the easiest and most efficient without much consideration. One evening I just decided to throw away my current Drupal site so that I could start over.

Requirements

  • Use as little infrastructure as necessary
  • Be simple for me to modify data
  • Use standard CSS to display exactly what I want
    • I decided that I wouldn't care if it didn't look right in IE (any version)
  • Be easy to write long formatted posts
  • Be easy to add in new random pages
  • No concern for security (no users besides me)
  • Fast for me to add new posts

User Centered Design

  • It's easier for me to format text in-line versus WYSIWYG
    • An aside: I love using the little nub pointer on my Lenovo. I can go from moving the mouse to typing quickly. I don't get why people love touchpads, they are so hard to use
  • I can upload data using ssh and sftp
  • Eclipse is easier to navigate compared to a web administration panel
  • I am pretty good at remembering syntax

Enter the PHP

Minimizing infrastructure lead me to consider a JavaScript and JSON in flat files only design. The beauty of that would be not needing even a webserver to test the pages. A major downside is that it means a lot of unnecessary data being transferred to the client instead of using the data server side. Another big drawback is that crawlers wouldn't be able to get at the site's content as easily. Finally no data would appear in browsers with JavaScript disabled (accessibility).

Fine, PHP is necessary. Which probably was better anyways because I could then use includes/requires to template out parts of the pages.

<?php require_once('inc/header.php')?>

<div id="main">
  <div id="sub-page-content">
    <div id="post-main">
<?php
if (NULL != $postname) {
  $text = file_get_contents($filename);
  $html = Markdown($text);
  echo $html;
} else {
  echo "<p>No post by that name</p>";
}
?>

Crouching YAML

While using PHP became a necessity I knew I could get away sans database. I'm not planning on having a ton of data on this site, so the efficencies of a database would be non-existant. Furthermore, no database meant no administrative interfaces and no user adminsitration. This lead me to consider hand-written JSON files as my data backend.

JSON is an awesome way to serialize data and transfer it across the 'net but it isn't the easiest thing to write when data gets complex. There's just too many braces, brackets, and quotes. JSON is easy to read and easy to parse but not when done by hand.

I went back to take a look again at YAML. I hadn't done anything with it since I briefly played around with Symfony a couple years ago. Frankly, YAML is not that widespread in the Java community. We like our verbosity apparently, so XML is used for most configuration. After a bit of reading and writing I was sold on using it for any structured data.

posts:
  - title: Lego Model
    file: lego_model
    short: Legos exemplify the idea of a platform.
  - title: Facebook's Platform
    file: facebook
    short: My begrudging praise for Zuck's crap.

A very simple to use YAML parser for PHP:

$yaml = sfYaml::load(dirname(__FILE__).'/posts/posts.yml');

Hidden Markdown

YAML was great for writing out any structured bits of data but it wasn't designed to write long essays. I needed something else and after using Google Code the past year for ARC, I really liked the notion of using wiki notations to format and style my text. Google Code's wiki syntax didn't have much in the way of formatting but WikiMedia and many others were pretty expressive.

Unfortunately many wiki systems assumed that I wanted an entire wiki site. For the most part that was the reason behind wikis is to provide the infrastructure for people to collaboratively write but I just wanted to formatting capabilities. WikiMedia appeared to be the front runner but embedding it outside of their whole framework seemed more work than necessary. The PEAR libraries seemed out-dated and used some of the older, less expressive formats.

I then stumbled upon Markdown and this PHP parser. Markdown has a very full featured syntax that provided a lot out of the box and the use for HTML when required. The PHP parser was easy to include and use.

# heading

* list item 1
    * sub-list
* list item 2

This is a PHP code block:

    $blah = $foo + $bar

And just like YAML, Markdown was easy to parse:

$html = Markdown($text);

Instead of loading Eclipse just to write some text I found Markdown support for GNOME's gedit using this addition

And then to make it look pretty I style it using CSS.

p {
  margin-bottom: 1em;
  text-align: justify;
}

h1, h2, h3, h4 {
  margin: 0.25em 0 0.5em 0;
}

...

ul, ol {
  margin-top: 0.5em;
  margin-bottom: 1em;
}

Going post-al

Now I had my programming language selected as well as the data backend figured out. How do I put those together now to show stuff on a webpage and make it easy to update? Remember that I'm a software developer, I live on command lines and remote connections. Why complicate things with another system to make updates? The simple solution I decided to run with involves dropping my markdown text files into a folder and then adding a little metadata to my YAML "database". The PHP script just reads through the YAML to load into the HTML. Simple and easy.

  1. Write a Markdown text file
  2. Put the text file into my posts folder
  3. Add short description information to a YAML file

I feel that a conclusion should go here

I wrote all this up for a few reasons:

  1. Practice writing and presenting systems is good
  2. Teach a lesson about requirements
  3. Hope someone else wanting to make a simple, yet dynamic website can use these ideas too
  4. Prove that there is a point between the old homepage days and the new CMS / blog one

Basically building a web presence doesn't mean learning a ton of things. A website should convey content, meaning, and information in a pleasing and easily navigable manner. This doesn't mean that everything needs to be stored in complicated systems and then abstracted out to the lowest common denominator. Someone like me can put together a few very cool libraries and focus on writing content and not managing systems. Blogs and their associated frameworks have their place but for me some flat files and modicum of code will do.

source print home