The Hippy Hacker

Emacs: A strange new world (Part 1 of many)

Wed, 24 Apr 2013 12:00:19 GMT

I often find, when adopting a new tool or language, to try to learn how to use it as it was meant to be used. Sure you could write Ruby code like a Java developer but far better to write Ruby like a Ruby developer. Idiom\ s matter.

To that end, lets approach Emacs as a beginner with few preconceived notions from VIM. I’m not suggesting that you forget all of the lovely features that you enjoyed in VIM but instead that you should start with the basics\ and build up from there.

So to begin at the beginning:

A quick google led me to Emacs’s built-in tutorial: C-h t. The built-in tutorial is a fantastic place to start. I found it more accessible, due to its narrow focus, than vim’s. That said, the tutorial will \ give you just enough to be comfortable with simple navigation within emacs.

Among the many features the tutorial will introduce you to is “help on help”: C-h C-h is perhaps your best friend. From there, emacs provides several different avenues to discover new functionality and elabor\ ate upon what you will learn.

Help yourself!

C-h C-h: help on help, literally. This function gives a summary of all of the built in help features and the keybindings to invoke them directly.
C-h b: list all keybindings.
C-h c: display the function run by a specific keybinding

Copying, yanking, pasting, deleting, and killing

As a newly-minted Emacs user, you’re probably wondering how to yank and delete. Be warned “yank” means exactly the opposite in Emacs as it does in VIM. Wacky, right?

In VIM, you yanked/deleted text and then pasted it. With Emacs, you “copy” or “kill” text then “yank” it into place.

With all of this in mind, let’s turn to our new friend C-h b.

Text search

C-s RET

: This puts you in interactive search mode (which, frankly, at this point, I’ve far from mastered). At its most basic, interactive search will navigate you forward through your current bu\ ffer toward the first matching characters. Subsequent presses of C-s will lead you to matches further forward in the buffer and then eventually wrap to the top of the buffer.

Discovering functions

My first big “Ah ha” moment with emacs came when I realized that I could use to invoke any “interactive” functions in emacs. That is, you enter M-x then begin typing the name of a function. Aft\ er a few letters, if you hit return, emacs opens a window showing you all of the matching function names.

yanking: I’m sure there’s a scholarly article somewhere in uncovering the history of yanking in the *NIX community but I will leave that as an exercise for the extremely atypical readers.
interactive: functions are emacs lisp functions containing a call to the “interactive” function thus informing Emacs that they may be invoked interactively.

Modality kills (or how I learned to love emacs and stop swearing at tmux)

Mon, 11 Feb 2013 12:36:00 GMT

I’m an Emacs switcher.

There. I’m out of the closet.

After 18 long years of vi, I finally switched to emacs. Despite many attempted explanations in <= 140 characters and numerous requests, I’ve relented and written this to explain why.

I’ve been a remote worker for over 4 years now. But, as an extrovert (yes, I’m freakish that way as a developer), I love to pair program. I’ve blogged about my pair-programming tool chain in the past. That tool chain has continued to evolve. The crucial point: I need to live in my shell to remote pair as I do.

And most recently, I learned that modality kills.

VI is modal. Tmux, my preferred terminal multiplexer, is also modal.

modal * modal = modality²

Put another way, usability goes straight to hell.

So here I am, minding my own business, writing some code in VI. When, all of a sudden, I decide that I want to switch to my terminal running in the other window in my vertically split tmux session. So I switch windows and try to scroll up with Ctrl-u. What the hell? Why doesn’t this work? Ctrl-u Ctrl-u Ctrl-u dammit!

Oh. Right. I’m in tmux. Ctrl-b [ Ctrl-u works. Finally.

Now repeat this a few hundred times.

(Much cursing at VI and tmux have been elided here to reduce your enjoyment of this article.)

The basal ganglia, physical memory, doesn’t understand this modal shit. You’re doing something. Then you’re doing something similar. It should work pretty much the same way, dammit. If I’m banging around in a terminal or hunting a sabertooth tiger the mental model should remain consistent. But, oh, that’s right: digital reality has little basis in the real world. Unfortunately, our brains just don’t quite get that.

And, dammit, modality makes all of that worse.

Sure, I learned to cope with VIs modality. Sort of. Let’s be honest, VI users. You know that you frequently are in command mode when you thought you were in insert mode and vice versa. But you develop coping strategies. Then you almost forget that you’re using them.

Now imagine having to have habits to cope with making that same mistake but in a shell within tmux instead of the VI session that you thought you were in.

Down this path lies madness.

And, so, I found my way to emacs. Emacs gives you eshell for standard: a LISP-based terminal emulator. ansi-term is a small step up from eshell. But I still found myself having problems with it. Then my friend Avdi Grimm pointed me at multi-term. I have been happy ever since.

You see, multi-term is a “major mode” of emacs. While it does commandeer a great many of the ordinary key bindings, at least I can scroll up or search through a multi-term history the same way that I would any ordinary emacs buffer. Though, for the life of me, I cannot understand why scroll down automatically throws me back to the prompt instead of actually scrolling down.

Oh, did I mention that emacs has an actual programming language, emacs lisp, instead of the vim’s sadomasochistic vision of hell known as vimscript?

Yes, I still use tmux. But now I solely use tmux per its name: as a terminal multiplexer. I don’t need to create windows: emacs gives me that. I don’t search within tmux sessions: emacs gives me that. Tmux barely matters any more except for facilitating sharing my session with another user. And that’s about it.

In case you’re deeply concerned about the productivity hit, I was running at about 75% or so after just a few days.

If you remote pair and live in the shell, you owe it to yourself: switch to emacs.

Conciseness > Verbosity > Leaky

Mon, 17 Dec 2012 19:50:03 GMT

Naming is one of those two well known problems in computer science.

It is key to abstraction. An abstraction with a poor name will often be misunderstood.

As I teach myself Clojure, I find myself reflecting on all of the functional code that I’ve seen in my career: the Lisp, Haskell, Erlang, and Clojure.

There is a single common thread through them all that troubles me: the names chosen for their core library. There’s a terseness to all of them. It makes for a steeper learning curve. However, for some aspiring functional programmers, the curve may be so steep as to be exclusionary.

Some examples

foldl/foldr (Haskell)
conj (Clojure)
car / cdr (Lisp)

Lisp, as the grand-daddy of functional languages, perhaps set the trend. Lisp functions names tend toward the spartan and terse. More recent functional languages perhaps follow suit.

The core functions outline the idiomatic use of the language. And, so, most functional programs I’ve seen have a strong tendency toward abbreviated names for their functions and their variables.

I fail to see how this is a good thing.

I can hear them now: “But, Evan, you’re a pathetic C/Java/Ruby programmer who has only dabbled in functional programming. You just don’t understand.”

What am I missing here? We’re far from the world where programmers may have measure code in byte sizes due to storage constraints. Can we all agree then, in this modern age, that we can stop fussing over saving bytes and just use meaningful (in the literal interpretation: full of meaning) names?

While I prefer conciseness, I’ll gladly take verbosity in its absence. Either are better than a name so terse that it results in a leaky abstraction!

Use Rails until it hurts

Wed, 21 Nov 2012 13:12:13 GMT

Over the past year, there has been a strong popular push toward what I’ll describe as purely SOLID-based approaches to building Rails apps. While I attempt to adhere to SOLID as a series of guidelines, they are just that: guidelines.

Evidently, once, someone caught me saying “Use Rails until it hurts”. By this, I meant “don’t preemptively implement around perceived Rails weaknesses solely to respect SOLID/your-favorite-OO-principle”. This does not add value to an application.

I recently wrote about #accepts_nested_attributes_for. In that post, I explained that there are clear circumstances where #accepts_nested_attributes_for will save you time and code. However, in many cases, it won’t. And, for those, I began working on an alternative.

Contingencies are good. Once you deviate from Rails’ “golden path”, your work can quickly become challenging. But knowing that a person/tool/technique has a weakness does not mean that you automatically preempt them. It means that you should remain aware of that weakness. You should compensate for weakness when it becomes an issue. To do so sooner smacks of angst.

Let’s consider the discussion here around the Observer pattern versus the benefit of a tightly coupled imperative style. The Observer pattern decouples event producers from event consumers. For that matter, the Observer pattern is similar to Queue-based messaging services such as the CORBA Notification Service, Java Messaging Service(JMS), and all of those that followed save that it is, typically, implemented in a synchronous fashion and within a single process.

As cited in the C2 wiki, the Observer pattern is best used for “dynamic relationships between objects.” There are relatively clear guidelines around when to consider employing it.

So what about when relationships are not dynamic?

Under these circumstances, I posit that tight coupling can be helpful.

What is tight coupling good for? Used selectively, in a word: clarity.

Which is clearer? (Please bear with my non-ActiveRecord ActiveRecord example for the sake of argument)

The Observer (listener)-based example at the top decouples the save event from the pushing the change to the client event. While you can argue that these are two different responsibilties, they are both directly related to the change on the User’s name. I argue that this approach adds unecessary indirection.

To speak more broadly, I argue that our campaign against tight coupling has simply gone too far.

In the latter case, we have less code! This is, often, considered a good thing¹. The controller, responsible for performing the change to the User object, also pushes a notification to the client of the change. The tight coupling makes this entirely clear: when I change the user’s name and save the user, I immediately push the change out on a socket to the client.

Yes, you can make a case for extracting the behavior from the UserController#update method into its own method or even class.

Whether to extract the logic out of the controller or not should be a fuzzy decision. Yes, the update method is clearly responsible for more than just routing. This is “bad”, right? Or is it?

If we extract a class to represent the context of the User’s name changing, we’ve just created another file and another class. Also, where does this class go? To me, it’s just a delegate of the controller. It’s certainly not business logic. Pushing a message out on a socket does not represent business logic at all. Instead, it’s just how we interface with our View/Client. Extracting a class, in this case, increases the cognitive burden on ourselves or any developer who comes after us.

If we extract a private method instead of extracting a class, we’ve added a layer of indirection instead of abstraction. Frankly, I’d lean toward something like this.

But, clearly, this will lead to a fat controller! ¡Qué terrible!

Personally, I would instead characterize it as a controller of a healthy weight.

Moderation is key. Noticing its lack is as well.

I hope that, from the above example, you’ve decided to stop factoring everything into another class and, occasionally, give tight coupling a chance. That said, if you’re among those who write “god classes”, “god methods”, and is unfmiliar with “loose coupling”, I strongly suggest reading Working With Legacy Code by Michael Feathers (the man who coined “SOLID”).

Rails isn’t perfect. But it is one of the best solutions for the problem space that most of us work in. Use Rails until it hurts. Don’t preemptively replace Rails features. Use Rails until you find yourself writing more code doing it “The Rails Way” than if you rolled your own solution. Then identify an alternative solution. Use that alternative solution as your application’s fallback convention for when the matching Rails convention fails.

Or, as a peer of mine, wrote:

@elight Refactoring to patterns > starting with patterns IMO.
— Brian P. Hogan (@bphogan) November 9, 2012

While Rails provides many solutions out of the box, you should make a concerted effort to keep your own personal toolbox of fallback techniques (such as the Form object) on hand. Share them. Convert them into tools for use by your peers whenever possible.

¹ As code itself is a liability!

#accepts_nested_attributes_for (often) considered harmful

Wed, 07 Nov 2012 09:13:46 GMT

TL;DR: #accepts_nested_attributes_for is not evil but it should be used infrequently. It often results in brittle code. Consider using the redtape gem (which offers an implementation of the “Form Object” pattern), instead.

As a long time #accepts_nested_attributes_for critic, I was excited when Bryan Helmkamp introduced us to the idea of the “Form obect” in his 7 Patterns to Refactor Fat ActiveRecord Models blog post.

#accepts_nested_attributes_for is used, in ActiveRecord classes, to reduce the amount of code in Rails applications needed to create/update records across multiple tables with a single HTTP POST/PUT. As with many things Rails, this is convention-driven: the ActiveRecord classes expect to receive their POST/PUT parameter according to specific naming conventions used solely for nested data.

While this sometimes results in less code, it often results in brittle code.

In order to benefit from this coupling, we now have to:

Write forms/HTTP clients that will send the nested data expected by the model
Have the receiving controller action simply passes the data through to the correct “top-level” model’s #new method.
Not require additional massaging of the HTTP params otherwise we’re just writing more code which is what #accepts_nested_attributes_for is trying so hard to avoid.

In my experience, use of nested forms often requires at least some massaging of the data if not outright removal of #accepts_nested_attributes_for at a later time in favor of handling the data manually within the controller action.

That is, it’s brittle.

So let’s go on a tangent: “best practices”.

“Best practices” are dangerous. Few, if any, so-called “best practices” are universally best. They’re perhaps best in a particular context. Yet developers often treat them as panaceas (a discussion for another day…).

So let’s put this in context:

Only use #accepts_nested_attributes_for if all of these conditions are met:

The form/API data requires no pre-processing prior to hand-off to your ActiveRecord::Base’s #new method.
(If you have a UI,) The UI fields can map, one-to-one, to the model fields; You know that you can afford to tightly couple the view and model so that they vary codependently on one another.

Conversely…

Use redtape if you need your UI to vary independently from your model.¹.

Consider using redtape if your input data requires pre-processing prior to hand-off to the model. Obviously, you can do this in a private/protected method of your controller as well.

Ultimately, the goal is to have working, maintainable code that satisfies your needs with minimal effort. Choose the simplest path to arrive there. Consider your options and weight them accordingly.

¹: I know what some devs out there are thinking: “But, Evan, SRP says I should always allow them to vary independently.” Yeah, well, sometimes you should break the rules but that should be the exception and not the norm. Not that SRP is a “rule” so much as a “guideline”. Pretty much the only “rule” of software development is “thy program should execute deterministically”.

UPDATE 1: I had considered making this argument in my Frustration Driven Development talk but, then, I didn’t have a solution at the time. I hate providing a criticism without presenting an alternative…

UPDATE 2: Redtape::Form includes ActiveModel::Validations. You can add validations to your Redtape::Form just as you would an ActiveRecord::Base subclass. Beware: Don’t duplicate validations from your model in your Redtape::Form. Instead, add validations if your form inputs are raw values requiring processing before being used in your model. Your form can then catch these errors early and provide contextually useful error messages.

The DCamp Manifesto

Sat, 06 Oct 2012 09:13:15 GMT

What is this “DCamp” thing I keep hearing about?

The typical conference model is involves a handful of one-to-many exchanges of information. The conference model assumes that you, as an audience member, will gain the most value by receiving information directly from a few people. It is, in essence, a classroom.

DCamp assumes you don’t do well in classrooms

In 2008, when DCamp was created, and Ruby still wasn’t quite mainstream, Ruby developers were, on the whole, brilliant. It seemed wrong, to me, to have an elite few who were frequently speaking at conferences.

In my experiences, speakers are typically extroverts. This in no way implies that introverts have nothing to offer. But introverts seem to put themselves out there with less frequency. And so conferences would typically feature the same extroverts again and again.

When you attend a conference, how many open laptops do you see? How many people are paying attention? How many are socializing with other attendees besides at the inevitable “drink up” after-party.when they get some alcohol in them?

I wanted to lure out the introverts. I wanted to hear what they have to say.

DCamp puts people on a level playing field

We don’t have “talks”. We have “sessions”.

Or, to put it more bluntly, there’s a “no talking head” rule.

No one stands at the front of the room and lectures to you (except maybe during 5 minute lightning talks). Presentations often serve to elevate and separate the presenter from the participants. That’s not our way.

Campers collectively decide on topics that interest them.

Anyone who proposes the topic for a session is responsible to be the facilitator for that session. Facilitating in no way implies expertise in the topic. It connotes a strong enough interest in the topic to moderate a discussion or a hands-on activity. The facilitator is there to keep the conversation flowing and to ensure that no one individual monopolizes the floor. Because…

Time is limited

Sessions are typically 30 minutes. Originally, they weren’t. But, over the years, I found that shorter sessions leave people hungry for more. The last thing you want is to have a session drag on past its inevitable conclusion.

Either a session will be too long or too short. If the session is too long, people become tired, bored, and listless. If it is too short, they’re still excited and eager. They’re more likely to continue the discussion on their own terms during breaks or after DCamp.

You’re responsible for your education

If a session isn’t valuable to you, the Open Space model provides “The Rule of Two Feet”. You have two feet (or perhaps 4 wheels): use them. Go to another session. Or take a nap. Or hang out with other brilliant people and shoot the shit.

Other than the Code Retreat, each morning, we collectively decide on the content.

We spend about fifteen minutes in a plenary brainstorming session.

The next fifteen minutes are spent proposing topics. Everyone is given pens, paper, and duct tape. You scribble down topics that interest you and your name next to the topic. Then you slap the topic up on the “wall o’ topics”.

Fifteen more are spent dot voting on topics.

The camp is set loose for fifteen to thirty minutes while a few of us sort the topics out into a schedule.

We’ve learned that, typically, a two-track schedule works best where one track has votes in descending order and the other ascending. This tends to minimizes the number of session conflicts for campers.

But we usually have a third track: for newbies.

The newbie track tends to be predictable each year as it rehashes a lot of the same territory: setting up a development environment, basic Ruby skills, using git, then an introduction to web development with Ruby. More experienced developers take turns, throughout the day, leading these hands-on sessions. Teaching is a great way to discover knowledge gaps for more experienced developers. To that extent, everyone wins!

DCamp encourages participation

Yes, you can be a wallflower through all of DCamp. But it’s not easy.

First, there are the sessions, that you’ve already read about.

Then there’s the Code Retreat. The retreat gives you about six opportunities to pair with people you’ve just met to solve a problem. Even if you’re an introvert, it’s not too hard to get together with another developer and just do your thing.

And then there’s the chores.

At DCamp, there’s:

No catering
No restaurants
No hotel staff
No hotel

Yes, the first DCamp was at a hotel. The event worked but, boy, was that hotel a pain in the ass to work with! Really, it is far cheaper, more fulfilling, and an overall better experience to just do it yourself!

The event provides the venue, a (relatively) comfortable place to sleep, bathing facilities, electricity, a kitchen, and space to hold sessions.

Getting supplies to the camp is tricky. For the first few years, that was all me, me, me and… let me see… *me*! But, as with stone soup, campers began to notice that everything went better when they participated in pretty much every phase of the event including the logistics. Bear in mind: this didn’t happen overnight! Most early assistance that I received was ad hoc at best. It wasn’t until perhaps until the fourth DCamp when campers, of their own accord, became proactively involved in logistics.

I’m not complaining but that was a lot of shit to buy, lifr, and haul mostly on my own! Having more logistical help has been wonderful!

Oh, and you’re on your own for internet at DCamp.

That’s right: bring your own internet and wifi.

DCamp is free

At first, it was $100. Then the US economy melted down. While our sector has withstood most of the storm, not all of us were so fortunate.

So… free (as in beer).

Again, that means the entrance fee, the food, the venue, everything: free.

That is, in truth, the event sponsors pay for it.

Yes, DCamp is listed as $1337 on the Eventbrite page. They require a for-pay ticket to be listed. If you don’t get the joke…

DCamp is frugal

If you include the cost of t-shirts, DCamp costs around USD $5k per year to produce.

DCamp attendees are curated

I’ve used Eventbrite to handle mass-email, registration, and wait lists for DCamp. Each year, I create coupon codes in Eventbrite. These codes get distributed to community leaders who I trust and respect. Each code is usually good for 5 registrations at a time. These leaders are then responsible to find the awesome people who will populate DCamp that year. Once a code is used up, typically, I refill it. Some communities are rabid DCamp fans so I titrate the release of codes to them. Otherwise, they would utterly overwhelm the event. This would not be a bad thing except…

DCamp supports diversity

Monoculture is death. We are stronger when we have a diverse set of individuals to learn from. And, so, I encourage, and actively attempt to draw from, people from all walks to participate. In the past, we have had software testers, a film director, an investment banker, women, men, people black, yellow, white, straight, and queer. Variety is not only healthy but damn fun!

DCamp is not commercial

Commerce is out there but it’s not part and parcel to the event. Sure, we all work for a living. And our sponsors generously help the event occur each year. But, first and by far foremost, the event is about its participants: the campers. If the campers win, the sponsors win.

Though we’ve had repeat sponsors: they occasionally get a good hire from DCamp!

DCamp is for technical people. NO RECRUITERS. NO MBAs (unless they’ve become programmers). Because…

DCamp is not for profit

No one makes money from producing DCamp. When I created it, I was an overpaid government contractor. DCamp was born for love of Ruby and its community and not greed. It continues in that vein.

DCamp is finite

DCamp is size constrained to 78 people: the number of beds available at Cabin Camp 3 in Prince William Forest National Park. We want to ensure that each and every camper adds to the value of the whole. This means that we welcome neophytes, journeyman, and experts alike. You’re qualified to be a DCamper if you’re:

Inquisitive
Passionate about sharing your knowledge
Someone who plays well with others

Due to the recent surge in interest, there will be exactly 0% growth in the size of DCamp.

Instead, I encourage you to make your own DCamp. This is the entirety of the reason for this piece.

DCamp is remote

DCamp is off the beaten path, removed from civilization, a little difficult to reach. Coming and going can be a challenge. And that has proven fortunate because…

DCamp is a community

I will in no way pretend that I intended every aspect that has made DCamp the wonderful event that it has become. Much of the above was discovered through serendipity and some from suggestions from within and without. But we, the campers, noticed these gems. Then we integrated them into our ethos.

I make every effort to include past campers. While I do not curate registration, I am personally responsible for the wait list. Preference always goes to past campers.

Why?

Because, over the three-to-four nights that people spend at DCamp, we forge tight bonds. This happens naturally when you are constrained to the same physical space with the same 78 or so people with similar interests.

And, so, each DCamp serves as a reunion of sorts for returning campers.

At the end of it all

We get together and hold a retrospective. We discuss what felt good and what didn’t. Lessons are shared and, sometimes, relearned. Occasionally, a worthwhile lesson is lost year to year.

Finally, we gather together, clean the camp in no more than 30 minutes, the remaining food is divvied up among folks who can use it, then folks depart.

Oh and I’m left with a small lost and found. Hooray. ;-)

What’s the point?

If you didn’t pick up on it along the way, DCamp is, at its core, a four night nerd commune.

In closing

The purpose of this piece was to provide the inspiration and insight for you to roll your own DCamp. Should you decide to, please do reach out to me. I would be glad to provide counsel and would love to attend!

If you’re a former camper and find that I forgot to include some essential insight, please do let me know!

DCI that respects the method cache

Thu, 24 Nov 2011 18:25:44 GMT

Ryan Bates sent this pithy tweet earlier today:

I’ve been toying with DCI lately. But the techniques spelled out to date here and here use Object.extend. Extending an object blows away the method cache, slightly reducing performance.

So, as I lazed in bed, reading this tweet while dreaming of turkey to come, it hits me: instead of implementing the Delegator pattern through extend, let’s just use an actual Delegator object.

Simple example below based on the usage of NewUserProvisioner within RubyPair.

Our good friend SimpleDelegator is defined in “delegate.rb” in stdlib, courtesy of James Edward Gray II.

Some people call me "the remote pairing guy"...

Mon, 17 Oct 2011 12:23:56 GMT

I’ve been remote pairing with folks for a couple of years now. However, it’s only the past few months that I decided that heavyweight application-based solutions just weren’t working for me.

Expectatons

I expect my remote pairing experience to be as close to in person as possible. To that extent, what I desire is:

Responsive

When I, or my pair, types, I expect to see it on screen in near real-time. Even a one second delay is potentially too much.

Low bandwidth requirement

I often pair with people on the opposite side of the country. Higher bandwidth solutions tend to suffer more due to lack of bandwidth

Audio and Video

I need to be able to both hear and see my pair when pairing whenever possible. Without video, body language can’t be communicated.

For instance, ever noticed how you will often gesticulate when you’re on the phone. Feels stupid, right? It’s human, it’s communication, and so it matters to pairing.

I need my video of my pair, and vice versa, whenever I can get it.

FYI, I tend to place the video of my pair just beneath the camera on my screen. I also work to keep the video o my pair visible at all times. More on that in a bit.

Modular

The above two reasons mean that I need to be able to pick and choose which features of my pairing environment I’ll use based on internet weather. All-in-one solutions dont lend themselves well to this.

Cost

I don’t want my pairs to have to pay for extra products or services to pair with me.

Learning curve

I want to use well-known and usable tools so that my pairs aren’t wasting time fighting the tools when they should be pairing with me.

I’ve tried

VNC
Teamviewer
Mac OS X Screensharing
Skype Screensharing
Google Plus Screensharing & Hangouts
Tmux
Screen

All of these have let me down.

VNC (and Mac Screensharing)

VNC and Mac Screensharing (allegedly VNC under the hood) are both bandwidth intensive, typically proving too unresponsive for sustained pairing. On-screen updates often lag one to several seconds.

Teamviewer

Teamviewer is generally responsive.

But it’s way too expensive! A single license runs ~$700! Sure, it’s for life. But then my pair has to have it as well. Granted, Teamviewer is free for non-commercial use.

I also had it crash a pair’s Linux machine! This did not give me good vibes. Your mileage may vary.

Skype

Ah, Skype. How I love to hate you.

The laundry list:

Screensharing is unidirectional: My pair can see my desktop but they can’t effect changes
Frequent dropped connections
Screensharing frequently hangs while audio continues to operate as normal. This can only be corrected by dropping and restarting the call! FAIL!
Frequent compatibility issues with older versions of Skype
Video may be the most bandwidth intensive of the tools I’ve tried that provide video
Skype 5 has one of the least usable interfaces ever conceived in the 21st century

Just don’t use it. Really. Don’t.

Google Plus Screensharing & Hangouts

G+ is a different beast from Skype, though it has some similar features.

G+ screensharing is also a strange beast. It’s a feature within G+ Hangouts, a group video chat provided by G+. Like Skype, it’s unidirectional. I know, bummer, right? But it’s extremely responsive compared to Skype. Alas, again, it’s unidirectional. That won’t work.

But G+’s audio and video in Hangout is simply amazing. And it’s cross-platorm. The only sad part is that it uses Flash; it’s pretty CPU intensive. For example, it would peg both cores on my 11” Core 2 Duo Macbook Air.

Let me provided emphasis here: I strongly prefer G+ Hangouts for my A/V while pairing.

Tmux/Screen

Tmux and GNU Screen are basically two different takes on the same idea.

They’re session multiplexeres.

English, please?

They let you open multiple shells within a single terminal shell. You can also share the Screen/Tmux session via a socket with other users on the same machine.

Again, for emphasis, I use tmux whenever possible when pairing. I have my pairs SSH into a machine under my control, fire up tmux, and off we go to the races! My impression is that it’s more a matter of taste; I’ve seen Screen work as well.

Delving into the details of SSH is a bit of scope for this article but you can read more about the basics here.

Tmux (and screen) is:

Open source and easily acquired
Extremely low bandwidth over SSH
Most responsive option of the bunch
Tmux has a shallow learning curve: it’s easy to become productive with it quickly. I’ve seen numerous developers learn enough Tmux to be productive in it within a minute or two of explaining how to navigate between terminal sessions.

Nut’s n’ Bolts

As I mentioned above, the high level of my pairing stack is…

G+ Hangouts
Tmux
SSH

… but there are few more parts to the equation.

I typically pair with people on a machine behind a router

I use a DD-WRT router. DD-WRT is an open source router firmware that works on a whole range of off-the-shelf routers. Among other awesome features, it has a nice built-in feature to keep DynDNS current with the router’s internet-facing IP address. Because, like many people, I lack a static internet IP address (they’re just a tad finite, you know?), I use:

A free DynDNS account
Keep DynDNS updated through DD-WRT

Finally, because I control the router, I port forward SSH from the router to my internal machine of choice. Advice here: don’t keep your SSH on the well known port 22 for security reasons.

I use a Mac

While I can do a passing job of faking it as a Linux sys admin, I prefer not to. Sorry, Linux peeps.

That said, OS X has this handy little checkbox in the Sharing -> Remote Login preferences to help you secure your SSH:

Working with SSH on a Mac

I also need to be able to easily add and remove users based on their SSH public keys. Most importantly, I need to be able to tell OSX that these newly created users should be allowed to connect to my machine via SSH. This took a little bit of research and, frankly, is OS X arcana. As such, I wrote a pair of quick-and-dirty scripts that automate the chore for me.

Recap

My whole stack amounts to:

G+ for audio-video chat while pairing
A shared Tmux session running on a Mac under my control made accessible via a DynDNS address hidden behind a DD-WRT router port forwarding SSH to the Mac with users provisioned/removed via a couple of scripts on an as-needed basis.

And, so, I bid you happy remote pairing!

Helping you fish better!

Fri, 23 Sep 2011 15:29:04 GMT

Helping you fish better!

In one form or another, I’ve been a contractor for the vasty majority of my career: building other people’s software for them. Along the way, I have mentored developers, founded and continue to run a conference (now going into its fifth year) to enrich and educate both beginning developers and expert alike, have shared some of what I have learned along the way by speaking at user groups and conferences, and regularly pair with distant developers to both educate, share with, socialize, and learn from them (I wrote most of RubyPair as well).

This has led me to realize that I am happiest when I am helping eager developers improve their skills. Seeing the “eureka” moments can only be described as a rush!

A couple of months ago, I began setting aside at least 3 hours each week, when I’m not on travel, to remote pair or otherwise consult with other developers on Open Source. Again, that time is only for Open Source and not for commercial use. I’ve taught a lot. I’ve learned a few things. I’ve met some cool people who I wouldn’t have otherwise. It’s been a blast!

As the Chinese proverb goes:

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

That’s what I’d been doing. I simply had not put a label on it! The mentoring, the conference and user group presentations, the (not-so-) occasional rant about why people should be writing their tests first and then move on to evolve a Test Driven Development discipline: it has all been about trying to help other developers get better.

I’d blog but, while not a terrible writer, I don’t have the writing bug as much as some. But, man, do I ever love a good conversation or pairing session!

I want to touch and enrich lives. I want to help people fish, that is: write software, better!

What only occurred to me a month ago was that this mentoring fills a real need. I could make a living off of helping people have “eureka” moments!

And, so, for anyone who is looking to improve: this one’s for you.

DANGER WILL ROBINSON! COMMERCIAL PITCH FOLLOWS!

