Ruby

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. ...

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. ...

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. ...

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. ...

Last night’s pair session was with @stuartrexking - a very experienced developer and technologist currently working at a really neat company called Antipodean Labs. It seems like he’s got a great handle on solving problems and staying maintainable. We started off by trying to decide what to do. I’m increasingly convinced this is the possibly the hardest part of remote pairing with people who aren’t part of your company. You don’t have a predefined complex project you both find interest in, so the most likely shared interests are either meta problems or highly common ones. Highly common ones are very visible and difficult to find low hanging fruit for. The meta problems are good to solve, but somehow feel like they are less valuable than the “real” problems. Maybe this is just a feeling I have. ...

Ruby is not Rails. Learn Ruby first. Get rbenv (preferred) or rvm installed with Ruby 1.8.7, 1.9.3 and 2.0 Write Hello World and run it puts "Hello World" Go through the Ruby Koans (simplest with 1.8.7) Go through some TDD exercises Code a simple ruby script that solves a problem you have, like… Add a TODO to a file Print out the date in another time zone Tell you how many days until… Perform some repetative task related to your environment Display something silly for your kids Ruby is not Rails. You do not need to learn all the “magic” of Rails to learn the awesome of Ruby. Spend some time and get where you can really drive a script and solve a simple problem. Doing this will get you far beyond a beginning Rails developer. You simply have to learn the magic incantations of Rails to be able to develop web apps after that. And those incantations won’t be nearly as scary.

I had a great #pairwithme session with @_zph. Always a pleasure to talk to him and solve a problem together. Setup TMUX + VIM on a slice github-auth gem Experience We wanted to add the feature to gh-auth so you could pass a –path or –user argument to it. Because we’re good developers, we started off by coding the acceptance test. We discussed the merits of how to write good tests and whether to follow convetions within a gem authored by someone else or do things ’the right way’ – according to whatever coding religion you follow. Eventually we decided on sticking to the conventions of the gem while trying to improve–but not radically change–the tests/testing that we touched. From there, we dove down into the implementation and unit tests and drove through until we had the –path argument working. Along the way we did a little refactoring to use the OptionParser instead of requiring a specific ordering of options. ...

Last night I had a great pairing with @Shicholas working on the String Calculator kata. Setup We again used TMUX + VIM, even though Nick wasn’t very familiar with VIM. Based on his experience, I think this might be the best way to learn VIM since you have someone guiding you through. You won’t pick up on everything, but you’ll learn a handful of new things each time. Exercise We went through each of the different rules and ping ponged back and forth. It was a struggle to do the simplest possible thing every time, and really let the tests DRIVE your development. Your developer brain wants to generalize the solution to a problem, but the strength of TDD is keeping your actual solution as simple as possible. Developers are notorious for over complicating things and over desigining. ...

I had my first pairing session with @willpragnell today. He’s a smart guy and my first European pair partner. It was a pleasure to talk to him about his iOS and Ruby experience and I picked up on a lot of little things from our pairing session together. Setup TMUX and VIM - (I got to use my newly revised pairing script to set up everything in seconds) TicTacToe - RSpec The Session We set a couple of goals out for the beginning. We both wanted to learn more of RSpec’s new syntax and we wanted to really adhear to the TDD principle of doing the most simple thing next. ...

Today I paired with @mattr_ and got quite a bit of good input regarding how to attack a problem and write tests. Matt is a super smart guy who has really absorbed some of the fundamentals of TDD and it shows through his ability to break down a problem. Setup TMUX & VIM on my box Conway’s Game of Life as an exercise Process When implementing the game of life, we started off looking at the problem on Wikipedia and found the 4 rules. I immediately started writing the first test when Matt noted that he liked to write all the specs he knows of as pending specs right at the beginning. Then he can really plow forward and know what’s next. He also noted that he likes to be able to write the assertion first, based on the test, and then build the test up from there. I felt the lightbulb go off when he pointed these two things out. When I’ve struggled to find the test or figure out how to test something, usually it’s because I can’t figure out how to get to the assertion, and that really comes down to not testing the right thing. ...