weblog.masukomi.org - Home

YOU NEED TO UPDATE THIS FEED URL

2008-03-09T00:00:00Z

I changed blog engines. Sorry, but it happens every couple years around here. Go here and grab the url for the feed type you prefer. And while I've got you here... thanks for reading, and thanks to those of you who have taken the time to leave comments. :)

The most useful Monkeypatch ever

2008-03-08T21:50:00Z

In Java we all dread the dreaded NullPointerException of dread.

In Ruby nil is a class and we can do something about it.

Monkeypatching core classes is of course a Bad Thing(tm) but this particular one should* break nothing since we're adding a self contained method to a class that doesn't alter the functioning of any of the other methods on the class. Furthermore we're adding something that simply makes sense, so when you call it sensible things happen. Now, as with most innovative thoughts, it isn't. According to _why it's been brought up by far more knowledgeable Ruby geeks than I: Jim Mernard, Dave Thomas, and Dan Fitzpatrick have all argued for this. Others have argued against. The others all work for The Man and are just trying to put you down.

Behold, the glory of nil.empty?

class NillClass
  def empty?
    return true
  end
end

Oooh ahh... Bow before its glory! Bow I say!

Do you not see? NilClass is the void. It is nothingness incarnate. You may debate if it is really false, since how can nothing be true or false, but it is most assuredly empty, for how could nothingness ever contain something? Now you never need to @#$% check if a thing exists or not before checking if it's empty.

More lately people including _why have been arguing for nil.blank? This is, of course, craziness. While I encourage such insanity in _why (it's what makes him great) it is impossible. Nothing can not be blank, for it has no form, no surface, and only things can be blank. Nothing is neither blank, nor non-blank.** Rails has, of course, incorporated nil.blank? because they'd monkeypatch their grandmothers if they could figure out how. Personally, while I love this particular monkeypatch I don't think any core classes should ever be monkeyatched in a distributed library or app, but YOUR app, that other apps don't use as a foundation.... monkeypatch whatever-the-hell you want, just be sure to document it well.

*I say "should break nothing" but there is, of course, being stupid and using the unexpected, and slow, thrown exception to change the flow instead of checking for nil.

** Yes, the antonym for blank is "full", but if you ask me, that makes no sense.

P.S. It's a really good thing that Java isn't monkeypatchable because if it was java.util.Calendar would be monkepatched a new and incompatible way in every single library out there because we all hate its @#$% guts. Use Joda Time instead.

Using Toonlet for quickie cartoon strips.

2008-03-08T17:11:00Z

I'd just like to take a moment to plug Toonlet.com. It's not perfect, but...

I've toyed with the idea of doing little comic strips (as you've seen lately) for... hell years now. But never wanted to deal with the work. It was Toonlet.com that finally got me off my ass to do it. Now, I'm not actually using Toonlet.com to generate them, but that's not the point. The point is that they make it easy and fun to put together your own strip with unique characters. You create a character by bringing up an "art pack" which is a collection of heads, bodies, arms, eyes, etc., and combining them to create characters that you save for later use. This is very cool and allows for a ton of possible combinations, but honestly, I just don't like the drawing style of their initial art packs. It's too high-school notebook looking. Fortunately, that's all about to change because they've just made it possible for anyone to add a new art pack. Everyone gets to use the various components in a pack that you upload, but that's ok, because it's unlikely that they'll use them in the same combinations that you will.

Playing around with Toonlet is what made me realize that it really didn't require that much effort to put together a strip. I'm doing it all from scratch with Inkscape but after doing so I have found that I get a little kick out of seeing my strip on a page. Enough that I'll spend the time to make whatever new poses, facial expressions, etc. for new strips. Of course, because I'm using Inkscape it means I'll have a library of things that I can recombine later to save time making new strips. Just like Toonlet (and ever other vector art comic strip you've ever seen).

There are a handful of things that suck about Toonlet, and unfortunately they're pretty big:

1) While you have great control over your characters, can save sets of them in various moods, and outfits, you've got absolutely zero control of placement and the size of the character is relative to the amount of text. This results in almost unrecognizably small characters when you have a lot of text in a panel.

2) You can only have one character in a panel. This means that two characters can never talk to each other in the same panel.

3) No preview mode.

4) While you can create a set of moods for a character if you ever want to ad a new mood to the set you can't just bring up and change an existing one of yours. You have to remember and recreate the exact combination of all the other elements that went into making that character and then hope you got it right because there's no delete character either.

5) It doesn't work in Safari. Creative types have been enamored with Apple for years. To not support the primary browser on the operating system that creative types tend to prefer is mind-boggling to me.

And now you see why I decided to do it from scratch.

I considered, very briefly, using Stripgenerator but they've got the opposite problems. You've got total control over what's in a panel, you can even use painfully crude collections of shapes to "draw" new things, but you can't save anything for re-use later. There's no way to create a new character that you could re-use without having to redraw it from scratch every time, and the users are insane. The people behind StripGenerator were/are considering adding the ability for people to draw (with a mouse / tablet) and a lot of users were actually arguing against adding it. Saying that it would destroy the look of things. Why would you ever want to force your strip to look like everyone else's or limit yourself to drawing by pasting and rotating 1/4 arcs and squares and such?

I think The guys over at Toonlet have their priorities straight. Make it as easy as possible to let people make comic strips then add features that will give users more choice and control. They're working on the issue of only one character per panel. Personally I think they should browse over to Stripgenerator and steal ideas from the strip creation UI. Right now it's SO easy to create a strip at Toonlet that people comment on other strips by making comment strips. It's amazing.

