After making the move to Jekyll, one thing I lost was the ability to generate machine-readable representations of content. That may sound trivial, but it’s actually not considering the RESTful direction we’re heading, and is crucial if you want to manipulate content on the front-end (e.g., Backbone ). The idea being, for any post or page, if you simply replace the final
.json, you should get an API.
I had previously written a short Jekyll plugin to generate JSON representations of posts, but GitHub Pages (where this site is hosted), doesn’t allow plugins for security reasons. Enter JekyllBot. JekyllBot lives on a (free) Heroku instance, and following any push to GitHub, silently generates JSON files for each post, pushing the changes back to GitHub. No need to do a thing. This allows you to continue to use web-based editors like Prose, and alleviates the need to ever touch the command line.
How does it work? I added my Heroku instance as a post-receive hook in the repository’s settings page, and have JekyllBot running within Sinatra to listen for the payload. After a push, it simply runs Jekyll (with the plugin), commits to git, and pushes the repo back to GitHub if there are any changes. The secret lies in the JSON generating plugin, which places the resulting files in the source directory (rather than
_site), allowing the files to be tracked by git, and thus silently passed through as static files by GitHub’s Pages servers when the site is built.
With a little customization, there’s no reason this process couldn’t work with most Jekyll plugins (e.g., sitemaps, tag archives), allowing GitHub pages to support much more robust Jekyll implementations from within their existing security restrictions. Feel free to give JekyllBot a try on your own site, or simply add
.json to the URL above to see it in action.
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →