Page: 3 of 4

Blog Posts

12 Dec 2013 » Comments and Pagination

Now that I've done further, most likely unnoticable, refinements to this site, I have been tossing the idea around of adding a comments section to each of the permalinked posts. There seem to be a fair number of static comment plugins already available, so it sounds like it would be brain dead easy to add something simple in. I'm going to avoid complicated things like Disqus since it seems like overkill for the "whopping amount" of traffic this website generates. I will continue looking into more static solutions, since it would make it harder for this place to just become a nest for spam bots.

In other news I've implemented/fixed pagination for this site, using Jekyll's built in pagination. I've technically had the code there the whole time, but since I had less than 5 posts up until now, it didn't do anything. It was broken anyways due to previous looking for page1/, which is not generated by my configuration. All that was needed was an addition if-else clause with Liquid, and everything works as intended. It's such a simple fix that I don't even know why Jekyll includes the broken example on their page.

For the curious out there, here's my version:


<div class="pagination">
  {% if paginator.previous_page %}
    {% if paginator.previous_page == 1 %}
      <a href="/">Previous</a>
    {% else %}
      <a href="page{{ paginator.previous_page }}">Previous</a>
    {% endif %}
  {% else %}
  {% endif %}
  <span>Page: {{ }} of {{ paginator.total_pages }}</span>
  {% if paginator.next_page %}
    <a href="page{{ paginator.next_page }}">Next</a>
  {% else %}
  {% endif %}

And that's really all it takes. I also tried the overly complicated fix they have listed below, and fought with it far more than I should have (as in I had to fight with it at all), and just settled on my slight modification instead. Sure, I could have had links to multiple pages instead of just having "next" and "previous", but who cares? That's what the archives are for!


06 Dec 2013 » Why Jekyll?

In my first post, I gave a couple of vague reasons why I decided to use Jekyll to create this website, as opposed to something like Ruby on Rails. Having recently used Rails for a school project, I can understand the appeal of using such a framework. It can be used to create powerful dynamic web apps with a range of useful tools and features. But for what I wanted out of this website, Rails would be like bringing a nuclear missile to a water gun fight. It's simply offers far more features than what I need.

Rails gives me the chance to build my own blog platform, while Jekyll is a blog platform, which allows me to focus on the blog itself, rather than writing and maintaining everything. While it would give me complete control over every aspect of my website, I am simply not interested in this level of control for such a small website. I feel comparing Jekyll and Rails is not fair because they are just two different tools that both happen to be able to accomplish the same task.

Since I'm far more interested in showing what I like about Jekyll than I am in comparing and contrasting Jekyll and Rails, I will keep the comparisons to a minimum.

Jekyll is as its website describes, "a simple, blog-aware, static site generator", nothing more, nothing less. Since it's just a ruby script, issuing a simple gem install jekyll in a terminal is all it takes to have everything installed, much like Rails. Again similar to Rails, one can then generate the scaffolding for a new blog by issuing jekyll new blog.

This is where the two diverge however, with Jekyll taking a simpler path, as far as blogs are concerned. Navigating into a newly generated blog directory gives a simple directory structure.



Even at first glance this structure is fairly simple to follow. Jekyll divides sites into three main components, layouts, posts, and CSS. Since each of these parts are constructed very differently from one another, it was a very sane choice to give each their own directory.

This layout is very easy to extend as well. For example, if JavaScript is needed then all that needs to be done is adding a js/ directory to the root of the blog directory, and it will be included in the final _site/ folder after generation.

Jekyll layouts use mainly HTML/CSS, spattered with Liquid Markup that gets interpreted to HTML at build-time. Again, if this sounds somewhat similar to how Rails works, that's because it is.

A good example of how this works is the following:


<!DOCTYPE html>
    <title>{{ page.title }}</title>
    {{ content }}

Then in index.html all that is needed is:

layout: default
title: Home

<p>Look at this snazzy navbar and footer!</p>

When jekyll build is run, the content of index.html will be combined with _layouts/default.html, with the index content being placed in the content tag, and the complete page(s), along with any CSS, will be placed in the _sites/ directory. By just using the YAML front matter at the top of a page, any page on the website can how have the navbar and footer, eliminating redundancy or inconsistencies between creating multi-page websites. I found this to be a very simple method to create consistency, while still maintaining a certain level of control for each page.

