Stop Being Lazy and Learn Haml… or another Templating Engine

The desire to write familiar view code, similar to the same html you were writing to support your shitty LAMP apps is completely understandable but it’s time to move on from the glory days..

There seems to be this idea that using erb is “good enough” in all scenarios because so many of web devs are accustomed to seeing their old friend html.. As someone who knowingly opted out of using Haml because HTML always felt like option that would give me the most flexibility. Since the actual engine driving the browser has a simple set of responsibilites (MASSIVE OVERSIMPLIFICATION: fetch a document from a URL and render the contents of that document onto the page) the document that we are going to be providing to the browser’s engine must adhere to standards that allow many browsers to function with their various implementations. Because of this fact debugging/learning a templating engine is actually a walk in the park if your HTML skills are as sharp as they should be..

To be fair; when researching Haml it may not be clear what you are getting yourself into.

<section class=”container”>
  <h1><%= post.title %></h1>
  <h2><%= post.subtitle %></h2>
  <div class=”content”>
    <%= post.content %>

To be honest the above code doesn’t look to be that bad to me but I’ve never really had an “eye for design”. As an additional bonus I know exactly what the browser output is going to be (assuming no CSS + JS messing with things). But let’s take a look at some haml code..

  %h1= post.title
  %h2= post.subtitle
      = post.content

The raw number of keystrokes should be striking to get the same browser output. The declarative simplicity that Haml provides is unbelievable when you consider all the bullshit we deal with when writing HTML. Anyone who written web apps can tell you at least one tail of a missing closed tag.

I was hesitant about writing something that wasn’t what I knew and used for a long time. The notion of “what works for me” is not a good enough reason to write code that is sub par. Since most devs are bright enough folk I don’t think learning Haml is more than a 1 micro-project away from being your new favorite way to write your views.

For more information on Haml check out the Haml Homepage. All links to get started should be easily accessible from there.

The beauty of using haml in every day development is that your code shape will be forced to be much nicer and cleaner. Consider writing a container div with a header, body, and footer. One would hope for clear structure that tells a “foreign eye” exactly what is going on in the given view.

Just imagine the skeleton that would evolve in the html version of this as a clean slate to start from.

<div class="container">
    <div class="header"></div>

    <div class="content">
    </div> <!-- end of content -->

    <div class="footer"><%= render "footer" %></div>

</div> <!-- end container -->

As anything gets added to this skeleton you hope that the structure stays readable. I think that the forced structure prevents you from being your own worst enemy . Because of this simple fact I am turning into a Haml guy and think a weekend using it will convert any non-believers.

Posted in Development, Rails, Ruby, Sinatra, Web Applications | Leave a comment

Thoughts on Heroku

After deploying over 10 applications with Heroku I think that I can finally make a fair assessment on the general developer / Heroku relationship.

After watching an excellent talk by Matz at Waza (link at the bottom) I was taken aback by how much he seemed to respect Heroku’s ability to support the developer that wants to build. Heroku’s use of AWS to anyone to standup a system to run their code at no cost is an absolutely stunning accomplishment .

My skepticism with this idealistic view is that at the end of the day Heroku is a business that needs to make money. But they also need to keep their image and offer the “playground” to build and prototype without needing a budget.

During the talk Matz mentions this ability to spin up a prototype at no cost which as being something fundamentally new and exciting. Having this ability eliminates a the large risk of money puts people in a new age; one where there is no barrier of hardware costs preventing concepts to come to life.

Heroku as a company proves that hardware is cheap and that it is feasible to remove the hardware barrier that used to exist less than 10 years ago(someone tell me if I’m wrong, I was 13 and it was too expensive for me). For developers that like to build things from the ground up Heroku is a wonderful tool that should be utilized to its fullest for as long as you can use it for free.

I am not sure about the exact price model of Heroku’s production ready systems are but I think that it becomes clear pretty quickly that if you are building to grow and scale Heroku may not be the best option.

I will use a real world example of a small sinatra app that is currently hosted on Heroku for the steep price of $0.

I have 1 Dyno with 512 MB of RAM that likes to shut off when it becomes inactive for a certain period of time (smart on Heroku’s part for sure to keep costs down), 1 MongoHQ instance with 512 MB of storage (they call it sandbox mode so this is an expectedly low amount of storage).

When upgrading from the Standard (free) dyno it would cost me $34.50 to essentially double my computer power and have a cycling set of dynos that will work together as a failsafe mechanism. I have just recently started crashing dynos and am thinking that it would be nice to have a backup that is reliable without having to do any system work to setup proper restarting and recovery (no god debugging for me sounds pretty sweet).

For any additional storage I would be paying around $18 per GB of SSD storage hosted through MongoHQ (of course an Amazon service wrapped in an add-on pricing model). I am not sure what the going rate for a mongoDB hosted solution but that seems a bit pricey to me if you are going to do large lazy data storage like I have been enjoying. But to be fair that could easily be moved to another database since in reality it’s just a minor detail.

When laying out the costs to double the performance of my small application it would be ~$52 a month. TBH that isn’t a horrible price for no extra work scaling. I am curious what the minimal cost of this setup would be on AWS directly (I do know that if you want to run tests on postgres instances it will cost you a pretty penny at the end of the month).


Matz at Heroku’s Waza (2013)

Posted in Development, Heroku, Web Applications | Leave a comment