In the continuing saga of this humble website: I have changed the underlying
tech stack again, this time to use Next.js. I am aware that many (most?) of the
posts on this site are related to changing the site itself but since the
intention of this site is to try out new things I am trying not to feel self
conscious about it.




## Why the switch?

The most recent change to [this site was moving from Hugo to
Gatsby](/blog/post/2020/05/switching-to-gatsby). That
previous move was moving towards something more familiar with using React since
I have been using React for the day jobs for the past few years. After moving
to Gastsby I found that I didn't like the GraphQL parts of making changes to
the site. I think that this difficultly was largely from my own lack of
experience with the technology.

Another reason for the switch was the generated TypeScript types generated from
the GraphQL types were large and change superficially frequently making it more
difficult to use.


## Cool things

### All of the cool things from the previous Gatsby rewrite

This incarnation of the site looks mostly the same as the Gatsby version of the
site. This is because it uses the same React components that the Gatsby version
does and changes the data loading to be via the `getStaticProps` and
`getStaticPaths` methods (these are the methods that Next.js uses to generate
pages at build time).


### More control of markdown processing

Previously all of the processing of markdown was happening within Gatsby
plugins. This was really nice from the perspective of getting a lot out of the
box, but meant that some aspects were more difficult to control. This Next.js
approach uses [`markdown-it`](https://github.com/markdown-it/markdown-it) to
process the markdown in a opinionated and extendable way.


## Wrapping up

I am hoping that this change will make it easier to make changes to the site. Perhaps someday I'll use this site to tell stories about other projects rather than use the site to tell stories about itself. 🤞.

Switching to Next.js

This past week I decided to spend some time switching this website to use
Gatsby. This comes on the heels of switching to Hugo at the end of last year.




## Why the switch?

No big grand reason. The biggest reason to make the switch was my experience
with React compared to the Hugo templating. It feels nice to use similar tools
to what I use day to day and feel like I have more control over the look of the
site.

I first worked with Gatsby for a friends wedding website and was really pleased
with it. It's got some very impressive things built in like prefetching links,
and image preprocessing (with cool things like "blur up" where the image first
loads as a minimal blurry base64 equivalent while the full image loads). One of
the things that also encouraged me to make the switch was Gatsby's excellent
docs.

## Cool things

### Automatic dependency updates

The JavaScript ecosystem contains many small packages and changes rapidly. To
help keep up with that there are systems like Dependabot which will open PRs on
the GitHub repo periodically. Normally it's up to people to review these and
merge the changes.

For this repo I decided to try our a service called
[Mergify](https://mergify.io/). It will read a configuration with a set of
rules and will merge dependency pull requests without any human interaction if
the tests pass!

An example of this can be seen
[here](https://github.com/hockeybuggy/hockeybuggy.com/pull/69). Notice that
this was opened by a bot and merged by a bot once the tests passed.


### End to End tests

The "automatic dependency updates" could be a really good way for this site to
break without noticing nice not every dependency is a non-breaking change. In
order to catch the site breaking before merging these changes in this static
site now has tests that fires up a headless browser and checks that the page renders.

This project has a [GitHub
action](https://github.com/hockeybuggy/hockeybuggy.com/actions?query=workflow%3A%22end+to+end+tests%22+branch%3Amaster)
that runs this process. The tests take screen shots while it's running of
various pages. These are collected as build artifacts.


## Wrapping up

Hugo had some really good things going for it. I will miss it's single
executable (since setting up a node environment can occasionally by tricky).
Thanks to the contributors of Hugo as well as the authors of the `hugo-coder`
theme that I recreated here.

Looking forward to continuing to improve the site and writing about it as well
as looking forward to learning more about Gatsby.  Hopefully I'll also write
about other things (other than my lovingly over-built simple website).

Switching to Gatsby

This past week I was thinking about what it would take to design and build a
home heating monitoring and control system. A "normal" mid-week thought. I was
imagining something like a small computer in each room that would have a
thermometer on radiator and thermometer measuring the ambient air temperature.
These smaller computers would send messages into a "central" computer that
would record things and turn radiators on and off. These computers would be on
a separate physical network from other devices in the house and would not be
internet connected (because having your house not work when the internet is
down sounds super frustrating).

These smaller computers will need to encode the information in some format and
send it to the central computer. Being a web developer I reached for familiar
tools and decided to make the systems communicate via HTTP, but since I
wanted to try something new: instead of having the body of the HTTP messages be
a plain text format I decided to try using Protobufs.




## What is a Protobuf

Protobufs are short for "Protocol buffers" and are a Google created mechanism
for serializing structured data into a binary format. They work be having
defined message types in `.proto` files. These files can then be used by
various programming languages to generate a language appropriate binding that
can be used to encode and decode messages.

The documentation on [why you might want to use
Protobufs](https://developers.google.com/protocol-buffers/docs/overview#whynotxml)
does a good job of explaining their advantages. Using Protobufs have some
trade-offs that likely make them not the most appropriate format for a hobby
home automation project (such as not being human readable), but here we are.


## Generating Rust structs from a Protobuf

I selected [the Prost library][PROST] somewhat arbitrarily since, in
retrospect, I didn't look into
[other](https://github.com/stepancheg/rust-protobuf)
[options](https://github.com/tafia/quick-protobuf).

I started off by installing Prost by adding this to my `Cargo.toml`:

```toml
[dependencies]
prost = "0.7"

[build-dependencies]
prost-build = "0.7"
```

Then creating a minimal `.proto` file called `src/messages.proto`:

```protobuf
syntax = "proto3";

package messages;

message ThermostatState {
    string name = 1;
    double air_temp = 2;
    double rad_temp = 3;
}
```

After that followed the instructions for using `prost-build` to generate a
struct from the Protobuf definition. That included adding the following to the
`Cargo.toml`:

```toml
build = "src/build.rs"
```

Creating a `src/build.rs` file that looks like this:

```rust

extern crate prost_build;

fn main() {
    prost_build::compile_protos(&["src/messages.proto"], &["src/"]).unwrap()
}
```

This file compiles are of the Protobufs in the first argument and outputs the
generated code to the second argument. That means that it will output a Rust
file that looks like this:

```rust
#[derive(Clone, PartialEq, ::prost::Message)]
pub struct ThermostatState {
    #[prost(string, tag="1")]
    pub name: std::string::String,
    #[prost(double, tag="2")]
    pub air_temp: f64,
    #[prost(double, tag="3")]
    pub rad_temp: f64,
}
```

The project's compile step generates the new rust file but we need to import it
to be useful. We do this by `include!` the file into the `src/lib.rs` file.

```rust
pub mod messages {
    // The name "messages" corresponds with the `package` name in the `.proto`
    include!(concat!(env!("OUT_DIR"), "/messages.rs"));
}
```

The `struct` can then be constructed an used as a return type normally: 

```rust
pub fn create_thermostat_state(name: String) -> messages::ThermostatState {
    let mut state = messages::ThermostatState::default();
    state.name = name;
    state
}
```


[PROST]: https://github.com/danburkert/prost


## Encoding and decoding


Now that we are able to generate Rust code from the Protobufs we next want to
send them from one system to another.

### Sending

To send a HTTP POST I reached for the
[`reqwest`](https://docs.rs/crate/reqwest/0.10.1) package (again didn't do a
ton of research, just picked a dependency that looked good enough). I was then
able to construct a Protobuf, encode it, then send it as a request body:

```rust
use reqwest;
use tokio;

// This trait needs to be included in order to call `.encode`
use prost::Message;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let msg = home_auto::create_thermostat_state("foo".to_string());
    // This being fixed length could be improved
    let mut buf: Vec<u8> = Vec::with_capacity(200);

    msg.encode(&mut buf).unwrap();

    let client = reqwest::Client::new();
    let _resp = client
        .post("http://localhost:8080")
        .body(buf)
        .send()
        .await?;
    println!("sent");
    Ok(())
}
```

The documentation for [`encode` can be found
here.](https://docs.rs/prost/0.6.1/prost/trait.Message.html#method.encode).


### Receiving

The next step was getting something serving HTTP requests running on
`localhost:8080`. To do this I also picked a dependency somewhat arbitrarily
and used [`warp`](https://docs.rs/crate/warp/0.2.0).


```rust
use bytes;
use tokio;
use warp::Filter;

// This trait is required to call `ThermostatState::decode`
use prost::Message;

#[tokio::main]
async fn main() {
    let route = warp::body::content_length_limit(1024 * 32)
        .and(warp::body::bytes())
        .map(|bytes: bytes::Bytes| {
            println!("bytes = {:?}", bytes);
            let msg = home_auto::messages::ThermostatState::decode(bytes).unwrap();
            println!("msg = {:?}", msg);
            "ok"
        });

    warp::serve(route).run(([127, 0, 0, 1], 8080)).await
}
```

This will bind to port 8080 and start decoding all request bodies as if they
are valid `ThermostatState` Protobufs (which seems like a dangerous assumption
if this was meant to be long living code).


### Results

Each time the first program is run the second program will print:

```plaintext
bytes = b"\n\x03foo"
msg = ThermostatState { name: "foo", air_temp: 0.0, rad_temp: 0.0 }
```

The first bit is the binary format sent over the wire and the second is the `std::fmt::Debug` of the generated `struct`.

Which is pretty neat!


## Conclusions

This was a fun thing to try out and I feel like I learned a few things from the process:

1. You could generate Rust structs from preexisting Protobufs allowing a typed boundary between languages.
2. Tooling to this approach (as is) is imperfect since the generated file only exists at compile time.
2. Async/Await in rust is wonderful and I am grateful of people's hard work to make it happen.

I could picture reaching for Protobufs again in the future.

Experimenting with Protobufs generated types in Rust

I haven't written anything in my blog for a little while.  I don't really feel
bad about it, but one of the things that I feel prevented me from writing new
things here was that I had some troubles with my previous static site generator
[Jekyll][JEKYLL]. Last week I switched this site over to use [Hugo][HUGO].

[JEKYLL]: https://jekyllrb.com/
[HUGO]:  https://gohugo.io/




## What I like more about Hugo

One of the biggest issues I had with Jekyll was how difficult it was to setup
on a new machine. I am not a Ruby developer (although I know enough Python and
have seen enough Smalltalk to fake it) and so setting up a Ruby interpreter
with `rvm` and getting Bundler setup was quite difficult when all I wanted to
do was write prose. Hugo on the other hand has a single executable. This means
that even though Hugo is written in Go I don't have to have Go setup on the
machine I want to write on. Instead I can just install an executable from my
package manager.

One other thing that I like about Hugo is that it supports [`.toml`
front-matter][TOML] on posts. Not really the biggest of deals, but I am not
wild about `.yml` so this is a nice way to stick with something more familiar.

Finally one of the nicest things about Hugo is the automatic reloading when in
development mode. This feature injects a script that will reload the page is
anything in the file system that it's watching changes. This is really nice
while authoring since it allows you to not have to switch out of your editor to
see rendered changes.

[TOML]: https://github.com/toml-lang/toml


## What was the process 

To perform the switch I used [the `hugo import jekyll`
tool](https://gohugo.io/commands/hugo_import_jekyll/). This tool did a great
deal of the work as it copied over most of the posts and setup a new Hugo site.

After that I removed a number of blog posts that I had written a while ago and
didn't feel so bad about having them fall off the internet (they are archived;
I checked).

Then I went from blog post to blog post and for each:

1. Switched the front-matter from YAML to TOML.
2. Set up aliases so that old urls to live posts will still work.
3. Added some tags and categories.

Finally I made sure that pages looked ok and that static files like the RSS
feed, the `humans.txt` and the `robots.txt` loaded.

Finally I went ahead and made the switch by merging [merged the
branch](https://github.com/hockeybuggy/hockeybuggy.com/pull/46).


------

Thanks Jekyll and the people who support it for helping me build my site for so
long. Thank you Hugo contributors for building a tool so nice that it made it
feel like it was worth finally switching.

Migrated to Hugo Static Site generator

In May, I switched to using relative line numbers in Vim and I thought I should
share a bit about my experiences. In preemptive summary, my impression so far
is "OMG where have you been all my life relative numbers!".



## In the beginning

Many people that I see using Vim have this in their `.vimrc`:

``` VimL
  set number  " Show absolute line numbers in the gutter starting from line one
```

Seeing line numbers in Vim is fantastic. So fantastic it should really be
default on. It gives you an idea of where you are in a file, particularly if
you've just jumped there from a search, and are a little disoriented. This seemed
indispensable until I switched, but then realized that I didn't miss it.

![Absolute line numbers][ABSOLUTE_GIF]

In the gif above to delete the method I am pressing `Vjjjjd` for **V**isual-line
mode, down, down down, down, **d**elete. That's a lot of keys and I have to hold
the shift key. Gross.

## The enlightenment

Turing on relative line number makes me feel like I am jumping around like a
ninja&trade;. By giving `j` and `k` a count, you don't have to feel like you're
mashing them just to get where you want.

``` VimL
  set relativenumber  " Show line numbers relative to the location of the cursor
```

![Relative line numbers][RELATIVE_GIF]

In the gif above, I am deleting the same method with `d3j`. This is **d**elete and
then the motion "3 down". It's easy to tell how many times I need to move down
while in relative line mode, since it's written in the gutter. This solution
takes three lowercase keystrokes compared to the visual mode solution that took
6 mixed case keystrokes.

## Overcoming the downsides

One of the down sides of the alternate line numbering system is that it can be
harder to find your absolute position. For example, if you have a test that is
failing, you'd want to jump to the line that is causing an error. Without absolute
line numbers, this can seem harder, however the Ex command `:123` will jump
straight to line 123.

When you really want to switch back to seeing the absolute line numbers running
`:set num` is enough to switch back. Alternatively, using the
[unimpaired][UNIMPAIRED] plugin you can switch between the two numbering
schemes with `con` and `cor`. A good mnemoic for these are "**c**hange **o**ption
**n**umber" and "**c**hange **o**ption **r**elative number"

## TL;DR;

If you haven't tried out relative line numbers in Vim, it give a shot.

[UNIMPAIRED]: https://github.com/tpope/vim-unimpaired
[ABSOLUTE_GIF]: /static/img/relative_line_numbers_absolute.gif
[RELATIVE_GIF]: /static/img/relative_line_numbers_relative.gif

Relative line numbers and you

I have a quite a few leader mapped keys in my `.vimrc`, and I use some of them.
The mapping that I use the most is to split the vim window to an existing
buffer buffer. If I wanted to split to file I have already opened, and I know
the buffer number is 2, I could type:

<div class="keysequence">
  <kbd>,</kbd>
  <kbd>-</kbd>
  <kbd>2</kbd>
  <kbd>CR</kbd>
</div>




This is a simple mapping but I think an
effective one since it's shorter and does not require the shift key.

The mappings [look like this][MAPPINGS_IN_SITU]:

    map <leader>- :sp<bar>b
    map <leader>\ :vsp<bar>b


## Why `\` and not `|`


When I first made the mapping, I used `-` for horizontal splits and `|` for
vertical split, since each of those characters look like the type of split they
produce. This ended up being annoying since `-` does not need a
shift and `|` does. To make typing them more constant I settled on `\` since
it's the lowercase `|`.

## Open buffer in a new tab

Upon occasion I use vim tabs to separate out different types of files of what I
am working on (e.g. Working on Python files in one tab and Javascript and HTML
in another). I found that I was wishing for the same quick mapping that I had
for vim windows, so I created this mapping:

    map <leader>t :tabe<bar>b

## What's the point?

The mappings are quite simple but change a 7 character mixed-case sequence
into a 4 character lowercase sequence. I would highly recommend them to anyone
who uses vim windows, buffers and tabs.


[MAPPINGS_IN_SITU]: https://github.com/hockeybuggy/dotfiles/blob/f067eaae643b0aa5ffa36fdd6154a5d002598df3/vimrc#L103-L105

Vim splitting shortcuts

In November I started working at an awesome Toronto Company called [Vantage
Analytics][VANTAGE] where I have the pleasure of writing Python everyday.
While working there, I ended up getting sick of typing `python manage.py` over
and over again, so I created some bash and zsh aliases for Python.



### Python aliases

These are for any Python project:

    alias -r ipy="ipython"
    alias -r pipir="pip install -r requirements.txt"
    alias -r rmpyc="find . -name \*.pyc -delete && echo 'pyc files removed.'"

I really like `rmpyc` since I can never remember the arguments for `find`.

### Django aliases

And these are for Django projects (or for running any script named manage.py I guess)

    alias -r pm="python manage.py"
    alias -r pmsh="python manage.py shell"
    alias -r pmt="python manage.py test"
    alias -r pmrs="python manage.py runserver"
    alias -r pmm="python manage.py migrate"
    alias -r pmmm="python manage.py makemigrations"

Send me a message if you have any other fun or useful aliases.

[VANTAGE]: https://vantageanalytics.com

Bashing long Python commands down to size

Whenever I tell someone what my email is, I get asked about the name
hockeybuggy.




## Back in the day

At the beginning of time[^1], gmail did not exist. On April 1st of 2004 Google
announced the Gmail beta. At first the beta was invite only. Once you were
invited to get a Gmail account, you received 10 invites you could send others.

On January 31st 2005, I received an invite from my older sister. I discovered
the day that I created my account using the helpful advice of [this
page][CREATION_DATE_METHOD].

Being young I foolishly did not get douglasanderson&#64;gmail.com. Instead, I
got hockeybuggy&#64;gmail.com, a combination of my favourite sport at the time:
**hockey** and a modification of a nickname: **buggy**[^2]

## Why Keep It?

I have the name just about everywhere on the web. Since I have the .com  as
well as the same username on Github, Google, and Twitter and just about
everywhere else, I don't think I will be changing it any time soon.

[^1]: &gt;= 2003
[^2]: My family sometimes calls me 'bug'.

[CREATION_DATE_METHOD]: https://www.labnol.org/internet/google-creation-date/20747/

What's the deal with the name hockeybuggy?

In this post I am gonna talk about the things in my configuration that I am
really excited about. Warning: non-technical people may find this either super
boring, undecipherable or both. Often the things I am excited about are recent
changes, but sometimes they are old treasures that I really like.

I spend quite a bit of time working on my [dotfiles][STATE]. The nicer the
environment, the easier it is to work.  Since the beginning of the year, I have
made 63 commits, which brings my total to 292 since March 2012.

------------

## Vim

I really like Vim. I like it an (almost) embarrassing amount. It has taken me a
while to build up my muscle memory but now that I have, it makes me look and
feel like a wizard (the casting spell kind, not the helping people use software
kind).

### Switching to Vundle

For a long time, downloading the plugins I use for Vim was handled by [Tim
Pope's][TPOPE] [Pathogen][PATHOGEN]. It's is a really great way to keep plugins
out of your dotfiles revision history, but it's not perfect. The problem is
that it relies on git submodules, and git submodules [kinda][GITSUB1]
[suck][GITSUB2].

### Airline

For quite some time I used custom statusline that was simple but did the job
quite well. It communicated things like which git branch was active and which
buffer was active. It's only issue was that it was sometimes difficult to see
what mode Vim was in my peripheral vision.

In a 'the grass looks greener over there' sort of move I switched to
[airline][AIRLINE]. It not only solves the problem of losing track of modes but
It also helps keep track of which is the current split window. As iceing on the
cake, it also tells me which line has trailing white-space or mixed
indentation.

![Demonstration of Airline switching modes][AIRLINEDEMO]

### Spellfile

I am really bad at spelling. While English may be my first language I am pretty
sure I am more proficient in several programing languages. Thankfully Vim can
help me compensate for my shortcomings with `:set spell`. Once spelling is
turned on misspellings are highlighted and can be managed with the following
normal mode mappings:

- `z=`: Show possible spelling corrections for the typo under the cursor
- `zg`: Add the "typo" under the cursor to the spellfile. More on this later
- `[s`: Move to previous typo
- `]s`: Move to next typo

The spellfile is the magical file of words that allow you to maintain your own
supplemental dictionary. For example check out [mine][SPELLFILE]. Keeping it in
revision control allows you to have your own dictionary on any machine you use.
Take that Microsoft Office.

### Completions

One my favorite feature of Vim is it's approach to completions. Some IDEs like
Visual Studio and Eclipse have tab completion which try to produce a list of
things you might mean to type (like function names in the project. While this
can be nice sometimes, it is **CRAZY** distracting. Vim will only give you a
completion list when you ask for it and Vim has a number of different list you
can choose from. From insert mode type:

- `<CTRL-n>`: Generic Complete
- `<CTRL-x><CTRL-n>`: Search among the current buffers to complete a word
- `<CTRL-x><CTRL-i>`: Search among the included files to complete a word
- `<CTRL-x><CTRL-f>`: Search among the current directory to complete a filename
- `<CTRL-x><CTRL-k>`: Search among the dictionary to complete a word
- `<CTRL-x><CTRL-l>`: Search among the current buffers to complete a whole line
- `<CTRL-x><CTRL-o>`: Context sensitive (language aware) search for a word

For a comprehensive list take a look at the help page with `:help compl-keyword`

------------

## Zsh

If I told you that I came to use zsh just because of the features it has over
bash, I would be lying. Another thing that made me really want to use it was
the differences between the American and Canadian pronunciation of the letter
'Z'. While most people call it 'Zee-shell', I patriotically call it 'Zed-Shell'.

### My Favourite Features

While I might have come to use zsh for the wrong reasons, I think that I have stayed
for the right ones. One of the most visually apparent is the **multi-line prompts**
(you can see an example of it in the right pane of the image at the top). I
really like having a multi-line prompt since I means that a lot of information
can be shown on the top line and long commands can still be typed on the second
line.

Another feature that is keeping me using zsh is what happens when the typed
command is not found in the path. This is what happens if your fingers slip in
bash (ubuntu 14.04):

    (bash) > gti log
    No command 'gti' found, did you mean:
     Command 'gtg' from package 'gtg' (universe)
     Command 'gt5' from package 'gt5' (universe)
     Command 'ti' from package 'ti' (universe)
    ... ETC ...
     Command 'gtv' from package 'smpeg-gtv' (universe)
    gti: command not found

Which is totally and completely **useless**. zsh out of the box does this:

    (zsh) > gti log
    zsh: correct 'gti' to git' [nyae]?

Useful. `y` will make the listed correction, `n` will execute the typed command
anyways. `a` will **A**bort the whole thing. `e` will **E**dit the command.

### Z directory jumper

I like to keep my home directory really well organized, but it can still be
taxing to remember where I keep all the projects I hack away on. To combat this
I make use of the [directory jumper Z][Z]. This awesome tool tracks highly used
directories based on frecency (a portmanteau of recent and frequency). For
example when I want to jump to my dotfiles directory I just type:

    > z dot

Rather than:

    > cd .dotfiles

Pretty slick.

------------

## Tmux

Tmux is a bit of a god-send. I was having a hard time managing all my terminals
and so I moved to the [window manager i3][I3]. It was a really cool way to
manage my windows and was great for multiple monitors, but it was less than
perfect for running Steam and meant that I was completely out of my element
when I used a traditional window manager.

Tmux allowed me to switch back to a 'traditional' window manager and keep my
Vim and Shell in the same window. Tmux is also a great way to run multiple
shells on a remote servers over only one ssh connection.

### CTRL-a Prefix

To interact with a Tmux instance you first type a control sequence, called a
prefix, and then the mapping. By default this prefix is `<CTRL-b>`, but I am
not a big fan. To type `<CTRL-b>` on a standard English keyboard, you have to
take your entire left hand off the "home row".

As an alternative prefix I, and many other people, use `<CTRL-a>`. It's a lot
closer to the left control key, and if you the caps lock key into another
control key, it is adjacent.

### TAT

When creating Tmux sessions to work on things, I was finding it super hard to
come up with names for sessions. Every time I tried I was reminded of this:

<blockquote>
There are only two hard things in Computer Science: cache invalidation and
naming things.
<br/>
-- Phil Karlton
<cite>
    <a href="http://martinfowler.com/bliki/TwoHardThings.html">(source: Martin Fowler)</a>
</cite>
</blockquote>

[Thoughtbot][THOUGHTBOT] has an awesome solution to this in [their
dotfiles][TAT]. This script either creates or attaches to a Tmux session with
the same name as the working directory. Meaning that creating a sensible named
session is as easy as navigating to the root directory of a project and typing
`tat`. Meaning that creating a new session to edit my dotfiles is as easy as:

    > z dot
    > tat

Nifty.

### vim-tmux-navigator

When you use Vim within a Tmux Session the line between Vim *Windows* and Tmux
*Panes* can get pretty blurred; Sometimes blurred to a frustrating degree.
Trying to remember whither you need to type `<CTRL-a> h` or `<CTRL-w> h` when
you simply want to move to the right can get tiring.

A really cool person called [Chris Toomey][CHRIS] created
[vim-tmux-navigator][VIMTMUXNAVIGATOR]. This really neat vim plugin allows you
to move between Vim *Windows* and Tmux *Panes* as though they were a single
homogeneous entity. Moving to the right is always `<CTRL-r>`.

------------

## Miscellaneous

Some things in my dotfiles don't really fit in with the other sections. Hence
this cleverly named section.

### War on Caps Lock

I really hate the caps lock key; I hate it almost to the point where I have
considered writing tirades about how useless it is. I've almost disowned my
sister over her persistence in keeping her caps lock key. But instead, I am
gonna quickly rant about here. Feel free to skip it.

`<rant>`

Caps lock keys are artifacts from they days when pressing a key on a keyboard
provided the energy to swing a little letter clad hammer aggressively at a
piece of paper. To type an uppercase letter, the shift key would lift a tray of
keys to change to a different set of hammers, so holding the shift key down
would require quite a bit of force and would strain people's pinkie finger. The
caps lock key was added to reduce this strain. Pressing it once would lift the
uppercase tray into place and pressing it again would lower it again.

These days are long gone, but the key is not. Many computer users (without a
disability) are able to type while holding the shift key if they really need
too. Since I am able to, I opt to use one of the best placed keys on the
keyboard for something useful: Another control key.

Since I use Tmux and Vim so much, having a better placed control key is really
useful. When I am chording control with a key on the bottom row I use the left
control key and when chording with a 'home' row, or an top row key I use the
"Caps Lock" key. It's pretty great.

`</rant>`

### Terminal

While looking at a lot of other peoples configurations, I realized a lot of
other people using [iTerm2][ITERM2]. However, since I used Linux rather than OS
X, I have to use another terminal: [urxvt][URXVT]. It doesn't have the fancy
GUI that iTerm2 has to configure the terminal, which is fine for normal use
since I don't have to change options much once I have found a comfortable
configuration. But I use a small font on a dark background, which is not great
for presentations. To rectify this I use gnome-terminal and gvim (gnome-vim)
which have been set up with a large font and light background.

## TL;DR

I have a pretty cool configuration.

[STATE]:https://github.com/hockeybuggy/dotfiles/tree/533ddd69f50f7ac16d37a79fc0ae347a44abf754

[TPOPE]: https://tpo.pe/
[PATHOGEN]: https://github.com/tpope/vim-pathogen
[GITSUB1]: http://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/
[GITSUB2]: http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/

[AIRLINE]: https://github.com/bling/vim-airline
[AIRLINEDEMO]: https://github.com/bling/vim-airline/wiki/screenshots/demo.gif
[SPELLFILE]: https://raw.githubusercontent.com/hockeybuggy/dotfiles/master/vim/spell/en.utf-8.add

[Z]: https://github.com/rupa/z

[i3]: https://i3wm.org/
[THOUGHTBOT]: https://thoughtbot.com/
[TAT]: https://github.com/thoughtbot/dotfiles/commits/master/bin/tat
[CHRIS]: https://github.com/christoomey
[VIMTMUXNAVIGATOR]: https://github.com/christoomey/vim-tmux-navigator

[ITERM2]: https://iterm2.com/
[URXVT]: https://wiki.archlinux.org/index.php/rxvt-unicode

State of the Dotfiles

Today I made a change to this blog. I hope that you can't see the difference
between the site now and an archived copy from [last month][archive]. The
change that I made (as you may be able to tell from the title) was to add
semantics to the site.

I was prompted to add semantics after giving some thought to how accessible my
site was to people who use screen readers. After doing some research I realized
that by changing some of my markup and less of my CSS the site would be able to
be better traversed by screen readers. I did quite a bit of my research at
[html5doctor][html5doc]. Here is a summary of the changes I made:




## Landmarking elements

Some elements exist on most websites. Screen readers allow people to jump
between these common elements using semantic tags that perform the same role on
every tag.

### header

The top of the page that in my case includes the title and the navigation bar.

### nav

The unordered list of links to other sections of the page. The tag for this is
\<nav\>.

### footer

The bottom of the page that in my case includes links to the rss feed, twitter,
and Github.

### main

This tag denotes the main section of the page. On each page this is the section
that is light-blue.

### article and section

These tags denote an atom of the page. Each of the *section*s denote a
particular area of the page. The article tag is a particular type of section.
To decide wither I should have used one or the other I looked [here][artVsSec]

## Improving SEO

This is not just an improvement for people using screen readers, but for
everyone. When I searched for my page on the one search engine *to rule them
all* I saw that the listing for my homepage looked really ugly. All of my other
pages had enough content to look ok but because my homepage was just a list of
other pages it looked like this:

![Image of my homepage's Google results before the change][SEOimage_before]

The 'fix' for this was to add a small paragraph of text explaining the intent
of this site. The listing now looks like this:

![Image of my homepage's Google results after the change][SEOimage_after]

---------

Note = I do recognize the irony of having a picture of words on a page that
discusses making the site better for screen readers. If you are reading this on
a screen reader = Sorry.


[archive]: https://web.archive.org/web/20140517102136/http://hockeybuggy.com/
[html5doc]: https://html5doctor.com/
[aria]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA
[artVsSec]: http://www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-difference/

[SEOimage_before]: /static/img/SEO_before.jpg
[SEOimage_after]: /static/img/SEO_after.jpg

Adding Semantics

Around the beginning of April last year I started to have problems generating
my site from it's source code. At the time it was using [Pelican][PELICAN] and
was somewhat enjoying what it provided. However then it stopped working.

For some time I was having problems working on the site on different computers.
I was using virtualenv to create little bubbles to work on the website from
within but it was proving to be more effort than it was worth. But when site
broke on the computer it original worked on, I become determined to find a new
static site generator.




## Why Jekyll

And now after what has been far to long a time I have decided to move my old
posts to [Jekyll][JEKYLL]. Jekyll seems to be by far the most used static site
generator likely thanks to it adoption by [Github][GITHUB].

I really like Jekyll's approach to static site generation. When using the
Jekyll tool to create a new site I found that it did not take many assumptions
as to how I would like the site to be laid out. I also enjoyed having all most
of the files in the root of the project.

## New Face

So now that I have to redo all of my markup I figured it was time for a new
face for the site. I keep the same colour scheme(borrowed from:[here][COLOUR])
and added some icons in the footer.

[PELICAN]: https://docs.getpelican.com
[JEKYLL]: https://jekyllrb.com
[GITHUB]: https://pages.github.com
[COLOUR]: https://bit.ly/9oo0N3

Migrated to Jekyll

Recently I have been working quite a bit on my Vim skills. If you don't use Vim
and don't want to read about a text editor you may wish to stop reading here.
For the past two years I had turned off the arrow keys in Vim. I did this with
the hope that I would stop having to move my hands from the home row. A couple
of months ago I gave myself the arrow keys back to see if I was ready to use
them responsibly. I found that I was (mostly) ready and stay on the home row
most of the time when moving around.




After reading [Practical Vim](https://pragprog.com/book/dnvim/practical-vim)
I started to use more word-wise operations (e.g. w,e,b,ge).
The word-wise motions moves the cursor around based on word
characters(a-zA-Z0-9). While
this is much much faster then the hjkl motions, they feel slow when you know
where in the text you want to go. The word-wise motions feel like they grind to
a halt when they hit URLs because of how many sub "word" a URL is made of.

The solution to this is the f, t, F, and T motions. These commands move to the
next occurrence of the supplied character. The f command moves **F**orward to the
next occurrence and the t command moves forward up **T**o the next occurrence. The
F and T commands are similar to their lower case counterpart except that they go
backward. At first I found it hard to picture how these motions would look like
in operation. When I was learning word-wise motions from Practical Vim I found
one of the figures greatly helped my understanding and I looked for a similar
graph for these character-wise motions. Failing to find one I made one and
thought I should share it here.

<img class="center" src="/static/img/fasterthanwordwise-800.jpg" alt="An image I made explaining some of the character-wise motions"/>

These commands are complimented by the ; command that repeats the most recent
motion. This becomes useful if you trying to move to a character and fall short
because you did not see another closer occurrence of a character. Rather then
retyping the motion and the character (two things) you can just hit the ; key
to repeat (one thing). As one of the goals of using Vim is to avoid repetition
we should try to remember to use the ; command.

Another thing that can make these motions useful is to preface them with a
count. If you do instead of taking the first occurrence of a character it will
take the count'th occurrence.

Moving beyond word-wise motions

So if you have seen the site before this post you will have noticed that we(the
royal we [aka. we := I ])
have gone though (and are going though) some changes in the layout of the site.




This new change is a result of changing from the static css about a week ago. I
knew that pelican had picked up less support but I did not realize the extent
of the power of the webassets module. I wanted to start with precompiled css
language and I picked up less first. I Started to used it and recreated my
previous css quickly in fewer lines. But as I used it more and did more
research on scss I started to think about how the syntax is nice.

Why do I prefer scss? Here are my thoughts:

##Reason number 1:

I prefer the usage of the '@mixin' and '@include' keywords that sass uses.
The alternative syntax for less would be a mixin name prefixed by a period
followed by parentheses. eg.

### LESS

    #container {
        color: black;
        .rounded-corners(10px);
    }
    .rounded (@radius: 5px){
        border-radius: @radius;
        -moz-border-radius: @radius;
        ...
    }

vs.

### SCSS

    #container {
        color: black;
        @include rounded-corners(10px);
    }
    @mixin rounded ($radius: 5px){
        border-radius: $radius;
        -moz-border-radius: $radius;
        ...
    }

When you are scanning though your code it would be nice to be able to see
things as context free as possible so going through the hassle of writing more
with scss is some-what worth it.

##Reason number 2: 

I like '$' more the '@'.  @ is two keys farther away from the
middle the $ which makes it kinda annoying when you are typing in a lot.

A new a stylish look around the site. Thanks to sass

It is finally time to publish this website. I do not imagine that it is anyway
complete. However I really do want to have something existent up and online.

Things that still need to happened for the site is it still needs a slightly
nicer colour scheme. I however do not really have an overwhelmingly strong
sense of style.

Blog Posts