How a Grumpy Programmer wires their home for internet

September 14th, 2017

Back at the beginning of August my long-suffering wife and I packed up our possessions and moved almost 2 hours away to a small village of ~2500 people into a house on a street that doesn't seem to show up on a lot of major GPS systems. Luckily it shows up both on Apple and Google maps, and there is a Tim Hortons close by to act as a known landmark and guide people in.

With the move came an opportunity to Do Something Different with the home wireless setup. In the past, I used a good, consumer-grade home wireless router and it was usually good enough. Sometimes my oldest daughter (her room was the furthest away from the wifi router) would complain about poor signal, so I bought some wifi extenders and those did the trick.

So this sort of thing was great...but I felt like I was not prepared for the near-future, which is a home filled with all sorts of devices that will connect via wifi to do things. I got a Nest thermostat and was going to have an awesome TV that needed a network connection. I also would have an older Roku device that would want to be on the network. Not to mention my own devices for work...and my wife's iPad and iPhone...and devices my kids were going to be using.

In short, I wanted to future-proof my network somewhat and try and anticipate an explosion of devices that would need to be connected to it. Yes, I am aware of some security implications and I am going to be working on minimizing the exposure these things will have to my network.

At some point I came across Troy Hunt's great blog post explaining how he helped wire his brother's home with some great networking hardware. I clearly am not re-inventing the wheel here -- Troy's template is one that I would absolutely follow...if you have the ability to run wires in your home.

In my case, it was not going to be a problem. The previous owner had been using VoIP for their phones so there were already several wired connections backed by cat5. I was going to need some other lines run throughout the house but it was not going to be an issue.

So I ended up with most of the hardware Troy recommended in his blog post:

  • 7 in-wall 802.11ac access points throughout the house
  • 1 24-port Power-over-ethernet switch
  • 1 security gateway device that I am slowly learning how to configure correctly
  • 4 cat5 connections for the access points
  • 3 cat6 connections for the other access points
  • 6u server cabinet (helpfully mounted on the wall) for all the equipment

I kept my existing wifi router, converted it to an access point, and plugged it into the switch because my youngest's Netbook refused to connect to the new hardware.

But why go to all this trouble and expense (it cost me CDN$2k for hardware and another CDN$1.5k for the cabling work) for my home network? Flexibility. This setup will be great for as long as gigabit ethernet remains faster than anything I can get at my home. Right now our local internet provider provides me with 50Mbps down / 5 Mbps up over coax -- the modem is mounted on the wall next to the cabinet. At some point they will be upgrading connections around here -- less than 1km away they are building a brand new subdivision with gigabit fiber being run to homes. When the time comes, I'll just have to update the modem...and nothing else. Maybe at some point Ubiquiti releases some nicer in-room access points. I can just swap my old ones for the new ones and everything else will just still work great.

Each room has an access point now that covers a small area. The equipment smoothly handles transitions from one location to another, and I can get to see some cool reports about who is doing what (how much is my youngest watching YouTube?!?) and adding and removing hardware for this setup is easy.

I highly recommend this type of setup for your home:

  • centralized location of a switch near where your modem / internet connection enters
  • wired connections to multiple locations, terminating near the switch
  • in-wall or very small, unobtrusive access points

I realize not everyone can do this -- apartments and older homes make this very impractical. I would recommend looking into mesh networks (Ubiquiti's consumer line of Amplifi look really good) to give yourself sufficient capacity. The number of network-aware or even network-required devices is only to go up, not down. If you can get out in front of it a little bit you'll be in a great spot to take advantage of it.

Who Coaches The Coaches?

September 6th, 2017

One of the things I have grown to enjoy over the years is mentoring people. It has felt like a very natural extension of the many years I have spend doing conference talks -- find people who are struggling to learn a concept I am familiar with, and then guide them through solutions. It's a very hands-on experience for me, and it provides me with an outlet to keep my programming skills from completely atrophying.

Back in March I got an email from Stefan Koopmanschap asking me if I was interested in participating in WeCamp later on in the year. After a quick check with She Who Must Be Obeyed flights were booked and plans were hatched.

WeCamp is a very unique experience. Code retreats, where you get a group of programmers together in a somewhat-isolated environment to work on something, are rare enough. I've participated in a few while at Mozilla, so I have a firm understanding of the underlying principles. WeCamp spins that a little differently by putting people on a private island in the Netherlands where they are actually camping (albeit with beds instead of sleeping on the floor of the tent).

I've been camping before, but not in at least 20 years, but I didn't think that would be a problem. Instead, there was the issue of what I was going to be doing as a coach. I had an idea of what a coach might do, but not sure exactly what would happen. Luckily, we had a Coach of Coaches in Jeremy Coates to guide myself and the other coaches (Steven de Vries, Michelangelo van Dam, Jeroen van der Gulik, and Juliette Reinders Folmer) through what we should expect and how to handle some rough situations (more on that later).

We were all assigned teams, the other campers showed up, and we got to work. And despite what you might think, it was actually work for the coaches too.

In my role as a mentor, I am used to being very hands-on with folks -- after all I am here to help and share what I know! But coaching is a very different thing. You are expected to help but definitely not step in and do the work for them.

My team did ask me lots of really good questions and I was happy to share my thoughts on a whole bunch of topics. My answers also surprised some of the team members because of a phenomenon I call "social media dissonance" and is entirely 100% my fault.

As someone who has spent A LOT of time on social media building up a brand to wrap my programming-related activities around, it's natural that people assume what they see me do on Twitter is how I am 100% of the time. To be clear, I am simply exaggerating certain traits of mine for fun and to build up a consistent marketing message. But I am not my Twitter account - it is part of me but not all of me. People see me, a very physically large white male with some very strong opinions on things, and assume it's going to be confrontations and yelling from the get go. That is not who I am, but that is the message I pushed for many years. Anyone who meets me in person and interacts with me for more than 30 seconds realizes what Twitter performance art is really about.

So when people asked me questions related to testing during the code retreat they were surprised to find that I was not immediately bellowing at them to write tests for everything. Look, playing the character on Twitter can be a lot of fun, but at the end of the day I am a real person dealing with real situations. One of those is what to do when you are prototyping things as part of a code retreat. Tests are nice, but until you have decided exactly what you are doing writing tests might be a distraction. Figure out your approach, your API, your interfaces and then break out the TDD and build stuff.

For the most part I valued the experience -- helping people reach higher levels of skill (technical or otherwise) was the goal. I watched for tension between team members, I got them water and snacks, and I worked very very hard to stay out of their way but be there when they needed something from me. But it wasn't all good.

One of the campers on my team was not having a good time -- they were struggling with a lot of personal and professional issues. In retrospect, the type of help they were looking for was not going to be provided at WeCamp. A discussion happened at one point where this camper expressed their frustration at some professional setbacks and was determined to not accept any feedback that contradicted their own opinion. I attempted to provide some calm, constructive feedback on better ways to handle the emotional side of such setbacks, and it culminated in the camper storming out of the yurt we were working in and leaving the team.

This was definitely not what I was expecting.

Luckily there was a good support system in place both for our frustrated camper and our stunned coach. In the end, the camper was given the freedom to work on other tasks and I just stayed out of the way as to not run the risk of another inadvertent confrontation.

In the end, my team got their application up to Minimum Viable Product status, integrated our lost camper back into the presentation, and I am very proud of the work they done and left them a lot of new things to think about. There is also a commitment for follow-up conversations in November to find out how they have been able to apply their experiences at WeCamp to their lives (both personal and professional).

See, part of the purpose of WeCamp is to give people a chance to set some goals that will push them out of their comfort zone. My team members got a chance to do some of that -- some with more success than others. But they definitely embraced the idea of "willful change" and that part alone made it worth it to me.

Despite the blow-up with the frustrated camper, I enjoyed the coaching experience and would not hesitate to do it again. As for WeCamp itself...I am not sure that I would get a lot out of it just as a participant. My goals are moving towards non-coding territory and something like WeCamp is not a good venue for working through those.

If you're looking for a very unique experience and a chance to push some boundaries as a coder, you should check out WeCamp and code retreats in general. They offer some very unique experiences in an environment geared towards providing you with the support needed to make the cost of failure almost zero.

Letting Emacs into your grumpy heart

May 26th, 2017

Yes, the rumours are true. Your grumpy blogger, a long-time and generally satisfied Vim user has decided to embrace some fear, turn on EVIL mode and give Emacs a fair evaluation.

To be truthful, I had used Emacs before. Back in 2002 I was using Linux as my working environment and used it because the guy sitting next to me (hi Kemo, wherever you are!) was using it and showed me the basics. All I retained over the years was C-x C-f to load files and C-x C-c to quit.

Over the years I tried all sorts of editors -- Eclipse, JEdit, TextMate, Sublime Text -- before finally settling on Vim and builidng the request muscle memory along with the proper superior attitude.

I also have used PyCharm and PhpStorm because sometimes you need an IDE to help you when you are learning new languages beyond the beginner stage or dealing with a really complicated code base you let spin out of control. Right tool for the right job is a real thing, not just advice that developers who are bitter you don't like the tool they think is "right" give.

Vim is a great modal editor -- really powerful, and has a ridiculous amount of plugins that can extend Vim to make it even more useful. I've been able to get quite productive with it. At the same time, I can also get frustrated with how some stuff seemed really hard to get just right with plugins and how weird Vimscript is.

All the while I would see Emacs stuff bubble up to the surface on Twitter or YouTube would recommend that I watch a video about it. I came to realize that Emacs is very powerful and can do pretty much everything that Vim can do. Plus there is EVIL mode, which allows me to use Emacs with all the HJKL goodness I have come to expect from Vim.

I thought it might be constructive for me to go over my .emacs file as it currently stands and explain my choices. Honestly, it hasn't been that hard a transition using Emacs at this point. Retraining my brain to remember new key combinations is the harder part.

;;; Code:

(setq package-archives '(("gnu" . "")
                         ("marmalade" . "")
             ("melpa-stable" . "")
                       ("melpa" . "")))