Since a huge reason to use Jekyll is for the blog features, it helps that creating blog posts is simple as well. Each blog post is written in markdown and needs to be placed in the _posts/ directory, with each following a naming convention like 2013-12-6-why-jekyll.markdown. Each post needs some YAML front matter for Jekyll to construct everything properly, but the rest can be written in pure markdown.


layout: default
title: "Why Jekyll?"
date: 2013-12-6
categories: posts

I dunno, _you_ tell me!

Jekyll makes it very simple to extend layouts for specific purposes, such as dedicated pages for a post, using YAML front matter:


layout: default

<h2>{{ page.title }}</h2>
<p class="meta">{{ | date_to_string }}</p>

{{ content }}

Now each dedicated post page can display the title and post date in a header just by specifying the post layout in the YAML front matter.

Of course, Jekyll has even more to offer, like built in pagination, syntax highlighting, and countless plugins, but I'm not about to go on and on about it for that long. Jekyll has so far been very pleasant to work with, and I can't imagine switching to anything else any time soon.


21 Nov 2013 » Simple OfflineIMAP Notifications with libnotify

Mutt in combination with OfflineIMAP and Msmtp is easily the least sucky mail setup I've used, but because of it's simplicity, it's missing one thing that I like to have: visual notifications for new mail. In my bspwm and dwm setups, I like to keep mutt running in a terminal window, in a dedicated workspace or tag respectively. Short of obsessively switching back and forth to the mutt terminal, I don't have a clean and efficient way to know immediately when I revieve a new email.

I found some scripts that can accomplish this on the Arch Linux forums, but they were more complex than what I wanted. Instead I wrote a short bash script to run OfflineIMAP and display the number of new emails, if any. With some googling and some help from the fine people over on the Arch Linux forums, I got this working with few issues.

The entire process was fairly straightforward, so here's a little how-to:

Make sure to have your OS' version of libnotify installed before you begin, and a notification daemon for notify-send to communicate with. I personally use dunst because it's lightweight and simple to setup, but there are many other choices that also work.

We can put the following in a file called


#run OfflineIMAP once, with quiet interface
offlineimap -o -q -u quiet

#count new mail for every maildir
new="$(find $maildirnew -type f | wc -l)"

#count old mail for every maildir
old="$(find $maildirold -type f | wc -l)"

if [ $new -gt 0 ] 
    export DISPLAY=:0; export XAUTHORITY=~/.Xauthority; 
    notify-send -a "OfflineIMAP" "New mail!\nNew: $new Old: $old"

Make sure the script is executable, and put it in your $PATH if you wish.

It will count all of the files in the ~/Mail directory and send a notification if there new ones. You may need to modify the counting section to your needs, depending on the location of your Maildirs.

The export DISPLAY=:0; export XAUTHORITY=~/.Xauthority; part is neccessary, in my case, when running the script from a cron job, since cron will normally not have access to the environmental display variables. I also tried to use this script with a systemd timer unit, in a systemd User instance, but I was unable to get it to display the notifcations, even though it was syncing my mail properly. If I can find a solution to this I will create a follow-up post with my findings.

We can run the script every 3 minutes with cron:

*/3 * * * * ~/Scripts/

Now you should have a lovely little notification every time you get a new email! Simple as that.

Click for example! (1024x600 728K)


If your OS keeps bash in /bin, then please change the shebang line 
to reflect that. Arch Linux keeps all binaries in /usr/bin but most other 
OS' don't.

Regarding my use of `find`: 
I am aware that in general parsing the output of `find` and `ls` can be problematic 
in certain circumstances. However, OfflineIMAP should not produce 
file names that are problematic, so ideally I should not see these issues. 
Any suggestions are more than welcome as I am still fairly new to bash
scripting myself.

20 Nov 2013 » Unexpected Downtime

Over the past few days, as probably nobody noticed, the website was inaccessible. I'm thinking it started partly due to me accidentally changing some of my port forwarding settings, along with WOW!'s general suckiness, and some other issue with my Raspberry Pi.

Whatever the issue was, I finally got around to rebooting the Raspberry Pi, and everything seems to be working again. Such a Windows-style solution!


13 Nov 2013 » Archive Test

There isn't much point to this post really, other than to test the archiving code that I added in. I found the code here, and it seems to work as I hoped it would.

Page: 3 of 4