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.
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?”
Exercism is a great way to think through a bunch of ways to solve a small
Emacs is neat in that…
it can actually contain a shell within a buffer and that shell is
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.
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.
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.
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 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.
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:
# '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.
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.
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.
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.
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:
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.
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.”
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.
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.
Get a pairing session scheduled and established. Share a screen. Type together. Sometimes this takes longer… sometimes it’s just a few minutes.
Work on the simplest possible setup you’re comfortable with. Usually this is Google+ and ScreenHero, but YMMV.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.