
For the first time since 2013, I have completed my year-end post before the calendar turns over.
I think the key is skimping out on the intro paragraph.

## Building stuff

I remain enamored with [my reMarkable 2](/posts/remarkable-2) after 14 months of daily use. The
large-eInk-screen-with-low-latency-pen-input device really feels like a new medium with a ton of untapped
potential. My recreational coding time this year was dedicated to enhancing my reMarkable’s utility. I built:

* A service that sends a twice-a-day pdf “newspaper” from RSS/reddit/twitter feeds straight to my
  device. I’ve been using this for 9 months and still look forward to the paper every time.
* A fully hyperlinked day planner for consolidating several of my rM notebooks into one pdf (more
  on this in the next section)
* several custom template files for my specific note-taking workflows

## A "real" side project

That [reMarkable day-planner](https://hyperpaper.me/) took on a life of its own after sharing it on
reddit, and for the first time I made a little income from a side project. Not enough to pay even a
single month’s rent, mind you, but it’s still been enormously satisfying to receive the positive
feedback and email from satisfied customers. You can, and should, order your own custom planner at
[hyperpaper.me](https://hyperpaper.me). I hope to write up a post at some point with "lessons learned"
from putting this out there.

## Reading

I read 57 books this year (gotta keep sharing my personal vanity metric). Favourites were:

* Masters of Doom
* The Art of Postgres
* The Psychology of Money
* Lives of the Stoics
* Burke’s Law
* Shape Up
* Carrying the Fire
* Bullshit Jobs
* Strong Towns
* How to Avoid a Climate Disaster
* The Vignelli Canon
* A Wealth of Common Sense

## Links

My favourite links on Pinboard over the year:

* [Visualizing a codebase](https://next.github.com/projects/repo-visualization)
* [Dream - tidy web framework for OCaml](https://aantron.github.io/dream/)
* [Fontshare](https://www.fontshare.com/) (I love me some pretty free fonts)
* [This Video Perfectly Explains Vancouver’s ‘Missing Middle’ Housing Mystery](https://thetyee.ca/Analysis/2020/12/14/Vancouver-Missing-Middle-Housing-Mystery/)
* [How to make space](https://www.capitaldaily.ca/news/blanket-zoning-pre-zoning-city-initiated-rezoning-victoria)
* [How Big Tech Runs Tech Projects and the Curious Absence of Scrum](https://newsletter.pragmaticengineer.com/p/project-management-in-tech)
* [How to avoid layout shifts caused by webfonts](https://simonhearne.com/2021/layout-shifts-webfonts/)

## Music

I am an old man, so it’s rare for a new album to trigger both intense anticipation and thorough
enjoyment. But [An Evening with Silk Sonic](https://www.youtube.com/watch?v=xA5hlB6bScc&list=PL9wpmMBKluP5LdNQDubgQvTDAgPtghZtC)
absolutely knocked it out of the park for me. It was easily my favourite new album in years, and if
you enjoy vintage R&B/funk/soul you need to check it out.

## Goings on with this personal website

I inexplicably re-built this site for a second straight year. For those keeping track at home, the
technology arc has been `Jekyll on GitHub Pages` -> `11ty on Netlify` -> `NextJS on Cloudflare
Pages`. NextJS was a project I wanted to explore, and I really enjoy how it abstracts away the usual
webpack/babel/typescript config shenanigans for you. Would recommend, so far.

I wrote [a single post](/posts/vim-plugins-revisited), which is actually enough to exceed
my average throughput over the past 5 years (!). Hope to see you again in 2022.



2021 Review


Over 6 years ago (!) I wrote a [little post](./vim-plugin-essentials) here about the vim plugins I
found most useful. In honor of [the Neovim 0.5 release last week](https://neovim.io/news/2021/07), I thought it would be worth revisiting
my plugins of choice, and reflect on how they've changed over the years.

Neovim 0.5 is really a game changer in a lot of ways, and its impact on my setup has been significant.
Native [LSP](https://microsoft.github.io/language-server-protocol/)
support and treesitter integration are two of the exciting headline features, but in my mind, the
biggest game-changer is the first-class support for scripting _everything_ in Lua. Many of the plugins
I've migrated below are fully implemented in Lua, and it's amazing to think that the community is just getting
started in harnessing a "proper", and much faster, built-in scripting language.

## Version control integration
**Then:** gitgutter  
**Now:** [gitsigns](https://github.com/lewis6991/gitsigns.nvim)

Gitgutter served me well for a very long time! However, with gitsigns the VCS feedback appears much,
much faster, and that was reason enough for me to switch. I also prefer its more understated use of
the sign column.

## Diagnostics
**Then:** Syntastic  
**Now:** [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig)

I have to give a shout out to [ALE](https://github.com/dense-analysis/ale) and [coc-nvim](https://github.com/neoclide/coc.nvim), two great
projects that I used for long stretches over the last five years. But as far as I'm concerned,
Neovim's built-in LSP integration is absolutely the future in this space.
I'd been cautiously kicking its tires before it was stable in 0.5, and ended up switching earlier
than I'd anticipated thanks to the phenomenal performance increase over coc.nvim.

## Syntax Highlighting
**Then:** vim-polyglot  
**Now:** [nvim-treesitter](https://github.com/nvim-treesitter/nvim-treesitter)

Another performance-related switch here, based on a new feature in Neovim 0.5. I have only
scratched the surface of what the treesitter integration has to offer, but am also excited about
features like [language-aware text
objects](https://github.com/nvim-treesitter/nvim-treesitter-textobjects). Again, the future in
Neovim is really bright now that these tools are in the hands of an active development community.

## Autocomplete
**Then:** ???  
**Now:** [nvim-compe](https://github.com/hrsh7th/nvim-compe)

Hard to believe I used vim for years without decent autocomplete. Sorry, vim curmudgeons, but modern
editors have raised the stakes here, and the built-in [Omnicomplete](https://vim.fandom.com/wiki/Omni_completion)
just doesn't measure up anymore. nvim-compe is snappy (thanks in part to Lua) and has a configurable
list of sources (including, most notably, neovim's LSP client). I don't quite
have the snippet support set up to my liking yet, but in every other respect it's been a great
experience so far.

## File finder
**Then:** Ctrlp.vim  
**Now:** [fzf.vim](https://github.com/junegunn/fzf.vim)

Looking at the list of file finders in the original post was quite a trip down memory lane. Again,
I switched to fzf eons ago, and I think the killer feature for me, besides the speed, was having the
same file searching available in the shell. There are fancier new options available like
[telescope.nvim](https://github.com/nvim-telescope/telescope.nvim), but after a cursory exploration
I've decided I'm quite happy with my trusty FZF setup.

## Grep frontend
**Then:** Ags.vim  
**Now:** [CtrlSF](https://github.com/dyng/ctrlsf.vim)

I've been using CtrlSF for ages as well, as a UI for grepping across a project (via the spectacularly
fast [ripgrep](https://github.com/BurntSushi/ripgrep)). It's modeled on Sublime Text's
project search, supports editing multiple files via search results, and is fairly customizable.

## Wrap up

My full [init.vim](https://github.com/af/dotfiles/blob/master/vim/init.vim) is up on GitHub,
with a few other miscellaneous plugins and supporting config. Notably, I've started moving some of
my more involved keybindings and supporting functions to lua modules. I'm still far from a Lua
ninja, but compared to vimscript, making these kinds of customizations is significantly easier.

To some readers, spending years customizing a text editor probably seems frivolous, an extravagant
waste of time. Why not just use VS Code? I can understand that perspective, but also derive a deep
satisfaction every time I'm able to sculpt the digital environment where I spend hours each day in
a way that fits my brain better. I'm very much looking forward to further exploring the new sculpting
tools in Neovim 0.5.


Vim Plugins Revisited – Neovim 0.5 Edition


Well, that was... a year. Like most people, for me 2020 was somewhat less than ideal.
But at the end of the day the upheaval and restrictions have made me very thankful to live with
people I love deeply, to have a livelihood that was only briefly interrupted by the pandemic, and to
have a clean bill of health. With those I escaped 2020 more fortunate than most.

I'm not going to spend too much time re-immersing myself in that dumpster-fire-of-a-year, but what
follows is the usual listicle of the books, tech, and miscellaneous stuff that helped me get through
it.


## Reading

For most of 2020, there wasn't a lot to do but hunker down and read. Fortunately for me, this is how
I spend most of my free time already. Some of the books I most enjoyed:

* Hillbilly Elegy
* Moonwalking with Einstein
* Programming with Types
* The Road
* Programming Rust
* The Soul of a New Machine
* Bowling Alone
* The Information
* [Hell Yeah or No](https://sive.rs/n)
* How to Live- a Life of Montaigne
* The Nurture Assumption
* Reinventing Comics


## Programming/Technology

You may have noticed above that like every other programmer and their dog, I spent a little time
with Rust recently. While the language is too low-level for my current needs and
tastes, I was impressed and inspired by its tooling and the deep integration of typed functional
programming idioms in the language. Dipping my toes in was a great learning experience and I expect
that I'll return to it at some point. Maybe lifetimes and the borrow checker will "click" for me
next time.

Most of my other programming endeavors have been in TypeScript for the last 18 months. The language is
still adding interesting features and I still feel like there is more to learn. For UI work,
I'm quite satisfied with TypeScript/React/Apollo.


## Links

From time to time I add a `top` tag on Pinboard to items that I particularly like (they show up as
bigger circles on my homepage's beeswarm chart). The ones I tagged in 2020 were:

* [Use the D3 Force](https://wattenberger.com/blog/d3-force)
* [Roy Fielding's Misappropriated REST Dissertation](https://twobithistory.org/2020/06/28/rest.html)
* [On Coding, Ego and Attention](https://josebrowne.com/on-coding-ego-and-attention/)
* [My Engineering Axioms](https://martinrue.com/my-engineering-axioms/)


## Board games

Have I ever mentioned here that I'm a big ol' board game nerd? Before the current restrictions on
social gatherings were in place, I had a lot of fun gathering with friends and family for the odd
game night. I don't record new games or plays, so some of these are probably from 2019, but below
are some of the "new" games I've most enjoyed recently:

* [Root](https://boardgamegeek.com/boardgame/237182/root)
* [The Crew](https://boardgamegeek.com/boardgame/284083/crew-quest-planet-nine)
* [Brass: Birmingham](https://boardgamegeek.com/boardgame/224517/brass-birmingham)
* [The Quest for El Dorado](https://boardgamegeek.com/boardgame/217372/quest-el-dorado)
* [Hanabi](https://boardgamegeek.com/boardgame/98778/hanabi)


## This site

I moved this site from Jekyll to Eleventy this year, but that was pretty much the extent of the
effort I put into it. I certainly appreciate the dramatic improvement in build speed, but otherwise
it was a mostly lateral move. After playing around with NextJS a few months ago (and being quite
impressed), I'm already considering another migration. These technology changes are pointless,
low-impact projects, but they're also decent ways to kick the tires on new technology and learn a
few things.



Surviving 2020


For a programmer, I'm not too big on gadgets. I've never owned wearable or "smart speaker"
devices, and view my phone more as a necessary evil than anything. There is one category of gadgetry that I've eyed
longingly for many years though– large-format EInk reading devices with stylus/touch and reasonable page refresh
rates. This year I finally gave in and purchased a [reMarkable 2](https://remarkable.com/),
hoping it would be a productivity boon and lessen my regrettable dependence on [glowing rectangles](https://www.theonion.com/report-90-of-waking-hours-spent-staring-at-glowing-re-1819570829). This post is a review of
how I'm finding it after about two months of use.

If you look solely at the spec sheet, the reMarkable 2 (aka RM2) is a pretty underwhelming product. Monochromatic screen.
Meagre feature set. Underpowered CPU. No third-party apps, audio, backlight, or Bluetooth. As a distraction-free
reading/writing/organization niche device, some of those are anti-features, but others would
improve the product, depending on what your primary use case is. I would be remiss if I didn't mention
another important downside– the RM2 is freaking expensive! I preordered the RM2, which knocked a few
hundred bucks off the current list price, but if I was considering the purchase today, I would have
a hard time justifying it.

I've been using the RM2 primarily as an notetaking device (its raison d'étre) and e-reader. Anyone
who's worked with me in an office can probably remember messy piles of post-it notes on my desk;
I've always found notetaking and sketching to be extremely helpful as thinking aids, and being able to mix
digital organization with analog-style tactile immediacy with the RM2 has been a big win. The
writing experience on the device is very good, and that's undoubtedly what most people are going to
be purchasing it for.

As an e-reader, the RM2 is more of a mixed bag. The e-ink screen is gentle on the eyes, and the
10.3” screen is a near-perfect size for the technical books (nicely formatted PDFs) that I've been
accumulating over the years. The refresh rate is good enough, though noticeable, and it's great to
have all of the same annotation tools for books that are available for notetaking. The flip side is
that the reading software is inexcusably limited. There's no way to see a list of pages with annotations,
bookmark a page for later (!), or follow pdf links. It's mindboggling
that after several years of developing the reMarkable software, these features are absent, but they
update the software semi-regularly so I hold out hopes that they might get added later.

The hardware design of the reMarkable2 is undoubtedly it's strongest point. Not only is the RM2
svelte and solid, both the tablet and the pen have wonderful physical textures, which make handling and using
the device a really pleasing tactile experience. The magnets that keep the pen and folio connected
to the tablet are strong and give a satisfying "click" as the pieces snap together.

For the technically inclined, the RM2 is also surprisingly open. It runs Linux and you can
ssh in as root to modify files and install (not officially supported) software and
[hacks](https://github.com/ddvk/remarkable-hacks). I have yet to try the "hacks" but it appears to
paper over some of the more frustrating limitations of the stock UI.

Overall, I haven't been this smitten with a piece of hardware since the iPhone 3G (my first smartphone, over
a decade ago). Despite its warts, the reMarkable 2 is now an essential part of my workflow and
I would dearly miss it if something happened to it.


## Misc thoughts

* A lot of reviews directly compare the RM2 to an iPad, but the experience with each device is
  markedly different. To me placing them in the same category is almost nonsensical, though they're
  both nominally "tablets".

* My kids really enjoy the RM2 as well. It's been a great motivator to practice their writing, but
  it physically pains me to see (and hear!) how much pressure they apply with the stylus (see nib
  wear, below)

* Nib wear was a concern of mine before getting the RM2, as it looked like regularly replacing
  the nibs had the potential to add a significant recurring cost. As I was writing this post,
  I just replaced my first nib, after 6 weeks with the device. It seems the amount of pressure you apply
  when writing is a major factor in how quickly you'll go through nibs, and if not for my kids’
  aggressive use, I think the nibs would each likely last over two months.

* reMarkable also has a Chrome extension that lets you send articles to the device via their cloud
  service. It's pretty limited (images don't make the journey to the tablet if you use the default
  epub document export), but reading long form content is _so much better_ on the RM2 vs a laptop
  that I find myself using it frequently.

* If you're interested in the reMarkable, you really need to check out the [reviews from
  My Deep Guide](https://www.youtube.com/playlist?list=PLsSI9-gaSSmiXwb7Vjk5Vb-nB41UTnrXd) on Youtube.
  They're probably the most in-depth and unbiased reviews of a product I've ever seen, and will go
  a long way to help understand if the RM2 would be a good fit for you.


Review– reMarkable 2


Another year, another review post. I'm keeping this one extra simple so I can actually get it out
on time for once.

## Learnings in Technology

I jumped on the TypeScript hype train in 2019 and have been pretty impressed with it so far. After
spending the better parts of 2 years using Flow, it was increasingly feeling like a dead end. By
comparison, TypeScript has a massive (and growing) community, fantastic developer tooling, and
decent documentation.

After tinking with OCaml/Reason for the last few years, I definitely miss [variants](https://v1.realworldocaml.org/v1/en/html/variants.html) (TS enums are a pale substitute) and pattern matching. But TS seems to be the most pragmatic typed frontend language around
right now– 80% of the type safety with 20% of the effort required to get up and running with the more ironclad but obscure
alternatives. It's also infinitely more employable, which is a _little bit_ of a bonus.

Another language I spent a little bit of time with in 2019 is Lua. I'd previously messed with it
a bit for use with Hammerspoon, but this year Neovim got first-class Lua support so I've been
playing with it a lot more. Being able to script Vim without VimScript (ugh) or remote plugins is
a treat!

## Reading

At the start of the year I set out a list of 12 books that had been lingering on my shelves
(physical or virtual) for years. Because I impulsively check out a lot of books from the library, it
came down to the last week, but I managed to read them all. In decreasing order of my enjoyment, they were:

* The Enchiridion
* Drawing on the Right Side of the Brain
* High Performance Browser Networking
* Domain Modelling Made Functional
* The Elements of Graphing Data
* Badass: Making Users Awesome
* Getting to Yes
* The C Programming Language
* The Psychology of Computer Programming
* Universal Principles of Design
* Domain Driven Design
* Clean Code

In total I read 59 books, which is pretty solid. Actually, it might be the most I've ever read in a calendar year.
Other standouts read in 2019 included:

* Atomic Habits
* Factfulness
* Why We Sleep
* Digital Minimalism
* The Coddling of the American Mind
* The Attention Merchants
* Siddhartha
* Creative Selection
* The Handmaid's Tale
* Super Pumped: The Battle for Uber


## Music

As I age, I find it progressively more challenging to find new music that resonates with me. So
I was really excited to find [Tiny Desk Concerts](https://www.youtube.com/playlist?list=PL1B627337ED6F55F0) this year.
The videos cover a wide set of genres, and the artists and sound quality are consistently awesome.
My favourite video so far is [the one featuring Joey Alexander](https://www.youtube.com/watch?v=_NIFz8wRvMs&feature=share),
and I had the good fortune to see him in concert this year. It was the best show I've seen in
years– he melted my face off!

## This site

This personal site got a fresh coat of paint late in the year, and I _almost_ got a real blog post out,
but not quite. With my flagging enthusiasm for posting here and the visceral cringe I get when
reading my old posts, I periodically wonder if keeping this site up is worthwhile. But independent blogs
are a somewhat imperiled medium, and one that I get a lot of value from. I want to do my part, however
tiny, at contributing to the ecosystem. Here's to renewing it for another year!


2019 Review


Just like last time around, my "year in review" post is comically late. This time it was so bad
I artificially back-dated this post. My blog, my rules!

## New Year, New City

I will keep this post brief as at this point I forget most of the details of 2018. However the big theme
was moving cities for the first time in my adult life. After many years in Vancouver, we picked up
and moved to Victoria in August.

The “Why I'm leaving Vancouver” blogpost is a well-worn trope by now, but I will continue to resist
the urge to indulge. I was hesitant about the move myself, but with several months of hindsight it
has been a great change. Victoria is extremely bikeable, there's less rain, and the laid-back vibe
suits my disposition well.

After considered it for many years, the move gave me the opportunity to dive into remote work.
Once I worked out the kinks in my workspace and daily routine (perhaps fodder for a future post), I'm
pleased to say that I've really enjoy it. I was already spoiled with a short walking commute in
Vancouver, but the flexibility of schedule and proximity to family is hard to beat.


## Tech things

Open source and on-the-side coding took a backseat to “real life” priorities this year. I continued
to monitor the ReasonML ecosystem, hoping its community would take off and I could justify pitching it
seriously at work (hasn't happened yet). Work kept me busy and I was able to focus on helping build
a large frontend app (React/Redux/etc).


## Books

I still managed to read a fair bit this year (56 books!). Here were my favourites:

* [Code](https://www.amazon.ca/Code-Language-Computer-Hardware-Software/dp/0735611319)
* [Man's Search For Meaning](https://www.amazon.ca/Mans-Search-Meaning-Viktor-Frankl/dp/080701429X)
* [When Breath Becomes Air](https://www.amazon.ca/When-Breath-Becomes-Paul-Kalanithi/dp/081298840X)
* [Homo Deus](https://www.amazon.ca/Homo-Deus-Brief-History-Tomorrow/dp/0771038704)
* [Dune](https://www.amazon.ca/Dune-Frank-Herbert/dp/0441172717)
* [Wait Until Spring, Bandini / The Road to Los Angeles / Dreams From Bunker Hill](https://www.amazon.ca/Bandini-Quartet-Spring-Angeles-2004-06-21/dp/B0182POW08)
* [How to Change Your Mind](https://www.amazon.ca/Change-Your-Mind-Consciousness-Transcendence/dp/1594204225)
* [Building Stories](https://www.amazon.ca/Building-Stories-Chris-Ware/dp/0375424334)
* [Refactoring UI](https://refactoringui.com)


## A New Habit

I started doing some light journalling. It's been helpful at times to get thoughts out of my
head and onto the page. Clearly it hasn't translated to increased blog output yet though!


2018 Review


Are you allowed to do a "year in review" blog post when it's already well into ~~February~~ ~~March~~
April? Despite the temptation to sit on this work in progress until August for maximum comedic
effect, here it is, warts and all.


## Most Exciting New Technology

It was [ReasonML](http://facebook.github.io/reason), hands down. Last year I kept close tabs on
this fledgling "language" (it's really just a toolset around the venerable OCaml), and was richly
rewarded. The community is incredibly friendly, and there is so much neat stuff to learn by diving into
a typed functional language. I wrote a [canvas-based game](https://github.com/af/shmup.re), started
working on some (very incomplete) [d3 bindings](https://github.com/af/bs-d3), and am kicking around
a few more small projects for fun. I will definitely be spending a lot more time with Reason this year!


## Best Return on Investment

I previously wrote up [my review](/posts/learnui-design-review/) of the UI design course that
I took early in 2017. While I don't do any design day-to-day, I'm really enjoyed continuing to pick
at this hobby, and dipping back into the course videos and homework from time to time. If you are
an analytically inclined person looking to gain some design skills, I still highly endorse it!


## Best Books

After chewing through 45 books last year, I think might have hit a new personal high score. Looking
through the list, only of few of them were truly exceptional:

* [Deep Work](https://www.amazon.com/Deep-Work-Focused-Success-Distracted/dp/1455586692/)
* [Flour Water Salt Yeast](https://www.amazon.com/Flour-Water-Salt-Yeast-Fundamentals/dp/160774273X)
* [The War of Art](https://www.amazon.com/War-Art-Through-Creative-Battles/dp/1936891026)
* [Ask The Dust](https://www.amazon.com/Ask-Dust-John-Fante/dp/0060822554)
* [The Brothers Karamazov](https://www.amazon.com/Brothers-Karamazov-Fyodor-Dostoevsky/dp/0374528373)


## Best New Hobby

I started taking to baking bread. *Flour Water Salt Yeast* was inspiring, and breadmaking is
a wonderfully tactile counterpoint to my usual computer-based hobbies. After a half dozen mildly
successful attempts at sourdough, I'm now working on mastering a more basic white bread. The plan is to
work up through pre-ferments and then back to regularly baking sourdough.

Also in the kitchen, I joined the cult of the Instant Pot. I'm only a few months in, but it does
seem like a really useful gadget.


## Best Music

Still going through a bit of a dry spell as far as discovering new music goes. But while going through
Stevie Wonder's [classic period](https://slate.com/cover_story/2016/12/the-greatest-creative-run-in-the-history-of-pop-music.html),
albums, I finally found *Fulfillingness's First Finale*, which is now one of my all-time favourite
records.


2017 Review


> The following is my take of the [Learn UI Design](http://learnui.design/) video course. I paid for access to the course when it was in alpha last year. As the course is accepting new students soon, and I haven't seen too many longer-form reviews online, I thought this post might be helpful to anyone who's considering the course, but not sure if it's right for them.


## My Background

As a programmer, I've always been drawn to the visual side of my field. I vividly remember making my first game (pong in Python!) and how amazing it was to watch things move crudely around the screen. Later on I worked at a small startup that didn't have a full-time designer, and acutely felt the pain of trying to put together styles and imagery that didn't look awful. As easy as some people make it look, designing user interfaces is a full-time craft, and unraveling its secrets is a challenge for most of us.

Despite chewing through countless articles and books over the years, passable design skills remained elusive for me. While some of these resources were excellent, at best they only gave me familiarity with concepts and terminology. Whenever I tried to actually build something visual, I got the same uninspired (or just plain ugly) results.

I subscribed to Erik Kennedy's email list after reading one of his excellent [Medium posts](https://medium.com/@erikdkennedy), as he communicated design concepts in a way that made things "click" a bit easier for me. So naturally when he announced his [online design course](http://learnui.design) I was very interested. I signed up for Learn UI Design about a year ago, near the end of the first batch of students.


## The Course

Learn UI Design is a hands-on video course, with an accompanying Slack channel for discussion and feedback. I won't rehash the syllabus here– you can a clear overview from [the website](http://learnui.design). The videos are extensive (18+ hours in total), well produced, and easy to follow. Each topic is dealt with thoroughly, and I can't remember finishing a video and feeling like anything had been skipped over. My only (minor) complaint is that I'd love to see a few more subjects added, like animation basics, and maybe some UX topics. Erik is still adding new content over time, so it's possible the scope could widen a bit in the future.

If you like Erik's teaching style from his Medium posts, you'll find it translates well to the videos. Maybe it's the cynical programmer in me, but a lot of design instruction out there comes across as overly artsy or "hand wavey". Erik's style is the opposite– very direct and pragmatic.

The Slack channel is a really helpful component of the course as well. When I signed up I thought it was kind of a "throw in", but being active there is pretty integral to getting the most value out of the course. Besides the general banter and tips, posting homework solutions there for feedback has been really helpful. I'm a perfectionist and I hate putting my work "out there" when I'm not confident in it (every blog post here is a struggle), so this was tough for me at first. But the other students have been really friendly and helpful, and Erik's direct feedback has been invaluable. The level of feedback and mentorship he provides each student is really commendable.


## Key Takeaways

Remember how I said the course has two main components? There is also a third part that I think is perhaps the most important of all: the homework. Looking back at my previous attempts at learning design, my biggest mistake was not getting enough reps in with the concepts I was reading about. Most videos in the course come with one or more related homework assignments, so you can apply your new knowledge right away. Maybe the idea of homework makes you recoil in horror, but if you're serious about levelling up your skills, you need to do the work to get there.

My personal favourite course section is the one on colour– an area that has historically been my achilles heel. Erik does a great job of explaining why HSB is vastly more useful than RGB for design work, and presents lots of useful tricks and heuristics. Other highlights for me are the videos on grids, imagery, spacing, and alignment.

One "meta" takeaway from the course is the importance of iterating on your work. Erik specifically talks about the importance of iteration early in the videos, and applying this lesson pays dividends as you complete the rest of the coursework. Trying to find multiple solutions to problems and tweaking as you go not only makes your designs better, it's also applicable to many other creative disciplines.


## Conclusion

Is Learn UI Design the *best* way possible to learn UI design? I don't know; I haven't tried every course or method, and the answer probably depends on your background and personality. But I can confidently say that nothing I've watched or read has been remotely as helpful for me personally, so I highly recommend it. My recommendation comes with the caveat that you should plan to spend at least 3 hours weekly (ideally 5+) working on the course to get the best results. There's a lot of material and I found it's important to immerse yourself and keep your momentum going.

A year after joining, I still get a lot of value out of the Slack channel, and I have referred back to the videos numerous times (the course gives you lifetime access). There were a few new videos added last week that I still need to catch up on. Anyways, I hope this review has been helpful and gives you a feel for the course. I'm **@af** on the Slack channel and hope to see your work there soon!


“Learn UI Design” Video Course– My Review


Last week I tagged version 4.0.0 of envalid, a Node library for environment variable validation
that helps you avoid [several environment variable antipatterns](http://aaronfranks.com/posts/env-vars/).
For those who have been using it (and may be wary of a major version bump) I wanted to do a quick
write-up of the notable additions. The backwards-compatible changes are small, but there is some
great stuff in the latest version!

Calling envalid "my" library is no longer accurate, as the last few months have brought contributions from several others. In particular [@SimenB](https://github.com/simenb) contributed most of the new code that culminated in this latest major release 👏. 


## What's not new

I've never really described envalid's features in detail here, but briefly, here are some of the things it handles for you out of the box:

* Allows you to declaratively describe the environment your app expects to run in
* Provides several useful env var validators (number, json, email, etc) so that the plain strings you
  get from `process.env` are converted to a useful format centrally, rather than all across your
  app
* It's super easy to define custom validators if the built-in ones don't cover all the shapes of your data
* Wraps the awesome `dotenv` package, so you can drop your development/testing default values in
  a `.env` file instead of hardcoding them somewhere.
* Handy shorthands `env.isDev`, `env.isProduction`, and `env.isTest` to replace the `if
  (process.env.NODE_ENV === 'production')` checks that tend to get strewn about.


## New in v4

Two nice little additions are the use of `prettier` for code formatting and new `host` and `port`
validators. In my experience, hosts and ports are extremely common env vars so it's nice to have
some extra validation baked in for these.

The major (and only breaking) change is to envalid's "strict mode", which gives you some extra guarantees about your validated environment object. In v4, strict mode will throw if you try to set,
or even access, an invalid property on your environment object. If the mistake was a simple typo,
envalid will helpfully suggest a related property that you may have meant.

The following (contrived) example shows how this helps in practice. Note how well it works when
destructuring your env imports– the errors happen at startup time, rather than later on during the
execution of your server route.

```js
// Oops! I forgot a 'T' in there.
// But in v4.x envalid will throw instead of returning `undefined`
const { STRIPE_SECRE_KEY } = require('path/to/my/env/object')

app.get('/customer/info', (req, res) => {
    const stripe = require('stripe')(STRIPE_SECRE_KEY)

    stripe.customers.retrieve(req.user.customerId)
        .then(customer => res.json(customer))
})
```


## The future

It feels like envalid is "mostly done", but I probably would have said the same thing three months ago, before all of the features above landed. It's exciting to see adoption pick up (currently just a shade under 10k monthly downloads) and lots of great community feedback and contributions. Here are a few random ideas I've thought of that might be useful in the future:

* A custom eslint rule to warn when accessing process.env directly – this would in effect force you to access the cleaned env object that you get from envalid.
* Built-in support for designating env vars that are used client-side, and returning a separate
  validated object that you can import from your webpack config.
* Bindings for [Reason](https://reasonml.github.io/)

If you have any other ideas, please drop by the envalid [issue tracker](https://github.com/af/envalid/issues)!


envalid v4


It's another year-in-review post! I'm not really sure why I keep doing these, but I guess everyone
does so why not?


## Best New Technology Learned

I wrote a rambling post about how I was [cautiously optimistic](/posts/rethinking-another-best-practice/)
about GraphQL shortly after it was released. This year I finally took it for a spin on a project at
work, and so far I've been very impressed. We are using [Apollo](http://dev.apollodata.com/) as our
GraphQL client, and it too has been a real treat. I hope to dive into this a bit more in a future
post, but these two technologies have taken a lot of the pain out of writing network APIs
and building isomorphic/universal web apps.

In other news, I spent some time learning the basics of Haskell, which was certainly a mind-bending
experience. Rather than becoming a proficient Haskell programmer, I wanted to become more
conversant about higher-level functional programming concepts. This year I might try dipping into
OCaml or its new variant [Reason](http://facebook.github.io/reason) to further my journey.


## Open Source

I didn't make many open source contributions this year, but two projects of mine did get some
love. [Envalid](https://github.com/af/envalid), my environment variable validation library, got
a complete rewrite to a much saner API. [apollo-local-query](https://github.com/af/apollo-local-query)
is a new, tiny library to make server rendering with the aforementioned Apollo a bit easier.

I don't have any specific goals for open source this year, but I do have a [skunkworks project](https://github.com/af/slashpile) that I revisit every couple of months. Maybe this year I'll sharpen it into a more "serious" project.


## Best Books

Of the ~40 books I read this year there were five standouts. I don't generally read new
non-programming books so I was surprised that three of them were actually released in 2016.

* [The Martian](https://www.amazon.com/Martian-Andy-Weir/dp/0553418025/)
* [Disrupted](https://www.amazon.com/Disrupted-My-Misadventure-Start-Up-Bubble/dp/0316306088)
* [The Food Lab](https://www.amazon.com/Food-Lab-Cooking-Through-Science/dp/0393081087)
* [The Inner Game of Tennis](https://www.amazon.com/Inner-Game-Tennis-Classic-Performance/dp/0679778314)
* [The Subtle Art of Not Giving a Fuck](https://www.amazon.com/Subtle-Art-Not-Giving-Counterintuitive/dp/0062457713)


## This Blog

My investment in this blog was basically non-existent in 2016, and I'm ok with that. Till next
time!


2016 Review


Environment variables are an important part of today's web applications. According to
Heroku's influential [Twelve Factor](https://12factor.net/) philosophy, env vars are the [preferred
tool](https://12factor.net/config) for managing configuration that changes across deployments.

Useful as they may be, without discipline env vars can turn into a liability - acting as chunks of
mutable global state sprinkled throughout your program. Here we'll look at three env var usage
antipatterns that are commonly seen in web apps.


## 1) Lack of Validation

Environment variables are a type of input to your program, and as such should be treated with
suspicion and care. While malicious inputs are generally unlikely in this case, if you expect a
number or an email address and that expectation is not met, it's best to throw an error as soon as
possible, ideally at deploy time. This makes the runtime behavior of your app much more predictable
and eliminates some of the guesswork of configuring your app for others.


## 2) Multiple Points of Access

While validating inputs from the environment is an essential first step, as always it's important
to keep things [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself). This means your logic
for accessing and validating an env var should be contained in a single place, and not duplicated
wherever the variable is accessed. Ideally all direct contact with, and validation of, env vars
should happen in a single place in your program. This also makes it easier to see at a glance what
your program's configuration dependencies are.


## 3) Mutation

From the program's perspective, environment variables are a form of global state. Global state is
not inherently bad if it remains static, but once it changes it becomes a rich
breeding ground for bugs and unexpected behavior. By wrapping env var access in a read-only data
structure, you can side-step these pitfalls and increase the predictability of your code.


## A Helpful Approach

The antipatterns above are applicable to any language or framework. A pattern I've found useful for
sidestepping these issues is to centralize all environment accesses through a single module that
does nothing else. When written in a declarative way, this module also serves as a form of
executable documentation for anyone deploying the app. The rest of your code can import this
module and use it as an immutable map of verified environment attributes.

For nodejs programs, I maintain and use [envalid](https://github.com/af/envalid), which provides an
implementation of this approach, and should effectively mitigate the env vars footguns
described above.


Environment Variable Antipatterns


It’s that time of year again, so here's another self-indulgent reflection on the
last 12 months. I promise to keep it mostly tech-focused this time.


## New Technology for 2015

I can't think of a year in recent memory where I learned so many new technologies.
It’s no exaggeration that my tools of choice are now completely different
than they were just 3 years ago. Of course the rate of churn in the front-end
world has been a frequent topic of lamentation this year, but generally I welcome
all of the great new ideas and libraries that we have to choose from. Here are my
top picks from 2015:

### Redux
Finally, a variant of [Flux](https://facebook.github.io/flux/) that just *feels
right*. I love how beautifully simple the APIs are, and there’s a really great
community and ecosystem sprouting up around Redux. Watch the [conference
talk](https://www.youtube.com/watch?v=xsSnOQynTHs) on how it came to be, and the
really excellent [tutorial videos](https://egghead.io/series/getting-started-with-redux).

### ESLint
It seems a lot of people are moving from JSHint to [ESLint](http://eslint.org),
and it’s easy to see why: style checking, pluggable rules, and a really active
ecosystem make it by far the best JavaScript linter going forward.

### Webpack
[Webpack](https://github.com/webpack/webpack/) takes a lot of heat (often deserved)
for being a beast to configure, but there really isn’t anything comparable for
transforming and bundling web assets. And once you experience [HMR](https://webpack.github.io/docs/hot-module-replacement.html) for JavaScript and CSS, writing a web app any
other way feels painfully archaic.

### Flexbox
I was definitely playing catch-up on this one, but 2015 was finally the year that
browser support for CSS's Flexbox made its widespread use feasible.
If you write CSS and haven’t jumped in yet, check out [how much easier](https://philipwalton.github.io/solved-by-flexbox/) it’ll make your life.

### Neovim
I moved from Vim to [Neovim](https://github.com/neovim/neovim) this year as my main
editor, and it has been remarkably stable for such an ambitious young project.
If you use Vim and aren‘t on an Amiga, I definitely recommend switching, if only
for the async command support (check out [Neomake](https://github.com/benekastah/neomake)).

### React-Native
Since November, I have been spending a lot of time with [react-native](https://facebook.github.io/react-native/). While it is still raw in a lot of ways (particularly the docs),
it is already an incredibly powerful platform for building mobile apps. I am constantly
stunned by 


## Books

Looking back on the 39 books I read, there were surprisingly few technical ones
last year. Of the half dozen tech books, [CSS Secrets](http://shop.oreilly.com/product/0636920031123.do) was *by far* the best. If you have some experience with CSS, I very
highly recommend it. There were a few non-technical standouts as well:

* *The Idiot* (Dostoevsky) - Not nearly as good as *Crime & Punishment*, but still worthwhile
* *Zero to Five* - The best parenting book I’ve read so far
* *The Sandman* (the full graphic novel series) - A really impressive piece of work
* *Zen to Done* - Another take on *Getting Things Done*. Still trying to put some
  of its ideas into practice.


## This Blog

One of my goals for the year was to write a few more things on this blog. While
I missed the goal of one entry per month, I eked out [8](/posts), still far above
my usual rate. Though I'm not particularly proud of anything I wrote, I am glad
that I managed to force some pieces out, just to get the practice. There are no
blog-related goals for 2016, so we’ll see what happens.


2015 Review


Christopher Chedeau posted [an interesting challenge](http://blog.vjeux.com/2015/javascript/challenge-best-javascript-setup-for-quick-prototyping.html) yesterday. A few
[insightul](https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4)
[follow-ups](https://medium.com/@Connorelsea/the-react-curve-3d3b16a54290) have
since made the rounds. The crux of the discussion is that for all of the
increasing sophistication and modularity of web app tooling
these days, it's become increasingly cumbersome to get started with a simple
prototyping project.

I've personally felt this pain on more than one occasion. Excited to try out a new
idea, I bring up my text editor only to realize that I can't remember how to configure
webpack. Or Babel 6 changed a bunch of things that I haven't learned yet, but a library
I want to use depends on it. And on and on. These tooling-related roadblocks can
quickly kill the enthusiasm for an idea.

The [discussion](https://twitter.com/floydophone/status/680226147213426688) around
this issue started by considering the experience of beginners, but soon many
more experienced developers voiced their frustrations with the current state
of webapp tooling. Clearly, both groups of developers are struggling with this,
but their needs are dramatically different.


## Beginners

For those new to web development, we really need to keep the number of suggested
tools and technologies to a minimum. That means no Babel, no JSX, no Webpack, no
Flux/Redux. Before you use these tools you need to understand them. And before
you can understand them, you have to experience the pain points they exist to solve.

A single html file with inline CSS and JS is a great starting point for a beginner.
They can save it locally, instantly use any text editor or environment that they
are comfortable with, and easily publish with something like [Surge](https://surge.sh/).

Of course, using a single html file goes against several web development best
practices, but that is *completely irrelevant* for a beginner. The emphasis should
be on facilitating learning, not conforming to every best practice out of the gate.


## Advanced

For more seasoned developers, part of the problem is the tooling we use
(webpack, babel, etc), once experienced, provide ergonomics that are hard to do without.
I never want to start a project without hot reloading again. It's also increasingly
annoying to eschew ES6 features or write CSS without a preprocessor. If you use
JSX, there's another thing that imposes a build step on your project. These luxuries
trap us in increasingly intricate tooling setups, yet for all but the most trivial
prototypes, I think they provide a net benefit over the lifetime of a project.

It seems people often suggest boilerplates as a solution to the problem. If
someone has already gone to the trouble of setting up all these components together,
why not just pull that in and build on top? Indeed, boilerplates seem to be growing
in popularity and (even more so) in number. However, once you need to deviate from
the boilerplate's built-in conventions, you need to descend into its constituent
tools, sometimes learning them from scratch.

If you're a web developer by trade, I think a *build-your-own-boilerplate* approach
makes the most sense. Instead of cargo-culting someone else's boilerplate project,
take the time to learn your tools thoroughly, set up a boilerplate that you can
quickly clone and extend, and use that for your projects.

With one command your boilerplate should ideally:

* Create a git/hg/whatever repository with an initial commit
* Create a Readme with your project name
* Setup a `package.json` (or the equivalent for your ecosystem of choice)
* Install all of your dependencies
* Start a development server, if applicable
* Open the browser so you can see some `Hello world` output right away

In theory, setting this up should be a one-time cost, paying interest every time you start
a new project. In practice, however, our tools change rapidly and there will always
be temptations to add new libraries and upgrade to the latest and greatest. Resist!
You should really only need to update your boilerplate a few times a year.


BYOB


I saw [on the twitters](https://twitter.com/swannodette/status/677528129418719232)
today that the [classic blog post](https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/) where David Nolen introduced [Om](https://github.com/omcljs/om) is
two years old today. Even though I’ve never written a single
line of Om or ClojureScript, this post (and Om itself) was extremely enlightening
for me. Furthermore I think it’s had a profound effect on the JavaScript ecosystem at large.


## React

It’s hard to imagine now, but the frontend community’s initial response to
[React](https://facebook.github.io/react/) was pretty lukewarm (at least from
where I was sitting). David’s post made a lot of people sit up and take notice.
I don’t think it’s coincidence that [interest in React](https://www.google.ca/trends/explore#q=reactjs) began to really take off shortly thereafter. React’s benefits are pretty
well documented by now, but its widespread adoption was never a given.


## Immutable Data

While certainly not a new idea, immutable data structures only seemed to "catch
on" in the front-end world since Om’s release. Now popular libraries like
[Immutable.js](https://facebook.github.io/immutable-js/)
give them a more familiar JavaScript API, and they’re even [being
proposed](https://github.com/sebmarkbage/ecmascript-immutable-data-structures)
for inclusion in a future version of EcmaScript.


## Single State Atom

Another technique popularized by Om is placing all application state in a single
object. Easy undo/redo and backup/restore are its most commonly cited benefits,
but I'm curious to see what else it makes possible as more people explore this idea.
[Omniscient](https://github.com/omniscientjs/omniscient) and
[Redux](https://github.com/rackt/redux) (among others) have brought it to
JavaScript, and the latter is currently seeing an explosion in popularity.


## Diversity in Frontend Architecture

In late 2013 it seemed like most people were pretty happy writing MVC*-ish* apps
in JavaScript. The Om blog post was one of the first pieces I saw that not only
gave a cogent argument against it, but also presented a reasonable alternative.
A few months later, Flux was released. The breaking of the MVC monoculture has
allowed a lot of diverse ideas to flourish, which has been both fascinating and
illuminating. Let’s hope it continues for a while yet.


The Om Inflection Point


Programmers talk a lot about automation. Once you get infected by the desire to
automate, everything you’ll need to do more than twice in your life must be scripted.
Because hey, you’d probably rather be wasting all that time on a social news
site or something.

There’s one area of our work that we often don’t think to automate, but which
can yield immense time savings: the way we interact with the GUI on our desktops.
Even if you spend the majority of your time in one terminal window, I’m willing to bet
you frequently switch over to your web browser and/or music app.

If you’re on a Mac, this is where [Hammerspoon](http://www.hammerspoon.org/) comes in.
This [strangely named](https://groups.google.com/forum/#!topic/mjolnir-io/4X9f8A2UdHQ)
app gives you a Lua API for a boatload of common desktop and application operations.
Here’s a quick list of what I use it for:

### Launching and switching apps

*Global hotkeys for most commonly used applications, to avoid the `Cmd-Tab`,
`Cmd-Tab`, `Cmd-Tab`, `Cmd-Tab` dance to get to a certain app. Getting
to iTerm is always `Ctrl-2`, regardless of when it was last in focus.*

### Moving and re-sizing windows 

*Basically, this is a simple substitute for a window manager. With one global
keystroke, you can resize a window however you like, send it to a different screen,
or snap it to a grid that you have predefined.*

### System audio control

*Volume/muting, in a way that is more customizable than the default OS controls.*

### Transport controls for iTunes

*Having global hotkeys for music is a godsend. No app (or mental context) switching
is necessary when you're deeply concentrating on something else.*

Hammerspoon’s [API docs](http://www.hammerspoon.org/docs/index.html) have a full list of
everything that’s available. Even after using it for several months, there’s a
lot there that I wasn’t aware of­ new features are being added constantly. My
dotfiles are a pretty simple [starting point](https://github.com/af/dotfiles/blob/master/hammerspoon/init.lua<Paste>) if you’re not sure how to jump in.

I highly recommend checking out Hammerspoon. It’s a robust and extremely powerful
automation tool for areas that you didn’t know you wanted to automate. Using it
has also been a great introduction to Lua, which seems like a nice little language.
If you come across novel applications for Hammerspoon, please let me know. I’m
always looking to expand the ways I use it.


Let’s Spoon



*TL;DR: I made [this visualization](http://aaronfranks.com/votesplit2011) about
vote splitting in the 2011 Canadian election.*


If you're a Canadian and haven't been hiding under a rock, you're probably aware
there's an election coming up. When we're not hearing about
candidates [peeing in mugs](http://www.cbc.ca/news/trending/canada-election-2015-peegate-jerry-bance-1.3218157) or [how Bill C-51 reflects the teachings of Jesus](http://www.cbc.ca/news/canada/british-columbia/holy-tweets-b-c-mp-compares-conservative-party-to-jesus-1.3152178),
we're knee-deep in speculation over who's going to be in power later this fall.

Unless you support the Conservative party *(full disclosure: I do not)*, there's
a good chance you've lamented the "vote splitting" of the left, and the
[tactical/strategic](https://en.wikipedia.org/wiki/First-past-the-post_voting#Criticisms)
voting that seems necessary to prevent Conservative (CPC) rule.

The spectre of vote splitting is invoked countless times in the run-up to each
election, but we rarely get a chance to see how it actually impacts the results.
Meanwhile, the poll numbers we see in the press are almost always the
nation-wide popular vote, which [give no
insight](http://thetyee.ca/Mediacheck/2015/09/16/Stop-Sharing-Nationwide-Election-Polls/)
into what's happening at the riding level.
Since our [first-past-the-post](https://en.wikipedia.org/wiki/First-past-the-post_voting)
voting system means our elections are really
hundreds of separate contests, it's complicated and counterintuitive to see how
changes in popular vote translate to movement in seats.

I took an interest in this topic and built a [data
visualization](http://aaronfranks.com/votesplit2011) that allows you to modify the
popular vote in the 2011 election and see how it would have affected the results.
You can also zoom in and click on ridings to see how each of them would have
played out with your changes, or look at the [absolute best
case of strategic voting](http://aaronfranks.com/votesplit2011/#split=NDP,LPC,GPC-100-Strategic)
in 2011.

Some pointers on using the visualization:

* The purple dropdowns let you move a chunk of the national popular vote from
  one party to another. Each riding, and the national seat totals, will be
  recalculated for each change you make.
* For every redistribution of votes, it's assumed that the same percentage of votes
  will be transferred in every riding. This is clearly pretty simplistic, but it
  would be very complicated to configure and read the results otherwise.
* There's an extra option in the last dropdown called "Strategic". What this does
  is distribute votes to whichever party that had the best chance to defeat the Conservatives
  *in each indidual riding*. It assumes each strategic voter would know which non-CPC
  candidate had the best shot heading into the election.
* You can zoom in, pan around, and select specific ridings to see their vote totals
* Each riding is colour-coded with the winner, and the strength of the colouring
  indicates which percentage of the vote the winner had. Translation: the lighter
  ridings are more hotly contested.
* "Battleground" ridings show up with a hatched pattern. These are ridings where the
  difference between the Conservatives and the top progressive party was less than
  5% of the riding's total votes.
* Things will kinda/sorta work on mobile/tablet, but a desktop browser is recommended
  if you have one.


## Warnings and Caveats

Before drawing any conclusions, it's important to stress
that its data is limited to the 2011 election. This year's election has 30 new
ridings to consider, many existing boundary lines redrawn, and
[polls](http://www.cbc.ca/news2/interactives/poll-tracker/2015/index.html) that
look very different than they did four years ago. In summary, you
really can't extrapolate too confidently from the 2011 results to today. However,
many of the trends and party strongholds remain the same in 2015, and gaining
a better understanding of past results is still useful in revealing the dynamics
of our democracy.


## The Greens

The Green party is the party most frequently
[accused](https://en.wikipedia.org/wiki/First-past-the-post_voting) of siphoning
off votes that could be used to defeat the Conservatives. With the visualization
we can see that even if all 2011 Green voters voted [for the second-place
NDP](http://aaronfranks.com/votesplit2011/#split=GPC-100-NDP), or [voted perfectly
strategically](http://aaronfranks.com/votesplit2011/#split=GPC-100-Strategic), we
would have still ended up with a Conservative government, and still a majority in
the first case. This lends some credence to Elizabeth May's [rebuttal](http://thetyee.ca/Opinion/2015/06/27/May-Green-Party-Does-Not-Split-Vote/) that the Greens did not split the vote
appreciably. But could it be different this year with the top three parties closer
in the polls?


## The Liberals and NDP

If you played around with some of the Green vote scenarios above, you may have noticed
that transfering their votes [to the
Liberals instead](http://aaronfranks.com/votesplit2011/#split=GPC-100-LPC) would
have cost the CPC an extra five seats. This highlights a pattern: even though
the NDP finished second in seats in 2011, the Liberals were actually in more
close contests with the Conservatives and may stand to steal more seats from them.
This may partially explain why most of the CPC's attack ads to date have focused
on Trudeau and not Mulcair, despite the NDP's strength in the polls for much of
the campaign.

There were actually only a handful of ridings where the Conservatives and NDP
were in close competition with each other in 2011. That's why if you are looking to vote
strategically, choosing the top non-CPC party in the popular vote numbers may
be counterproductive; you're much better off looking at
[riding-by-riding polls](http://www.threehundredeight.com/p/canada.html) and
supporting whoever has the best chance of knocking off the Conservatives in your district.


## The Conservatives

One thing that's clear from running through different scenarios is that if the
Conservatives [lost support to the
Liberals](http://aaronfranks.com/votesplit2011/#split=CPC-10-LPC) as current polls
indicate may be happening, they'd be in trouble in many swing ridings across the country.

At the same time, their strongholds in the prairies appear to be very safe­ in some
ridings they collected upwards of 80% of the vote in 2011. There has been speculation that
the NDP's victory in the Alberta provincial election may presage a shift in the federal
election, but it seems unlikely and the [current polls](http://www.threehundredeight.com/p/canada.html) don't support that theory either.


## Takeaways for Progressive Voters

From trying out various scenarios, it seems there are three major classes of ridings
for the would-be strategic voter to consider:

* A: The Conservative stronghold (see all of the dark-blue in Alberta). Polls indicate
  there's a good chance many of these ridings will go CPC once again.
* B: The safe progressive riding. 2+ progressive parties are projected to have a
  higher vote count than the Conservatives, so vote-splitting is less of a factor.
* C: The battlegrounds. The Conservatives and one or more progressive parties have
  a tight race. This is where strategic voting could really make a difference.

If you were to go back in time to re-cast your ballot in 2011, it seems clear that
the majority of ridings are of type A or B. If you lived in one of them, you wouldn't
need to worry about vote splitting at all,
and should vote for the party that best aligns with your values. However, in the
ridings that are [shaping up to be battlegrounds](http://www.votetogether.ca/riding/list/), you may want to vote
strategically, with the help of [VoteTogether](http://www.votetogether.ca/) and
the [current polls in your riding](http://www.threehundredeight.com/p/canada.html).


A few more things that deserve attention for October 2015:

* All major parties beside the CPC have
[pledged](https://www.thestar.com/news/canada/2015/06/16/trudeau-would-end-first-past-the-post-electoral-system.html) to end first-past-the-post if
  elected. So hopefully this is the last election where we even have to think
  about splitting and strategic voting!
* Improving 2011's poor voter turnout numbers (61%) could also have a dramatic effect
  on the results, particularly if [more young people
  voted](https://en.wikipedia.org/wiki/Young_voter_turnout_in_Canada)
* Once again, if you want to vote strategically against the Conservatives, *know your riding*
  and don't let the popular vote influence your decision.

On a final note, the [source code](https://github.com/af/votesplit2011) for the
visualization is available. Please file an issue on Github if you have any suggestions
for improvement.


Does "Vote Splitting" Have a Large Impact on Canadian Elections?


Just over two years ago, Facebook released React. At the time, I joined an
apparent majority of commenters in declaring that it looked weird and clunky.
Inline XML, onclick handlers, markup and logic together... yuck! To say React
has taken off and captured developer mindshare since then is a huge understatement.
Today it feels like every second company is migrating their existing MVC codebase
to React and/or [Flux](https://facebook.github.io/flux/).

Web developers are a fickle bunch, and the massive churn in the world of web
frameworks is well documented. So what's far more interesting than React's popularity
is the way it's changed how we think about front-end web applications. React's key
features are great encapsulation through components, and declarative UI, rather than
directly manipulating global state (ie. the DOM). React's virtual DOM is generally
considered to be its key feature, but in reality it's an implementation detail
that powers these two breakthroughs.

A few weeks ago, Facebook released the initial [spec](https://github.com/facebook/graphql)
and [reference implementation](https://github.com/graphql/graphql-js)
for GraphQL, a new way to do data transfer between servers and app/web clients. Just as
React and Flux challenged our assumptions that MVC was the preferred (only?) way
to write clean frontend applications, GraphQL now puts REST in the crosshairs.

REST has turned into a bit of a sacred cow among web developers.
It's generally considered "the right way" to do data exchange between servers and
web UIs, and what we've lost with this uncritical attitude is a more nuanced understanding
of REST's tradeoffs for the systems we're building. Furthermore, most of us are
pretty low on the [Richardson Maturity
Model](http://martinfowler.com/articles/richardsonMaturityModel.html),
so you can argue that often we're not even doing REST correctly. How many REST
APIs have you written that actually use hypermedia to link and expose affordances
between your resources?

I highly recommend reading [Facebook's GraphQL
introduction](https://facebook.github.io/react/blog/2015/05/01/graphql-introduction.html),
as it does a fantastic job of enumerating the problems with REST for the increasingly
complex and performance-sensitive systems we're building today. It also lists
issues with the "Ad Hoc Endpoints" that many of us build and erroneously call
"REST APIs".

One of the promising things about GraphQL is that it's not tied to HTTP at all–
this is great for two reasons. First, it means you should also be able to use it
with other transports like Websockets or TCP. Secondly, HTTP has always been
pretty awkward for representing application semantics. If you've ever agonized
over the *correct* response code for an error condition in a REST API,
you've experienced this first-hand. It shouldn't be surprising that a protocol
designed for document delivery is not an ideal fit for the wide variety of things
we do with APIs and web applications today.

GraphQL is still extremely young as a public project, so it's hard to tell if
it will live up to its promise. Like any technology, it will have its pain
points, but at the moment only people inside of Facebook are intimately aware
of them. It's also clearly still at the "technical preview" stage, and some critical
things like mutations (ie. writes to your data) are still not fully fleshed out
in the documentation. Things should really ramp up when Facebook releases
[Relay](https://gist.github.com/wincent/598fa75e22bdfa44cf47), a client-side JavaScript
framework they've been teasing that's designed to integrate tightly with GraphQL.
It's projected to drop some time in the next month and I'm really looking forward
to digging in, so we can get a wider look into GraphQL's potential.

### More links

* [GraphQL Tuturial with the reference
implementation](https://medium.com/@clayallsopp/your-first-graphql-server-3c766ab4f0a2)
* [Relay Introduction](https://facebook.github.io/react/blog/2015/02/20/introducing-relay-and-graphql.html),
* [Building the Facebook News Feed with Relay](https://facebook.github.io/react/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html)
* [Mutations in Relay](https://speakerdeck.com/laneyk/mutations-in-relay)


Rethinking Another Best Practice


I was discussing semicolons with a coworker recently, when I (rather inelegantly) made
a case for omitting semicolons from a new JavaScript project. I'm rephrasing it here
because I don't often see this perspective in the endless public debate
about semicolons in JS.

The JavaScript community has a history of piling on those who advocate
semicolon-free code (although the tide does seem to be turning of late).
For a long time, I was in the pro-; camp. While semicolon-free code has always
looked easier to read and “cleaner” to my eyes, why would you seemingly invite bugs into your
software for such a small aesthetic benefit? Also, Douglas Crockford forbade them
(his views are apparently still a primary factor in the style choices of many
JavaScript developers).

Before getting into the crux of my argument, I must concede that if you write your
JavaScript without trailing semicolons, you need to make a habit of adding them to
the start of the line in
[two specific cases](https://gist.github.com/ryanflorence/61935031ff729f072d9b)
– when you begin your line with a `[` or a `(`. Otherwise in some cases JavaScript
will interpret those characters as the start of array indexing or function invocation,
respectively.

Anyways, I was experimenting with semicolon-free JS on a side project a few
months ago when I tripped up and forgot the two edge cases above. What I saw
caused me to swear off trailing semicolons for all future projects. It looked
something like this:

![Semicolon enlightenment](/img/posts/semicolon_enlightenment.png)

The screenshot above shows [JSHint](http://jshint.com/docs/) catching the two
aforementioned cases where omitting trailing semicolons could cause a bug in
JavaScript. The beauty in this example is that this feedback happened
instantly in my editor (via [syntastic](https://github.com/scrooloose/syntastic)
in Neovim).

If you don't have a linter making these (and other) automated checks for you
before you check in, a) you're missing out, and b)
please refrain from lecturing others on programming style and code quality.
If you do have linting checks in place, you can skip trailing semicolons.
It's up to you, but with today's tooling support for JavaScript, code "quality"
and robustness should not factor into your decision.

[Further](http://inimino.org/~inimino/blog/javascript_semicolons) /
[reading](http://mislav.uniqpath.com/2010/05/semicolons/) /
[on](http://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding) /
[semicolons.](https://medium.com/@goatslacker/no-you-dont-need-semicolons-148d936b9cf2)
Also, for a good time, read [this entire thread](https://github.com/twbs/bootstrap/issues/3057)

*Postscript:* There are a few more contrived cases where ASI can bite you, but in my
experience they're not worth worrying about:

```js
function thisIsTerrible() {
    return              // ASI would strike here; returns `undefined`
    {
        foo: 'bar'
    }
}
```

Seriously, who writes code like this? Oh yeah, and JSHint will catch this too.


You Don't Need Trailing Semicolons


In my 7+ years of using Vim, I've tried a lot of different plugins in attempts
to improve my workflow. This post is a look into what I've found to be
the *crème de la crème* in the Vim plugin world. If you're lazy, or just
allergic to bad writing, you can [skip to my
vimrc](https://github.com/af/dotfiles/tree/master/vim/vimrc) to see how it all
comes together.

It would be irresponsible to discuss Vim plugins without first imploring
the reader to spend a lot of time with plain Vim first. You will get far more
out of plugins once you have a firm grasp on Vim's fundamental actions, motions,
and overall editing philosophy. *By far* the best resource I've found so far is
[Practical Vim](https://pragprog.com/book/dnvim/practical-vim), by Drew Neil. It
is well worth your money and time if you're serious about Vim. His
[Vimcasts](http://vimcasts.org) video series is also excellent.


## Installing Plugins

Before you start messing around with plugins, it is imperative that you choose
and install a Vim plugin manager. Dealing with installing, upgrading, and deleting
Vim plugins by hand will leave you in a world of pain. It's one of the things
about Vim that is really terrible out of the box. Fortunately, there are quite
a few good plugin managers out there, and I use and strongly recommend
**[NeoBundle](https://github.com/Shougo/neobundle.vim)**. Its
killer feature is the ability to pin each of your plugin dependencies to a
specific Git commit– as far as I know, none of the alternatives do this. Pinning
to a commit keeps your plugin installs repeatable, and also gives you more
flexibility since you aren't limited to in pinning only to tagged versions.

See also: [pathogen](https://github.com/tpope/vim-pathogen),
[vundle](https://github.com/gmarik/Vundle.vim),
[vim-plug](https://github.com/junegunn/vim-plug)


## Navigating between files

After using vanilla Vim for a while, navigating between and launching files can
still be a pain point. Probably the most popular plugin for addressing this is
the mighty **[ctrlp.vim](https://github.com/kien/ctrlp.vim)**. It does the
project-wide fuzzy file matching you may have come to expect from Textmate or
Sublime, as well as fast MRU and buffer switching. I use all 3 modes dozens of
times daily, and ctrlp is probably my most indispensible plugin. If there's a
downside, it's that ctrlp hasn't seen an update in almost two years, but there
is an [actively developed fork](https://github.com/ctrlpvim/ctrlp.vim) that might
be worth checking out.

Another common use case is searching file contents within your project. I've just
started using **[Ags.vim](https://github.com/gabesoft/vim-ags)** for this, which
uses the excellent [silver
searcher](https://github.com/ggreer/the_silver_searcher) tool under the covers.
It's really fast and makes navigating the results easy. I've used a few other
plugins for this, but Ags seems to hit the sweet spot for me.

See also: [Ack.vim](https://github.com/mileszs/ack.vim), [Command-T](https://github.com/wincent/Command-T), [FuzzyFinder](http://www.vim.org/scripts/script.php?script_id=1984), [Unite.vim](https://github.com/Shougo/unite.vim)


## Syntax/Error Highlighting

Comprehensive, up-to-date syntax highlighting is a must
for any programmer. **[vim-polyglot](https://github.com/sheerun/vim-polyglot)**
gives you great syntax highlighting for a ton of different languages, while
minimizing the increased startup time from having them all installed.

Also, getting quick feedback on errors as you type saves a ton of debugging time,
especially if you're writing in a dynamic programming language.
**[Syntastic](https://github.com/scrooloose/syntastic)** runs linters and other
checkers as you save your code for quick feedback. It does cause some lag with
slower linters (looking at you, JSHint), but that's a limitation of Vim's purely
synchronous APIs, and despite this it's still more than worth your time.


## Version Control Integration

**[Fugitive](https://github.com/tpope/vim-fugitive)** is the ultimate plugin for
git integration. I've had it installed for years and have still barely scratched
the surface of all the things it does. For a taste, install it and enter `:Gblame`
or `:Gdiff` while editing a file with changes. `:Gmove` and `:Gremove` are very
handy as well, but I haven't yet absorbed any of the other commands into my
workflow yet.

Another nice tool is **[gitgutter](https://github.com/airblade/vim-gitgutter)**,
which shows which lines of the current file have been added/removed/modified in
the "gutter" to the left of Vim's line numbers. It seems like a small utility,
but I could honestly not go back to editing without this information available
at a glance. It also enables the following key mappings in my vimrc, which allow
me to jump to the closest modified "hunk" in the current file, without needing
to know anything about where that is. Super handy!

```
map <C-j> :GitGutterNextHunk<CR>
map <C-k> :GitGutterPrevHunk<CR>
```


## Miscellaneous

Some other plugins I use and recommend (but am too lazy to write about further)
include:

* **[Ultisnips](https://github.com/SirVer/ultisnips)**, a powerful snippets system
* **[Sparkup](https://github.com/tristen/vim-sparkup)**, a concise way to author html
* **[YankRing](https://github.com/vim-scripts/YankRing.vim)**, for recalling copy/paste history
* **[airline](https://github.com/bling/vim-airline)**, a stylish, clean, and efficient statusbar
* **[filebeagle](https://github.com/jeetsukumaran/vim-filebeagle)**, another efficient way to
navigate among project files
* **[colorizer](http://www.vim.org/scripts/script.php?script_id=3567)**, highlights
css colours in the editor.

You can see the full list near the top of [my
vimrc](https://github.com/af/dotfiles/tree/master/vim/vimrc).

I confess to being somewhat of a plugin junkie, so this post is really just
a snapshot of where my setup is now. I'm sure things will be a little different
in a year's time. If you share the same tweaker's mentality, I recommend following
[usevim](http://usevim.com/) and the [vim subreddit](https://www.reddit.com/r/vim/),
which are generally how I keep tabs on the Vim community. Also, the
[Neovim](https://github.com/neovim/neovim) project is making great progress, and
I'm excited to see how its Lua support and async capabilities will impact the
plugin landscape going forward.


Vim Plugin Essentials


It's my annual year-in-review, note-form brain dump!

## Reading
I read 40 books last year, with the following standouts:

* Refactoring (Martin Fowler)
* Envisioning Information (Edward Tufte)
* The Disaster Artist (Greg Sestero)
* Web Audio API (Boris Smus) [--> read it online for
free](http://chimera.labs.oreilly.com/books/1234000001552/index.html)
* Blankets (Craig Thompson)
* Jimmy Corrigan (Chris Ware)
* The Innovator's Dilemma (Clayton Christensen)
* Show Me The Numbers (Steven Few)
* Antifragile (Nassim Taleb)
* The Lean Startup (Eric Ries)
* The Wisdom of Anxiety (Alan Watts)


## Music
I was well on track to discover exactly zero new music last year, until
R&B legend D’Angelo came back from the dead to release [Black
Messiah](http://en.wikipedia.org/wiki/Black_Messiah_%28album%29) in late December.
While it's definitely not at
[Voodoo](http://en.wikipedia.org/wiki/Voodoo_(D%27Angelo_album))'s level,
I enjoy the new album, and at least it gave me something fresh to listen to.
Looking forward to actively seeking out new music again in 2015.


## Open Source
In 2014 it was time to learn a few technologies I'd had my eye on for a while:

* [d3](http://d3js.org/), and data visualization in general
* [React.js](http://github.com/facebook/react)
* the Web Audio API

At the end of the year I had a few things to show for my efforts:

* [JSnoX](https://github.com/af/JSnoX), a tool for using React without JSX
* A d3-based [data visualisation](http://aaronfranks.com/openra_chart) for
[OpenRA](http://openra.net)
* Another data visualization for [this site's homepage](http://aaronfranks.com)

I'm also working on a Web Audio-related side project that will hopefully see the
light of day at some point.


## Work
Work was steady for 2014. A highlight was definitely implementing a few data
visualisations with d3 (dataviz was obviously a major theme for the year).


## Travel
Nada.


## Exercise
Very little.


## Misc
So it turns out there wasn't too much to write about (here) for 2014. My life last year
was dominated by non-programming concerns, and was overall pretty damn intense and
stressful. I begin 2015 refreshed, and extremely thankful for a lot of
things in my life. One of my goals for the new year is to write here a little more–
[stay tuned](/atom.xml) for more questionable ramblings.


2014 Review


Hanging out in IRC channels is a great way to learn the nooks and crannies of
programming languages and tools. I've tried several desktop IRC clients in the
past, but each one felt more like a nuisance, and eventually I'd stop using IRC
entirely until I came across the next app to try. Since these days I spend a lot of time
inside a [tmux](http://en.wikipedia.org/wiki/Tmux) session, I'd much rather have IRC
in my terminal, rather than granting valuable screen real-estate (and, more importantly,
attention) to a separate native app.

The main contenders for terminal IRC seem to be [irssi](http://www.irssi.org/)
and [WeeChat](http://weechat.org/).
I went with WeeChat, since it seemed to be the more modern and actively
maintained of the two. Both are popular options, and you probably can't go wrong
with irssi either. Even though WeeChat is allegedly the more “user-friendly” client, I
encountered some bumps getting it set up on OS X (Yosemite)– hence this post.
A lot of what I learned was cribbed from [the WeeChat quickstart
guide](http://weechat.org/files/doc/devel/weechat_quickstart.en.html), so I
highly recommend reading through it if, like me, you're just getting started.

Below is a screenshot of what you'll end up with at the end of this post. Note
that I'm using [custom terminal colours](https://github.com/chriskempson/base16),
so YMMV on that front. Also, the culmination of my experimentation is
[on github](https://github.com/af/dotfiles/tree/master/weechat) if you want to
skip these ramblings.

![screenshot](/img/posts/weechat.jpg)


## Installation

If you're interested in a command-line IRC program for OS X, I'm going to assume
you have [Homebrew](http://brew.sh/) installed, or at least know how to get it.
Install WeeChat with:

```brew install weechat --with-perl --with-python```

The `--with-perl --with-python` flags are important if you want to use WeeChat
[scripts](http://weechat.org/scripts/), since most of the popular ones are written
in one of those two languages. You can also add `--with-lua` and `--with-ruby`
if you think you'll need plugins from those languages.


## Running WeeChat

You start WeeChat, predictably enough, by entering `weechat` in your terminal
app of choice. After that, things can be a bit bewildering. The first time run doesn't give
you any hints for how to connect to a server, configure the program, or
do much of anything. The magic command to get you started is `/help`. This lists
the available commands used to interact with WeeChat. Each command should be
prefixed with a `/`, and you can (and should) run `/help {command}` to get more
information about the important ones.

A few essential commands and hotkeys:

* `/quit` exits WeeChat
* `/set` is used to read & write your WeeChat configuration. The contents of
  `/help set` is one of the first things you should read as a new WeeChat user.
* `/save` saves your current configuration to various config files, in
  `~/.weechat` by default. Out of the box, WeeChat also saves your up-to-date
  configuration any time you exit the program.
* `/close` closes the current "buffer". If you're familiar with vim, WeeChat's
  concept of buffers is similar. Otherwise, just assume that a buffer maps
  one-to-one to a connected IRC channel for now.
* `/join {channel}` joins an IRC channel (once you're connected to a server;
  more on that in the next section).
* Use Alt + arrow keys to switch buffers
* Use PageUp/PageDown to scroll text in the current buffer


## Connecting to Freenode

[Freenode](http://freenode.net) is where the majority of programming IRC talk
happens, so let's connect to it. WeeChat comes with basic Freenode
configuration out of the box, which is nice and convenient. I'm going to assume
you have a Freenode account (or will connect without one); registering there is
outside the scope of this post.

You can run `/set irc.server.freenode.*` to see all of the available freenode
settings. I configured the following settings (substitute your own values where
applicable):

```
/set irc.server.freenode.addresses chat.freenode.net/7000
/set irc.server.freenode.autoconnect on
/set irc.server.freenode.autojoin {comma-separated list of channels to join}
/set irc.server.freenode.nicks {nicks to use}
/set irc.server.freenode.sasl_password {your freenode password}
/set irc.server.freenode.sasl_username {your freenode username}
/set irc.server.freenode.ssl on
/set irc.server.freenode.ssl_dhkey_size 1024
```

I'm a little fuzzy on whether [SASL
authentication](http://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer) helps much if you're already
connecting over SSL, but I turned it on anyways. [This
post](https://pthree.org/2010/01/31/freenode-ssl-and-sasl-authentication-with-irssi/) has more
information on that.

Once you've entered these settings, `/quit` and restart WeeChat, and on the next
startup WeeChat should try and auto-connect to Freenode.


## SSL Certificate Errors

One glitch I hit pretty early was that OS X apparently doesn't ship with the SSL CA
certificates needed to connect to Freenode over SSL. Of course, you could
leave SSL off, but after following the news for the last few years, that
just seems irresponsible. The error message I got looked like this:

```
gnutls: connected using 1024-bit Diffie-Hellman shared secret exchange
gnutls: receiving 2 certificates
- certificate[1] info:
  - subject `OU=Domain Control Validated,OU=Gandi Standard Wildcard SSL,CN=*.freenode.net', issuer `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', RSA key 2048
bits, signed using RSA-SHA1, activated `2014-01-13 00:00:00 UTC', expires `2015-01-14 23:59:59 UTC', SHA-1 fingerprint `a0fde217de32fae602fe67409697e15ac06f0286'
- certificate[2] info:
  - subject `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST
Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-10-23 00:00:00 UTC', expires `2020-05-30
10:48:38 UTC', SHA-1 fingerprint `a9f79883a075ce82d20d274d1368e876140d33b3'
gnutls: peer's certificate is NOT trusted
gnutls: peer's certificate issuer is unknown
irc: TLS handshake failed
irc: error: Error in the certificate.
irc: reconnecting to server in 10 seconds
```

The WeeChat FAQ [has an entry on
this](http://weechat.org/files/doc/weechat_faq.en.html#irc_ssl_connection), but
the `curl-ca-bundle` package it mentions doesn't seem to be available in homebrew.
Instead, you can follow [this gist](https://gist.github.com/1stvamp/2158128) to
install the CA bundle that you need. **Update: on OS X 10.11 and later, follow [the
instructions in this comment](https://gist.github.com/1stvamp/2158128#gistcomment-1573222)
instead**

Back in WeeChat, the following command will point to the CA file that you just
created:

```/set weechat.network.gnutls_ca_file "/usr/share/curl/ca-bundle.crt"```

Now restart WeeChat and it should finally connect to Freenode successfully!


## Securing your password

If you followed the connection instructions above, your IRC password is now
stored in plain text in your WeeChat config file, which is, um, _not ideal_.
Fortunately, WeeChat has the `/secure` command, which lets you store sensitive
information in an encrypted local file, and will prompt you
for a password to unlock it on startup. The user guide has [a nice
section on using this
feature](http://www.weechat.org/files/doc/stable/weechat_user.en.html#secured_data).


## WeeChat Scripts

You can customize and extend WeeChat by installing various "scripts". It comes with
a built-in script manager (try `/help script`), and [tons of
scripts](http://weechat.org/scripts/) are available for installation. As mentioned
earlier, you need to have support for a plugin's language (generally perl or
python) compiled in for them to be installable.

The [buffers.pl](http://weechat.org/scripts/source/buffers.pl.html/) and
[iset.pl](http://weechat.org/scripts/source/iset.pl.html/) plugins are essential.
Assuming you built WeeChat with perl support, you can install them
with the following commands:

```
/script install buffers.pl
/script autoload buffers.pl
/script install iset.pl
/script autoload iset.pl
```

Buffers.pl gives you an always-visible list of the buffers that you have open
(in my opinion this should be built-in to WeeChat). You can tweak it a bit if
you want, but it works great out of the box. iset is a nice UI for interactively
editing your WeeChat configuration, rather than entering verbose `/set` commands
every time you want to change something. Install it and read `/help iset` for more
details.

The other scripts I've found useful so far are:

* `urlgrab.py` - lists and opens urls from your IRC buffers
* [`notification_center.py`](https://github.com/sindresorhus/weechat-notification-center) -
  uses OS X's native notifitions to alert you to IRC highlights and private messages
* `colorize_nicks.py` - colours IRC nicknames in the messages themselves


## Grab bag

Here's a miscellaneous list of other stuff I recommend looking into:

* Customizing the WeeChat UI colours. For example, the following colour tweaks
  made things a bit more readable for me:

  ```
  /set weechat.bar.title.color_bg black
  /set weechat.bar.status.color_bg black
  ```

* Filtering out join/leaves. In many IRC channels the actual conversation can
  be drowned out by tons of join and leave messages. WeeChat has a nice way of
  intelligently filtering these out as needed; run
  `/filter add irc_smart * irc_smart_filter *` to activate it.

* WeeChat lets you easily customize your keyboard hotkeys. I'm a complete hotkey
  junkie, so this is one of my favourite features. Read `/help key` for more info.


## Conclusion

It's only been two weeks, but I'm really enjoying WeeChat so far. For the first
time, having IRC open feels natural and unobtrusive to my workflow. While the
initial learning curve can be quite steep, once you understand how things are
laid out WeeChat is really fun to explore and customize. [My weechat
config](https://github.com/af/dotfiles/tree/master/weechat) is online if you
want to crib some settings. And if you have questions or need help, `#weechat`
on freenode is a great place to ask.



Setting up WeeChat on OS X


I realized recently that I've never written anything about any of the [open
source code](https://github.com/af?tab=repositories) I've written. Though
I'm by no means a prolific contributer, there are a few repos kicking around
my github profile that may be of general interest. This post is an attempt to
catalogue a few of them, and reflect on how they turned out.


## djangbone

My first, and most “successful” project, [djangbone](github.com/af/djangbone)
is a REST API library for Django. I was learning Backbone.js at the time (this
was in 2011), and wanted to write some backend APIs that worked with Backbone's
conventions. Djangbone is intentionally minimalistic, but also pretty extensible
and you can create a pretty useful API very quickly.

I've been pleasantly surprised by how much attention Djangbone received. I put it
on [Django packages](https://www.djangopackages.com/grids/g/api/) early on, and
that seemed to get it some traction. As of this writing, it's still the 4th most
popular API library there, ranked by GitHub stars.


## backprop

Another project that received a bit of traction, [backprop](https://github.com/af/backprop)
is a Backbone plugin that helps you use JavaScript's
[properties](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty)
on your models.

Even though properties are pretty commonly used in Python, they
don't seem to have found much uptake in JavaScript-land since being [introduced in
ES5](http://ejohn.org/blog/ecmascript-5-objects-and-properties/).
I always thought that was a shame, and replacing Backbone's somewhat ugly `model.get('name')`
for property access seemed like a perfect fit for them. On top of that, backprop lets
you define lightweight schemas (eg. type coercions and default values) along with
your property definitions.


## littledom

[littledom](https://github.com/af/littledom) was a fun pedagogical exercise–
it apes a subset of jQuery's DOM manipulation API. I learned a lot while
writing this and peeking into the internals of jQuery and Zepto. It's also come
in handy for a couple of small side-projects where jQuery felt like overkill.


## shamus

[shamus] is a project automation/watcher desktop application. It's a
node-webkit app that runs pre-defined tasks when files in a (recursively) watched
directory change. I've found it really useful for running unit tests, linters, and
build tools and receiving near-instant feedback without jumping between apps.
However, since I'm now using [tmux](http://en.wikipedia.org/wiki/Tmux) pretty
heavily, I haven't fired shamus up lately. I'd like to try making a curses-based
version to run in a tmux pane at some point, that could be pretty useful too!


## openra_chart

[d3](http://d3js.org) is a library that had been on my radar for a long time,
but I'd never sat down and built something with it. Earlier this year I finally
took the plunge and built a little unit visualization for one of my favourite 
video games, [OpenRA](http://www.openra.net/).
I still have reservations about the resulting design, but it was
a fun learning exercise. If you're familiar with OpenRA, you should [check it
out](http://aaronfranks.com/openra_chart).


## canvasulative

A [fun little game](http://aaronfranks.com/demos/canvasulative/) I made a few
years back. One of my first experiments with `<canvas>`, this is a clone of
a Flash game that I found incredibly addictive. My nephew seemed to really like
my version and told me he played it a lot, which I thought was
pretty great. If I remember correctly, my high score is around 6300...


## Wrapping Up

There are a few other odds and ends on [my GitHub profile](https://github.com/af),
(including my [dotfiles](https://github.com/af/dotfiles) and [this web
site](https://github.com/af/af.github.com)). I have a stack of open source ideas
I'd like to get to, but finding the time has really been a challenge of late
(for very good reasons).


Open Source Roundup


## Travel
* Portland, OR
* Tulum, Mexico
* Los Angeles
* Toronto & Ottawa
* shorter trips to Seattle/Victoria/Whistler

## Exercise
* Ran my first 2 half marathons
* Both completed in under 2 hours, best time 1:49:52
* Can actually do some chin-ups now. Not many, but it's a start

## Music
* Saw jazz legend [Kenny Burrell](http://en.wikipedia.org/wiki/Kenny_Burrell) in concert
* Saw [Avenue Q](http://en.wikipedia.org/wiki/Avenue_q), which was equally amazing
* New discoveries (no particular order): Flying Lotus,
  [Random Access Memories](http://en.wikipedia.org/wiki/Random_Access_Memories) (album
  of the summer for sure), Michael Kiwanuka, [Tosca](http://en.wikipedia.org/wiki/Tosca),
  Mozart’s [Ave Verum Corpus](https://www.youtube.com/watch?v=6KUDs8KJc_c),
  and Andrew Mason's equally majestic *Hardly Workin’*

## Reading
Completed 38 books (not bad). Favourites included:
  * [Meditations](http://en.wikipedia.org/wiki/Meditations) (re-read this incredible classic)
  * [Pragmatic Thinking and Learning](http://www.amazon.com/Pragmatic-Thinking-Learning-Refactor-Programmers/dp/1934356050)
  * [Pragmatism](http://www.amazon.com/Pragmatism-Philosophical-Classics-William-James/dp/0486282708)
  * [Beautiful Evidence](http://www.amazon.com/Beautiful-Evidence-Edward-R-Tufte/dp/0961392177)
  * [Test Driven Development: By Example](http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530/)
  * [The Golden Spruce](http://www.amazon.com/The-Golden-Spruce-Story-Madness/dp/0393328643)
  * [Patterns of Enterprise Application Development](http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420)
  * [SQL Antipatterns](http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557)
  * [Practical Vim](http://www.amazon.com/Practical-Vim-Thought-Pragmatic-Programmers/dp/1934356980) (*indispensible* if you use Vim)

## Work
* Participated in Warner Brothers’ Media Camp LA program (a great experience!)
* Helped launch a [pilot program of Warner Bros films on Reelhouse](http://variety.com/2013/digital/news/warner-bros-kicks-off-test-in-startup-reelhouses-enhanced-digital-storefront-1200923528/)

## Open Source
* [littledom](https://github.com/af/littledom), a tiny DOM library
* [backprop](https://github.com/af/backprop), for using ES5 properties with Backbone
* [shamus](https://github.com/af/shamus), a work-in-progress desktop app for
  instant feedback during development (using node-webkit).
* Small contributions to about a dozen other projects. It wasn't much, but it was
  something I'd like to build on for 2014.

## Misc
* Finally set up a personal site (this one)
* Learned how to cook beef brisket (easy and delicious!)
* Attended the CascadiaJS javascript conference, which was great


Overall not bad, but there was some personal stuff that put a damper on 2013
for me. Bring on the New Year!


2013 Review (in note form)


I’ve been a [vim][0] user for over five years. While it’s one of my favourite
pieces of software, there are two snags that I noticed myself constantly
tripping over while using it:

* Using the `<esc>` key (or `<C-[>` for that matter) to exit Insert mode
  is quite a stretch on standard qwerty keyboards. Since vim usage
  involves making this mode switch constantly, this is a big annoyance.

* It must be a weird manifestation of OCD, but no matter which program I’m
  using, I compulsively save my work after almost any edit. In vim, this means
  hitting `:w<CR>` to make sure the current buffer is saved.
  That is a lot of keystrokes to go through every few seconds!

My favourite vim mapping addresses both of these problems, and has made editing
much more pleasant.

The first step is to remap our awful CapsLock key to pull double-duty: when
pressed, it works as an `<esc>` keypress, and when held down while pressing
another key, it works as a `<Ctrl>` modifier key. I picked up this trick from
Steve Losh’s [awesomely comprehensive blog post][1] on keyboard customization,
and it has served me very well for the last year. It uses [KeyRemap4MacBook][2],
but I’m sure similar programs exist for Linux and Windows.

With that mapping in place, an `<esc>` key is very conveniently located next
to the left pinky finger, so getting out of vim's Insert mode is now a snap.

To address the compulsive `:w<CR>` problem, I’ve set up custom bindings in Vim
so that every time I hit `<esc>`, (in Insert or Normal mode) the buffer is
automatically saved. The mappings (in my .vimrc file) look like this:

{% highlight vim %}
inoremap <esc> <esc>:w<CR>
autocmd InsertLeave * nnoremap <esc> <esc>:w<CR>
{% endhighlight %}

The second mapping is a bit of a hack, and will only work after you’ve spent
some time in Insert mode. However, using just `nnoremap <esc> <esc>:w<CR>`
caused weird problems when opening a file for the first time. If anyone has a
more elegant way to handle the Normal mode mapping, I’d love to hear it!

I’ve just started revisiting my dotfiles, cleaning them up, and
[putting them on GitHub][3]. Thought this trick might come in handy for anyone
else who has the same annoyances when getting started with vim.


[0]: http://www.vim.org/
[1]: http://stevelosh.com/blog/2012/10/a-modern-space-cadet/#controlescape
[2]: https://pqrs.org/macosx/keyremap4macbook/index.html.en
[3]: https://github.com/af/dotfiles


My Favourite Vim Trick


So it looks like I actually got around to putting up a personal site. This
is something I’d thought about doing for a couple years, but had never
invested the time to get it off the ground. After a couple of false starts,
I am going to try and publish at least a few things here going forward.

One of the things I asked myself any time I considered setting
up a personal site is *“why”?* I think I finally have a few answers to
that question. First off, working on the web platform for the last 7 years
and still not having any kind of personal online space is a bit embarrassing.
While most of my posts here will probably be software/technology related, the
occasional non-technical article will probably find its way here as well.

A second reason for the site is that I’ve noticed my written communication
skills have really deteriorated over time. I haven’t really written anything longer
than 4 paragraphs since university, and anytime you abandon a skill for that
long, atrophy is inevitable.

Finally, I’m hoping to “reset” the way that I communicate online somewhat. I’ve
used Facebook and Twitter for a few years, and I think writing exclusively in
media of their ilk dulls your brain a bit. After the [shutdown of Google Reader](http://googleblog.blogspot.ca/2013/03/a-second-spring-of-cleaning.html),
there has been small renaissance in feed reader software, so
it’s good to see that people are still interested in life beyond 140 characters.
That’s where I am hoping to spend more of my time online.

So hopefully this has been a reasonable defence of this site’s existence.
I’m sort of re-learning how to write, and trying to find a voice,
so it will probably be ugly for a while. Anyways, this site’s source and posts are
all [open source on github](https://github.com/af/af.github.com) so if you
see anything wrong, or have any suggestions, let me know. If you are interested in
keeping tabs on what I post, an [Atom feed is available](http://aaronfranks.com/atom.xml).


Latest Open Source Projects

(Infrequent) Blog Posts

2021 Review

Vim Plugins Revisited – Neovim 0.5 Edition

Surviving 2020

Links from around the web