The Hippy Hacker

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.

Getting free

Sun, 28 Aug 2011 16:52:34 GMT

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.

Lone Star Ruby Conf 2011 "More DSL, Less Pain" Presentation Slides

Fri, 12 Aug 2011 16:51:49 GMT

You can find the slides from my LSRC 2011 presentation here.

Contemplating performant acceptance testing

Fri, 12 Aug 2011 09:05:06 GMT

The symptom

Rack app acceptance tests are slow.

The problem

Acceptance tests add value by exercising the complete system. In doing so, scenarios within acceptance tests reiterate upon previously tested features of the system.

Example

This is, perhaps, the most simple example.

Given an acceptance test that demonstrates the ability for a user to create an account When I write another feature for user, with an account, to authenticate Then my new feature’s acceptance test will require the user to first create an account

Explanation

Most current acceptance testing practices would have us retread this ground. This is the essence of why acceptance testing is slow: most Rack app acceptance tests exercise the entire Rack app stack several times. This is done in order to acrete the desired “setup” state within the test to actually perform the test.

Hypothesis

Why don’t we treat a test suite like a real build process?

Express ordered lists of dependencies between acceptance tests
Each successful test records the changes that it made to the database and the HTTP session
Before executing a given acceptance test, the recorded state changes are played back into the database and http session
Now we can acceptance test as normal

This should allow for acceptance tests to execute a minimal number of trips through the Rack stack. This would, I hope, increase acceptance test execution time geometrically if not by an order of magnitude on the whole.

Your Thoughts?

These are just words: a brain dump of an idea that I had in the shower this morning. I’d love to see (maybe, OMG, write?) a Rack=specific way to facilitate this that could be used by Coulda, Cucumber, etc.

Help me give back

Sat, 16 Jul 2011 11:44:10 GMT

For those of you who have found any of my blog posts, conference presentations, pairing with me, or rants from me in other contexts to be of value, I need your help.

I live in Worcester County: perhaps the poorest county in the state of Maryland. The unemployment here is worse than the already depressing national average.

Sadly, the local educational system emphasizes anemic tech skills. While they recently began offering an online-only Ruby course, they don’t offer one on their campus. Nor do they offer a Ruby on Rails course. I approached them 3 years ago to allow me to teach a Rails course and was rebuffed.

This is the year that they’ll have a Rails course. I don’t care if I or someone else teaches it. Although I don’t know anyone who does Ruby or Rails within 150 miles of here. That means that it’s probably me.

I’m trying to convince the community college that the economic demand is there. If their prospective students aren’t asking for the skills then the skills should be marketed better to the students.

So now I need your help.

Please let me know if you’d be willing to act as a reference as I attempt to win the community college over.

Thanks.

UPDATED: You can best help by writing a comment on this post about what, when, and where you learned something from me and what you thought of my ability to teach. Thanks! The sudden outpouring of support has been as surprising as it is appreciated!

UPDATED2: Please do mention a little about yourself as well for context.

Knowing when (and not) to suggest removing the beans

Sun, 10 Jul 2011 12:09:44 GMT

Last night, I happened upon this delightful article thanks to Hacker News. Within it, the author, a consultant not unlike myself, relates a story given him by a mentor. In it, in short, the storyteller’s client does what can only be summarized by irationally and willingly “stepping in it”.

From this, the storyteller relates his First Rule of Consulting: “No matter how much you try, you can’t stop people from sticking beans up their nose.” In other words, sometimes otherwise rational people will knowingly and willingly do things that, to you, would seem insane.

This story stuck with me.

You see, I’ve contracted to the US Federal Government for many years and I’ve witnessed a lot of fail.

But I digress; this article isn’t about the US Government. This article is about determining when to give advice.

Watching the beans go up

While I’m “only a consultant”, I care about my clients. I hate seeing people stick beans up their nose: it looks damn uncomfortable and its an unfortunate use of some possibly good beans.

Of course, I’ll humbly suggest that this may be a poor use of their beans. However, sometimes the client isn’t open to advice on the matter. And, sometimes, they’re right not to be.

It’s only fair to admit: I don’t know everything about my clients. Gerry Weinberg would probably argue that I shouldn’t try to. Even so, while I may see Beans Nose United (a new soccer team?), they may see The Mona Lisa. And they may be right.

But this article is about when they’re not.

Planning the intervention

The article I cited above suggests asking “So, how [are those beans in your sinus cavities] working for you? Did [they] do everything you’d hoped?”

That’s a fine (and hilarious) start. It’s possible that the response may be “this really REALLY hurts!” at which point any humane individual would provide Kleenex or refer them to a rhinoplasty surgeon.

However, most people (and I’ll include myself here) are reluctant to immediately admit failure. Maybe tilting our head just so could make our nose hurt less. Mouth breathing could provide some relief as well. Now we’re bargaining.

The consultant must approach with patience. A younger, more rash version of myself would rush in (and has before) with something like: “You have beans up your nose, fer crying out loud! Blow your nose, dammit!”

This is not a good way to endear yourself to your client.

With a little age (eventually) came some wisdom. I’ve since learned to ask questions instead of leaping to offer advice. Yes, sometimes even with the calmness of a yoga instructor.

(Ok, so a badass yoga instructor)

And, perhaps a few days or a week later, I’d ask, “How is your nose feeling today?”

I admit I’m pretty sure that I know the answer already. I expect to hear, “It bloody hurts!”. But that may not be the answer that I receive. And that’s the two-fold point: (1) Has the client started to accept that they made the wrong decision or (2) do I have the wrong sense of the situation. If the former, we’ve found our opening.

Intervening

This would be a good time to find a private place to further inquire about their nasal discomfort.

Be gentle! We’re dealing with the soft sensitive tissue of the nasal cavities (or, eschewing the metaphor via this aside, our clients feelings/self-image)! Rushing directly to extract the beans could result in severe trauama! Don’t. Reach. For. The. Forceps!!!

At this point, your client has signaled you that they realize they’re in a bind. You’re finally on the same page. And, odds are, your client already knows solution. Now it’s safe to offer a few gentle suggestions and ask some more probing questions

Thus begins your journey, hand-in-hand, down the path to a legume-free and more productive client.

Fiddling with Redis sorting

Thu, 17 Mar 2011 15:52:36 GMT

Nick Quaranto’s excellent Redis talk at Mountain West Ruby Conference particularly captured my fancy when he demonstrated Redis sort. An audience member asked whether it was possible to chain the result of gets on a sort. Redis’ documentation is excellent; however, the entry on multiple gets in a sort was just a touch unclear.

During a break today at MWRC, I through together this quick example. I’m also posting it here as someone on Twitter questioned my conclusions (as I do myself). Provided below: