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.
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.
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.
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!
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.
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.
I often find myself talking with people who are talented but unfulfilled in their career. I tend to ask them what they love or what frustrates them enough that they’d love to fix it. Those are the two ideas that motivate me. What can I make better or what pisses me off enough that I feel compelled to do something about it.
The conversation often follows the same route. The other person has some ideas. Who doesn’t? So I challenge them: I ask them why they’re not pursuing those ideas already. I tend to hear something like “I have a mortgage to pay”, “I’m in too much debt”, or “my wife/husband would kill me”. What do all of these have in common?
Most people are extremely attached to their standard of living.
“Money is a dissatisfier”, my father would tell me. When you don’t have enough to be comfortable, life is hard. When you have more than you need to maintain a comfortable standard of living, it is easy to fall prey to the notion that the crap that you buy is essential to your happiness.
Before I continue, just a little about me. I was raised in a simple middle class family. My father worked for the government (he’s retired since) and my mother is a piano teacher. Admittedly, my parents spoiled me to the extent that they could while I was a youngster. This probably contributed to my previously poor understanding of the value of money but don’t tell them that. They still feel guilty about it sometimes. But, hey, I turned out OK after all. I was more fortunate than some: my parents saved for me to attend college. Ultimately, this meant that I exited college without debt. I always pay my credit card every month, much to the chagrin of credit card companies. The only loan that I maintain is a modest mortgage.
Now back to my point.
Just before my wife and I relocated from Northern Virginia, we had a $450,000 home with a third-acre in Vienna, two cars, several computers, three cats, and a giant television. But it didn’t start that way. That’s just how we were three years ago.
When I made my decision to seek fulfillment over income, just over three years ago, I quickly learned that, unlike the US government, the private sector pays according to market forces. The US government, in its infinite wisdom, generally pigeon holes people into buckets based on years of experience and some other factors, e.g., how many and the specific kinds of acronyms following your name. Those buckets largely determine your earning potential.
Leaving the government sector, I had almost no “portfolio” to show, just a single tiny OSS project, and no presence in the market.
This left me with a decision:have a rewarding job that pays about half of my cushy government contracting salary or continue on as I was. I chose the former, took the paycut, and I have not regretted it even for a moment.
My great epiphany, in my first year of living here in Ocean Pines, MD was this: happiness is not determined by income or material possessions. I long held to this belief but I didn’t understand it, at a gut level, until two years ago. You probably don’t grok it either unless you came from a poor upbringing or have had to suddenly put the fiscal belt on much tighter due to circumstances.
You don’t need the expensive house. You can probably live somewhere cheaper. Your debt doesn’t keep you from saving money. If you’re reading this then you’re probably also self-identify as a “geek”, “nerd” or similar. You don’t need all of that fancy Apple hardware; you can get by on cheaper and use Linux. You don’t need that iPhone/Android phone with it’s nearly $100/month plan; a feature phone with a calling card will satisfy most emergency needs.
Write a list. Decide what is essential. I mean absolutely essential. Then write another list: what possessions will you be unhappy without. I mean genuinely unhappy. Now how much do you need to save each year to feel safe and secure?
If you got rid of everything else, how much less would you be spending per month? Congratulations! You probably just found a way to largely break free of the establishment.
Given a reasonable intellect, contemporary skills, and a reasonable but modest definition of “comfort”, the less money you need to spend. That means there’s less money that you need to earn. Less time spent earning means more time for perhaps the most important of preoccupations: realizing your potential.
My name is Evan Light and, yes, I am a nerd. I'm also a professional software developer who, after spending one too many years contracting to the federal government, escaped into the far more enjoyable commercial world. Having spent several years using C and even more using Java (the latter very nearly caused me to give up programming entirely), I consider myself fortunate to have discovered Ruby and to use it as part of my daily work.
My name is Evan Light and, yes, I am a nerd. I'm also a professional software developer who, after spending one too many years contracting to the federal government, escaped into the far more enjoyable commercial world. Having spent several years using C and even more using Java (the latter very nearly caused me to give up programming entirely), I consider myself fortunate to have discovered Ruby and to use it as part of my daily work.