Small Site Update

Posted on July 11, 2014

I’ve been publishing this site with Jekyll for several years. I’m not sure exactly when I switched over from Wordpress, but it’s long enough ago that I’ve forgotten when I started.[1] Over the past few weeks I’ve run into a few issues with Jekyll that have caused me to reevaluate if it was still the right choice for me. The short answer is no, the long answer is that this site is now published with my own Python script.

List of Grievances

Jekyll is popular enough with the geek crowd that there are probably reasonable solutions to everything listed below. However, that would assume that I’m reasonable, which I think we’ve established is not always the case. And besides, something Dr. Drang said the other day has been stuck in my head:

the great advantage of making your own software is that you can customize it to match your own idiosyncrasies.

Thus, 370 lines of Python. On to the motivation to move.

  • Dependencies

Strictly speaking, there are not that many Ruby dependencies for Jekyll, and they are automatically installed when running gem install jekyll. To be able to compile the gems, you need to have either the full Xcode IDE installed, or at a minimum the Xcode command line tools. Not much, still more than I thought necessary to parse text and move files.

  • Lost Pages

One of the ways I used Jekyll was to build an internal site where I work. I use the site to keep coworkers updated with what I’m working on, but more importantly I use the site to publish reports. The reports are kept in a separate “/reports” directory under the site root, and Jekyll used to automatically compile the markdown to HTML in that directory along with the rest of the site. I’m not sure what happened, but at some point the process stopped working, and when I rsync’d my site using the “–delete” flag, all my reports were gone. Luckily, I had a backup so I was able to quickly restore the reports, but once I realized what had happened I had to rethink my “modern living document”. [2] A process I was in the middle of when I encountered the next grievance.

  • Failure to Build Site

Jekyll failed to build my site last week because of a UTF–8 error; it was all I needed to start looking for something else. Apparently there was a special character in the title of one of my posts. Again, this wasn’t anything new, that post must have been built before because I wasn’t building anything new at the time. Something changed, I don’t know what, and troubleshooting this error led me down a Ruby rabbit hole I didn’t want to go down.


I evaluated, and discarded, several options.

  • Wordpress.com
  • Self-Hosted Wordpress
  • Squarespace
  • Ghost
  • Hakyll
  • Hyde
  • Hugo

I briefly looked at a few others, but these were the ones that received the most thought. I considered moving back to Wordpress or another hosting platform, but after looking at pricing and considering how I would feel having my site locked up in a database somewhere on the Internet, I decided against it. I feel the same way about Squarespace and Ghost. What I really wanted was a static blogging engine that would take my markdown formatted Jekyll posts as they were and generate a site from them.

I thought Hakyll looked interesting[3], and I’ve been curious about Haskell for a few years, so I gave it a try. To run Hakyll, you compile a Haskell source file that defines how your site should be built, and then run that executable to build the site. Once installed Hakyll was very fast, but to really use it, you need to dedicate a significant about of time to understanding how Haskell works. I abandoned it because I got to a point where I wanted to modify the default behavior in some small way, and found that the modification was going to be far more complicated than anticipated.

Hyde is Jekyll’s Python twin, but it would not import and build my site, so it got the boot as well.

Hugo looked the most promising, it is very fast, understands Jekyll’s YAML “front matter”, and has a couple of nice themes to start off with. I very nearly decided on Hugo. The developer, Steve Francia even reached out to me on Twitter with an offer to help if I need it. The reason I shied away from Hugo is because it too failed to build the site because of the format of the date string in the front matter. I asked the developer about it, he told me how to fix it, and suggested I try a pull request.[4] I did download Go, the language Hugo is written in, and the Hugo source code, but felt lost on how to get started.

At this point, I decided to rethink my problem. For this site, there is a default HTML template, a post template, and a folder full of markdown files. There is some CSS, and some javascript, and a few images. It’s very simple. What I really needed was a reliable way to compile my markdown to HTML, and insert that HTML into the default template. Some extra code to build the index and atom feed, and that’s about it. It took a couple of days working on it in my spare time, but I now have a very simple Python script that builds my site with no dependencies.

The source code of the script would be of very little use to anyone but me. I’ve taken the approach that the source code is just as much a part of the site as the HTML or javascript. The script reads all of the markdown posts, parses the title and published date, and generates a URL. It then runs the markdown text through Fletcher Penny’s MultiMarkdown, and adds the HTML, URL, date, and title to a dictionary, before building the full HTML page and writing it to disk. The dictionary is then appended to a list.

The list is then sorted later by post date, and the last ten posts are used to build the index page and atom feed. I have separate portions of the code to build the contact page, and the colophon, and my books list.

That the site is now entirely home grown is fantastic. If something doesn’t work, or doesn’t work like I want it to, I can make whatever changes I want. It’s simple and small enough that I can understand the flow of the code, but it still does everything I want it to do. I may later add a few argument options to build, serve, and publish the site, but I’ll get to it when I can.

  1. There was, of course, Paragraphs. I’ve moved on.  ↩

  2. My term for an internal, corporate blog. I maintain it as a way to avoid emailing Word documents and PowerPoint presentations to each other. When someone wants something like that from me, they get a link to an HTML document.  ↩

  3. I realize the irony involved with the many dependencies of Hakyll.  ↩

  4. He called it a “PR”, and I had no idea what he was talking about at first.  ↩

What it Does

Posted on June 10, 2014

Our relationship with technology has become unexpectedly skewed. I was just reading through Sid O’Neill’s recent article, Losing Apple, and found myself nodding along on several points, particularly here:

How did it come to this? Time was I loved poetry, literature, art, music, cheap wine and the smell of an old book. Now my spare moments are spent rubbing glass: from the latest $AAPL share price, to the wildest speculative mockup, to the newest analysis. Levels upon levels of inconsequential meandering in flat prose that I’ve rolled and wrapped myself in like a musty felt blanket till I almost forgot the taste of fresh air.

I have watched the WWDC, and I was excited when all the new fancy was revealed, but a couple of days later I found myself wondering what exactly I was so excited about. I tried to recall a specific feature that I was looking forward to and momentarily came up blank. The new language sounds great, but I don’t have time to learn a programming language right now, or to develop a new app. I’m genuinely excited about the new look and feel of Yosemite, but I’ll most likely be waiting till the Fall to install on my daily driver at work.

I’m excited for the people I know at Apple who have done such great work and have been a part of something so big. I’m also happy that the developers of many of my favorite third-party apps are excited about iOS 8 and Yosemite, because it means that the apps I use every day will continue to get better. Thinking back on watching the CraigNote, I was excited because it felt great to see our team winning, it felt great to be a part of something, even if I was just a small, insignificant part. Being part of the Apple community for the past ten years, it’s exciting to see what we believe in succeed.

But, what else? Why do we become so enthralled by these machines?

I believe that whenever we choose to align ourselves with a particular product, brand, or organization, we do so because what we perceive as their values or the values they claim line up with our own. In the case of “Apple and related technologies”, those values are simplicity, beauty, and technical excellence. What burns some of us out, like what I believe may be happening to O’Neill, is that we focus far too much on how those values are expressed in the products, and far too little on the actual usefulness we get from Apple’s investment. In other words, it’s what they do that defines them.

What we love about Apple products frees us to get real work done. That’s one of the most interesting differences between Apple and Android advertising. Android ads, particularly the older Droid ads focused on what the phone was. Apple’s ads focus on what the device allows you to do. Play baseball, fix a windmill, conduct an orchestra, travel the world with a disability. Live. Live your life without worrying if your chosen tools are going to work or not. The promise that Apple makes, and the deal we make with Apple when we buy from them, is that we give them our money, and they give us devices that work.

We need Daring Fireball, Shawn Blanc, MacStories, MacSparky, Stratechery, and of course Dr. Drang. These writers inform and inspire us, they show us how we can do more with our machines, and they explore the details we appreciate. What we don’t need is an echo chamber constantly reverberating the same small set of words. If you have something to say, then say it, if you find joy and belonging in the community, then participate. But don’t let the obsessions of others get in the way of what your life is meant to be. Find your own passion, and pursue it relentlessly. Pick tools that you can rely on, and that reflect your values, and then get out there and do something great.


Posted on April 29, 2014

“UNLESS someone like you cares a whole awful lot, nothing is going to get better, it’s not.” – The Lorax

I believe that it is my responsibility to have an understanding of my impact on the world around me, and who and what I support, either implicitly or explicitly, by the products I use. Not everything easy is right, and not everything cool is good. I try to do the right thing whenever I can, balancing the needs of my family and the culture we live in. Sometimes, there’s no good answer, but sometimes, as in the latest case of sexism in the tech industry, the answer is clear.

I’ve removed my site and all code from Github, and deleted my account. Based on the report by Julie Ann Horvath, the vague response by Github, and the storm of coverage that has followed the issue, as well as resurfacing of past stories, I’ve decided not to do business with the company. I’ve had an account on Github for years, and used Jekyll and Github Pages to host this site for at least the past three years. As of yesterday, I’ve moved the site to Nearly Free Speech.net. I’ll be considering switching from Jekyll to another static blogging engine. In fact, I built one that I might resurrect.

My actions are small, and completely inconsequential to Github, but they mean something to me. I cannot, in good conscience, continue to support an organization run by an immature boy’s club. There is a sickness in the industry, something that has been pervasive in geek culture for years. The objectifying of women in the industry and our culture is damaging to everyone involved. One might not think that one woman getting harassed at a silicon valley darling is that big of a deal, not worth starting a tempest in a teapot, but is it? Is it really?

It is wrong to have business meetings at strip clubs. It is wrong to yell out sexual jokes across the office. It is wrong to treat women as being anything other than equals. Treat them as you would wish to be treated.

Culture is made up of who we are together. One person making a change might not matter, but it’s a start. Perhaps soon it’s one, then another, then another, and another, and eventually those who care become the majority, and the culture has changed.

Site Design Non-Update

Posted on March 23, 2014

The site design of jb was very nearly upgraded tonight. Well, upgraded is not quite the word for it. Changed is more accurate. Even though I’m quite happy with the look and feel of the site, from time to time I get frustrated with one aspect of it or another. I’ve spent more time that I want to admit thinking about readability, fonts, font sizes, spacing, kerning, and the like, but occasionally I’ll look at another site and think “that looks good”. And then mine looks like crap for a day or so.

The most recent bout of site envy came while reading a recent post by the brilliant Dr. Bunsen[1]. His entire site is worth reading, some posts several times. I decided to do a bit of HTML spelunking and see what the source revealed, and saw several references to the Pure CSS framework. I hadn’t heard of this one before, so I downloaded it and set up a new Jekyll powered site with the base blog layout. It looked fine, it works as advertised, but it would obviously take a lot of work to tweak it to look just the way I wanted it to.

After running through this exercise I went back and thought about what I don’t like about my site right now, and realized that it is not the overall look of the site that I’m not happy with, it is a few details that are nagging at me. For one, code syntax highlighting is not working, and for two, the Bigfoot footnotes were not lining up properly on the home page. I solved the latter problem by only showing only one post on the home page at a time, but the former is still bothering me.

The funny part of it is that one of the reasons syntax highlighting is not working is that I’m not using the default Jekyll Markdown converter. In order to get footnotes to work the way I want them to, I’m using Kramdown, which doesn’t use Pygments, but can be configured to use Coderay. I have the settings for Coderay, but so far they don’t seem to be doing anything. None of my inserted code is rendered with anything but “code” and “pre” tags. Ah well, this site remains, as always, a work in progress.

It’s always a good exercise to try out a completely different way of doing things. Even when I decide to scrap the work and keep things the way they are, I still count it as progress made.

  1. Whom, if you are not following, you certainly should.  ↩

For The Fun Of It

Posted on March 01, 2014

I still need an anything bucket, and nothing fills that gap like my old friend Yojimbo. I was an early adopter of Yojimbo, back with version one, and I upgraded faithfully for version 2 and version 3, but I held off for a long time on version 4. In the mean time I tried Evernote, DEVONthink, Pinboard, and just the file system to fill the void that Yojimbo filled so gracefully. No more, I’ve come home, and it feels great to be here.

Back before I used a Mac for work, I used it for fun. It was fun to grab random stuff off the web that I wanted to keep and save. I like collecting things, mainly maps, pictures of old 60’s era Volkswagens, and British motorcycles. I also like to grab quotes I’ve found inspirational, designs that I love and want to go back to, funny pictures of cats and dogs, and whatever other random thing catches my eye.

When I bought my first iPhone, I found that I wanted to be able to collect things on the go as well as on the web. Pictures of artwork at a store, or a quick note about a blender. Without a proper Yojimbo client for iOS, most of that stuff was lost. I tried to use Evernote or DEVONthink To Go, but neither tool really clicked with me.

Nothing else works like Yojimbo. The web clients like Pinterest are too slow, and Pinboard is too basic. I can’t just browse through pictures of things in Pinboard. I really don’t like having to rely on the web. As long as I have a Mac I can get to my Yojimbo database, one way or another.

Yojimbo feels right. Not for work, not for a project management system or detailed information store. That’s not what I use it for; I have a system for that. Yojimbo is for everything else, all the fun stuff that I find and want to keep. In the end, Yojimbo 4 works great, and recaptures some of the magic that made me fall in love with the Mac. I keep it just for the fun of it.

Converging Mobile and Desktop Environments

Posted on February 10, 2014

Computing has been on a linear progression towards smaller, more mobile, and more personal devices for seventy years. It seems unlikely to me that the notebook computer is going to be the last iteration of “real” computers for the foreseeable future. Critics can point to the failure of Windows 8 as proof that the market doesn’t want a converged device, but I would argue that they simply went about it the wrong way. There are two different interaction mechanisms between mobile and desktop, but the infrastructure below the user interface could be shared.

What if the desktop was an app? Everything inside of your desktop computer, the entire world of OS X, wrapped up in an app that launches automatically when your mobile device is docked. If your phone rings, pick it up and your desktop goes away for a few minutes. When you are done, put it back.[1] It’s not ideal for everyone, but it is an interaction model that would work. It’s a trade off.

When your iPhone is not docked, there would be no need for desktop metaphors in the iOS user interface. Sit down to do some work, and you have everything you always had in OS X, including the Terminal. Windows could have done this too. When the device is mobile, show the Metro interface, when it is docked, default back to a Windows 7 interface. I’m not alone, Canonical is working on this for Ubuntu. However, with Ubuntu’s spotty record for usability, stability, and performance I have doubts about Canonical bringing a viable product to market. I have high hopes, but I think this is going to have to come from Apple. Once again, they won’t be the first to market, but they have the opportunity to be the first on the market to do it right.

I think the argument that the phone hardware is not powerful enough to do this is shortsighted. History has shown that hardware becomes faster smaller over time, it is conceivable that the current “desktop class” chip in the iPhone 5S could run all of the applications on your desktop right now, if they were recompiled for the architecture. Will desktop hardware always be more powerful than mobile? Probably. Will it matter? Probably not. Why? For the same reason we don’t all have servers sitting on our desks, we just don’t need that level of power in our day to day tasks.

There are obviously many pitfalls to this concept as well. What about those notebook computers? They could be shells where a phone slides into it like a CD-ROM does today, though that sounds a bit clunky. Perhaps a better idea is that if you still need a notebook than you get one, but maybe more and more people will not.

I wrote about this topic for OStatic last year, and I stand by what I said. The Ubuntu phone concept does look like the future of computing, what I can’t see is how far out that future is.

  1. Or, you know, answer the phone in an OS X phone app, like Skype.  ↩

Command-T Crashing Vim

Posted on January 27, 2014

For some reason today when I opened up MacVim and hit ,t to navigate to a file, MacVim crashed. The terminal spat out an ugly, and unhelpful error about “deadly signal SEGV”, but knowing that I just invoked the Command-T plugin, the error was easy to track down. Command-T is not like other plugins that I have installed with Pathogen, it lives on its own and is not updated as a Git submodule.

To fix the error, all I needed to do is download the latest version of Command-T as a “.vba” file and run through the install again. The install procedure is fairly simple:

To install open the vimball archive in Vim:

vim command-t.vba

Then source it:

:so %

The C extension must also be then compiled; for instance, if Vimball installs your plugin files in ~/.vim, then you would do this:

 cd ~/.vim/ruby/command-t 
ruby extconf.rb 

And now everything is back to normal. Command-T is a great plugin, I recommend it. My latest adventures in Vim are available on Github, if you’d like to follow along.

Parsing iostat Results

Posted on January 25, 2014

In the course of load testing a new system, we gathered the output from iostat from a group of servers. In addition to parsing through the device statistics, we thought it would be handy to graph the CPU stats as well. We set iostat to run every five seconds and captured the output in a text file, one per server. This gave me a sizable pool of data, but with everything I needed on separate lines.

Time: 18:00:01
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.79    0.03    0.48    0.06    0.00   98.64

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               2.22         0.20        38.52    1948442  373500872
sda1              0.00         0.00         0.00      16224       1848
sda2              2.22         0.20        38.52    1931938  373499024

I gathered all the text files into a single directory, and ran a loop in zsh to create a csv file, ready for easy manipulation in any number of programs.

for each in `ls`
egrep -A 1 '(Time)|(avg-cpu)' $each |sed s/Time\:\ //g | grep -v '\-\-\|avg-cpu' | paste -s -d '\ \n' - - | sed 's/\( \)\{1,\}/,/g' > $each.csv

I always start building long lines like this one section at a time. Each section is separated by a pipe, (|), so the first section in the loop calls egrep.

egrep -A 1 '(Time)|(avg-cpu)' $each

This command alone give us output that looks like this:

Time: 00:03:39
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.20    0.00    0.10    0.00    0.00   99.70
Time: 00:03:44
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.10    0.00    0.20    0.00    0.00   99.70

The “-A” flag on the egrep command tells egrep to get both the matching line in the text and the line directly below it. The section between the single tics, searches for either “Time” or “avg-cpu”. This gives me the time and the CPU statistics I’m interested in. Next, I pipe this output to the next section, a sed command that strips out the “Time” string, so our command now looks like:

egrep -A 1 '(Time)|(avg-cpu)' iostat.ba-rec1  |sed s/Time\:\ //g 

And gives us output like:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.10    0.00    0.00   99.90
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.40    0.00    0.30    0.00    0.00   99.30

The next section uses grep with the “-v” flag, which tells grep to reverse it’s normal behavior and only return the strings that do not match the search text.

egrep -A 1 '(Time)|(avg-cpu)' iostat.ba-rec1  |sed s/Time\:\ //g | grep -v '\-\-\|avg-cpu'

The grep command is looking for either “avg-cpu” or two dashes and removing both lines, giving us:

           0.00    0.00    0.10    0.00    0.00   99.90
           0.40    0.00    0.30    0.00    0.00   99.30

This is looking much better, but the lines of text are offset from what I need them to be. A post I read recently by Dr. Drang reminded me of paste, which is perfect for this job:

egrep -A 1 '(Time)|(avg-cpu)' iostat.ba-rec1  |sed s/Time\:\ //g | grep -v '\-\-\|avg-cpu' | paste -s -d '\ \n' - - 

Which puts everything on the same line, nice and clean:

00:04:14            0.00    0.00    0.10    0.00    0.00   99.90
00:04:19            0.40    0.00    0.30    0.00    0.00   99.30

Only thing left now is to clean up the excess spaces a bit and separate each column by commas, another job for sed, which is only slightly modified from this post on StackOverflow, which leads us to the final command:

egrep -A 1 '(Time)|(avg-cpu)' iostat.ba-rec1  |sed s/Time\:\ //g | grep -v '\-\-\|avg-cpu' | paste -s -d '\ \n' - - | sed 's/\( \)\{1,\}/,/g'

Which I redirect the output of to a text file, one per server, just like the input from the loop. This, finally, gives us the csv output we were looking for:


Now it is ready.

A Different Vision of the Future

Posted on January 12, 2014

I ran across a few articles in the past week or so that predict the majority of the population will be living in cities by 2050.[1] I don’t dispute the projection, these people generally know what they are talking about, but I would like to do a bit of daydreaming of my own. I can envision a world of small towns populated by remote workers and independent service providers, communities with relationships that are closer, deeper, and happier than their city dwelling counterparts.

I read Remote by Jason Fried and David Heinemeier Hansson last month. The book struck a chord with me because I live 40 miles from where I work. I make the drive every day, except when weather prevents me or I’ve made other arrangements. I have the opportunity to work remotely from time to time, but it is not every day. The team at 37 Signals is mostly remote, and detail in the book how more businesses could benefit from adopting a culture that supports remote work. Fast Internet access, video conferencing technologies, and collaborative software have made remote work not only possible, but beneficial. Richard Branson says that One day offices will be a thing of the past. I agree. In fact, I think remote work could transform modern businesses, and in turn, our culture.

If most knowledge workers worked remotely, and could choose where they lived and who they spent their time with, I imagine that many, like me, would choose to live in smaller communities. The cost of living is less in small towns, the people are generally polite, and crimes are few and far between. If there are groups of remote workers in small towns, than they and their families could support a secondary economy of service workers. Grocery stores, bakers, butchers, barbers, small restaurants and cafés, plumbers, electricians, carpenters, and all the other services that are needed by groups of people. A community of entrepreneurs, similar to the villages that were common in the western world before the industrial revolution.

Big box stores can be replaced by Amazon and other online retailers. If you need a lamp, order it from Amazon. Batteries? Amazon. I generally do this now. I understand that the goods must come from somewhere, and that there will still be factory work, and that the factories will most likely be in the cities, but in my vision of a sustainable small-town future, our needs for factory made goods would be far less than what it is today. This brings me to the third part of my vision, the Maker Movement.

We think of movements as the organized action of a group of people following a common ideological or cultural path. The DIY and Maker Movements certainly fit that description. They are filled with people who want to figure out how to make or do stuff on their own, rather than purchasing pre-packaged goods or services. Are the two movements different things? I don’t think so. I think they’re two circles on a Venn diagram that overlap almost completely. Perhaps there’s a bit more art and design in the Maker Movement circle (what we might call the “Burning Man Influence”), and a bit more changing-your-car’s-oil-in-the-driveway in the DIY circle, but otherwise the passions for creating, building, and sharing are the same.

Creating, building, and sharing is at the core of this vision of mine. Knowledge workers can bring in money to small town economies, service work builds the core of the village soul, and makers reduce the amount of factory-built junk we need. Makers can sell their work locally or remotely via services like Etsy, or just set up their own stores with Squarespace.

What will make the system workable is transportation of goods. We need truckers, or, maybe even trains. Research into automotive efficiency will continue and work its way more and more into the big trucks. I imagine something like a general store being responsible for the import and export of goods and, more importantly, raw materials to the small town. Raw materials could be used by the makers of the town to build what they need, strengthening the core talents of the citizens, building self reliance, trust, respect, and community.

Like I said, this is a daydream, but I don’t think it is unreasonable. I’m optimistic about the future, and I don’t think it needs to involve stuffing seven billion people into super cities, packing them like sardines in a tin. There are other options, better options, and it is up to us to make them come true.

  1. There are several others. Just do a search for “seven billion live in cities in 2050” for more.  ↩