Object-oriented relativism

When a Method Can Do Nothing, Michael Feathers:

If polymorphism means anything at all, it means that the object is in charge. We send it a message and it is up to it to decide what to do. That's core to OO and part of Alan Kay's original view of objects - that they are all about messaging. That said, it is not the dominant view today.
The majority of this article is on working with/around conditionals using intention-revealing method names or null objects. Yet, this paragraph smacked me in the face with "oh, yeah, obviously!". Lots of people view the moving parts in object-oriented languages as ways to group and share functionality. But to people who talk about OO a lot, read the history books, read the pattern books, know what SOLID is, etc. it's an entirely different thing.

Here’s a sports metaphor: the Dallas Cowboys are a widely disliked sports team, for various reasons. If I was from anywhere but Dallas, it would be “not cool” to count myself one a fan. But being from Dallas, I have an entirely different view on the Cowboys and can safely watch their mostly mediocre performances with occasional memories of greatness, safe from scorn.

I find that holding that tension in my head is important when talking to sports fans. It’s the same with OO: you haven’t read the books, watched the presentations, or worked the exercises I have. We’re on different pages, but we need to talk about the same code and how to structure it. There’s a tension between my understanding of OO and the next person, but it’s not a barrier. We have to get our language straight before we can talk about language!

In short, we have to establish what city in OO-land we’re from before we can effectively talk about OO.


Designing technological empowerment

Applied Discovery:

What future are we building, given that we play a role in such an important process?
On the role designers play, what they do as careers progress, and how design can positively enhance the world.

Reminder: if you tilt your head just so, developers do a lot of design activities too.


Friday at a Mexican restaurant

20131109-124843.jpg

Could be any Mexican restaurant. Could be any Friday. This one seemed special to me.


Currently intriguing me

A channel, a sewer, Alabama, and a sunset walk into a bar:

What’s intriguing you, dear reader?

Breakfast cannot wait, Prince

rd.io/x/QFWiK0E…

Look, Prince, I’m not sure if I can agree with you regarding “Breakfast Can Wait”. Cereal? Toast? English Muffins? Sure, those things can wait. Migas? Pancakes? Bacon? These things cannot wait. And don’t get me started on eggs; wait too long and delicious eggs can go rubbery and gross all too quickly.


A path through Enumerable

In Cocoa, you can poke inside object graphs (and more!) using dotted strings:

 NSDictionary *bestOfBeatles = @{@"paul": @{@"beatles": @"Hey Jude", @"solo": @"Jet"}};

NSString *solo = [bestOfBeatles valueForKeyPath:@"paul.solo"];
NSLog(@"Paul's Best solo song is: %@", solo);

Hey, did you notice that Objective-C sprouted some really handy literals for arrays and dictionaries lately? One could reasonably extrapolate that Apple has an interest in not breaking people’s fingers when they build for iOS and OS X.

There are libraries, e.g. Hashie, that make uniform access into object graphs, like you might get from an API response, as close to idiomatic Ruby as you probably want. Key paths, as implemented in Cocoa’s Key-Value Coding APIs, takes a different approach, using strings to define paths to traverse an object graph. I don’t really like “string programming”, but it’s an interesting approach, so let’s see where it takes us. Let’s add something like “key paths” to Ruby!

Hark, an implementation

Enumerable is an awesome thing about Ruby. Let’s build key path traversal on top of that. The goal is something close to the Objective-C snippet above:

 best_beatles = KVC.new({"paul" => {"beatles" => "Hey, Jude", "solo" => "Jet"}})
solo = best_beatles.for_path("paul.solo")
puts "Paul's best solo song is: #{solo}"

Turns out this isn’t hard to implement, even with a little error handling thrown in:

require 'delegate'

class KVC < SimpleDelegator

  def for_path(path)
    segments = path.split('.')

    segments.inject(self) do |value, s|
      if !value.respond_to?(:has_key?)
        raise ArgumentError.new("Expected #{value} to respond to has_key?")
      end

      if value.has_key?(s)
        value[s]
      else
        raise KeyError.new("Missing key #{s}")
      end
    end
  end

end

OK, first off, did you realize that SimpleDelegator makes it ridiculously easy to wrap objects with extra behavior? It sure does! Second, you could easily write this with a while loop or even a simple each, but why have local variables hanging around when you could use inject instead?![1] Third, this has more conditionals than I’d like, but it fits within 80 columns[2] so I’ll take it.

The pros and cons of using key paths

I’ve got this code, based on a whim. I’m not even sure it’s a good idea. Maybe it is!

  • It’s simpler to specify a traversal into a deep object graph with a string than with a bunch of key lookups or method chains. It’s slightly clearer too.
  • “Selector APIs”, like XPath or jQuery’s extensions to CSS, are an idea many developers have already wrapped their head around. I wouldn’t want to go anywhere near the complexity of those APIs, but an opinionated set of operations on an object graph might not get too complex.

Maybe it sucks?

  • Enumerable is pretty great, why wouldn’t you use that?
  • Programming by banging strings together is terrible.

Judgement

I can’t really tell you, definitively, if you should try this or not. I’ve barely even used KVC in Cocoa! It’s a nifty idea, though, and it’s pretty rad that you can implement something like it in Ruby so trivially.

Now you know!


  1. I realize this is a point of contention in the Seattle.rb ranks  ↩
  2. Forgive me now, Seattle.rb?  ↩

Football rules: not hard, even for the defense

The NFL is going through an awkward transition from laissez-faire bloodsport to something…less bloodsport-y. Players-turned analysts often rush to the side of the “victimized” defensive players who are now faced with…rules. It’s pretty dumb, on both sides:

  • It's not like these players learned different rules in high-school and college. Tackling is the same from age 12 onwards: you put your arms around a guy and pull him to the ground. Knocking a guy off his feet is just an impressive but dangerous form of bad tackling.
  • Defensive players already learn complicated blitzing and coverage schemes. To suppose they can't figure out how to hit a guy only between the knees and shoulders is a bit cynical.
  • All that defensive players do is react. React to a block, react to a ball-carrier cutting, react to a pass. Adding circumstances under which you can't clock another play is only a marginal increase to their rule-bound duties.
  • Football is always changing. New offenses, new defenses, new rules, new schemes, etc. Slightly changing how tackling works isn't going to turn football into badminton.
  • Players know what they're getting into in the short term: possible injuries. Not as many know what they're getting into on the long term: the possibility of being a zombie.
  • Some former-players have gone on to lead productive lives. Others have not, and a few have taken their own life rather than go on with the one football left them. Survivor bias is not a reason for inaction.
I think football can turn into something less about violence and more about strategy and skill, but only if those on the outside help those on the inside instead of helping those seeking the untenable status quo.

Let me help you, computer DJ

I look forward to the day when machine learning can differentiate between “don’t play this song because it is awful” from “ don’t play this song because I’ve heard this it a thousand times” (e.g. “Superfreak”, “Rapper’s Delight”, “Come as you are”). Related, I’d love a way to tell the machine learning “if you are ever stumped about what to play next, it’s always OK to slip this song in” (e.g. “Wouldn’t it be nice”, “Summertime Blues”, “Izzo (H.O.V.A)”, “Overture to Samson and Delilah”).


Quit your desk

Things I’ve quit doing at my desk:

Many writers maintain a private writing hut. The hut has one purpose: it’s the place they go to write. They don’t do anything else there. Once they can’t write any more, they go do something else. I think we need to think of our desks in the same way: these are places where we get work done.
I like my desk, but I know the hours I can sit at it and get work done before fatigue sets in are finite. I try to mix in standing at our bar-height dining table, sitting on the couch (most recently, with three dogs), working from coffee shops and occasionally sitting on the front or back porch.

The big idea from that article, burning a hole in my head, is that we should step away from our desks when we’re not working (for me, telling computers to do things). Thinking can happen on a walk, standing outside, or in the shower. Socializing can happen from the couch or mobile device. Procrastinating by reading, surfing, social networking, etc. can happen anywhere.

Once I freed my mind from the idea that I’m only working the moments my butt is in a chair at a desk in front of a computer, my work improved and my life got better. Quit your desk and find out for yourself.


It's all made of maths

Math: humans mostly have a love/hate relationship with it. And yet, even if you’re challenged by the continuous maths like myself, it’s hard to argue that there isn’t something magical to seeing the commonplace of our world in mathematical terms.

vimeo.com/77330591


Coffee and other warmups

Making a cup of coffee sometimes helps me prepare for the process of solving puzzles with computers. Something about choosing AeroPress, French press, Chemex, or Clever; heating the water to 212F or 200F; medium-fine, medium, or coarse grinding of the beans. The weighing and grinding of the beans, boiling the water, rinsing the filter, pouring the water, waiting, pouring more water, agitating, pressing the coffee, discarding the filter and grinds. Now I’m left with a cup that I made for myself. A minor victory for the day.

All sorts of things require warm-ups. Stretching, air-squatting, or a quick jog lets my body know it’s almost time to exert itself. Word association or playing little games tells my brain it’s time to improvise.

Updating some documentation. A tiny, superficial refactoring or layout change to some code. Drawing a picture in my notebook. Making some coffee. That’s how I know it’s time to solve puzzles.


Off my grid

Off my grid

Courtney regularly drives an hour southwest of Austin, past Dripping Springs, to practice dog agility at a barn her friend rents. It's amazingly quiet once you get past the city, past the backroads, and out into the hills and trees. It was an overcast evening when I went with her so the sunset was a no-show. Yet, the serenity and variety of it wasn't lost on me.

Reads for your weekends

That what I’ve read today and greatly enjoyed:

  • 1491, on rethinking what America looked like before Europeans arrived. Has a delightful sci-fi twist: large parts of the Amazon rainforest could be a human effort, not simply nature. The notion that what many of us consider wilderness might be due to the human hand has tricky ramifications for the tension between preservation and development.
  • The End of the Nation State asks, what if we’re already forming the structures that come after large-scale states?
  • Innovation Starvation, Neal Stephenson on the reasons why we aren’t building big, awesome things like we did in the sixties or seventies.
  • Presentation Skills Considered Harmful, Kathy Sierra argues that it isn’t a good performer that makes a presentation good, it’s a presenter focused on the skills, needs, and experience of the audience that makes it good.
  • The Inferno of Independence, Frank Chimero on the tensions of what it means to be an independent creator of words, music, software, etc. The tensions and misconceptions are worth considering, even if you don’t consider your work “indie”.
  • FastImageCache, an iOS open source library for quickly storing and rendering images, has an intriguing explanation of why displaying many images on mobile devices is hard and how they’ve worked around it to deliver a smooth user experience.

Ignorance: pros and cons

We can often, but not always, choose to ignore those on the internet, on TV, and in our lives with different ideas, philosophies, or opinions about the world. Whether intentional or accidental, this is ignorance.

Ignorance is handy because it can keep us sane. We can’t know all the things or have all the experiences. We all value things based on our own experiences and learnings. We cross-reference that with our ego and emotions and come up with our “truths”. Conflicting “truths” can hurt, and so we only let some kinds of them in and trim our lives to exclude the others. This is helpful for reducing stress and making for more happy days.

It’s not great though, because it isolates us from seeing more of the world and understanding it more clearly. Many media fights/beefs/arguments are rooted in conflicting “truths” and collisions of ignorance. You ignore the value of a supportive government, I ignore the value of maximum personal liberty, and boom! we’re arguing. We’re not getting things done.

Personally, that arguing is stressful. I’d rather not get worked up about politics, governance, and technical minutiae if at all possible. Therefore, I selectively engage in ignorance. I try to double check my assumptions and ignorance occasionally; I find ignorance is a useful tactic, not a long-term strategy.

If you could imagine a world where empathy ruled and everyone possessed a superpower for compromise, you might see a world where ignorance isn’t so much of a problem and amazing things can get done. Oh, what a fantastic, science-fiction world!

Ignorance is bliss and that which prevents us from achieving really big things. Use your ignorance carefully and with consideration.


Peyton Manning, boringly awesome or awesomely boring?

The best thing you’ll read about football today. Peyton Manning is what happens when a guy with the attention to detail of an accountant is also proficient at throwing a football and making snap decisions. Manning also looks like he could give you excellent tips on cutting your hedge or fixing that one toilet.

This is why Peyton is my favorite Manning.


Draw your software

Better Code Design through Pictures:

Looking at a picture like this reveals so much that is missing when only looking at Emacs or Vim. Classes that violate the Single Responsibility Principle may become obvious because they’re related to too many other classes. Cyclical dependencies might be identified. Even class names may be brought into question. These discoveries are not very obvious when writing code, but they were remarkably obvious once we threw the structure up on the whiteboard.
I almost always have some kind of notebook and pen by my side so that I can doodle words and shapes. Having a whiteboard nearby is even better.

Happy Birthday, Mr. The Boss!

How to celebrate the 64th birthday of Bruce Springsteen, “The Boss”, if you’re new to this curious American phenomenon:

You want to listen to at least one of these albums because there is no one who better combines the story of America with its music than Bruce Springsteen. If all you know of his work is “Born in the USA”, you got some educatin’ to do!

Find the classes lurking in your ActiveRecord models

This advice is going on a year old, but it’s still some of the best around. If you’ve got ungainly ActiveRecord objects that are doing way more than abstracting your data model, you are missing classes in the design of your application. Chances are, one of the objects Bryan describes here is what you might want to extract.


Developers are weird with words

Naming things is hard. Witness things that developers have named and then struggle to explain because words and people are weird:

  • TDD sounds like it's about testing, but it's really a design technique.
  • BDD sounds like it's about what code does, but it's really a communication discipline.
  • Outside-in development sounds like a way to discover the design of software, but it's really a technique for building software using a fractal todo list.
Bonus developer weirdness not about words: If you can't decompose an idea into a todo list, you've got an initiative, not a project. Be afraid, keep digging at the idea until you can make it a todo list.

Twice the podcast listening

I like to listen to podcasts and screencasts at two or three times the recorded speed. The application I use (Instacast) does this with pitch correction, a feature that’s probably built into iOS at this juncture. In short, I can listen to a thirty minute podcast in ten to fifteen minutes and they only sound funny when music plays. I do mean funny; listen to Radiohead’s “Creep” at 3x speed and it comes out downright chipper.

Our brains can process speech at these accelerated rates just fine. In fact, when I listen to some of my favorite podcasters in “real” time, they sound like they’re thinking really hard and speaking slowly, or that they’re flat-out drunk. The interesting bit is when an accelerated speaker has an accent or when there is radio interference with the FM transmitter I use in the car. At this point, all bets are off and I have to slow the podcast down or listen when the signal is better.

The bottom line is that, empirically, human speech has built-in redundancy. We tend to speak at a rate that, if you miss some sounds, you can probably still make out the words. Further, the space in-between words is probably filled with our own thoughts anyway; we only listen part of the time we’re listening.

Nifty things, our brains are.