Via Triple Dog Dare (I admit, I really need to update this page with more recent work but I’ve been too busy!!!), over the past several months, I have helped bootstrap one company from almost no Rails knowledge to a working application. For another client, I’ve provided occasional periodic one-on-one mentoring in building his web startup with Rails (shhhh….. it’s a secret for now!). For both, the majority of the collaboration has been online. Although, for the former client, I’ve occasional traveled out to San Fran to help them onsite. San Fran is just such a terrible town to visit, after all – and, yes, I’m kidding; San Fran is pretty awesome.

But, yes, most of the mentoring occurs online. Sometimes I’m answering questions via email, more often IM, doing a code review, or helping via VOIP or a remote pairing session.

And, let me tell you, remote pairing works pretty darn well. The technology is not only there but it’s been there for some time. Frankly, VOIP was the missing component for a long time. The other technologies involved are tried and true *NIX apps.

I’ll write about remote pairing in a later post. It’s been at the forefront of my mind a great deal lately.

If you or a team you work with is new to Rails and you believe you would benefit from someone to shepherd you through the learning process, drop me a line!

The automated testing confessional

Sun, 04 Sep 2011 07:23:59 GMT

Hi, my name is Evan. And I don’t always start a new app by writing tests.

There, I said it! Crazy, right? Well, ok, maybe within our test-obsessed Ruby world.

As much as I promote automated testing and Test Driven Development, and you can call me a hypocrite, but I don’t always TDD or even test first. Sometimes I just want to write some %#@&ing code!

But here’s the catch: it almost always bites me in the ass later.

Take for example Ruby Pair. Ruby Pair is, currently, a humble little directory of people interested in pairing on Ruby, remotely or in-person, for fun or to work on open source.

Bad Evan! You only started writing tests a few weeks in!

Now that I’ve berated myself…

Ruby Pair hasn’t been my full time job; it’s been my hobby project for the past 3 weeks. When I’m working on a project for fun, or on my own dime, I’m more likely to try to see how far I can get without automated tests.

Why? Because I’m lazy, dammit!

The key is to be lazy in a good way.

RATHOLE

So I have another confession: until I found Ruby, Perl was my favorite tool to avoid writing shell scripts. I deplore writing shell scripts. Sure, I live in the shell (zsh, thank you very much) on a daily basis but that doesn’t mean that I have to code for the shell using the shell!

/RATHOLE

Larry Wall, the author of Perl, talks about the “three great virtus of a programmer”. He lists laziness chiefly among them. When Larry says “laziness”, he means the kind of lazy where you’ll go to great lengths to avoid doing unecessary work later.

Sounds a little like automated testing, if you think about it.

When writing a new app, at first, it’s almost always easier for me to begin by just banging out code. How many times have you set up authentication in an application? Or created a User class or a users table? Pretty motherhood and apple pie, right?

So you’re writing your code, you think everything’s fine, everything’s good. Then the next thing you know, you’re on fire!

Ahem Ok, I mean “you discover that your code base is a flying spaghetti monster”.

My point is twofold:

You don’t miss something until it’s no longer there. It is important and reasonable to sometimes avoid writing automated tests. Now don’t go and use that as an excuse to your momma if you get busted for it. Occasionally skipping your automated tests is a healthy way to develop an appreciation for them.
Not every piece of code should necessarily be tested.

BLASPHEMY! Right?

Well, not really…

Have you ever tested every path in your application? If you say “yes” then that application must have been no larger than a few methods.

Instead, we pick and choose what to test. We do it all of the time.

Typically, most of us write tests for the happy path. “What’s the happy path?”, I’m occasionally asked. It’s that magical case when all of your inputs are valid, all of your external dependencies are met, and so everything works as expected. Everything else is a “sad path” a.k.a. “degenerate” or “edge” case.

“What not to test” is a heuristic that varies from project to project. Personally, I decide what not to test based on the (1) risk and (2) impact of failure of the particular component/feature.

A couple of anncecdotal examples:

ALMOST ALWAYS TEST: Whenever I’m dealing with currencies, virtual or otherwise, I’m writing a test. Few things tick off a user faster than mishandling their money!
RARELY TEST: Authentication? Psh! I’ve set up Devise enough times. For the happy path, it’s easy!

If you’re not familiar with the basic ideas behind risk management (and you’re too lazy to follow that Wikipedia link), use this rule of thumb: just how confident are you that your code will work? How bad will it be if it doesn’t? Listen to your Jiminy Cricket.

To sum up: not TDDing or writing your tests first is a decision. If you’re going to make that decision, do it in an informed way. Occasionally, writing code without tests serves as a useful touchstone to remind us why we write tests and use TDD.