Geek Smithology

March 16, 2009

Gardening; not architecture – Oblique Strategies with Brian Eno & Peter Schmidt

Filed under: Craft of Dev by Nathan @ 10:01 pm

Everybody blocks.  Writer’s block.  Programmer’s block.  Lego block.  As with so many things, one of the things that differentiates the great from the average is how we break through.  I’m always on the lookout for new ideas and came across the idea of oblique strategies, an idea from producer Brian Eno & Peter Schmidt.[1]  The basic idea is a deck of cards, each with a pithy (or cryptic) saying on it that helps you reframe your thoughts, like the the one in the title of this post:

Gardening; not architecture.

What does that mean?  We all have our own interpretation, and while our left brained developer minds might not like it, every one of those interpretations is correct.

It has been said that the best metaphors often come from bisociational discord.  In fact, assuming we can bring it together, the further apart the two sides of our conceptual model, the more epic our epiphany when it comes together.

And if it doesn’t?  Who cares!  Pick another card and go again…

Not building a wall, but making a brick.

[1] There are various web resources for using Oblique Strategies: I use the iPhone application myself.

February 28, 2009

It’s ALIIIIIVE!!1!

Filed under: Announce,Craft of Dev,Ruby by Nathan @ 11:34 pm

chess Shortly after I left Service Intelligence all those years ago, a small panel convened at a Tim Horton’s to discuss the future. Well, actually, it was me, The Ront and Foo and since we seemed to like working together we figured we’d write a game of some kind. After not a whole lot of thought we figured we’d go ahead and write a chess game in Java. We didn’t really get anywhere with that, though. Then it happened.

I remember it like it was yesterday. But really, it was right after No Fluff Just Stuff 2005. My eyes were opened and it was decided right then and there that the chess game would written in Ruby. Sure it’s not the most “performant” language for chess calculations, but I wanted to learn Ruby and it’s always better to have a real project to work toward.

We decided to call it “pawnzilla”, for all the reasons you can imagine someone might want to call a chess engine pawnzilla. It’s been a bit of a roller coaster – we went through a horrible OO implementation, transition to 64-bit love and bitboards, and a fairly recent switch from sourceforge to GitHub, but after three and a half years (maybe a couple person months total effort – it’s tough to get time to work on this stuff!) I finally realized a dream, and played a game against my own chess engine.

It was pretty anticlimactic. All of the time so far has been spent working on a complete rules engine (this turns out to be quite a difficult proposition!), so the AI is pretty stupid. So stupid that the game lasted only 7 moves. But still, after all this time, it was great to watch pawnzilla make moves and actually “understand” that the game was over.

I think that we’ve implemented some pretty cool ideas in pawnzilla (including our domain specific approach to testing) and now that there is finally something to see, I hope to start blogging about some of those ideas. The next big goal is to develop the AI into something that doesn’t suck and hook it up to the free internet chess server so that it can get rated. So far it’s been a hell of a ride, and even though it took so long, it’s nice to get to such a significant milestone in my own labour of love.

If you’d like to see it, pawnzilla is licensed under the Apache 2.0 license and you can check it out over on github. And if anyone out there wants to play with a pure-ruby chess engine (should be a lot of fun just to work on different AI strategies now that the rules engine is in place) drop me a line and I’ll be happy to talk about it.

So cheers to pawnzilla.

February 1, 2009

This is your project on Git…

Filed under: Craft of Dev,Ruby by Nathan @ 3:36 pm

There’s been a lot of noise ’bout distributed source control the last year or two, especially with regard to Linus’ other baby, Git. Even I’ve bit – moving pawnzilla from sourceforge to GitHub last year, with serious thought to going with gitsvn in my professional life.

Stuart over at Relevence even went so far as to say that If you run a significant open source project that is not on a distributed SCM, it is a clear warning sign that you are a dinosaur.

He points to a pretty brilliant data visualization of commits to the rails project over the years. Take a look around April 2008, when they moved to Git. Make sure to watch the HD version fullscreen, it’s truly something to behold.

As always, our friends the pragmatic programmers have a book about Git to get you started on the road to enlightenment. (Or distributed SCM, as if they aren’t the same thing…)

July 1, 2008

Street Usability (or lack thereof)

Filed under: Craft of Dev by Nathan @ 8:16 pm

Happy Canada Day! While it’s nice to have a special day, I hope my fellow Canadians take more than one day a year to celebrate everything that makes this such a great country. Except for the number pads on these newfangled parking “meters” in downtown Calgary. I’m sure they’re all over the world by now, but I don’t drive all that often to begin with, and me driving downtown is almost unheard of. The idea is that you park, and then pay for time based on the numbered zone in which your car resides. It insisted the zone number I was keying in didn’t exist. Just as I was about to reduce the machine into it’s component atoms, I looked down and saw this:

WTF is the zero doing up there? There are really two different ways number are represented – like a phone, or like a numeric keypad. The only common idea is that the zero goes on the bottom! So I had pushed the $1 key a couple o’ times and ended up not inputting the correct zone. But what about the larger potential consequences? What if the completely incorrect number I typed in actually was a valid parking zone, just one that was elsewhere. Then while I’m off traipsing around downtown, thinking I’ve done my duty in properly remunerating our fine municipal government for the privilege of parking I’ve left myself open to any nefarious combination of ticketing or towing. Sure you may say I should looked at the display and double checked my work, but can you really defend the position of that zero?

Luckily I was able to calm my nerves by heading into the local coffee shop and settling down with this:

June 12, 2008

Well Done, Mozilla

Filed under: Announce,Craft of Dev by Nathan @ 9:59 pm

I just got around to installing Firefox 3 on my MacBook Pro, and while I find the new Firefox is completely hideous under Ubuntu, it is beautiful in OS X. It’s obvious that a lot of effort was put into making the GUI have the native look and feel. From a couple hours of light browsing everything is better – from the little things like buttons and checkboxes and text fields looking “right”, to the new look for the tabs, to the buttons, Firefox finally looks like it belongs on a Mac.

I’ve never been a fan of skinnable applications, I’d rather have everything be consistent (in an aesthetically pleasing way). So, great work on making Firefox look great out of the gate. And this doesn’t even include any of the new features:

- It only saves passwords after you’re authenticated – about damn time!
- Nicer download window
- Waaay better incremental search in the address bar
- like the new add-ons and plugins look and feel

And it’s noticeably faster for general browsing. I’ve tended to use Safari (gasp!) over the last few weeks, but Firefox has come back with a vengeance.

My only real complaint is that my All-in-One Gestures plugin isn’t compatible. When the hell are you going to make mouse gestures part of the core feature set, Mozilla? Opera did it years ago…

Update – All-in-One Gestures has been updated, so Firefox is back to it’s glory. That said, I’m doing this update from Safari…go figure. Oh, and I changed my heretical misspelling of MacBook because Popowich made fun of me.

February 27, 2008

Domain Specific Adventures in Real Life

Filed under: Craft of Dev,Ruby by Nathan @ 6:49 pm

There is a lot of buzz about Domain Specific Languages and about ten thousand pages describing what they are, so I’m just going to demonstrate a Domain Specific language that I am personally using. It’s for testing our chess engine, pawnzilla.

Probably the simplest thing one can do in chess is move a piece. Here is a sample unit test from earlier in the project:

1
2
3
4
5
6
7
8
9
def test_should_move_piece
    state = GameState.new
    state.clear
    state.place_piece(Coord.new(0, 0), Chess::Piece.new(Chess::Colour::WHITE, Chess::Piece::PAWN))
    state.move_piece(Coord.new(0, 0), Coord.new(0, 1))
    assert_nil(state.sq_at(Coord.new(0, 0).piece)
    assert_not_nil(state.sq_at(Coord.new(0, 1).piece)
    assert_equal(Chess::Piece.new(Chess::Colour::WHITE, Chess::Piece::PAWN)
end

Right now you’re probably thinking “DAMN, that’s a lot of code, and I can barely read it!” And you’d be right. Here’s what the exact same test looks like after some massive rethinking:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
def test_should_move_piece
    state = GameState.new
    state.place_pieces("
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        p - - - - - - -
    "
)
    state.move_piece(A1, A2)
    assert_position(state, "
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        p - - - - - - -
        - - - - - - - -
    "
)
end

Now, dear reader, assuming you know even the tiniest little bit about chess, is there any way you can’t understand this test? This relies on two primitives, each very important in their own way. First, the chessboard itself. Chess players will be familiar with FEN, or Forsythe Edwards Notation, which is used to describe chess positions. Now, FEN is less verbose than our chess board object, but we take the idea of piece representation – white pieces are lower case, black pieces are upper case. This makes it trivial to present any conceivable chess position in the same amount of space, and anybody looking at a test knows exactly what it’s trying to accomplish. The second important thing to note is that in the move_piece method, we’re using simple constants that represent the coordinates of all 64 squares in the corresponding algebraic notation. While (0, 0) (0, 1) is convenient for the engine, it’s very tough for a chess playing human – you end up spending several seconds mentally transposing the cartesian coordinates into algebraic notation. Why not just remove the barriers?

Tests that may have previously been a nightmare to read and figure out become dead simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
def test_should_detect_blockable_back_rank_checkmate
    state = GameState.new
    state.place_pieces("
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - - - - - - - -
        - b - - - - - -
        - - - - - - - -
        - - - - - p p p
        R - - - - - k -
    "
)
    assert(!state.checkmate?(BLACK))
end

This idea can extend to other tests as well. For example, let’s define a square under attack using an asterisk(*). Then testing attack vector calculations also becomes an easy visual test:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
def test_should_calcluate_queen_attack
    state = GameState.new
    state.place_pieces("
        - - - - - - - -
        - - - - - P - -
        - - - - - - - -
        - - - Q - - - -
        - - - - - - - -
        - - - - - p - -
        - - - - - - - -
        - - - - - - - -
    "
)
    state.calculate_queen_attack(BLACK)
    assert_attack_state(state, "
        * - - * - - - -
        - * - * - P - -
        - - * * * - - -
        * * * Q * * * *
        - - * * * - - -
        - * - * - p - -
        * - - * - - - -
        - - - * - - - -
    "
)
end

Now you can really see the power! Can you imagine trying to make sense of a test that had to check all of that board real estate using coordinates?

This demonstration is the quickest way I know how to define a domain specific language. We take concepts directly from our domain, the game of chess, and create primitives that translate directly to real world concepts. Because of its lovely meta-programming facilities, it’s very easy to make Ruby use our DAL by adding our code to the Unit test module. It is important to note that we are not extending the unit test module, but adding behavior to it, as if our domain concepts are native. It’s quite simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
require "geometry"
module Test::Unit
    class TestCase
        A1 = Coord.new(0, 0)
        # etc.
        H8 = Coord.new(7, 7)

        def assert_position(state, position)
            # code
        end

        # and so on
end

Now all of our tests can call upon an incredibly rich toolset that brings us to a holy grail that I previously thought was unattainable: Code that is actually easier to read than it is to write. That it’s not hard to write either is just icing on the cake. You just create a macro that drops an empty grid into the code, place your pieces, and away you go.

One of the most interesting things about this is that from a technical standpoint, this was a very easy thing to implement – Ron did the translation stuff and converted several test in only a few hours. The important breakthrough here, like when Google unveiled their map website, is NOT that it requires crazy voodoo programming, but that it requires a different way of applying what’s right in front of us.

February 23, 2008

A Note on My Bookshelf

Filed under: Craft of Dev,Written Word by Nathan @ 2:01 pm

It was awhile ago now, but the Rontologist put up an entry about his top shelf and was hoping to probe the deep Freudian secrets that lie beneath our own top shelf decisions. Mine are based on the fact that my top shelf is shorter than the second shelf, so certain choices are essentially forced. I don’t want to know what kind of complex that may represent. There are currently six full bookshelves in my house. Three of those are in my office. I will choose the one behind me because it gets the most consistent use.

From left to right, without further ado…

A Brief History of Time by Stephen Hawking
The quintessential book of cosmology for people who can’t pass Astronomy 100, I read this book several years ago and have been browsing it off and on ever since. Hawkings’ attempt to explain these concepts without equations is laudable but I still forget everything I read within days of closing the book.

Into Thin Air by John Krakauer
A harrowing account of a disaster on Everest. Some people have called the author for what they deem questionable behavior, but the book is hard to put down. I’ve read it at least three times.

Kitchen Confidential by Anthony Bourdain
This is the best book about life in the kitchen yet written. Sure it explains some things you might wish you didn’t know — the admonishment against ordering fish on a Thursday and why ordering mussels at a restaurant where they are on special is a game of Russian Roulette are sobering — but it’s a thoroughly entertaining read. A word of caution for the sensitive: Bourdain uses language that will make you think “Hmmm, maybe sailors curse like Anthony Bourdain.” I’ve read it four or five times.

Planet Simpson by Chris Turner
A Christmas present. The author attempts to tie the Simpsons into various cultural touchstones and philosophies. Moderately intriguing, I found it too pretentious to keep going before I got halfway through.

The Nasty Bits by Anthony Bourdain
Bits of variety meat and offal from everyone’s favorite explicitly opinionated food writer. It’s no Kitchen Confidential or Cook’s Tour but still a good read for fans.

Masters of Doom by David Kushner
Finally the true story of id software (or at least as true as we’re likely to get.) I’m a confessed John Carmack groupie who has read every interview and watched every keynote available, so this is a well worn book. It’s a very personal look into the rise (and plateau) of id that discusses everything in a way that makes you wish you were there. I’ve read this one six times, and after writing this I’m thinking read seven isn’t too far away.

Fork it Over by Alan Richman
In case you don’t know who Alan Richman is (and, based on my readership, I’m going to guess that’s all of you), he has been the food writer for GQ for years — I’ve been reading him since at least the early nineties. This collects several of his articles and every one reveals why Richman has won so many “best food writing” awards. Alan is the Roger Ebert of food critics – while he does love him some fois gras, he can be just as rapturous about a good hot dog. He sees things for how they are, not how he wishes they would be. I’ve read the whole book four times and certain articles seven or eight times. It’s that good.

To Die For by Stephen Downes
A list of 100 things you should eat before you die. Pretty disappointing.

Slack by Tom Demarco
Allegedly a novel about burnout. I’ve been too tired to read it.

Hackers by Stephen Levy
I only bought this book because I read that it was one of John Carmack’s favorite books. Yeah, I’m a fanboy, but I admit it. It contains several stories about great hackers through the years, from the MIT model railroad club to those whacky Steves who founded Apple to Sierra On-Line and their (in)famous hot tub parties. A great read.

Microserfs by Douglas Coupland
I originally read this book during one sitting in the university library, and actually thought it was autobiographical. Instead, it’s a fictional (but very accurate according to Joel Spolsky, who worked there) account of several Microsoft employees experiencing various ups and downs. I’ve read it a couple times since. It’s a lot of fun and every time I read it after another couple of years in the trenches I see more of my coworkers in its pages.

FIT for Developing Software by Rick Mugridge and Ward Cunningham
There was a project. We wanted to use FIT. I bought this book. Like most books in this milieu it’s a fine intro that was out of date by the time it was printed and doesn’t go into any of the really advanced (read: cool) stuff.

Agile Retrospectives by Esther Derby, Diana Larsen, and Ken Schwaber
I like the idea of what retrospective should be. I hate retrospectives in practice. Why? Because I have yet to work somewhere where the recommendations that the team compiles actually become policy. Generally when retrospective action items are invoked the reply is “there’s no time.” I guess we’ll add it again in the next retrospective. And the one after that. And the one after that. I did enjoy this book, but like books about “good meetings” you need an entire organization on board to make a difference.

User Interface Design by Joel Spolsky
I have yet to meet a developer whom I thought was an outstanding UI developer, and that includes yours truly. This book provides enough ammunition for your average non-designer to develop a UI that is at least functional. While a number of Spolsky’s own prejudices color the recommendations it’s still a valuable resource. Based on what developers usually create one could do substantially worse.

The Perfectionist by Rudolph Chelminski
The tragic tale of Bernard Loiseau, a three star chef from France. How elite are the three star restaurants? At the time this book was written, of all the thousands of restaurants in France, a scant nineteen had three stars. Loiseau killed himself at the mere rumor he would be demoted to two stars. A tragic tale of what can happen when you let your work define who you are.

The Secrets of Consulting by Weinberg
You don’t wanna know. Ha ha.

Peopleware by Tom Demarco and Timothy Lister
I hate this book. You heard that right. I hate this book. Because it speaks to a happy fun land where our opinions and skills are valued, we are given free reign to use them, and we are respected rather than tolerated. I wish that every manager I’ve ever had actually put this book into action. I’d say I wish they would read it but most of them have. They just decide that it’s too hard and go back to the same micromanaging carrot-stick management style that drives everyone crazy.

Journey to the Centre of the Earth by Jules Verne
I haven’t read this, but it fit in the tiny space left on the shelf.

Business Grammar, Style, and Usage
The Elements of Business Writing by Blake and Bly
Oh baby, I desperately wish most developer and managers would read these books. I’ll give one quick hint for free: count the number of commas you have and take out half of them. I don’t know why but most developers love commas like nerds like a girl in a Princess Leia slave girl costume. Unfortunately that is just the beginning. I would say that nineteen out of twenty documents that are described as “really good for technical documentation” are dross. I don’t know why folks strive for quality in other aspects of their work but settle for bad writing. It’s not that hard.

Snow Crash by Neal Stephenson
My secret life as a fanboy strikes again. I bought this book because I heard John Carmack liked it. I can’t say I was blown away, but it was okay. A neat story that I’d recommend to fans of science fiction, but that is unlikely to draw people to the genre.

Getting Things Done by David Allen
Maybe I’d get more things done if I actually read this.

Candy Freak by Steve Almond
A book about all kinds of candy. It’s well written and meticulously researched, but surprisingly dull. Word Freak is more fun.

Runaways Volume 7 by Brian K. Vaughn
One of the best comics from one of the best writers. While this isn’t the strongest arc, they’re all good reads. A gang of kids finds out that their parents are evil masterminds. It goes without saying that hilarity ensues.

Pragmatic Version Control Using Subersion by Mike Mason
A pragmatic book about a pragmatic concept using a pragmatic tool. ‘nuff said.

Professional ASP.NET by a bunch of folks
I really don’t know why I have this book. If anyone wants it, drop me a line.

And there you have it. I’m not sure what secrets of my psyche are revealed herein, but remember that sometimes a cigar is just a cigar.

December 30, 2007

Good Articles Don’t Need Social Bookmarking Links

Filed under: Craft of Dev by Nathan @ 12:13 pm

What makes a site like Digg worth the visit is that people find interesting things on the web that they feel the need to share, and thus share it. But I see a proliferation of blogs and other sites that provide easy “Bookmark Me” links on every vapid link blog post they put up. Here’s one of the more heinously egregious offenders ‘ve found:

screen.jpg

I only know a few of those by their logos, and won’t bother mousing over to figure out the rest. Here are a couple of universal laws, folks:

If you end an anecdote with “it was so funny”, it wasn’t.
If you feel the need to add a “digg me” link, they won’t.

January 24, 2007

Jobs on Java – it’s dead.

Filed under: Craft of Dev by Nathan @ 7:30 pm

As a developer who genuinely likes Java, this is just ignorant (see more info here)…

Markoff: “And what are you thinking about Flash and Java?”
Jobs: “Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

With all the Java developers using Macs these days, this feels like a slap in the face. The iPhone runs OSX – what are apps going to be written in? Ruby? Objective C? Is there some magical deal with Microsoft to bring .NET to the iPhone? There’s always Javascript…

Besides, talk to Amazon, eBay, Google, or the thousands of developers writing Java code right now — rumors of its demise are greatly exaggerated.

January 19, 2007

The Story of XMLHTTP

Filed under: Craft of Dev by Nathan @ 12:21 pm

If you’ve been developing dynamic web applications for any length of time (especially pre-buzz when there wasn’t a googol of Javascript frameworks trumpeting AJAX enabled for all the world to hear), you’ve run into XMLHTTP. Alex Hopman, the author, has posted the story of XMLHTTP and if you like to read about what goes into the technologies we use, it’s a must-see.

January 1, 2007

Is Agile Estimation an Oxymoron?

Filed under: Craft of Dev by Nathan @ 1:12 pm

Browsing Jeff Patton’s blog, I read this entry about story estimation that illustrates some points that we’ve all instinctively felt but not had the words (or the courage, more on that in another entry) in which to frame those instincts. As developers, we are always forced to give estimates for the work that we’re going to complete in any given timeframe, and we’re almost always wrong. Occasionally, there is the perfect storm where:

  • The customer and developer both have a clear idea of what is needed
  • The problem is small and well understood
  • We are conversant with the domain
  • We know the implementation technology like the back of our hand

And in these cases our experience allows us to build meaningful estimates.

Far more often, however, we’re in the middle of a windless sea, and in the absence of landmarks we wet our thumbs and throw out a SWAG[1] estimate so that the PM has something (anything!) to enter into his Gantt chart. And that’s where we run into trouble. Jeff’s advice (and a new favorite quote) is to

Treat estimates given at the outset of a project as a budget for some possible solutions, not as a bid for one specific solution.

When we’re writing stories, measuring velocity, and planning our iterations, we feel confident in calling ourselves agile…but those stories stop being launching pads for clarification and start being bullet points in a distributed requirements specification document. Why are we so afraid to be honest about what we can reasonably take on, and why is there always some point at which we stop embracing change? Is the mere idea of Agile Estimation an oxymoron?

I believe passionately in the theoretical underpinnings of Agile, but I’ve yet to see it play out in practice. I’m willing to offer the fallibility of mine and my team’s in bringing these theories to life, but I don’t see this as a problem easily solved with a bit of coaching. How deep and how wide can we manage customer expectations? How long do we overschedule iterations while saying “trust me” before it’s all gone Pete Tong and we’ve failed? How many under-implemented projects will be burned at the stake in the name of projected velocity being written in stone and married to hopeful estimates too early in the budgeting cycle. Where is the Herculean PM that can manage not only the client expectations but his own to see this through?

Or is Agile another idea that’s great on paper but cannot be both pure and effective when it hits the real world? I would love to be proven wrong.

[1] Shitty Wild-Ass Guess

November 14, 2006

Estimating is Bunk

Filed under: Craft of Dev by Nathan @ 10:38 pm

But I thought you beat the inevitability of death to death just a little bit – The Tragically Hip

I started a fairly recent talk on estimation poker with the following line:

Objective Software Estimation is Impossible

A slide emblazoned with a provocative statement, but not one without merit. As the shock wore off and the crowd grew restless I reached into the gaping maw of palpable disagreement for some input. Turns out I’m crazy – these Project Managers and Business Analysts had successfully shepherded several projects where the estimates turned out to be bang on. Even with big up front design. Seemingly debunked, I cast a line for what these projects had in common. A few of the answers:

“We had an excellent team with a lot of domain knowledge.”
“We had an excellent team with experience writing this type of application.”
“We had an excellent team and it was an expansion to an existing system.”

Touché. Or…not so fast. I’ll give you a moment to ponder the common thread woven through these finely honed ripostes. (No points for saying that good software depends on an excellent team – that’s obvious.)

Time’s up.

Did you get it? Each one of these statements is inherently and intensely subjective. I would be surprised if a team with a lot of domain knowledge building an extension to a system they originally implemented couldn’t estimate to within a single unit of work. But what happens when your crack Java Web Ecommerce SWAT team has to implement a .NET Accounting Application for Windows?

To predict the behavior of ordinary people in advance, you only have to assume that they will always try to escape a disagreeable situation with the smallest possible expenditure of intelligence. – Friedrich Nietzsche

The sad reality for too many of my developer brethren is that someone in a far flung Ivory Tower™[1] will create a giant specification, then giddily double click a Microsoft Project desktop shortcut to assign tasks and times. When the schedule slides (likely the next day, if not that day), some poor peon will get the near full-time task of updating the precious Gantt chart on a daily basis. By the power of Xenu, I wish this was a joke. In time the updates can’t outrun the inevitable domino cascade and Bad Things Happen. The autopsy will likely find the cause of death to be “insufficient analysis.”

I hear you, I hear you…”So Mr. Big Man, what’s your solution?” Since I’m not in the energizing, moisturizing, tantalizing, romanticizing, surprising, her-prizing, revitalizing tonic biz, the truth is I don’t have one. I don’t think that’s a failure, but a realization – I’m not the lone ranger, and the estimation problem may be a bugbear, but it’s not a werewolf. We need to base zero (or low) information initial estimates on the following, written in stone facts:

  • We cannot think of everything before we start.
  • You don’t know what you want until you see it.
  • User satisfaction comes from handling change, not mitigating risk.

Hell, there are no rules here– we’re trying to accomplish something. – Thomas A. Edison

This doesn’t suggest that our Big-Up-Front-Design needs to become Gargantuan-Up-Front-Design, but that we should take an iterative approach.

I refuse to believe that the resemblance between Gantt charts and waterfalls is purely coincidental.

[1] Why do we call these places “ivory” towers when they are employed in the practice of such dark arts?

September 18, 2006

The State of Enterprise Ruby

Filed under: Craft of Dev,Ruby by Nathan @ 8:48 pm

I have been to the mountain! Having spent three days in the cloister, intensely meditating the Zen at the core of the Enterprise Ruby scene, I have clearer insight into the current state of affairs. Using the simplest terms, in the most convenient definitions, here are the enterprise concerns we attempted to allay…

Scalability

When contemplating the appropriate context for scalability, let me remind you that the word “big” is both too subjective and too narrow. Think arbitrarily sizable without significant development overhead. Ruby is good at this. So is Java. So is Perl. So is any system with the appropriate architecture. I worked on a system with tens of thousands of users (several hundred simultaneous) that required no client server stickiness whatsoever – merely a round-robin load-balanced cluster of JBoss dragoons. If the load got heavy, we’d just add more heat, and the system would chew through simultaneous connection like Sauron’s hammer. Ignoring all other aspects of this system, Ruby could certainly have handled that same load. ‘nuff said.

Flexibility

Ruby is a smorgasbord of tools that increase your flexibility: dynamic typing, blocks, closures, mixins, and that’s just the list of things that are easy to understand. You simply cannot beat Ruby for flexibility, and the maxim “Thou shalt trade CPU cycles for developer cycles” makes its most sense in this area. Not quite a year ago, during dinner with Dave Thomas, he mentioned that people were doing enterprise development with Ruby, using it as glue between big iron systems. This I get. You want a quick cron to check a property in LDAP and then use a Web Service to drop a message into a queue? Save yourself some hell and use Ruby. Have a lot of legacy code in another scripting language (like, say, Perl…not that I have any experience with that or anything) and you need to start talking to MOM components, the only thing sillier than not using Ruby would be to put nipples on the Batman suit. And you know that worked out.

Reliability

Here, we’re thinking enterprise reliability (like, 1 + 1 always equals 2, and if it doesn’t, your software is the last thing you’ll care about), not script reliability (like “M. Night Shyamalan will always make good movies, and if he makes the Village, well let’s just not bother with Lady in the Water.”) A good example is Rinda. You can share distributed tuplespaces until the cows come home[1], or until the machine crashes, whichever comes first. I for one don’t want to restrict the lifetime of my messaging infrastructure to the MTBF of that Dell server my client bought because it was “cost effective.” You want guaranteed delivery? You want durable messaging? Then consult your friendly neighborhood JMS implementation (there are some good open source MQ systems) and let Ruby talk to it.

If your server infrastructure is running Ruby, be aware of the performance (or lack thereof.) It doesn’t have native threads and isn’t compiled. I know, I know, 37 signals is running a gazillion hits through Rails, but if you’re doing heavy back end processing (say, image processing or time critical data analysis for reporting) you’ll want to trust something a little more specialized, compiled, and up to the task. However, keep in mind the words of Dave Thomas:

I wouldn’t do stuff that required high performance in Ruby, but I wouldn’t do it in Java either.

There was another reliability hit: it was harder to get some piece of the puzzle working than getting Paris Hilton and Nicole Richie speaking again. LDAP took a Conan-at-the-wheel-of-pain level of effort to get running under Windows (and we gave up on the pipe dream of actually building it and just Googled some pre-built dlls), and we never did get the JRuby web server to work.

Finally, damning as all the rest, there are no distributed transactions. You need to make sure you grab something from the queue, write to the database, and drop a new message in a single transaction? Ruby won’t do that. So while this stuff is coming along for internal tools and admin scripting, you can’t trust mission critical back ends to Ruby.

IMPORTANT NOTE:

One thing I have to make crystal clear is that I am writing this for people who are wondering about Ruby’s suitability as an enterprise platform. This is NOT a rebuttal to the Ruby community, because they are so damn pragmatic, they wouldn’t endorse Ruby as a back end platform. I cannot stress this enough: Stuart and Justin never sold Ruby as anything other than a very convenient tool. Nobody is saying it’s a replacement for Java, just a good companion. Justin has a very good blog post about this exact subject.

Security

There was not much said about security, because Ruby doesn’t have a lot of support that you don’t code yourself. Concepts from the .NET and Java worlds like Declarative Role Based security or Authenticated Principle objects just don’t exist. I’m not saying that those languages have the problem licked, but I am saying that they make it easier to track authenticated users (at a thread level in the case of .NET). That’s a big deal when we’re having the debate about how best to spend developer cycles.

Internationalization

Ruby ostensibly supports Unicode, but most of its libraries do not. And unlike Java and .NET, there is no support for locales (cultures, for the .NET folk) and bundled resources. Of course, in Java and .NET, most developers don’t pay any attention to character encoding and end up painting themselves into the exact same corners. But as someone who was attempting to run a dynamically multilingual website, this is a tough pill to swallow. Oh, and I have to say this: extended ASCII is NOT internationalization.

In Closing…

So there it is. I know I’ve painted a grim picture, but that is only because I was earnestly hoping that Ruby was more mature. I am a staunch support of Ruby and genuinely love programming in the language. I’m buoyed by the progress made so far, especially compared to other scripting languages. And one can’t help but be optimistic that the rich communities of great minds doing significant work in Ruby will eventually elevate it to a higher plane.

The real takeaway is that if you truly believe in using the best tool for the job, then you will be using Ruby at some point in the future.

[1] As a resident of Calgary, dear reader, there are two things I can promise: The postman always rings twice, and the cows always come home

September 12, 2006

Enterprise Ruby Pragmatic Studio, Day 2

Filed under: Ruby by Nathan @ 9:45 pm

(Go check out Day 1)

I know what you’re thinking – why wasn’t the day 2 report up on day 2 (for those of you reading this in the future, I used my 1337 h4X0r sK1LLz to make this post appear to have been posted on the 12th, but that wasn’t the case.) Well, it turns out that even though I thought 2 hours was no big deal in the vast sea of jet lag, I was wrong in ways that only a 32-year-old with a severe case of temporal hubris can be. After typing out the Day 1 missive, I proceeded to not sleep. So after day 2, I didn’t do much else. ’nuff said.

Day 2 expanded on Rinda, our end of Day 1 topic. We explored the world of the Rinda ring server, which let’s you forage into the ether looking for tuple sockets to which you may attach (while that sounds vaguely lewd, I assure you that there is no fetish of which I am aware that could make Rinda erotic.) I’ll avoid the obvious Tolkien and less obvious Niven puns here – goodness knows we didn’t at the studio. Far from making you all powerful (and invisible, like Jessica Alba) these rings function like nameservers, letting you find shared tuple spaces by name. I am so attracted to this in theory, but I just can’t think of a practical use (where I wouldn’t desire a more robust technology, that is.)

Next we played in the wonderful world of HTTP. We wrote a web server in a few lines of code (which blew my mind when I first saw it done in Perl several years ago, but appears to have become de rigeur if you want anyone to take your scripting language seriously) using WEBrick. There were a few jabs at Tomcat, but to suggest[1] that WEBrick has even a small fraction of the utility of Tomcat is beyond even the most devout Rubyist (I wouldn’t put it past Perl Hackers, tho’) Then we played with HTTP::Client, which let us talk over the web using Ruby. More of an “of course” than a “ooooh, sweet!”

LDAP. The technology we all love to hate. Well, I don’t hate the technology, I just hate the specification. cn? dn? oid? OY! The good: there are some really cool tools for helping you work with LDAP, along the same lines as our old friend ActiveRecord from the rails world. The bad: You need a rather specifically designed schema for it to work, along the same lines as our old friend ActiveRecord from the rails world. The ugly: If you have a legacy system, you probably do not have the right schema, along the same lines as our old friend ActiveRecord from the rails world. Getting this lab to run under windows was quite a pain, which is disturbing – if Ruby wants to be a serious contender to Java, its tools gotta work somewhere other than *nix.

SOA. Love or hate the buzzword, we’ve all gotta deal with services. And I’ll bet you a tidy sum that at least some of those services will be on the web. And in a world that created the specification for LDAP, I’m shocked to learn that these services running over the web are called web services. Support for producing and consuming web services between Ruby clients is dead simple, very clean, and it just works. In a world of ever mutating WS-* standards and the wonderful world of SOAP, Stuart and Justin admitted that there would be a lot of manual work involved to keep up. The bright side is that it will only be a couple lines of code. That said, Ruby does the things it’s supposed to, like auto generate your WSDL and make it incredibly easy to play with the headers. If you have some scripts that need to make use of web services, this would definitely be quicker with SOAP4r than equivalent apis in Java or .NET, but I wouldn’t do a back end or mission critical pipeline service with it yet (and that’s not even worrying about transactions, but that’s for later)

And that was Day 2. One of these things I love about these conferences is getting to talk to other developers (and developers “in the know” – the average calibre of people doing Ruby, finding out about this conference, and getting out to Boston is pretty high). In addition to Stuart and Justin, Mike Clark is here and I had lunch with him today. Good talks about Rails and hearing what other people out there are doing with Ruby in general.

[1] At this moment, the power went out. Thank goodness for laptops and their battery power. Boston (well, the wee part of Boston where I am) is dark.

September 11, 2006

Enterprise Ruby Pragmatic Studio, Day 1

Filed under: Ruby by Nathan @ 9:46 pm

In a crusade to sniff some of the glue that never sets, I’ve come to Boston for the latest Pragmatic Studio, the one playfully and provocatively named Enterprise Ruby. As I’ve mentioned in the past, there’s meaningful enterprise[1] application development, and then there’s vendor bullshit. Our hosts, Justin Gehtland and Stuart Halloway, are poised to take us on a three day roller coaster ride that (for the love of $DEITY) does not involve Rails.

I got to the room where the studio is being held, plugged in my stuff, and realized I am the lone Dell in a sea of Apples and “PC Laptops that are not Dells“. People instinctively moved away, scared that it might explode at any second. The class got off to the traditional inquiry for a count of hands from folks currently being paid to sling Ruby. I’m fairly certain at least a few folks were plotting the death of the one man who almost apologetically held up his hand.

I decided to partake of the “continental” breakfast. Apparently “continental” is short for “quaffable but unremarkable coffee, cantaloupe, and an array of pastries.” You shouldn’t be allowed to use the c-word to describe your breakfast if there are no croissants. How can I save up enough buttery French heart attack bombs to build a Chinese Throwing Croissant if I can’t even find one?

The session started out usefully, but slowly, introducing us all to the Tiddly Wiki. To be fair, it’s an extremely cool little product – an entire wiki in a single page (a single page with a crazy amount of javascript). That’s where all of the course material is held. I will be using it in the future, it’s that cool.

Next we went onto rake, which was depressing. Depressing like a fox. You know all those times you’ve gotten mad at make, nmake, ant, nant, or because they were missing just one little thing? Well, you can’t get mad at rake, because it’s not text or xml or happy-fun-dsl, but ruby. I remember having to sign a whole boatload (well, it would’ve been a small boatload, but about 14 wouldn’t have made much of an impact, no?) of jars for a java applet and thinking to myself Self, wouldn’t it be nice if we could write a loop here?

Rake was followed by some quality time with flexmock. It reminded me somewhat of Rhino Mocks for .NET (I can’t think of anything remotely similar in Java, but I’ve been away for a half year), but quintessentially Rubenesque. Er, I mean Rubyesque. Check this out:

1
2
mock = flexmock("foo")
mock.should_receive(:bar).and_return("baz").at_least.once

You don’t need to know anything about this to figure that out. That said, C# isn’t too far behind…

1
2
IFoo mock = mockRepository.CreateMock<ifoo>();
Expect.Call(mock.bar()).Return("baz").Repeat.Times(1, int.MaxValue);

Anyway…we put all this into a nice little directory so that we can use it as we go forth (goal is to unit test everything.)

Next was DRb – distributed Ruby. If you’re thinking about CORBA or RMI, you’re on the right path, except it’s Ruby, so it’s easy. Not entirely sure where I’d use this in the real world, but it’s there in the core of Ruby. It’s got some sophisticated methods for creating observers and callbacks, and there are ways to synchronize several machines to do a task, so who knows. During the lab, Justin made the comment We just had an entire room of people, some of who don’t even know Ruby, write a client-server in 10 minutes. Okay, this was pretty cool.

The day ended with an introduction to Rinda. To put this simply, it allows for a distributed Ruby system to share a collection of Tuples. To put it anything other than simply would make your head explode. Well, my head at least. I’m familiar with distribution, and I’m familiar with Tuples, but this was a very interesing look at things. Rinda is based on Linda, a coordination language. Once again, I’m not sure of the immediate implications, but in terms of a toolbox, Ruby seems to have a lot more going on than meets the eye.

I’m still annoyed that Ruby doesn’t have native threads (but they’re coming…), but both DRb and Rinda come with the core Ruby distribution, so there are some impressive tools coming out. All in all, it was a fun day and I’m looking forward to tomorrow.

[1] That’s right, enterprise doesn’t need to be capitalized when Captain Kirk isn’t in the picture.

September 5, 2006

Unusable at any Speed

Filed under: Craft of Dev,Industry by Nathan @ 8:56 pm

Just a little while after I praised eBay for their outstanding search UI, I get the following message:

bad error message

Here I thought I was adding a message to my auction that would be sent as email. However, apparently some unfrozen caveman user hater at eBay would rather I spend a few unprofitable seconds as amateur copy editor, constricting myself to some strange circle of hell in which the content I am allowed to place onto the internet and into an email cannot contain text that is valid on the internet and in email. They did throw a nice cherry of insult on top of this delicious sundae of injury by placing the following friendly text in the edit window:

Note: The user you are contacting is registered on another eBay site and may speak a different language. Your message will be sent exactly as typed below.

Evidently, there is some dimension in which the grammatical laws of our everyday world do not apply, and exactly has some alternate meaning of which I am unaware. There are no excuses for not allowing HTML, quotes, or asterisks. Oh wait, there are a thousand and one exuses…starting with, oh, I don’t know…lazy developers who hate their users and think that telling me I need to strip HTML, quotes, and asterisks in an error message AFTER I’VE HIT SEND constitutes due dilligence in the interaction design department. So I’ll amend that to say there are no defensible excuses for not allowing HTML, quotes, or asterisks.

Remember, our applications are not there to be admired for how well they are implemented, but to get the f**k out of the way so users can DO SOMETHING INTERESTING! So the next time you’re developing a web form, don’t make the users think about how to enter their phone number or credit card information, make it obvious.

If you’re not part of the solution, you’re part of the problem. If your app isn’t helping your users kick ass, then chances are that they’ll want to kick yours.

August 16, 2006

Usability in Real Life

Filed under: Craft of Dev,Industry by Nathan @ 8:10 pm

It may bruise our raging developer egos, but here’s the thing: users don’t care how smart we are. They don’t care how sweet our technology is, and they don’t care how intuitive our application is. They do care about what they can accomplish.

Amazon does not have the coolest web store interface out there (not even close.) But I know that I can go from thinking hmmm, I want a copy of Agile Retrospectives to having it ordered in under two minutes. So I don’t go anywhere else.

Another site I spend a lot of time on (I’m an online shopping junkie – where’s the support group?) is eBay, and when an innocent search turned up no results, I was pleasantly surprised by the ensuing screen, which I present here:

What tickled me pink (manly pink, of course)? Well…

    • The results of the search are highlighted
      Rather than a generic try other search terms, it illustrates (with a nice strikethrough effect) permutations of my search terms
      It lets me access any of these alternative searches with a single click
      It asks me if I want an email when there are results for my search
  • No ads. No push your browser’s back button and try again. No maybe you want this instead. I was trying to find something, and eBay is doing its darnedest to help me find it. The result? Stickiness. Ergo today’s moral:

    Users want to get things done. The software that gets out of the way and helps them get it done wins.

    June 27, 2006

    Static Typing Sucks, a Prologue?

    Filed under: Craft of Dev by Nathan @ 8:58 pm

    Static types give me the same feeling of safety as the announcement that my seat cushion can be used as a floatation device.
    — Don Roberts

    To antonymously crib Roger Ebert, I love, love, love this quote.

    I don’t know about you guys, but I honestly can’t remember the last time I had a ClassCastException (or an InvalidCastException, for that matter) that wasn’t a glaring bug. When will these people learn? Looks like C# is starting to get it in 3.0, but I don’t imagine Java will catch on anytime soon.

    Yeah, Ruby has no static typing. But don’t let that scare you, let it free you. Because when you’re free-flying with Ruby, you don’t need any safety net.

    April 20, 2006

    SOA – Who cares?

    Filed under: Craft of Dev,Industry by Nathan @ 9:14 pm

    …’SOA’ might have meant something once but now it’s just vendor bullshit.

    So relates Tim Bray in a recent blog post, and I say “hear, hear!” Whether an open SOAP layer over a JMS queue or a RESTful HTTP GET from one Perl CGI script to another, anyone that’s been in the trenches for a few years has done SOA.

    Yet, the architecture astronauts have struck again, claiming that every system and process can be reduced to a series of “services.” But this abstraction is so high (and leaky) that businesses are lead to believe that unless they spend thousands of dollars on middleware and employ a team of EAI surgeons, they are doomed. I admit that these solutions can be appropriate, but I also smell charlatans with hammers seeing a lot of nails. Eventually ESBs and MOM will go the way of the RDBMS, making the transition from proprietary goldmine for experts to commodity for the masses. Even now there are open source alternatives (like Mule) emerging.

    So what’s the point? We, as an industry, need to stop pushing architectures to proselytize on behalf of vendors, and start producing solutions based on what our clients actually need. And when the next “paradigm shifting” tool arrives, we don’t hold it high as the new aegis under which we play upon FUD to fill industry coffers.

    Rather, we relegate the gewgaw to the toolbox — where it belongs.

    April 19, 2006

    Expertise is Overrated, or Why I Hate Design Patterns

    Filed under: Craft of Dev by Nathan @ 3:00 pm

    I know, let’s build a Facade using a Strategy that takes a Command to build its Memento and we can modify it using a Builder! Oh, and I think it should be a Singleton.
    – famous last words, number 629 in a series

    A few weeks ago, a colleague mentioned in passing that he had spoken with a more junior developer who was attempting to bridge the gap between procedural and object oriented programming starting with Design Patterns. Talk about shifting paradigms without a clutch!

    According to the Dreyfus model of skill acquisition, experts come to rely on intuition and experience whereas novices depend on explicit instructions and detailed rules. Yet many a sage ur-guru has suggested the path to object oriented enlightenment crosses through the valley of the Gang of Four. I call this the expert’s folly.

    Design Patterns are descriptive, not prescriptive. While the wizards may describe their caching policy as a “Decorated Proxy” using a convenient shared vocabulary, novices barking their shins in the dark create Singletons and States without any regard for data encapsulation, domain modularity, or coherent behaviour. It’s the Golden rule turned lead. Experts feed advice they would like when following the Platinum Rule would yield smoother sailing.

    It is often said that those who can, do; those who cannot, teach. But that glorifies the wrong side of the scale. It’s easy to perform based on your intuition, but very difficult to teach based on your understanding. I think this ancient aphorism needs an update:

    Those who cannot teach, merely do.

    Powered by WordPress