Closet Coder

I work in my closet. I code. Yep.

Pairing Post Mortem - @piisalie - Emacs and Exercism.io

| Comments

The other night, I got to pair with @piisalie to learn some Emacs and work through a little exercism.io.

Paul is a relatively new developer, but he’s been studying under the tutelage of @jeg2 and getting ramped up very quickly as a result. It’s neat to see people who are able to absorb so much so quickly.

Setup

  • Google+ Hangouts
  • TMUX + Emacs (Ahhhhhhhhhhh!!)

Paul was pretty familiar with Emacs and did a good job showing me around. We worked on a small exercise and I tried to do as much of the editing as possible as he guided me when I said “how do I move up and down again?”

Takeaways

  • Exercism is a great way to think through a bunch of ways to solve a small problem
  • Emacs is neat in that…
    • it can actually contain a shell within a buffer and that shell is editable.
    • the mnemonics are easier to remember
    • it’s easy to test out config changes in the scratch buffer
    • fuzzy searching is built in
  • Emacs is crazy (mostly in comparison to VIM) in that…
    • nearly every command has a prefix (C-x, C-c), which seems like insanity when you compare moving around/highlighting in VIM with hjkl. It reminds me of TMUX, which is much more tolerable because you’re not switching panes multiple times per second
    • it seems much larger than VIM is
    • The default Emacs on my Mac is version 22, Paul had version 24. VIM is at 7.3 on nearly every system I’m using.
    • it is not VIM and my brain explodes.

All in all, a good session. I’m glad I have a better understanding of Emacs and that I understand some things that I specifically like about VIM and a couple of things that I like about Emacs. Looking forward to pairing with Paul again where we can actually work on something real.

On to the next pairing session…

How to VIM+TMUX

| Comments

Chris Hunt gave a great presentation at LA Ruby Conf about VIM+TMUX. There, he shows you a bunch of cool things you can do with VIM and TMUX.

But he doesn’t tell you how to do them.

So here, I’m going to list each of the things he does and give you the keystrokes/information you need to do what he’s talking about.

TMUX

For these shortcuts, the prefix is mapped to C-b (i.e. Ctrl-b) – though I believe it is much faster and more comfortable to map it to C-a. Chris even maps his to C-j so you use two different hands.

  • 3:51 - List Keyboard Shortcuts - C-b ?
  • 4:06 - Chris Hunt’s TMUX Config
  • 4:30 - Create New Window - C-b c
  • 4:35 - Rename Window - C-b ,
  • 4:39 - Change Windows Absolute - C-b 0|1|2|3|4|5
  • 4:39 - Change Windows Relative - C-b n|p
  • 4:46 - Switching to Last Used window C-b l
  • 4:49 - Split Window vertically into Panes - C-b %
  • 4:52 - Split Window horizontally into Panes - C-b "
  • 6:18 - See List of sessions - C-b w
  • 7:06 - Auto-start iTerm with tmux tmux attach -t hack || tmux new -s hack
  • 11:10 - Detach from session - C-b d
  • 17:50 - Make a new, shared tmux session tmux -S /tmp/pair new -d math && chmod 777 /tmp/pair && tmux -S /tmp/pair attach
  • 19:14 - Attach to a shared tmux session tmux -S /tmp/pair attach