All I am gonna say here is that Emacs packaging is interesting.

;;; EVIL mode to help me transition from Vim to Emacs
(require 'evil)
(evil-mode 1)

EVIL mode is a really good Vim emulation mode for Emacs. It allows me to use most of the keystrokes I am comfortable with to move around within Emacs buffers.

;;; Some general settings
(setq make-backup-files nil)
(define-coding-system-alias 'UTF-8 'utf-8)
(setq inhibit-startup-message t)
(set-language-environment 'utf-8)
(set-default-coding-systems 'utf-8)
(set-selection-coding-system 'utf-8)
(set-locale-environment "en.UTF-8")
(prefer-coding-system 'utf-8)

I took these from Some Random Person's Emacs Settings. Mostly it's to make sure we do everything in UTF-8 and to not have my filesystem littered with all sorts of back-up files.

;;; Set up autocomplete
(require 'auto-complete-config)
(setq-default ac-sources (add-to-list 'ac-sources 'ac-source-dictionary))
(global-auto-complete-mode t)

Autocompletition that works! Before you get all mad, I have used autocompletion in Vim for a long time but sometimes it wouldn't quite work properly. I have found Emacs autocomplete to be programming language sensitive, something I did not notice happening in Vim.

;;; YaSnippet
(yas-global-mode 1)

YASnippet is an Emacs mode that allows you to create language-specific templates to allow you to quickly generate code for things like for loops or if-then statements.

;;; PHP settings
(require 'php-mode)
(require 'php-auto-yasnippets)
(define-key php-mode-map (kbd "C-c C-y") 'yas/create-php-snippet)
(setq php-auto-yasnippet-php-program "/Users/chartjes/.emacs.d/Create-PHP-YASnippet.php")

Still gotta do PHP work despite all my Python QA work! The PHP mode is pretty solid, and I like being able to generate snippets for my work. Remember kids, we only have so many keystrokes in our fingers.

;;; Some file mappings
(add-to-list 'auto-mode-alist '("\\.md\\'" . markdown-mode))
(add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode))

Just telling Emacs what file endings map to what languages. Some programming-language modes can figure this out, Emacs wanted me to be specific about Markdown and Python

;;; Modeline
(defvar sml/theme)
(setq sml/theme 'powerline)

If you're a Vim user who liked a cool status line? Check out smart-mode-line

;;; Flycheck
(require 'flycheck)
(global-flycheck-mode t)
(setq flycheck-phpcs-standard "psr2")
(add-to-list 'flycheck-disabled-checkers 'python-pylint)
(add-hook 'python-mode-hook #'flycheck-mode)
(add-hook 'python-mode-hook
      (lambda () (flycheck-select-checker 'python-flake8)))
(require 'flycheck-color-mode-line)
(eval-after-load "flycheck"
  '(add-hook 'flycheck-mode-hook 'flycheck-color-mode-line-mode))

Flycheck will do on-the-fly syntax checking of your code. Just hook into the proper modes and you'll be good to go. Works great with PHP code too.

;;; JEDI autocompletion for Python
(add-hook 'python-mode-hook 'jedi:setup)
(defvar jedi:complete-on-dot)
(setq jedi:complete-on-dot t)

JEDI is a cool tool for doing Python-specific static analysis and syntax checking for your Python code. Highly recommend it.

;;; Mageit for Git
(require 'magit)
(global-set-key (kbd "C-x g") 'magit-status)

The only Emacs mode you will ever need to do work with Git

;;; Elm-specific settings
(require 'elm-mode)

Maybe one day I can do Elm for money.

;;; We will also need web mode stuff
(require 'web-mode)
(setq web-mode-ac-sources-alist
  '(("php" . (ac-source-yasnippet ac-source-php-auto-yasnippets))
    ("html" . (ac-source-emmet-html-aliases ac-source-emmet-html-snippets))
    ("css" . (ac-source-css-property ac-source-emmet-css-snippets))))
(add-hook 'web-mode-before-auto-complete-hooks
          '(lambda ()
             (let ((web-mode-cur-language
               (if (string= web-mode-cur-language "php")
                   (yas-activate-extra-mode 'php-mode)
                 (yas-deactivate-extra-mode 'php-mode))
               (if (string= web-mode-cur-language "css")
                   (setq emmet-use-css-transform t)
                 (setq emmet-use-css-transform nil)))))

Web mode is intended to make working with web-centric languages easier in that it can recoginze when you have HTML and CSS code mixed in with your scripting language of choice, applying different syntax highlighting and styling rules to them. Really neat stuff

;;; Python settings
(require 'virtualenvwrapper)
(setq venv-location '("/Users/chartjes/Kinto/kinto-integration-tests/venv-kit"))

Did I mention that you can make Emacs aware of virtual Python environments?

;;; Settings for Corral (surrounding text with stuff)
(global-set-key (kbd "M-9") 'corral-parentheses-backward)
(global-set-key (kbd "M-0") 'corral-parentheses-forward)
(global-set-key (kbd "M-[") 'corral-brackets-backward)
(global-set-key (kbd "M-]") 'corral-brackets-forward)
(global-set-key (kbd "M-{") 'corral-braces-backward)
(global-set-key (kbd "M-}") 'corral-braces-forward)
(global-set-key (kbd "M-\"") 'corral-double-quotes-forward)

I have relied heavily on surround.vim in the past, Corral seems to be a great solution to do the same thing in Emacs.

So there you have it! My early experiences with Emacs are good, I am slowly learning new keystrokes to do new things and trying to get Emacs to intelligently help me be a better developer.