Avdi Grimm

TL;DR: OS X users pick their hardware from a very short list of known-good configurations, and when you do the same thing for Linux, the results are equivalent.

Like most nerds I know, I don’t mind disagreement, but something in me just can’t stand a poor argument. And thus it is that I feel compelled to write about one such argument. The one that goes:

I’d use Linux if the hardware support was as good as OS X.

This is (usually) a bullshit argument. Read on for why.

Do you use OS X? Great! I used it for close to two years, and was very impressed with it. I’ve already written about why, for me, switching back to Linux was the pragmatic choice based on the work I do. Linux gave me a more broadly useful,  reliable, it-just-works development environment than OS X. YMMV; I’m not here to tell you what works for you, or rehash that old article.

Anyway, if you use OS X, what are you running it on? Did you put it on that old Dell you had lying around? Or the Toshiba with the funky keyboard layout? Or are you dual-booting it on your hand-built gaming rig?

What’s that? None of the above? You bought it pre-installed on Apple hardware? And, lo and behold, it supports that hardware really well? Amazing. What are the odds of that?!

Here’s the problem with the “Linux has lousy hardware support” argument. What people are really saying when they make this argument in comparison to a Mac is this:

Linux didn’t support the hardware on whatever random computer I tried to throw it on. But OS X runs on its reference platform with no problems!

This is a double standard. To have its “great” hardware support, a given release of OS X has to support a few dozen hardware configurations. Linux has to support eleventy-billion, including but not limited to intelligent prosthetic knees. But while a poor argument, this would still be a perfectly viable reason to buy a Mac if Linux had no reference platform. Supporting 95% of the hardware in the universe is no great comfort if your laptop’s touchpad is in the other 5%.

But here’s the thing: it does have a reference platform. No, it doesn’t have an official reference platform, not even whatever PC Linus happens to be using these days. But for developer workstations, there’s a de-facto reference platform, and it’s called a ThinkPad. If you’ve been using Linux for any length of time you know that if you want a linux desktop machine to Just Work, you buy a ThinkPad. There is a self-reinforcing cycle that perpetuates this phenomenon. Linux developers tend to use ThinkPads, so they tend to make sure that the hardware is well supported, so Linux developers tend to buy more ThinkPads, and so on. I don’t know where it started, but that’s how it works.

Chances are you implicitly picked a MacBook or a MacBook Air when you chose your next  OS X machine. You paid a premium, but it was worth it for the great overall experience. When I last decided it was time for a new development machine, I picked a ThinkPad X230 because I know ThinkPads are the gold standard for running Linux on the desktop. And guess what? It Just Works. Beautifully. (In fact, these days I’m starting to see Linux support PC hardware better than Windows in some cases, which is just embarrassing for MS. But that’s another topic…)

It’s not completely limited to ThinkPads; these days you can also get a Dell XPS 13 Developer Edition, with Linux pre-installed and tweaked to work perfectly. And of course there’s always System 76.

The point is this: if you have a great OS/hardware experience because you picked from a short list of known-good configurations, that’s no great feat of engineering. If you do a little research, you’ll find that there’s a similar short list for Linux machines. Your choices  are limited and you may pay a little more… go figure.

But stop complaining that Linux didn’t work on your dad’s old Compaq as well as OS X runs on a brand new MBA. It’s a double standard and you know better.

(Addendum: in rare cases, someone actually makes the “Linux has bad hardware support” in good faith. Usually it’s in the context of some very new (or very obscure) hardware which they need for their work, but which Linux doesn’t yet have drivers for. If this is you: I hear ya. This article is not about you.)

EDIT: There is an important corollary here for Linux users. If you use Linux and like to advocate for its use, it’s time to stop telling people they should try it and it’ll Just Work. Because it won’t. It’ll probably Mostly Work. And the remaining 5% of not-workiness will cause yet another person to start propagating the “Linux has bad hardware support” meme. If your friends are curious about running Linux, tell them to go ahead and give it a whirl. But make sure they know that for best experience, they will have to research and choose a known-good configuration. Just like they did when picking out their shiny Mac.