VIM

  • 7:30 - Fuzzy search with CtrlP
    • C-p [search] to find files
  • 8:22 - Profject wide search with Ag
    • :Ag [text] to find text
  • 9:18 - Surround
    • change double quotes to single quotes while within double quotes: cs"'
    • change [ to ( while within square brackets: cs[(
  • 10:39 - Aligning code with Tabular
    • :Tabularize /<regex to match>/
  • 12:18 - Run bundle within vim :!bundle
  • 13:23 - Create new spec file :e spec/math_spec.rb
  • 14:22 - Running tests within VIM - Gary Bernhardt’s RunTests in .vimrc
  • 15:44 - Make a Gist of the current buffer with :Gist (Gist-Vim)
  • 19:56 - Using the Arglist for global search and replace
    • Find all files :args ag -l MyAwesomeApp .
    • View args :args
    • Execute a replace across files (with confirmation) :argdo %s/MyAwesomeApp/ToDoApp/gc | w
  • 21:54 - VIM Macros
    • To start recording Esc q a
    • To stop recording, in command mode, q
    • To execute recording, in command mode, @a
    • To execute multiple times, in command mode 9@a
    • To execute across arg files: :argdo norm @a

Adventures in Elixir

| Comments

At the Lone Star Ruby Conference, Dave Thomas talked about Elixir to everyone. I found it kindof interesting that there were no loops and the use of if was discouraged. It was neat to see that everything was idempotent and that pattern matching made certain problems incredibly easy to solve with very little code.

So when I found exercism.io and saw that they had an Elixir track, I jumped on it. What I’ve noticed is that solving problems in a functional way changes the way that I code in an OO language. It doesn’t mean I want everything to be a function and never have state, but I want each method on an object to have no side effects and to require an absolute minimum of internal state to function.

Let’s look at some examples from the Exercism Elixir track.

Pattern Matching

The Fibonacci sequence is an oft-asked puzzle question since it requires knowledge of recursion and proper branching conditions. In Elixir, it breaks down very simply because of pattern matching.

fib.exs
1
2
3
4
5
defmodule Fib do
  def fib(0), do: 0
  def fib(1), do: 1
  def fib(n), do: fib(n-1) + fib(n-2)
end

Since Elixir looks for the first match when a function is called, Fib.fib(1) matches line 3, and Fib.fib(2) matches line 4, which calls fib(1) + fib(0) which then match lines 2 and 3. Impressive, no?

Guards

Guards allow you to pattern match based on a property of the values being passed to the function. This lets you test the types without having to have branches inside your function. There are only a few expressions that can be used as guards.

dna.exs
1
2
3
4
5
6
7
8
9
defmodule DNA do
  def to_rna(strand) when is_binary(strand) do
    String.replace(strand, "T", "U")
  end

  def to_rna(strand) when is_list(strand) do
    to_rna(list_to_binary(strand)) |> to_char_list
  end
end

This allows you to have a single interface for Lists, Binarys, Bitstrings and Tuples, even if the logic for each one is quite different. Since they’re all separated, it becomes very easy to maintain..

Cond

Cond is an interesting construct, similar to case, but without an initial argument. It is more like saying case true …. As a result, it’s very easy to pattern match on anything.

bob.exs
1
2
3
4
5
6
7
8
9
10
11
12
def hey(string) do
  cond do
    is_silent?(string) ->
      "Fine. Be that way."
    is_asking?(string) ->
      "Sure."
    is_shouting?(string) ->
      "Woah, chill out!"
    true ->
      "Whatever."
  end
end

Pipelining

Since it’s really common to work on the result of one function in another function, but you don’t have objects which keep internal state, Elixir and Erlang have the idea of pipelining.

word-count.exs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
defmodule Words do
  def count(sentence) do
    sentence |> normalize |> find_words |> count_words
  end

  defp count_words(words) do
    Enum.reduce(words, HashDict.new, fn(word, dict) ->
      HashDict.update(dict, word, 1, &1 + 1)
    end)
  end

  defp find_words(sentence) do
    Regex.scan(%r/\w+/, sentence)
  end

  defp normalize(string) do
    String.downcase(string)
  end
end

Pipelining is really just a shorthand for passing the result of one function in as the first argument for the next function. As you can see on line 3, this makes it very easy to read the order in which you would think of things. “Take a sentence, normalize it, find the words in it, count the words you found.”. The other way to write this would be count_words(find_words(normalize(sentence))). It works, but it’s harder to read and you end up with lots of right-parens.

While there’s nothing super special about this, I have found it very useful for readability, and that’s a huge part of programming.

Binarys, Strings and Lists - Oh My.

One of the most confusing things about Elixir (and Erlang) when I started off is that 'abc' != "abc" because one is a list of characters (i.e. [A?, B?, C?]) and one is a UTF8 binary (i.e. <<65, 66, 67>>).

You can convert one into the other, though, if you are trying to work that way:

convert.exs
1
2
3
4
5
# 'ABC' to "ABC"
list_to_binary('ABC') # => "ABC"

# "ABC" to 'ABC'
to_char_list("ABC") # => 'ABC'

But the best thing to do is to think of them as two very separate things. If you’re working with Strings, you’re really working with UTF8 encoded binaries. If there are valid UTF8 codes contained inside the binary, you’ll get a string returned. If not, you’ll get a generic binary. Understanding this difference is crucial for working with Strings in Elixir, especially when coming from another language like Ruby.

The Documentation

Lastly, I learned how to find things in the documentation. Understanding how the standard library works is key to being effective in any language, and the available docs are okay. They’re not great though. Lots of holes and sometimes it’s difficult to understand exactly what an argument does.

Concurrency

This is the key part of Elixir and I have to admit that I know very little about it. I intend to explore it more as I go forward and hopefully write another post outlinging what I’ve learned.

Going forward

Elixir is a neat langauge. I think it will do more to influence developers in other languages than it will become a production ready system, but either way, it has taught me a handful of ideas that make me consider what advantages functional programming has and how I can incorporate them into my day to day work. Looking foward to diving in more.

Automating Distraction-free Work

| Comments

I’ve followed the Pomodoro Technique for a few years now. I’ve tried several different tools to get it where I want, but in the last few months I’ve begun using AppleScript to automate things that I want done in my environment every time I start/finish a Pomodoro.

I use Things as well to keep track of my tasks. I think GTD and the Pomodoro Technique are a wonderful marriage where GTD gets to keep track of the What and the Pomodoro Technique motivates to to actually make progress. It’s all too easy to feel like you’re making progress by simply moving tasks around and “getting organized.”

So when I combined these two techniques, I used Pomodoro.app – which is no longer available on the App Store, but you can easily download it and compile it with XCode.

I have 4 scripts that I use for managing the link:

Start
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
tell application "System Events" to if exists process "Things" then
  tell application "Things"
    set pomoName to "$pomodoroName"
    set createToDo to true
    repeat with todayToDo in to dos of list "Today"
      set toDoName to name of todayToDo
      if toDoName starts with pomoName then
        set createToDo to false
      end if
    end repeat

    if createToDo is true then
      set newToDo to make new to do with properties {name:pomoName} at end of list "Today"
    end if
  end tell
end if

do shell script "cp /etc/hosts ~/.old-hosts; sudo echo '127.0.0.1 facebook.com www.facebook.com netflix.com movies.netflix.com twitter.com youtube.com www.youtube.com' >> /etc/hosts; dscacheutil -flushcache" with administrator privileges

This script finds a TODO with the appropriate name and creates it. Pomodoro.app tries to do this, but it doesn’t work when you add [X] to the title to indicate the number of pomos.

It also blocks facebook, netflix, twitter, and youtube so you can reduce your distractions automatically during your pomo.

Interrupt
1
2
3
4
5
6
7
8
9
10
tell application "System Events" to if exists process "Things" then
  tell application "Things"
    repeat with possibleToDo in to dos of list "Today"
      if name of possibleToDo starts with "$pomodoroName" then
        set currentName to name of possibleToDo
        set name of possibleToDo to currentName & " [']"
      end if
    end repeat
  end tell
end if

During an interruption, this marks a small [‘] on your task. This lets you see which kinds of tasks get you interrupted the easiest when looking over your day.

Reset
1
do shell script "sudo mv ~/.old-hosts /etc/hosts; dscacheutil -flushcache" with administrator privileges

When you reset your pomo, this unblocks all the websites that you originally blocked.

End
1
2
3
4
5
6
7
8
9
10
11
12
tell application "System Events" to if exists process "Things" then
  tell application "Things"
    repeat with possibleToDo in to dos of list "Today"
      if name of possibleToDo starts with "$pomodoroName" then
        set currentName to name of possibleToDo
        set name of possibleToDo to currentName & " [X]"
      end if
    end repeat
  end tell
end if

do shell script "sudo mv ~/.old-hosts /etc/hosts; dscacheutil -flushcache" with administrator privileges

After a successful pomodoro, this script finds the task you were working on in Things and adds a [X] to the end of the title so you can see how many pomos you actually spent on it.

It also unblocks the blocked websites.

All this together makes for easy to prep, easy to review, and relatively distraction-free work.

Lone Star Ruby Conf 2013

| Comments

This last weekend I went to the Lone Star Ruby Conference 2013. It was a good conf. Of course, there were some weak talks and bad wifi issues, but overall, it was the most enjoyable and useful conference I’ve been to.

Highlights

  • Sandi Metz’s keynote looking at the history of writing and tech - Always great to hear that you’re going to be obselete and thus, you need to remember what your priorities are.
  • Dave Thomas’s talk on Exlir - Showed off the power of the language by live-coding and having a good time doing it.
  • Brandon Hays‘ talk on Ember.js and Rails - perhaps the best beginner talk I’ve ever seen. Great combo of funny, interesting, informative and technical enough to be useful.
  • Sarah Mei’s talk on fostering creativity and problem solving - Just a great talk–well delivered and interesting. Best soft talk of the conf.
  • Nell Shamrell’s talk on RegEx - Super informative, well delivered and highly technical without alientating anyone. 200 devs paying attention to every word she’s saying about how a RegEx parser works. That’s mad skills.
  • Sam Livingston-Gray’s talk on Refactoring - Wonderful talk that dove deep enough to give you an idea of HOW to refactor something. I always forget that it is one small thing at a time.
  • Getting to meet and visit with people I had only known on twitter before like @_zph and @avdi.
  • Getting to meet lots of people interesting in #pairwithme.
  • Bryan Helmkamp: “Your goal is to make refactoring invisible. It should happen every time you touch the code. Little improvements here and there.”
  • Getting to give my Lightning Talk on #pairwithme

Overall a great conf. It seemed like the best and most interesting talks weren’t focused on Ruby–with the exception of @geeksam’s talk on refactoring. Nearly every talk worth it’s salt was either talking about broadening your horizons or improving your code quality. That’s a tall order, and it’s a great thing that the Ruby community embraces it.

There will be no LSRC 2014, but the hope is that there will be one in 2015. I wonder if the Ruby Community will thrive to a point that makes all these regional conferences possible over the next two years. Maybe it will and maybe it won’t. We’ll see. Here’s to hoping.

The #pairwithme Progression

| Comments

I gave a quick lightning talk on how to have a good #pairiwthme session at LSRC this year.

I still had a question on how to get started in pairing afterward. I came up with a basic set of steps, which can be combined as needed.

  1. Get a pairing session scheduled and established. Share a screen. Type together. Sometimes this takes longer… sometimes it’s just a few minutes.
  2. Work on the simplest possible setup you’re comfortable with. Usually this is Google+ and ScreenHero, but YMMV.
  3. Work toward an optimal setup you’re comfortable with that maximizes responsiveness and communication. Typically this is low bandwidth (i.e. Audio Only (Skype?) and terminal sharing (tmux))

You may be able to get all the way to step 3 in your first session, or you may take 3 separate sessions to get all the way there. Either way, you’ll get there, and then you’ll be comfortable enough to take someone else through it.

Let’s level up the community by fostering a culture of pairing with everyone.

Pairing Post Mortem - @jnanney - OAuth

| Comments

I finally got a chance to pair with @jnanney tonight. He had a project dealing with the OnStar API that needed OAuth Authentication, so we took a stab at implementing it.

Setup

  • Skype - TIL Skype 6.x turns off your video if you connect to a Skype 2.0 client–but the audio still works!
  • TMUX+VIM on a slice (not local)

Experience

We started by making some large, rough ideas about what we wanted to accomplish and then began looking up some things on OAuth2 to help us accomplish them. Pretty quickly we stopped driving everything via tests and started exploring via IRB.

We struggled quite a bit with the OnStar OAuth2 documentation… figuring out what the endpoint was. We also needed to know how to get a token from the command line. We spent most of our time just digging around in the documentation and IRB. Eventually we disovered what we wanted to call and headed that direction. By that time, it was time to wrap up our time.

Takeaways

  • On Ubuntu, vi isn’t compiled with ruby support, but vim is. Weird.
  • In VIM, dt will delete everything from the current marker to the character you specify
  • Documentation matters a lot
  • Just moving a little bit down the road is often enough. Even though we didn’t make more than about 20 lines worth of progress (including tests), we moved far enough that he was able to finish out the feature by the next day.

It was great pairing with Jim. Looking forward to it again in a few weeks.

On to the next pairing session…

TDD and Pairing Will Save You

| Comments

12 Lessons I learned from Unit Tests/TDD is a great article for practically adding TDD to your teams rhythm. I can’t stress enough how much point 8 makes a difference:

Pair programming helps the team to adopt TDD. When we are trying TDD for the first time or when our deadline is tight, we will have the will to forget the tests and write only production code. Pair programming will prevent the team to cut corners and will keep it writing tests.

This is absolutely true. When you’re on your own, we’re all tempted to cut corners, and when a deadline is looming, that’s when you need the accountability more than anything. Pairing isn’t just for accountability either. It helps you figure out how to test something that you’re intimidated by, it keeps you from taking nasty shortcuts in design, and it helps you look at code from other angles. All three of those are great for deadlines and TDD.

Pairing Post Mortem - @willpragnell - Mute Pairing With VIM

| Comments

Last week I had the opportunity to pair again with @willpragnell. He had just moved and didn’t have internet access, so I suggested that we try a “mute” pairing session from a coffee shop, where all our communication happened through VIM.

He was game, so we started off with a quick chat session on Google+ to get set up, and then switched to a VIM+TMUX setup for the rest of the time.

Observations

  • It was nice to listen to music during pairing since I normally listen to music while coding
  • It required a bit more thinking since we sometimes began typing over one another. Wasn’t a big deal, just something I became aware of.
  • We used comments to “talk out” our ideas
  • It was faster to get going since we didn’t spend a lot of time gabbing at the beginning.

We began working on an engine for the game Pandemic. We realized that trying to implement the whole game would be a bit to much to bite off in one session, so we decided on trying to get the map/graph parts of the game going along with the ability to know what the infection state was at any given location.

When we started by trying to define a location that knew about all it’s neighbors, we quickly realized that wasn’t the best way to represent it and went for more of a Graph form, with points and edges. The points knew information specific to them (infection level, research station status), but didn’t know about it’s neighbors, that was the board’s job.

We also worked a bit on refactoring and naming towards the end. One of the biggest plusses of pairing is that you can bounce ideas off each other related to naming so that you really communicate in the best possible ways to future maintainers.

After about 45 minutes, we made a good deal of progress and I think we’re ready to begin implementing the city decks and all the rules related to them next time around. It was quite fun.

Takeaways

  • Mute pairing sessions aren’t as fluid as sessions with audio, but they do in a pinch.
  • Implementing a game is really fun since there are lots of different things to consider, but the ruleset is still finite.
  • Implementing a game that deals with geography with someone overseas is humorous.
  • Refactoring naming alone is a huge benefit of pairing. I would have stuck with cure and partial_cure for method names, but considering that the default needs to be partial cures, we changed to cure and cure_all – much better, I think.

Can’t wait to make more progress on the game. Looking forward to pairing with Will again.

On to the next pairing session…

Pairing Post Mortem - @peter_v - Improving a Semantic Store

| Comments

Today I got to pair with Peter Vanderabeele, who is a programmer from Belgium with a highly methodical bent. He has clearly had a lot of experience and it was neat to get to work on his project since it isn’t every day you get to work on a high performance fact storage system.

Peter is creating a data store meant to store semantic facts that have relationships to each other. It’s a very different project with a goal, he stated, to have data in this format and extractable for the next 50 years. To try to view code with that lens is very different from how most other Rubyists think. We tend to see our code dying in the next 5 years… max. So we make decisions with that timeline in mind. Thinking of a timeline longer than my own life has very different implications.

Pretty much all my sessions these days are VIM+TMUX. ScreenHero is useful for when someone else doesn’t have everything set up, but in general, TMUX+VIM is the way to go. I set up our session and cloned his project. The tests all passed after a quick bundle and so we were ready to go.

Once we got to coding, one thing I really liked was being able to just Ack for the TODO comments. We found 2 in the codebase and talked about both of them. One seemed fairly simple and a good way to get introduced to the project, so we went with it. We wanted to validate that the format of a CSV coming in was good on a row-by-row basis.

We started by discussing how to describe the correct formats for each column. Eventually we converted the array of attributes to a hash of attributes and regexs. That made it easy to loop through the parsed CSV and determine if each field was valid. It was easy to make each of these changes because the tests were fairly thorough and so every change made at least a handful of tests fail. We would see the failing tests, make the appropriate modifications, and then watch everything pass. Man, I love a project with a great test suite.

We also quickly determined, once we saw some tests failing after we expected them to pass, that we neglected the idea that some fields were optional. We added an additional flag to the hash, which is when we should have refactored to a ColumnSpec class, but we didn’t quite have the time. Either way, we got the tests passing and saw the validation working as we had expected.

Takeaways

  • TODOs in code are very useful for pairing and figuring out what to attack, even more so than an Issue tracker, I believe.
  • Thorough tests made it very, very easy to make changes with confidence.
  • US Lunchtime pairings work well for most EU evening pairers :)
  • Goals and timelines for your project have significant effects on your willingness to compromise. It’s important to know what you’re trying to do and how long you are trying to do it.

All in all, I learned quite a bit from pairing with Peter and I hope we get to do it again soon.

On to the next pairing session…