To give you an idea, here is a Toonletized version of this post's main points (Mac users should check out the note afterwards):

P.S. In case you're considering using Inkscape on the Mac, I'd recommend not. While it is rock-solid under Linux something about running X11 apps under OS X means it'll crash if you do things like accidentally click too fast or, well, it seems any rapid sequence of operations involving the mouse will kill it. I'm downloading a demo of LineForm now which looks very promising and is only $80. If it has good export capabilities I'll probably buy it because I prefer using OS X for anything that isn't code. VectorDesigner is probably the most affordable commercial Vector graphics software for the Mac but unfortunately it will only export bitmaps, so there's no way for you, or anyone else, to leverage any of your vector based creations in any other app. I refuse to use software that will lock me in and never let me change to something else as my needs change so this is a deal-breaker for me.

Importing an existing codebase into Git (a flowchart)

2008-03-08T11:27:00Z

A simple flow chart showing the steps you should take to add an existing codebase to Git. This assumes you don't have revision history that you wish to migrate from another version control system.

Some notes about the flow:

When adding file paths you can use wildcards like "git add /path/to/images/*.jpg"
This is one of the few times when you'd want to use "git rm --cached <file path>" to un-add a changes in the index. After the first commit the recommended way to un-add changes to the index (staging area) is to "git reset HEAD <file>".
Note that the only file that is edited during this process is .gitignore When you call "git add" you are adding the current content of a file to Git to the index. If you change a file after you add it Git won't commit the additional changes (unless you add them too). So, it's a good idea to run "git add .gitignore" just before you commit in order to make sure Git has the most recent version of it.
You'd only, obviously, "add" files you wanted. "git add ." (note the dot) tells Git to add everything in, and below, the current directory.

I really ought to be writing.

2008-03-08T02:40:00Z

Yes, I really have that hat. I knitted it. It's supposed a tea-cosy hat like Hermione knitted for the House Elves. Unsurprisingly, it looses something in the translation to black-and-white-cartoon.

Yes, more details will follow about the new co. as soon as the site is up, but yes, I will be publishing other people's work, and yes, I'll be focusing on books for geeks initially. What I can tell you about Very Useful Books is that I'm looking to publish a line of concise, but very useful books. Yeah, I know, that doesn't help you much. But hey, if you've got a good idea for a programming book that no-one else seems to have bothered to write. Get on it. If I don't publish it there are other companies that will probably jump at the opportunity.

A lot of people think you need to horde writing ideas lest some other writer steal them, but the truth is that there's no difficulty in thinking of something to write about. The difficulty is in actually writing it. Or, more accurately, the difficulty is in continuing to actually write it. I think if you ask any non-fiction author you'll find that after the first few chapters it's actually work. Enjoyable, fulfilling, and constructive work, but work none-the-less. The trick, as the NaNoWriMo folks know, is to just keep writing. Don't stop. You need to try and write something for your book every single night. Even if it's just a page. I advise eschewing any major editing until the end. Editing just slows you down and makes you feel like you're not getting anywhere.

The downside, I've found, to writing books about software is that you can't just stop and say "that's enough." At least, you can't if you've still left a third of the thing undocumented. You have to write about it all. Maybe not cover every single little detail but you can't just skip over a feature set because you're tired of writing about the subject. On the other hand, it means you have to explore all those corners of the app/language/library that you wouldn't have normally looked in, which means you become even more proficient in it by writing about it.

The Git book is actually making decent progress. I'm pretty much done with the section on managing files, and have a start on the section on managing local repos, but I've not taken my own advice and pretty much blew-off writing this week to play Project Gotham Racing 4. It's a really good game but I'd only recommend it if you have an HD screen. It was "meh" on my standard-def. After the upgrade, it rocked.

P.S. Yes, as soon as I post this, I'm going back to working on the book.

P.P.S. Is the comic a little too small? I can't decide. I think I'm pushing the lower size boundary, but anything bigger doesn't fit this site layout (which really needs to go).

Review of Edward Tufte's Presenting Data and Information course

2008-03-07T00:12:00Z

First, let me set the stage. I've been reading stumbling across interesting data information articles by Edward Tufte for years now, have been interested in getting his books for a while now, and was excited when my manager offered to send me to his one day course, and am quite grateful to have had the opportunity to go. So, I definitely went into this with good expectations.

30 Seconds summary:

The first two thirds were not bad. The second two thirds sucked. The type of people who would appreciate this course the most are ones akin to the woman in front of me who wore red velvet pants, a scarf that probably cost $60 and from the Museum of Fine arts, dangly earrings of semi-precious stones, and, were you to talk to her, would be sure to let you know that she's "an artist." She loved it. You, on the other hand, should buy his books and skip the course.

Details:

The first two hours were pretty informative, and essentially all of my notes that didn't involve expletives came from that portion of the talk. But, there were two quotes (taken completely out of context here) that pretty much summed up his course

"...I prefer text." and "Well this is all very interesting but..."

After the first intermission Edward made sure to let everyone know about his wonderful four hundred year old books by by Euclid and Gallileo which he held aloft, and flipped the pages of with his oily ungloved hands, thus guaranteeing they will not survive the next four hundred years as they have the last. He even made sure to carry it down a couple of aisles and show it to the people on the end, whilst frustrating and / or boring the other 95% of the audience.

After lunch he talked about visual interfaces which was comprised almost entirely of him telling you how cool his iPhone was. According to Mr. Tufte the only major thing that Apple got wrong with the iPhone was using icons on the main interface instead of text. Just imagine how many more items you could fit on that screen if it used text instead of icons! Oh the joy of having to read through text lists to find the fucking calendar app instead of just poking a fingertip sized picture of a calendar. Gallileo was so cool. Did you see this section of my book by Gallileo? To be fair he pointed out some valid ways they could improve the weather and stock apps.

Much time was spent making fun of PowerPoint, "bullet grunts", and "chartoonists". A grand total of zero minutes were spent discussing the pros or cons of any standard graphing technique: bar graphs, line graphs, area graphs, pie charts, scatter plots, etc.. Zero minutes were spent discussing what graphing techniques were best suited for what kinds of data (unless you count the 3 minutes spent on vertical scaling of graphs). Did you see the picture of Gallileo? There aren't many pictures of him but I have an etching of him in my 400 year old book right here.

In between jabs at PowerPoint he discussed his technique for speeding up time in meetings, which is to start out with a "massive data dump" (giving the participants stuff to read before you talk), and then to ask if there are any questions. He guarantees this will make your meetings at least 30% faster. I guarantee that if you ever try that with a potential customer you won't make the sale. He repeatedly used this technique on the audience by saying "now turn to page x in my book titled y" and waiting silently until everyone in the audience had read the whole page. Oh have you seen my book by Euclid?

He repeatedly advised people to clarify confusing data by adding more detail. While there are a handful of situations where this may actually be good advice it's incredibly bad advice to give to an audience without clarifying when, why, and how to do so, which, of course, he never did. I will note that I found at least one good example of this technique while flipping through his books. The iPhone is so cool, but AT&T's Edge network is the reason it isn't cooler.

Edward also seems to be laboring under the mistaken impression that people actually want to understand all of the details of all the data you're presenting to them. It is my experience, and many concur with me, that most people want to be shown the high-level "bullet grunts" of whatever data you have so that they can have a clue what the hell they're looking at. Only then do they actually want nitty-gritty details, and usually they want the details on just a subset of the information. Aren't Gallileo's etchings of these sun-spots wonderfully detailed?

Documentation. All(?) graphs need documentation. The names of everyone who contributed to them should be present in big bold letters just like Gallileo did in this really old book. He even put his picture in it. Isn't Gallileo cool? Also, descriptions: lots of descriptions, and annotations, and annotated descriptions, It's fine if it the text required to describe the graph requires the same, or more, space than the graph itself. One of the techniques that he mentioned multiple times for making data more approachable was using annotations, which is great if your data isn't going to change the next time the person looks at it (any stats on constantly changing things), but doesn't seem to grasp how incredibly difficult it is to write software that can intelligently find a point to annotate that is either interesting or indicates some causality, never-mind trying to write software that will generate useful text about it. As an example, check out the Google Trends for "git". Only one of the annotated points has any causal effect on the data that's being graphed (the one about Git software being released).

Resolution. He makes a really big deal about resolution. He applies it to media (screens, paper, etc.), as well as the resolution of information in a graph. He makes a lot of valid points about resolution, then talks about how some typographers designed their fonts at a resolution of two thousand grid lines per inch, and how his "Sparklines" have "two significant digits of resolution". But he utterly fails to grasp that there is a point at which adding resolution is useless. In print his Sparklines may very well be precise to within a hundredth of an inch, but no fucking reader can tell the difference. Imagine a typical ruler with precision down to a sixteenth of an inch. Now put ten times as many tick marks in each inch and you're roughly at one half the resolution of print on good paper. Even at half the resolution of print you're still going to have a really hard time telling the difference between 23/160ths of an inch and 21/160ths. But, after telling you how amazingly high the data resolution is in his Sparklines he proceeds to tell you it's not enough and that he's started work on displaying information in "High-def" Which bewilders the mind when you consider that you're very lucky if your "High Def" screen is one third of the resolution of paper. Have you seen the resolution in this etching of Gallileo's sun-spots? By giving the iPhone a higher resolution screen they more than doubled the amount of information they could fit on it relative to a normal phone! If only Gallileo had of had an iPhone...

Throughout the presentation I arrived at the following conclusions (potentially wrong) about Edward Tufte.

He has great distain for software developers.
He has no clue about the problems involved in displaying dynamic data.
He has no clue about how to run a presentation.
He has no clue why software works the way it does and berates it for not working the way he thinks it should.

BUT It didn't all suck. As I said there were a number of good points in the first two hours, and all attendees got a box with all four of his books in it. You will need these if you attend the course because a third of the time he's referring to pages in them like a typical college professor, and the other two thirds of the time you'll need them to entertain yourself while he tells you about his four hundred year old books and his iPhone. I've read a few articles that went into one of them and I've skimmed through the rest and I do think they're actually worth the cover price. He makes a lot of good points in the books and has a lot of good examples, although I don't think that all of his suggestions actually play out in the real world.

Notes from the course (in case anyone cares):

Focus on causality when presenting information.
Data visualizations should be content driven not method driven.
Strive to invoke content responses / questions in your users.
Data should tell a story
Provide a context for the data.
Annotations: choose a point, explain it, then tie tangentially related facts to that explanation (not sure I agree with that last part)
Try and make the "smallest effective difference" when trying to emphasize some point.
Order data by the most important aspect, not alphabetically.
Find a way to connect your data to your users on a personal level (for example when dealing with data on neighborhood fires plot it on a satellite image of the town so that your users can find their house and thus connect to it personally).
Try to eliminate legends. You don't want your users to have to look up details of your graph. It should all be integrated. For example if you've got a line graphing Bananna sales put "Bananna" on the line.
Keep related items adjacent in space.
It's easiest to see variations in a slope when it is roughly at a 45 degree angle.
Make comparisons.
Attempt to overcome recency bias.

Also, some paraphrased questions to ask when consuming presentations:

What's their story?
Can I believe them?
What is the "domain specification" of this presentation.
What do I want to see? Is that what I was shown?

Some questions to answer when presenting information:

What is the problem I'm addressing?
Who is it relevant to, and why?
What is the solution I am presenting?

Mr. Tufte, if you're reading this, I appreciate and respect the work you have done, but you need some serious lessons on how to give a course. I'd recommend spending some of the millions people have given you for these courses on some private lessons with Tony Robbins. Whether or not you agree with what he has to say it's hard to deny that that man knows how to convey lots of useful techniques to his audience in a way that is both memorable and entertaining.

P.S. Gallileo did, in fact, rock. However, if I wanted to see a historically significant book I'd go to the museum or the library (Boston happens to have a kick-ass library with regular, and free, exhibitions). The iPhone also rocks, and is a triumph of interface design, but if I wanted to see a video of someone using it I would go to Apple.com.

[Rant] @#$% Rails

2008-03-06T01:04:00Z

Rails:

I was all happy to get a chance to code something in Rails at work. Just a throw-away prototype, and then it came time to deploy it. God I hate you Rails. You're a freaking clit-tease. You're all "come on baby...don't you want to be productive? Think of how fast you and I can built your hot app..." The next morning, when it comes time to deploy, you hear laughter fading down the hallway from some 500lb lady with strangely oozing bits who looked much more attractive when you were drinking the good shit last night. You clean yourself vigorously, get the thing deployed after much frustration (and never well on a shared server), and then find out that it's runs slower than frozen dog shit if you don't give it injections of fast-cgi, mongrel, and any other uppers you have lying around.

