I've been thinking for a couple weeks about a series of posts called "The Wrong Tool For The Job" where I pick a tool that is arguably the wrong tool for a particular job, then build a proof of concept where the wrong tool is actually working to do the job. It's supposed to be funny. And educational.
I was messing around with Ruby, which is a much better language then I ever gave it credit for! My excuse is that, as a Python programmer, I already knew a language that filled Ruby's niche just fine. If I was going to learn another language, it should either be lower level like Go or a different paradigm altogether, like Haskell or Scala.
This is part of a 2 part series. You can find the first article here.
While examining our hosting costs, I discovered that we were hosting one customer on Heroku and it cost us a lot of money. The customer we were hosting was a medium-sized CMS site and we had a (relatively) twelve-factor compatible internal hosting environment that the site could be deployed to. You can read about twelve-factor here.
We need a way to determine "routes" and "flows" for messages. Right now, we define a "route" to a "page" that allows an upgrade to Web Sockets, but there is no way to define more complicated protocols. Is it even necessary to allow them to be defined? Right now, we pretty much accept the message, check the message type, then if we are smart, we dump the message into a method that processes it.
Hurray! Comments are live. Here's the simple version of what I did:
Here I am, a guy with a statically generated blog, trying to add comments. I've already added a contact page that just goes to google docs, though you wouldn't know it's google docs just to look.
So this is probably the 4th or 5th iteration of the site. For a while it was a custom rig running Django, then a Wordpress, then a Tumblr. Now I'm using Jekyll. My old Wordpress posts (probably the best posts) are probably gone forever, but it's OK! I only had some processing workbooks posted, and they all needed the Java plug-in anyways. They'd be all but unviewable in 2013, the age of Java security updates.