EDIT 2: I should also point out that I use Ubuntu, because it has the highest it-just-works factor of any distro I’ve tried. I’ve thought about going back through this article and s/Linux/Ubuntu/. 

EDIT 3: Yes, it’s true, even some ThinkPads (or some choices of components) are wonky. I checked ThinkWiki before I pulled the trigger on my last workstation purchase.

Today’s freebie (episode 55, if you’re counting) covers a simple technique for making a single .rb file work as either a library or a runnable script. In the process, it covers the __FILE__ constant and the $PROGRAM_NAME variable.

I just released a gem I’ve been working on for the last couple days. It’s called Naught and it’s intended to make it easy to build various kinds of Null Object class in Ruby.

This isn’t the first generic Ruby Null Object library, but I think you’ll find its approach a little different than most. Rather than a one-size-fits-all solution, Naught gives you tools to quickly build the null objects that make sense for your library or app. It also includes some less-common features, such as:

• The ability to “mimic” or  ”impersonate” specific classes. The resulting null object has a stubbed version of the target class’ interface; any other messages sent to it are errors.
• Traceable null objects that can remember where they were instantiated, for easier debugging.
• The option to have null objects implement sensible default versions of #to_a, #to_s, #to_i, #to_ary, etc.—all the usual explicit and implicit conversion methods.
• Convenient conversion functions like Maybe(), Just(), and Actual(). See the documentation for examples.
• And quite a bit more…

The README is fairly detailed, check it out for more about the what, they why and the how.

Hey, remember when I said I’d finish Confident Ruby by September 1, 2012? Ha ha! That was a funny joke!

Seriously though, this book has taken much longer than intended, partly as the scope grew, but mostly because of other projects getting in the way. Such as the launch of RubyTapas. I’m hugely appreciative of all the early-access buyers who supported the project and have been patient through this process.

Those early buyers have already heard the news, but now I’m letting the rest of the world know: as of now, Confident Ruby is finally content-complete and entering a Beta phase. That means that while there is plenty of editing, clean-up, and tweaking to do, all the major content (a little over 150 pages’ worth) is now in place.

I intend to spend one month getting Confident Ruby into shape for a final release. At the end of that month, I will be raising the price to $35. Until then, you can still get it for $25. As always, if you don’t have the scratch you can send me a postcard instead.

Curious about what’s inside? The nutshell version is that this is a patterns book, focused on the method level of code. It’s all about how to make methods that are “confident”: that is, they tell a clear, straightforward story without a lot of distracting provisos and digressions. In order to get you from “timid” code to confident code, I lay out 32 patterns for collecting input, delivering output, and handling failure within a method. There’s a strong emphasis throughout on removing the scourge of nil values from code, and replacing them with more semantically meaningful constructs.

Here’s the current table of contents, if you’re curious:

• Introduction
  • Ruby meets the real world
  • Confident code
  • A good story, poorly told
  • Code as narrative
  • The four parts of a method
  • 3.times { rejoice! }
  • Collecting Input
• Sending a strong message
  • Conditionally call conversion methods
  • Define your own conversion protocols
  • Define conversions to user-defined types
  • Use built-in conversion functions
  • Use the Array() conversion function to array-ify inputs
  • Define conversion functions
  • Replace “string typing” with classes
  • Wrap collaborators in Adapters
  • Use transparent adapters to gradually introduce abstraction
  • Reject unworkable values with preconditions
  • Use #fetch to assert the presence of Hash keys
  • Document assumptions with assertions
  • Handle special cases with a Guard Clause
  • Represent special cases as objects
  • Represent do-nothing cases as null objects
  • Substitute a benign value for =nil=
  • Use #fetch for defaults
  • Use symbols as placeholder objects
  • Bundle arguments into parameter objects
  • Yield a parameter builder object
  • Receive policies instead of data
• Delivering Output
  • Write total functions
  • Call back instead of returning
  • Represent failure with a benign value
  • Represent failure with a special case object
  • Return a status object
  • Yield a status object
  • Signal early termination with =throw=
• Handling Failure
  • Prefer top-level rescue clause
  • Use checked methods for risky operations
  • Use bouncer methods
• Refactoring for Confidence
• MetricFu
• Stringer
• Parting Words

And here’s a video of the talk that started it all:

http://www.youtube.com/watch?v=T8J0j2xJFgQ

And here’s that big friendly “buy now” button again!

On May 22, the 100th episode of RubyTapas will arrive in subscribers’ inboxes and RSS readers, and I’m marking the occasion with a great big giveaway! I’ve got a whole pile of eBooks and other goodies to give out. Check out these prizes, and check back later because I may be adding more before I’m done!

UPDATE: This giveaway is now over. Thanks to everyone who entered, and congrats to the winners!

Everyone

Everyone who enters will receive a 20% discount for Cloudapp Pro and 10% discount on all AppSignal plans for the first 12 months! Yep, everyone!

Grand Prize

One lucky winner will receive:

• A full year of RubyTapas!
• Free ticket to Barcelona Ruby Conference (travel/accommodations not included)
• 1-year free AppSignal Small plan
• 1-year membership to learnable.com
• 1-year subscription to CloudApp Pro
• 1-year subscription to RailsCasts Pro
• 2-month subscription to thoughtbot Learn Prime
• Jump Start Sinatra by Darren Jones
• Rails As She Is Spoke by Giles Bowkett
• Upgrading to Rails 4 by Andy Lindeman
• Prosthetics And Orthotics: Lessons Learned In Building Plugins For Backbone.js by Derick Bailey
• Master Space and Time With JavaScript by Noel Rappin
• Clean Ruby by Jim Gay
• Rebuilding Rails by Noah Gibbs
• Ruby Under a Microscope by Pat Shaughnessy
• Everyday Rails Testing with RSpec by Aaron Sumner
• Working With Unix Processes by Jesse Storimer
• Mobile Web Patterns with Backbone.js by Nick Gauthier
• Gitty App for GitHub

Second Prize

Two winners will receive this package:

• Six months of RubyTapas!
• Free ticket to Barcelona Ruby Conference (travel/accommodations not included)
• 6-month free AppSignal Small plan
• 6-month subscription to CloudApp Pro
• 6-month subscription to RailsCasts Pro
• Jump Start Sinatra by Darren Jones
• Rails As She Is Spoke by Giles Bowkett
• Upgrading to Rails 4 by Andy Lindeman
• Prosthetics And Orthotics: Lessons Learned In Building Plugins For Backbone.js by Derick Bailey
• Master Space and Time With JavaScript by Noel Rappin
• Clean Ruby by Jim Gay
• Rebuilding Rails by Noah Gibbs
• Ruby Under a Microscope by Pat Shaughnessy
• Everyday Rails Testing with RSpec by Aaron Sumner
• Working With Unix Processes by Jesse Storimer
• Mobile Web Patterns with Backbone.js by Nick Gauthier
• Gitty App for GitHub

Third Prize

97 more winners will receive the following prizes:

• A 3-month Cloudapp Pro membership
• 1-month subscription to RailsCasts Pro
• 25% discount on all AppSignal plans for the first 12 months
• 10% off Upgrading to Rails 4 by Andy Lindeman
• A coupon to get Everyday Rails Testing with RSpec by Aaron Sumner for just $8
• 10% off Working With Unix Processes by Jesse Storimer
• 10% off Master Space and Time With JavaScript by Noel Rappin
• $5.00 off Prosthetics And Orthotics: Lessons Learned In Building Plugins For Backbone.js by Derick Bailey
• $10.00 off Mobile Web Patterns with Backbone.js by Nick Gauthier

How to enter

Just fill out the form below! All entries must be submitted by May 21st at 23:59 UTC. I’ll announce the winners on this blog on May 22nd.

At the borders of our systems, mockist testing hits a point of diminishing returns. In this free episode we take a look at when to stop mocking and start integration testing.

Some functions are useful in many different contexts. In this free episode we’ll explore some ways to make them available both to library code and to client code of a library.

