Jekyll & Microblogging

I’ve been following Manton Reece’s blog and his development of a microblogging service. The first thing that caught my attention was when he discussed supporting webmentions.

Today he outline he is building on top of Jekyll. One interesting thing is that he’s adding XML-RPC. Considering my recent advances in implementing micropub here, I guess I was secretly hoping that was something he was baking into his new platform and MarsEdit was going to add it. Maybe in the future. Regardless of the technology, I’m excited for another platform that gives people the opportunity to own their voice and step out of the feed lots of the corporate web.

Speaking of micropub and Jekyll, Pelle released his project today. It’s still in early development, and requires deploying to Heroku, but is what I’m using here. My goals now are to add support to my Jekyll-IndieWeb project and help document setting it up.

All in all, I’m bullish on Jekyll, and hope these advances and the addition of theme gems in 3.2 continue to broaden the appeal of the platform. Perhaps to the point I could find work developing and supporting it. But that is for another post.

Forking Paths

In no small part I started down the path of rebooting my personal site employing the tenets of IndieWeb principles because I read about it on Jeremy Keith’s weblog adactio. It took some time to come to fruition, with lots of starts and sputters, and I still have itches to scratch.

I wasn’t surprised then when I read his post from his recent talk . He does a superb job of starting from the beginning of the web and coming full circle to where we are today with “walled gardens” and how we do not have to lock ourselves into them.

I would like us all to spend more time in the garden of forking paths. I would like us all to continue to grow this garden of forking paths. Add your own website to this garden of forking paths. Use it to make more links.
Jeremy Keith

Losing Steam

I had built a pretty good habit of writing and using the blog as my primary source of commentary, but a glitch (I think, which this post is partly to debug said issue) slowed me down using micropub, the holy grail of being able to post first here and syndicate to social media. Coupled with the easy trap of using Twitter, and here I am.

This is my personal reminder the work I put into this site is about owning my voice and words, and to find the time to reduce the friction to do so. Also, to share that experience so that others can do the same.

Plans for Jekyll IndieWeb Project

I started a project soon after I began embracing the IndieWeb for the Jekyll platform, Jekyll IndieWeb (A less than inspiring project name I’m afraid to say.) My initial goals were to have a framework for myself that was fully microformats 2 compliant to build my own site off of and to share a starting point for anyone new to having their own website and wanting to embrace IndieWeb themselves.

So far I know of one person who is using it, which is encouragement enough to continue looking at ways to improve it. In the upcoming release of Jekyll, themes will be supported. While considered a minor enhancement, I think its a major milestone for Jekyll. Previously, there was no simple way to change the look and feel of your site without manually copying files into your install. Most theme projects are packaged as standalone Jekyll builds.

So that said, my plan moving forward to is to package the microformated theme, complete with the same config options as a Gem under the name “Crier” (as in town crier. Not sure it’s anymore imaginative than the original project.) The original GitHub project will switch to the Gem once the new version is released, but will stay as a standalone Jekyll install for anyone who wants to get started from scratch. Also, Tom began working implementing a webmention gem for sending while at IndieWeb Summit 2016. With the help of Bear in the IndieWeb community, I hope to have a tutorial and example of using continuous integration to build and deploy a site back to GitHub allowing the sending of webmentions along with the already supported receiving.

I would love to hear from anyone else interested in the project or using it, and what else you would like to see. Long term goal is micropub support.

One Simple WWDC Wish: The Font

My feed reader and Twitter timeline are full of posts with wish lists for next week’s Apple World Wide Developer conference. Siri this, iOS 10 that. And I’m sure some of the ideas are great and I’ll be happy when they are at my disposal.

But all I want is for Apple to include the font from the WWDC web site. When the site launched, it took me some time to realize the page is a giant image. A simple monospaced font on a background you’d find in a terminal or code editor app. It’s beautiful and I want it for my own.

WWDC screenshot

IndieWeb Summit 2016

This weekend is the 2016 IndieWeb Summit in Portland Oregon. I would have loved to attend in person, but a cross country flight wasn’t in the cards. Fortunately, the organizers have long had plans in place to accommodate remote attendance by providing live video feeds of demonstrations as well as covering a couple of the breakout sessions on Saturday. IWC also has a robust IRC channel which will facilitate participation on build day.

My primary goals beyond furthering my understanding of the technologies behind the IndieWeb is to switch back to for receiving webmentions. Aaron Gustafson updated his Jekyll plugin and I like the idea of cached mentions as well as the idea of using progressive enhancement in displaying them. This will entail taking the mentions from the current tool and formatting them to match Aaron’s cache file.

Secondly, I want to wrap my head around syndicating from micropub and begin to use it more. I believe there is a workflow out there, I just need to fully understand how to wire them all the bits together. If time permits, also in the micropub realm, I want to get mobile publishing set up.

GitHub is My View Source

When I first started learning web development in earnest, (beyond basic HTML), the community college I was attending was still teaching Dreamweaver as de facto method of building a site and using Photoshop and tables based layouts. Meanwhile I had launched my first blog with WordPress, fresh off the 1.5 release that brought full themes, XHTML and CSS. Reading blog posts on the subjects was basically the way I learned those skills. And viewing the page source of the authors writing those posts.

Fast forward to 2016, and I still view source. More often than not now, I’m learning from GitHub repositories. Which is why finding the Octotree browser plugin was such a find. Rather than having to navigate back and forth inside a repo, you get a tree view of the files to the left of the browser window. If you find your self using the back button and navigating breadcrumbs, I highly recommend checking it out.

Couch to 5k – Day 3 Week 1

First week (well, 3 runs) in the book. Lesson learned today is take the little twinges of discomfort serious. I had minor discomfort in my right ankle but pushed through, and am now feeling that I was compensating for it. I may need to wait until Friday to start the next week, but that’s to be determined. Consider me day-to-day on the injury report.

The other take away from today was, despite being a native Floridian, it’s easy to forget the seriousness humidity contributes to the feels like temperature. I may want to start timing my runs for morning, or later in the evening (though the summer weather patterns might not play nice with evening runs in general.)


  • Distance: 1.75 mi
  • Pace: 11:29 min/mi

Couch to 5k – Day 2 Week 1

This evening I completed day 2 of the first week of couch to 5k. As exhilarating as day one was, I was equally sore the next day. Though I try to walk a little every day, there are muscles you use to jog that don’t come into play walking. That said, I wasn’t deterred, and today was my planned day 2. The schedule is 3 days a week for the first 3 weeks at least, I didn’t look beyond that.

One thing I did learn from day one was to not push the jog too hard to start, and was able to pace myself a bit better today. I also tried to zig-zag around the neighborhood rather than do laps around the small park near my house. The laps felt a bit too monotonous, as I was checking the app to gauge progress. Snaking through the neighborhood didn’t feel that way. It may have slowed me a bit as I didn’t have a route planned, but the app maps the run so I can check back and have a clearer idea of what would be a good loop. Speaking of, on my geek side, I’m looking at ways to export the .gpx file and create a static map of the run and post with these posts, much like the static map I created with my Instagram photos.


  • Distance: 1.69 miles
  • Pace: 11:46 min/mi

Extraneous Whitespace in Jekyll HTML

One artifact of Jekyll that has bothered me is the redundant blank lines in the rendered HTML. In my case, I was seeing hundreds of blank lines creating the page navigation at the top of the page. It doesn’t affect what the visitor sees, but for developers who use Jekyll poor source is a bad practice. Also imagine someone new to Jekyll and HTML in general trying to view source to debug an issue. Turns out the problem is with the Liquid template language Jekyll uses. Seems the Liquid community have been discussing the issue for 3 years without a solution.

My first approach to solving this was to use a Ruby gem HTML Beautifier. It works great, but for a site like mine with over 500 posts with a lot of tag pages, it increases the build time exponentially. To the point I’ve seen Travis time out due to the long process. Today I went looking for another solution and stumbled upon this gist – remove empty lines. It concerned me the plugin would increase the build time in Jekyll vs in Travis, but was pleasantly surprised it added no noticeable overhead and produces much cleaner HTML output.

Now I get quick build times and cleaner source.

Housekeeping May 2016

Figure for my own reference I should document the updates I’ve made to the site the last month.

I’ve written before that my primary goal with the reboot of this site is to embrace IndieWeb. The first step was receiving webmentions, then sending them. Also in the process I, started an indiewebified Jekyll theme (which I’m using on this site at the time of writing.) Part of that was to have better microformats in the markup.

The big itch that I wanted to scratch was implementing micropub to free myself from Twitter (something I’ve failed at thus far). With the help of Pelle Wessman who shared n bit of yet to be public “glue” to pull together his other tools, I set up my own micropub endpoint on a Heroku.1 I still need to workout adding a syndication endpoint for Twitter so I can auto-tweet notes, but that is coming.

Once that was in place, I was able to use the tools Aaron Perecki built, Quill and OwnYourGram. Quill is a web based micropub publishing app, and OwnYourGram is a service that helps you PESOS your Instagram photos to your own site2.

A lot of the experiments I’ve been doing here might be overkill for a simple blog, but are great ways to expose myself to new technologies. I’ve long had an Amazon Web Services s3 bucket set up as a CDN, but had never found a workflow to efficiently use it. With the my current build/deploy process with Travis, a copy of the Instagram photo is saved to my GitHub repository via micropub. In the build script, the image is copied to the s3 bucket, then linked to the CDN.

The primary reason to use the CDN was I went through the steps to get 100% on Google Pagespeed (last I checked). Since the site is primarily text and is already static it ranked pretty well, but I went ahead and configured loading critical CSS3. (I had set that up with my old Habari theme, but Google’s added a step to async load the remaining CSS). I also had to tweak caching in nginx, which while I was in there, I went ahead and set up http/2. The primary reason I moved back from GitHub pages to my VPS was to serve the site over https with a free LetsEncrypt SSL certificate.

Finally, I went back and forth on analytics. I don’t need them, but it’s nice to see what visitors are looking for and at. I poked around at some self hosted options, ultimately decided for now that for the people who don’t want to share data with Google, there are browser tools to block sending the data, which I’m OK with, therefore using GA here isn’t forcing anyone into it.

I still want to do a fresh design, but only after last few kinks in Jekyll-IndieWeb theme are fixed. I’ll still use the markup as the foundation, just present it differently. As always, if you have any questions, hit me on Twitter @miklb or leave a webmention and I’ll do my best to reply.

  1. Which was my first experience with both Heroku as well as a node app.
  2. Instagram has locked you out of pushing your images from your own site to Instagram.
  3. The command line tool in Filament Group’s CriticalCSS tool made that pretty trivial.

Free Resource: Combining Type

One of the few design skills I would truly like to fully understand and be able to employ in my work is the ability to choose and use type properly. Tonight I stumbled upon a post on the TypeKit blog sharing a pdf of a previously for sale book on the subject. While it is unfortunate that publisher didn’t succeed, it is generous of the author to share it with the public. Head over to the blog to get a digital copy of Pocket Guide to Combining Typefaces. If you have other resources, please send them my way.

Organizing Jekyll Posts

Until last night, I was under the impression you had to store all of your posts as markdown files in a single directory called _posts unless you changed that in your _config.yml file (and even then, my assumption was it was still a single directory.) That said, I still sought out whether there was a way to organize them by at least year within that single folder. I’ve been blogging for 11 years this spring, and while sporadic at times, that is still a lot of posts. When I need to reference a new one, or look for something from the past, having them by year would be nice.

tl;dr yes, you can arbitrarily organize under the _posts folder however you want. All Jekyll looks for are markdown files with FrontMatter.

What I also learned, and isn’t well documented 1 is that you can create top level folders each with their own _posts sub-folder and Jekyll will read from each one, appending that folder name to the generated url for the post, i.e. a folder foo with _posts with 2016-04-26-post-title would yield a URL of (varying by your permalink structure). Those top level folders are then treated as categories, allowing for more filtration within your templates and site organization. I can see other ways of using them, especially as I continue to move towards a more Indieweb way of doing things and more tweets originating from this site.

I intend to contribute my discoveries to the official documentation as soon as I can.

  1. Hint: it’s hidden under page.categories