In the past I’ve used Textile markup for this blog, processed by the RedCloth gem. It has done (and continues to do) a good job.
However, it seems the trend is toward Markdown. GitHub, StackExchange, and others have all embraced it. A new project I’m working on will also be using Markdown.
It seemed like it was time to move to Markdown here on the blog too.
There are a number of gems capable of processing Markdown. However, one of the most extensive appears to be redcarpet. It has baked-in support for most of GFM (GitHub-flavored Markdown), which is a bonus.
Going forward, all posts will be rendered accordingly. As a bonus, GFM’s fenced-code-blocks are much cleaner than what I had hacked in previously, so there should be fewer weird-syntax-highlighting issues. I don’t plan on going back to cleanup the old posts though.
Oh, and comments now enjoy Markdown too! Yay!
As an aside, way back I discussed syntax highlighting in rails. My current gem of choice is coderay. Most of the options are just Ruby wrappers for the Python-based pygments. That’s a viable solution, but if you want to keep it Ruby-native, then coderay is a nice alternative.
One of my long running habits when dealing with databases has been to use transactions. Transactions simplify handling errors in complex, multi-record operations.
More recently, I’ve been using transactions to wrap external API calls that I also need to store data about. External APIs fail. For that matter, internal APIs fail too, so let’s simplify that: APIs fail. Sometimes for no good reason.
Accordingly, it’s necessary to be able to fail gracefully in the face of such circumstances. Failing gracefully includes not only rendering meaningful error messages, but also not leaving local data in an unexpected state.
Transactions provide a simple, clean way to resolve this issue too. And they seem all but indispensable when combining multi-record operations with APIs.
Lately I’ve been doing more work with NoSQL databases. They’re fantastic for certain use cases. But the near universal lack of transaction support is annoying at best.
So now the challenge is how to work around the overall issue and provide as robust an experience as possible within the local app.
Once again it has become time to refresh the site design. Looking back, it appears the last site refresh was in July of 2007—I’m not sure if 5 years on the same design demonstrates longevity and consistency, or if it just means I’m horribly overdue.
Regardless, now everything is nice and shiny. One of the goals of the new design was to do my best to leverage HTML5 and CSS3, including new HTML5 tags and use of many of the newer CSS features. As a consequence, the only image file is the background. Everything else is CSS effects along with a couple CSS fonts.
I also used the refresh as an excuse to experiment with responsive design. I haven’t had a chance to test a wide array of small-screen devices yet, but on the ones I have access to (various iDevices), the site is usable. I’d love to hear your experience, good or bad, on any kind of smaller-screen device.
Other changes include numerous updates to the software stack (Rails 3.2, etc.), better syntax highlighting (now with line numbers!), and improved (in theory) spam filtering.
It’s clearly time that I catch up with the world around me. It’s curious how much can pass you by while you’re consumed with other priorities. Now that some of those have passed, I’m rediscovering several things that got pushed aside.
Among them is hopefully writing at least a little more often here. Apparently, that won’t be a difficult bar to jump over—it’s been 2 1/2 years since my last post. Ack!
Apart from writing here, the process of catching up looks like it will include a bunch of software upgrades (Rails 3 a part of that), a new design for here, and migrating a bunch of stuff to git.