Bloerg est. 2012

## Moving to Jekyll 1.0 ∞

I was happy to see that Jekyll 1.0 was released today and of course I was eager to move on. Because subcommands are the latest shit now, the --no-auto option and the destination directory weren’t working in the Git post-receive hook. Additionally, the auto: true statement in my _config.yml caused Jekyll to scream at me. Also, Jekyll told me that it could not find a matches method in the Markdown converter, which seems to be required nowadays. Nevertheless, all these problems are easily fixed.

But I also noticed that syntax highlighting and the typogruby enhancements were silently gone. Problem was, that my Kramdown converter was not used for the Markdown input, even though the matches method looks for the .md extension. The easiest fix? Use a dummy Markdown extension in _config.yml

markdown_ext: foo


and the default converter will be skipped. Apart from these minor problems, the Jekyll move went smoothly.

## Beamer's weird column defaults ∞

From time to time I encounter a problem with LaTeX or Beamer that costs twice as much time to solve than what I save by using LaTeX. Here is a reminder for me to fix a particularly strange behaviour with Beamer’s columns environment.

The columns environment is used to split content horizontally in (you guessed it) several columns. Intuitively, you’d write something like this

\documentclass{beamer}

\begin{document}
\frame{
\frametitle{Slide with columns}
\begin{columns}
\column{.5\textwidth}
First column

\column{.5\textwidth}
Second column
\end{columns}

Conclusive text
}
\end{document}


and expect the columns to be aligned nicely with the adjacent text. But for whatever reason, that’s not the case by default:

To fix this, you have to pass the onlytextwidth option to the environment

  \begin{columns}[onlytextwidth]


and you are good to go:

I don’t know if this happens only with TeX Live 2009, but it is certainly annoying …

## A Git cherry pick text user interface ∞

Lately, I’ve been merging more and more commits between branches using git cherry-pick instead of a regular merge. Sometimes this is necessary because “the other guy” messes up his own branch and merging is just not feasible and sometimes it is useful because only some changes are of particular interest.

The workflow usually looks like this: First, I checkout the branch where the merge should happen. Then, I will have a look at the branch using git log from where I want to pick commits. Eventually, I cherry pick the commits by specifying their hashes:

git cherry-pick ae4971b fe0281b


The last step is tedious and error-prone when typing the hashes by hand, so I wrote a stupid tool called pick-from to simplify this. After specifying from which branch to pick from

\$ pick-from other-branch


pick-from shows me a list of commits that exist in the other branch but not in the current one:

Choose commits to cherry-pick and accept with q'

[ ] 13579ef: A commit message
[X] fa45678: Another commit message


After selecting all desired commits with Enter and accepting with q, the commit hashes are passed unconditionally to git cherry-pick:

[master fa45678] Another commit message
Author: Gandalf the Grey
1 file changed, 16 insertions(+), 7 deletions(-)


pick-from is written using the TUI toolkit urwid, which is practically available for all distributions. If you want to let the tool look more officially” integrated, you can also alias it in your .gitconfig:

[alias]
pick-from = !pick-from


Have fun with that.

## Managing notes with the Gollum wiki ∞

I already wrote about how I took notes in Markdown, render them with Pandoc and keep them in sync with my server via Bitpocket. However, there are several problems with this approach:

1. Wherever I am, I need SSH access to my machine and Bitpocket must be installed to keep everything up to date.
2. Even the smallest changes require mundane tasks.
3. From within a note I cannot reference and jump to other notes.

Obviously, the perfect solution to all my problems would be a web-based wiki with Markdown formatting. A quick search revealed only two serious Markdown-based wikis: Markdoc and Gollum.

Markdoc is for wikis what Jekyll is for blogs: A static site generator for a bunch of Markdown files. The builtin web server is good for viewing the generated HTML pages but nothing else. Because Markdoc does not solve any of the mentioned problems, I took a stab at Gollum.

Gollum was founded by GitHub developers and backs all public GitHub wikis. With this in mind, it is no wonder that each wiki is backed by a Git repository rather than a data base. Thus editing a page, simply requires a Git commit. However for quick edits the builtin web server is much faster.

As with most Ruby programs, you can install Gollum with

gem install gollum


and run it by pointing it to an existing Git repository:

git init .
gollum .


A big advantage compared to my retired setup is a live editing preview

and MathJax support

However, you should be aware that the Markdown processor eats escape characters and that you have to enclose inline equations in \$$ and \$$`.

To get Gollum (semi-privately) online, I run Gollum locally inside a tmux session and setup nginx as a reverse proxy that forwards outside requests to the Gollum service. That’s definitely not a perfect setup but it works very well for me.

One last word: If you want to serve a statically generated site you could either use Markdoc or Smeagol (way too many puns intended). I hope this will be me last infrastructural change to my “note taking system” for the foreseeable future. Keeping fingers crossed!