I have a few ongoing miniseries in RubyTapas. In this, the second installment of a miniseries chronicling the creation of a Rubygems plugin and an associated server, I touch on a number of topics including acceptance testing, the shellwords standard library, the TDD rhythm, and the DataMapper ORM.

Today’s cautionary episode demonstrates and explains a Hash gotcha that often comes as a surprise.

Does code optimized for RAM usage need to be ugly? Find out, in this free episode of RubyTapas.

In this episode, Dave Frey of Haiku LMS, talk about being the first remote worker on a distributed team, remote pair programming, and his own work/life balance.

Show Notes:

Dave Frey (twitter github)

00:36 – Dave Frey Introduction

01:08 – Haiku LMS

05:14 – Being the first remote worker on a distributed team

06:35 – Team Dynamic

07:58 – Remote Pairing

09:30 – Work/Life Balance

In this episode, Allen Maxwell of EmpowerIT, talks about several remote tools and resources, collaborative drawing and design, and making remote working work.

Show Notes:

Allen Maxwell (twitter github amaxwell@empowerit.com)

00:36 – Allen Maxwell Introduction

03:09 – Working Remotely

06:46 – “A Day in the Life”

07:24 – Working with Team Members

10:17 – The Evolution of Remote Tools and Pair Programming

14:25 – Making remote working work

16:43 – Collaborative Drawing & Design

21:10 – Face-to-face meetings and nonverbal cues

In this episode, Jay Hayes of Big Nerd Ranch, talks agile software development and overcoming isolation and communication issues while working remotely on a distributed team.

Show Notes:

Jay Hayes (twitter github blog)

00:39 – Jay Hayes Introduction

01:54 – Results Only Work Environment (ROWE)

03:23 – “A Day in the Life”

05:18 – Topography of Big Nerd Ranch

07:18 – Free Time

08:32 – Challenges of going from collocated to remote work

10:37 – Isolation & Personal Development

In this episode, cofounder Tom Moor, talks about Sqwiggle: an application that allows remote teams to work together throughout the day.

Show Notes:

Tom Moor (twitter github blog tom@sqwiggle.com)

00:41 – Sqwiggle

01:52 – Constant Visual Connection

05:56 – Capturing Faces

08:08 – Awareness vs Monitoring

08:58 – Features

10:44 – Origin

13:22 – Video & Audio Quality

16:06 – Competing with Google+ Hangouts?

17:17 – Upcoming Features

In this episode, Amos King, talks about his experiences working remotely and gives a pretty cool background noise resource for those lonely times.

Show Notes:

Amos King (twitter github blog)

00:39 – Amos King Introduction

01:43 – Commute

03:02 – Asynchronous Communication

04:44 – Backgound Noise

06:25 – Companies & Promoting Remote Work

08:16 – Transitioning into working remotely

13:18 – Amos’ Office

16:21 – Having spare time

17:47 – This Agile Life Podcast

In this episode, J Sherwani and Vishal Kapur talk about Screenhero: a new and convenient collaborative screen sharing application. 

Show Notes:

J Sherwani (twitter linkedin)

Vishal Kapur (twitter github linkedin)

01:01 – J Sherwani Introduction

01:35 – Vishal Kapur Introduction

02:17 – Screenhero

02:43 – Presentation Tools vs Collaboration Tools

05:10 – Proxying

05:54 – Inventing Screenhero

08:15 – The Screenhero Team

09:48 – Use Cases

12:49 – Proxying Desktop Audio

13:41 – Feature Requests

15:34 – In The Works/Improving Screenhero

18:33 – Using Screenhero while Collocated

20:31 – Mobile to Mobile App

23:26 – Work for Screenhero!

In this episode, Ernie Miller of LivingSocial, talks about his transition into managing a dispersed team, “Optimizing for Happiness”, and dealing with distraction.

Show Notes:

In this episode, Nick Adams of Hudl and remotejobs.co, talks about living and working in Rochester, New York, and starting a remote jobs board for companies dedicated to specifically hiring remote workers and people specifically looking to be them.

Show Notes: