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.
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:
Both columns take much more space than the actual slide “surface”.
To fix this, you have to pass the onlytextwidth option to the environment
\begin{columns}[onlytextwidth]
and you are good to go:
Fixed alignment.
I don’t know if this happens only with TeX Live 2009, but it is certainly
annoying …
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:
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:
Wherever I am, I need SSH access to my machine and Bitpocket must be
installed to keep everything up to date.
Even the smallest changes require mundane tasks.
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
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!