After fighting with it for hours, giving up on Mongrel working (yes i've gotten it working many times before), and having to hack the Rails source to make it boot even Webrick, I realized that for a simplistic app I could have written it in just as much time in Smalltalk with Seaside, and had it deployed in about 5 minutes. Smalltalk I say! I'm not dissing Smalltalk, but it's not like the world is jumping up and down to make Smalltalk deployment easy. Rails on the other hand has thousands upon thousands of people trying to get it running, many for businesses, and each needs to go jiggery-poking it with pound, or Nginx, or mod_proxy, or fast-cgi, or anything they can fucking think of just to make it usable. Even then it's laughable the amount of hardware you have to throw at it for a site like Twitter.

So, yeah. Rails can bite my shiny white ass. I'm incredibly grateful that they revolutionized the web development landscape but their intolerance towards anything the core Rails devs. don't happen to need (legacy databases anyone?), the blinders they're wearing when it comes to scaleability, and the bullshit you have to go through to get it deployed result in me giving it the finger. I still don't think Java's a fun language but one thing you can say about it is that deploying Java webapps is freaking easy, hell, distributing them isn't even that hard. Even the ThoughtWorks guys decided it'd be much easier for their customers to deploy Mingle (a Rails app) under the JVM with JRuby, and that's just sad.

P.S. Who the fuck thought it would be a good idea to replace the really nice photos on the Mongrel web site with a drawing of a drowning dog ?! "Yes please! I wanna install the drowning dog software!" OMFG people!

P.P.S For those who keep not getting it: Rails != Ruby. Ruby rocks, even if it is slow.

P.P.P.S. Yes, I realize something was @#$% in my ruby+gems+whateverthefuck installation and that it's not specifically Rails fault, but it's a pain in the ass to deploy for production even when all the stars are aligned.

Xbox 360 Wireless Racing Wheel

2008-02-28T02:58:00Z

The Logitech DriveFX had to go. Piece of crap. I plunked down an extra $50 ($100 total) when I returned it to get the Microsoft Xbox 360 Wireless Racing Wheel. The difference is incredible.

The Good:

This product is very well designed, and very well put together. It feels sturdy and solid. The rumble is very strong. The force feedback is also very strong. The buttons aren't cheap. The pedals have an empty area that your heel goes in. At first it just looks like it's there to save plastic, or to look cool, but it actually serves a purpose. Because it goes behind your foot it's not possible for it to slide away from you because it would always catch on your heel. When you get slammed off in one direction you have to fight the wheel to turn back the other way.

The Mediocre:

The X,Y,A,B Buttons are reachable without difficulty, but they could be better. It's a hard problem to solve though because when you go into a hard turn you still need to be able to reach them.

The Bad:

It doesn't have equivalents for all the buttons. There's no analog sticks and no trigger buttons. They advertise that you can remap some of the functionality, and that's true, but the ability to remap is supported at the game level not in the OS.

The Burnout:

I got this because I freaking love Burnout Paradise. Unfortunately EA Games doesn't support any controllers on the 360 other than the default. Since there aren't any analog sticks you can't navigate the map, and some maneuvering (controlling rolls for example) is harder than it would otherwise be. It does make your driving much smoother, but on the other hand sometimes when you bounce off of something (another car, a side-rail, etc.) the force feedback will drive you hard to one side and you'll have to fight it to get it back to the other direction, then over-compensate, and reverse the process in decreasing sine-wave like pattern. Maybe this is realistic (I wouldn't know), but it is trickier.

In Conclusion:

If you like racing games this is a really great product. If you only want to use it on racing games made by EA Games you'll not be getting the full potential of it, but you may still find it worth it. I do.

P.S. If you set a new record on each of the roads you get the Carbon Ikusa GT which has 8 speed 7 boost and 5 strength along with the Speed King achievement. Unfortunately there's no achievement for holding the fastest time on all the roads simultaneously, which yours truly happens to have at the time of this writing.

[Update: revised The Burnout and In Conclusion based on further play and input from fellow gamers. It wasn't as limited as I'd initially thought.]

Logitech DriveFX == teh suck

2008-02-26T02:34:00Z

So, I really like Burnout Paradise. I love just driving around the city setting new speed records for others to try and beat. I enjoy it so much I decided to pony up the $100 to get the Microsoft Wireless Racing Wheel but when I got to GameStop there was another option: the Logitech DriveFX, and it was $50 cheaper. "What's the difference?" I asked. "The Logitech one isn't wireless."

I looked at the box and thought... "For $50 I don't care about wireless." And, Logitech tends to make good hardware. Then I got it home and found its fatal flaw. You can't hold it in your lap. It's got these two clamps that allow you to easily clamp it to a table. The only problem is that everyone I know only has a coffee table, about knee-high, in their living room. This means you'd have to lean over it like an adult crammed into a kids go-kart. Then there's the pedals. Where are you supposed to put the pedals? You can't sit on a couch, pull a coffee table close enough to use a steering wheel clamped to it, and then somehow put your legs out under it. You'd need to add a backwards knee half way down your shin.

The clamps don't come off, and stick out uncomfortably from the bottom. Even if i was willing to dismantle the thing to get them off it's not wide enough to really sit on your lap so you'd have to clamp it between your thighs which would get really uncomfortable really fast. If you try and set it on your legs, instead of between them, there's nothing in the design to hold it steady so it'll just keep shifting around.

It's going back tomorrow and I'm shelling out the extra $50 for the Microsoft one, which can optionally clamp to a table but is designed to sit on your lap. Thus putting the steering wheel where you need it and the pedals out at the end of your extended legs, just like oh, I dunno... a car maybe?

Zombies!!! Player Turn Flow chart

2008-02-22T03:25:00Z

I decided to make a flow chart to help new players in an upcoming attack of Zombies!!!. I think I may have gone a little overboard with the details, but it's done now. This represents standard rules plus the Zombies!!! 6 (Six Feet Under) expansion, but you can just skip the subway and sewer bits if you don't have that.

For those of you who aren't familiar with Zombies!!! there's a good review / overview of Zombies!!! here. The biggest complaint people have about it is that it can run long. A nice atypical aspect of this game is that you absolutely will / must screw over your opponents repeatedly as opposed to most games where people tend to get annoyed with you if you do that. I liked it enough to go buy 2 expansions (3.5 and 6) and a bag of extra zombies (you'll need 'em when you have lots of people or expansion sets with tiles). You probably have to enjoy poking fun at the shambling zombie movie genre to enjoy this game.

A PDF of the flow chart.
A PNG of the flow chart
The OmniGraffle file

Burnout Paradise Review(ish)

2008-02-10T07:55:00Z

Burnout Paradise (XBox 360) Review

I played until I got a crick in my neck and my ass hurt,

both from setting on the edge of my seat.

Then I stood up so I could play more.

Then my friend came online.

Now it's 1:30 am.

Nuff said.

A rebuttal to "Use Mercurial You Git"

2008-02-07T15:00:00Z

There's a good deal of confusion about Git, Ian's Use Mercurial You Git article is a good example of it which I'd like to address point by point. But first, I'd like to say that I'm giving Ian the benefit of the doubt. I don't think he's intentionally trying to mislead people I think he simply doesn't understand Git very well, and that's not his fault. Git has two problems that face new users. It suffers from the Blub Paradox and the documentation tends to assume that you already "get" how radically different Git is. So people end up applying the assumptions of how other version control systems to how Git and end up becoming confused and frustrated like Ian, because while some of the commands look similar, what Git is doing and how it does it are dramatically different from other systems, but that's a good thing. It's what makes Git so much better than the competition. It's kind of like how Struts (Java web framework) and Ruby On Rails (Ruby web framework) are both doing essentially the same thing and processing the same parameters from a web server, but if you try and program a Rails app like you program a Struts app you're in for a world of hurt.

The basic version control concepts are the same in Git, but at the same time, they're not. Most version control systems are concerned with managing files, or metadata about files. Git doesn't even care about files. Yes, it seems like it does, and you can even use it as if it does but it really doesn't. The key for me to really buying this statement was when I realized that, if I really wanted to, Git would let me pick and choose between the various hunks of a file and only add the ones I wanted to the next commit.

My advice to new users is simple. To get started, act as if it's like the version control system you're familiar with, but as soon as something doesn't work the way you'd expect take the time to learn what is really happening and why Git is doing it. Every single time this has happened for me I have obtained another "aha!" moment which gave me a significantly better understand of Git as a whole and showed me how truly awesome git really is.

So, with that said, let's look at Ian's complaints:

Installed Files
When talking about Git's usability Ian complains that Git installs "nearly 150 distinct binaries" and claims that "Mercurial has one." What Ian doesn't mention is that while Git may install nearly 150 files you only have to reference one of them directly just like Mercurial which installs over 150 files (a number which roughly doubles as each .py file begets a binary .pyc file after it gets executed). But, this is a straw-man argument because it doesn't matter how many files an application installs, and it doesn't matter if they're binary or not. What's a much more important measure is how many you have to interact with directly and in both cases the answer is one. The confusion is probably a result of the fact that Git actually allows you to call its component parts directly if you really want to, whereas Hg does not. Another good example of this is Dreamweaver, which installs a metric fuckload of files, including a little JavaScript file for almost every one of the cool pieces of functionality. But you never hear newbish web developers complaining about it because they never have to interact with them directly. However, power users love the fact that they can work with them directly (and change how Dreamweaver works).

Usability
Ian uses Git's rebase command as an example of why Git's usability is bad. Rebase is one of the most dramatically powerful tools in the Git arsenal, it's also something you never have to use if you don't want to. It allows you to reorder, merge, and exclude any / all of the commits in your history. But guess what? Ian doesn't mention the fact that Mercurial has a similar functionality called Transplant which is roughly as easy to get confused about using as Git's rebase functionality. Of course you don't have to ever use it in Mercurial either, as evidenced by his not knowing about it. I'm assuming he wasn't intentionally trying to make Git look bad by ignoring Transplant. The fact that the Rubinius project he was looking at requests that committers use it for it's valuable housekeeping aspects is irrelvant to the discussion of Git's usability.

He then goes on to say that "For day-to-day use of Mercurial, you only need hg fetch to get code, and hg commit to give code." except commit only works on a local repo and doesn't "give" code to anyone, and my fairly recent copy of Hg only has a "pull" command but I do see mention in Google that fetch is "...only available when you enable hgext.fetch extension...". So, what he should have said (unless we want to include non-default commands) is that for day-to-day use of Mercurial, you only need hg pull && hg up && hg merge && hg commit to get code and hg push to give code." If we cut him some slack and replace all that garbage with hg fetch and compare it to Git where you need git pull to get code and git push to give code you'll see that the two are almost identical. In fact, for a surprising number of operations Git and Hg use exactly the same name for the same command.

Overloaded Commands
Ian complains about the fact that git checkout can do three "massively different tasks": change to a new head, revert changes to a small number of files, and create a branch. And from a the perspective of someone who doesn't understand Git or version control systems I can see why they might look "massively different". But, lets look at them from the perspective of someone who does understand Git and version control a little better.

First off, if you don't know, "change to a new HEAD" is an odd way of saying switch to a different branch (HEAD is just a convenient pointer to the current branch). When you grab a branch from most version control systems repositories the operation is referred to as "checking out" the code/branch so when you replace the tree in your current directory with that of another branch you are literally "checking out" the code from the repository which is what every system does when you request the files from a branch. But, if "checking out" a branch was confusing for him, he could simply keep each branch in a separate folder like most revision control systems do and just change directories.

To cut him some more slack git allows you to manage multiple branches within the same repo which entails managing multiple branches in the same folder. And yes, the power to manage totally different branches in the same place, does require some new learning, and has some potential gotchas if you don't understand how it works, but note that I said "allows you to manage" not requires. You can live in the simpler one branch per root folder world if you want and there's no real penalty to doing so. Actually, I encourage new users to work that way. It's a simpler way to get started. And yes, to be clear, each folder would be a different repo, but Git's smart and hardlinks the common objects (unless you tell it not to) to save space and merging branches in across repos is just a matter of git pull instead of git merge.

When you "revert changes to a small number of files" Git, like any other version control system, gets a copy from the repository, and what do you call the action of getting files from a repository? That's right kids, "checking out". The fact that git calls it what it is instead of giving it some misleading name like CVS's "update" command, which doesn't "update" shit but instead checks out a version from the repo, should be a point in Git's favor not a point against it.Hg calls this operation "update" too but "checkout" is an alias for it*, so I guess they get to make it work the way the CVS / SVN people and Git people expect.

His argument about checkout enabling you to create a branch is a fair one, but isn't it nicer to be able to create the branch and check it out in one command instead of two? If Ian was really confused by this he could simply create it with "git branch <branch_name>" and then check it out with "git checkout <branch_name>". Personally I prefer the combined form since I'm creating them all the time.

In writing this book on Git I have repeatedly come across situations where a command took options that made it seem to do "massively different tasks" but when I spent the time to investigate what it was really doing I almost always found that the problem was simply that I had been applying behavioral expectations from other version control systems to Git without understanding the fundamentals of how things work in Git. Now, helping people to understand the its fundamentals is something that Git's docs are not particularly good at. They tend to tell you how to execute a command and assume you understand what's happening (at a conceptual level) behind the scenes. This is one of the things I'm trying to address with the book. "git add" is a great example of this. If you don't really understand how Git leverages its index you'll be bewildered as to all those "massively different tasks" you can do with it, but once you understand the index they all make sense and you realize that "add" is exactly where they should be.

Simplicity
He says that Git has lost the "simplicity argument". But the basics of Git are, in fact, very simple to use. If you wanted to you could use it in almost exactly the same way you use CVS with commands of essentially similar complexity, and CVS is a very simple system. But, Git also offers you the power to do very complex things. And that's exactly how I wish every piece of software I used was.

Let me give you an example of how simple things can be:

Operation	CVS	Git	Hg
checkout a repo	cvs co <some_url>	git clone <some_url>	hg clone <some_url>
add a file	cvs add <some_file>	git add <some_file>	hg add <some_file>
replace a file with the version last checked in	cvs update <some_file>	git checkout <some_file>	hg revert <some_file>
commit changes to the repo	cvs commit	git commit	hg commit

I could continue but you get the point. For all your basic commands these systems are all equally simple. Yes there are complex commands too, but there are in all version control systems.

Ian quotes a bit of Git knowledge:

The core Git filesystem can be explained as four types of objects: Blobs (files), Trees (directories), Commits and Tags.

And then says "Unfortunately, no, it can't. The core of Git may well be implemented as four kinds of things. But to get even the most basic tasks done, you need to know repositories, working trees, branches, remotes, masters, origins, index caches, and a bunch of other unexplained concepts."

With the exception of the index (or "index cache" as he calls it) all of these things exist in Mercurial and you also need to understand the same ones in both. Although maybe Mercurial does have something similar to the index for staging commits, I don't know. You could argue that "masters" don't exist in Hg but master is just the default name for the initial branch in a repo. They had to call it something and they picked "master". Every version control system has at least one branch whether or not they happen to mention it, and if you only use one branch per repo you never have to even think about "master". And if you don't want to name it "master" you don't have to. SVN has the idea of remote repositories just like Hg and Git and you don't need to use remote repositories in any of them. It's certainly helpful if you understand the concept but it's not as if this is some obscure thing that Git came up with and no-one else has. To do basic CVS style operations you can be blissfully ignorant of the index in Git. All you need to know is to use the "-a" option when you commit to commit all your changes.

Finding Documentation
He's totally right about not being able to look up the appropriate command in Git's man pages without knowing what it's called. It is sometimes hard to find instructions for what you're trying to do in Git. This is another thing I'm trying to address in the book but that's no help to people who don't have the book, and no excuse for it not being better handled by the docs, but since the book will be GPL I fully expect some of what I write to make it onto the web (I may even put it there myself), and maybe into the docs.

Windows
He's also right about Git sucking on Windows, although he doesn't put it that way, and this is the biggest reason not to use Git. If you need to share your codebase with Windows users Git is, IMNSHO, simply not ready. It can be done with Cygwin but Mercurial is much less of a hassle on Windows. There is work being done to address this, but for now Git is primarily for Linux, Unix, and OS X.

Unreliability
He also complains about Git being unreliable but doesn't back it up in this post. I've seen no evidence to this effect or mention of any on the web, but I'm betting that his problems with Git's "reliability" will be based in similar misunderstandings of how Git works. Which would mean that Git needed to work on it's documentation to help improve people's understanding.

Closing Thoughts
Ian makes a lot of complaints about how much worse Git is than Hg, but in almost all cases if you examine the truth behind what he says you end up with Git and Hg coming out almost exactly the same. The places where Mercurial wins are Windows support and, probably, documentation. Both of these are very important, but neither of them make the tool more functional. For everyday simple usage Hg and Git are roughly equivalent tools, from a usage standpoint (assuming you understand how to use them), but I believe that Git is simply a more powerful tool that lets you go much farther beyond the "everyday simple usage". Yes, it requires thinking differently about version control. Is that really so bad? Most of the programming tools that can dramatically enhance your productivity, or capabilities require getting your head around new concepts. Git really isn't hard, it's just different. Think of it like a harp. It's simple to understand how to play and it looks like plucking it would be the same as plucking any other stringed instrument, but it really isn't and you're going to have to get used to it because your fingers interact with it like nothing else, and you're not going to be able to take it everywhere either.

On a related note: Ian's gripes are primarily founded in issues about usability the failure of Git's documentation to help him understand it, but based on those criteria Darcs kicks everyone's ass. I don't recommend Darcs anymore for a number of reasons, but, with a couple exceptions, Darcs is damn easy to use and it's not a bad system at all.

*Thanks for the correction on Mercurial Lurker and thanks SJS for your notes about CVS.

The rules of Presidential Bitching

2008-02-06T00:05:00Z

The rules of Presidential Bitching are quite simple:

Everyone gets to bitch about all things presidential until the primaries.
After the primaries only the people who voted (or honestly intended to but were thwarted) can bitch about the candidates and party nominations. Everyone can bitch about general presidential issues.
After the election only the people who voted (or honestly intended to but were thwarted) can bitch about anything our president does or how much better off we'd be if someone else had of won.

Reserve your right to bitch. Vote!

Remember: you can vote on a provisional ballot if you neglected to register to vote.

Some thoughts about Git

2008-02-04T22:16:00Z

Not too long ago I decided to start writing a book about distributed version control. I was originally going to focus on Mercurial (Hg) because it's quite good and of the two leading systems it was the only one that ran on every OS (because it was written in Python). The fact that it could also run under Windows meant that I could help spread the word about distributed version control to more people, and it slightly increased the chance that I might actually make some money in the process.

There was just one problem: Linus was right.

"Hg is pretty good, but Git is better." - Linus Torvalds

When I heard him utter those words in his talk to the folks at Google I took them with a grain of salt. Almost every project owner believes that their software is "better" than the competition, especially when they're so similar, but it turns out that it wasn't hubris on his part. When you sit down and compare the functionality Git simply lets you do more.

I had actually started writing the book about Hg but time and again I found myself confronted with something that was either easier to do in Git, or simply not possible in Hg. It happened enough that I decided that I didn't want to keep writing about, and arguably helping, out a product that I not only wouldn't choose to use myself but also felt was dramatically inferior from a usage standpoint.

And then I joined the Git mailing list. Linus mentioned that it had a high signal to noise ratio but... holy shit. I have been on a lot of mailing lists for open source projects over the years and I have never seen anything like this. Almost every e-mail is a patch, or a good discussion of a patch, or a good discussion of some new feature and how to go about implementing it. Currently, one of the topics they're discussing is how to allow people to push to a Git repo based on GPG keys stored in, or accessible by, Git. What's amazing is that it isn't just one or two people going back and forth or someone trying to proclaim the "one true way" to do things. It's exactly what you would expect if you took a bunch of smart geeks, stuck them in a room, and watched them all work together to solve some common problem. That alone is impressive, but when you combine that with the fact that it's a pretty high traffic list and you've got a lot of really smart people pushing a tool forwards at an incredible pace.

Now, all is not sunshine and roses in Git land:

The documentation is actually pretty good, but when you want to do a specific task and don't know the Git specific terminology for it it can be a little difficult to find what you need, and sometimes the commands take a dizzying array of options and could really do with more examples. That works out well for me, because it'll be all the more reason for people to buy my book, but it's obviously not great for attracting new users. I still think that, for most use cases, Darcs does a better job than anyone at making it easy to ferret out what command you need to accomplish a task.

Git is a lot like C. It's incredibly flexible and powerful but it is also incredible flexible and powerful. If you want to shoot yourself in the foot Git will point you to the gun rack and show you how to load the bullets.

Under the covers Git is a collection of small C apps surrounded by shell scripts, Perl scripts, Python scripts.... whatever the author chose to get the job done. From a usability standpoint this is irrelevant. Calling "git foo" is going to work just as well regardless of what foo was written in and will have no impact on the user, but I'd personally prefer to hack on a project that was all written in one language. It also means that the msysgit team has a lot of work ahead of them in trying make it install easily under Windows. If you'd like to see git working under Windows, and are familiar with coding for Windows please check these guys out and see if there's anywhere you can help out. Even just taking on a little task here and there is something that would be greatly appreciated. Part of me wonders if it wouldn't be better to just port everything in Git to C.

I think that if the Git book goes over well I may go back and retool it for Mercurial, but in the meantime I have to agree with Ted Tso*:

"...the main reason why I've come out in favor if Git is that I see its potential as being greater than [that of] Hg, and... in the long run I think it has 'more legs' than Hg..."

* Just to be totally up front. Ted did have some complaints about ease of use and documentation, but I think that since his post came out Git has made some really significant improvements in those areas.

P.S. For anyone who things I should improve the docs instead of bitching about their limitations and profiting off their lack by writing a book I would say, "chill". I plan to submit some documentation patches and the book will be GPL v2 licensed so people will be free to grab anything they want from it, although the book is taking a task-based, cookbook style approach which isn't really appropriate for man pages, but may be useful on the wiki. Also, I probably won't see much, if any, profit from the book. ;)

Bullitt with Steve McQueen (a review)

2008-01-25T03:32:00Z

I'm convinced that there must be two "Bullitt" movies with Steve McQueen. Because all the reviews seem to talk about one of the best action movies ever, the best car chase ever, a great story. They use words like "thriller", "epic", and "gritty", but none of these things apply to the film I saw.

The director made sure that whenever the audience came within view of a potentially tense moment to quickly salve their nerves with at least ten minutes of sleep inducing banter, bored toothpick chewing, newspaper and frozen diner purchasing, car washing, clicky machine watching, plane embarkment and disembarkment, and, of course, coffee house music. Nothing is resolved in the end. And the plot is essentially: witness gets shot, cops slowly work their way from one clue to the next, as they learn more about why the man was killed. Eventually more people get shot, and no-one cares. I'm not kidding. No-one cares. The guy who was impatient to get the witness's testimony starts reading his newspaper, Steve goes home and washes his hands in the bathroom sink, and the credits roll. The end.

I'm convinced that it would be possible to induce a heart attack in the director simply by going back in time and showing him a modern action flick like The Bourne Identity. And the infamous 100 Mph car chase through San Francisco? It was quite possibly the most boring car chase I've ever seen. It's entirely possible that this was a great action flick by the standards of it's day, but it's not by today's.

On the up side, they did a great job with the transfer to HD so you can watch the boredom in all its glory.

What if I were to write my personal?

2008-01-22T01:47:00Z

What if I were to write my personal?

What if it were true?
What if it spelled out
in black and white
the things I want in you?
What if it held nothing back:
my faults, my hopes,
my geek...

There are things I want
you'll never be.
There are things you want
I'll never have.
But maybe... just maybe...
that's the way it's meant to be.

Perfect little imperfections,
that together make up me.
Perfect little imperfections,
that define who we could be.

Thoughts, feelings,
wishes, dreams...
Secrets.

Imperfections.
Misconceptions.

I'd love to write my personal
and show it here to you,
but I know it won't be seen
be only you and me.

It's too dangerous to be open
so we put on little shows,
that make a pretty face to
bring you to your toes.

Single white geeky chick seeks....
what? Love Family. The kiss
of a beautiful woman?
Yeah, that's it.

Joy: closeness, comfort, laughter, surprises, tenderness, patience, support, desire, ambition, strength, confidence...

Further adjectives, adverbs, nouns and more available upon receipt of same.

P.S. I am so not leaving Boston.