Archive for category Computers

Git.

Posted by on Tuesday, 1 September, 2009

(Apologies to the original poster. I noticed the ‘name’ line of the git manpage today and got inspired.)


From: sussman@red-bean.com (Ben Collins-Sussman)
Sender: cooks@red-bean.com
Subject: The True Path (long)
Date: 01 Sep 09 03:17:31 GMT
Newsgroups: alt.religion.version-control

When I log into my SunOS 4.2 system with my 28.8kbps modem, both svn
*and* hg are just too damn slow. They print useless messages like,
"Type 'svn help' for usage" and "abort: There is no Mercurial
repository here". So I use the version control system that doesn't
waste my VALUABLE time.

git, man! !man git

GIT(7) Git Manual GIT(7)

NAME
git - the stupid content tracker

SYNOPSIS
git [--version] [--exec-path[=GIT_EXEC_PATH]]
[-p|--paginate|--no-pager]
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
[--help] COMMAND [ARGS]

DESCRIPTION
Git is a fast, scalable, distributed revision control
system with an unusually rich command set that provides both
high-level operations and full access to internals.

---

Computer Scientists love git, not just because it comes first
alphabetically, but because it's stupid. Everyone else loves git
because it's GIT!

"Git is the stupid content tracker."

And git doesn't waste space on my Newton MessagePad. Just look:

-rwxr-xr-x 1 root 24 Oct 29 2009 /bin/git
-rwxr-xr-t 4 root 1310720 Jan 1 2005 /usr/bin/hg
-rwxr-xr-x 1 root 5.89824e37 Oct 22 2001 /usr/local/subversion/bin/svn

Of course, on the system *I* administrate, hg is symlinked to git.
svn has been replaced by a shell script which 1) Generates a syslog
message at level LOG_EMERG; 2) reduces the user's disk quota by 10GB;
and 3) RUNS GIT!!!!!!

"Git is the stupid content tracker."

Let's look at a typical novice's session with the mighty git:

$ git add *
fatal: Not a git repository

$ git checkout
fatal: Not a git repository
Failed to find a valid git directory.

$ git git
git: 'git' is not a git-command. See 'git --help'.

$ git --help

$ git over here
git: 'over' is not a git-command. See 'git --help'.

$ git "eat flaming death"

---
Note the consistent user interface and error reportage. Git is
generous enough to flag errors and pack repositories as dense as
neutron stars, yet prudent enough not to overwhelm the novice with
useless details. If users REALLY want to know what git commands are
available, a simple 'man git' will reveal them all, sheer genius
in its simplicity:

git-add(1)
git-am(1)
git-archive(1)
git-bisect(1)
git-branch(1)
git-bundle(1)
git-checkout(1)
git-cherry-pick(1)
git-citool(1)
git-clean(1)
git-clone(1)
git-commit(1)
git-describe(1)
git-diff(1)
git-fetch(1)
git-format-patch(1)
git-gc(1)
git-grep(1)
git-gui(1)
git-init(1)
git-log(1)
git-merge(1)
git-mv(1)
git-pull(1)
git-push(1)
git-rebase(1)
git-reset(1)
git-revert(1)
git-rm(1)
git-shortlog(1)
git-show(1)
git-stash(1)
git-status(1)
git-submodule(1)
git-tag(1)
gitk(1)
git-config(1)
git-fast-export(1)
git-fast-import(1)
git-filter-branch(1)
git-lost-found(1)
git-mergetool(1)
git-pack-refs(1)
git-prune(1)
git-reflog(1)
git-relink(1)
git-remote(1)
git-repack(1)
git-repo-config(1)
git-annotate(1)
git-blame(1)
git-cherry(1)
git-count-objects(1)
git-fsck(1)
git-get-tar-commit-id(1)
git-help(1)
git-instaweb(1)
git-merge-tree(1)
git-rerere(1)
git-rev-parse(1)
git-show-branch(1)
git-verify-tag(1)
git-whatchanged(1)
git-archimport(1)
git-cvsexportcommit(1)
git-cvsimport(1)
git-cvsserver(1)
git-imap-send(1)
git-quiltimport(1)
git-request-pull(1)
git-send-email(1)
git-svn(1)
git-apply(1)
git-checkout-index(1)
git-commit-tree(1)
git-hash-object(1)
git-index-pack(1)
git-merge-file(1)
git-merge-index(1)
git-mktag(1)
git-mktree(1)
git-pack-objects(1)
git-prune-packed(1)
git-read-tree(1)
git-symbolic-ref(1)
git-unpack-objects(1)
git-update-index(1)
git-update-ref(1)
git-write-tree(1)
git-cat-file(1)
git-diff-files(1)
git-diff-index(1)
git-diff-tree(1)
git-for-each-ref(1)
git-ls-files(1)
git-ls-remote(1)
git-ls-tree(1)
git-merge-base(1)
git-name-rev(1)
git-pack-redundant(1)
git-rev-list(1)
git-show-index(1)
git-show-ref(1)
git-tar-tree(1)
git-unpack-file(1)
git-var(1)
git-verify-pack(1)
git-daemon(1)
git-fetch-pack(1)
git-send-pack(1)
git-update-server-info(1)
git-http-fetch(1)
git-http-push(1)
git-parse-remote(1)
git-receive-pack(1)
git-shell(1)
git-upload-archive(1)
git-upload-pack(1)
git-check-attr(1)
git-check-ref-format(1)
git-fmt-merge-msg(1)
git-mailinfo(1)
git-mailsplit(1)
git-merge-one-file(1)
git-patch-id(1)
git-peek-remote(1)
git-sh-setup(1)
git-stripspace(1)

"Git is the stupid content tracker."

Git, the greatest WYGIWYG revision control system of all.

GIT IS THE TRUE PATH TO NIRVANA! GIT HAS BEEN THE CHOICE OF EDUCATED
AND IGNORANT ALIKE FOR CENTURIES! GIT WILL NOT CORRUPT YOUR PRECIOUS
BODILY FLUIDS!! GIT IS THE STUPID CONTENT TRACKER! GIT MAKES THE SUN
SHINE AND THE BIRDS SING AND THE GRASS GREEN!! GIT WAS HANDED DOWN TO
US FROM LINUS UPON THE MOUNTAIN, AND LINUX USERS SHALL NOT WORSHIP ANY
OTHER TRACKER!

When I use a version control system, I don't want eight extra
MEGABYTES of worthless HTTP protocol support. I just want to GIT on
with my coding! I don't want to subvert away or mercurialize!
Those aren't even WORDS!!! GIT! GIT! GIT IS THE STUPID!!!

CONTENT TRACKER.

When Linus, in his ever-present omnipotence, needed to base his patch
juggling habits on existing tools, did he mimic svn? No. Hg? Surely
you jest. He created the most karmic version tracker of all. The
stupid one.

Git is for those who can *remember* what project they are working on.
If you are an idiot, you should use subversion. If you are
subversive, you should not be mercurial. If you use GIT, you are on
THE PATH TO REDEMPTION. THE SO-CALLED "FRIENDLY" SCM SYSTEMS HAVE
BEEN PLACED HERE BY GIT TO TEMPT THE FAITHLESS. DO NOT GIVE IN!!! THE
MIGHTY LINUS HAS SPOKEN!!!

?

My new friend, Mr. Arduino.

Posted by on Thursday, 30 July, 2009

A year ago at OSCON I was on the exhibition floor and discovered a great booth called Maker’s Shed. They’re connected with O’Reilly’s Make magazine, which is a quarterly journal for harware hackers — folks who actually enjoy dissecting electronics, building hardware gadgets, modifying things, and aren’t afraid of either circuits or soldering irons. But it wasn’t until this year back at the conference I really got “sucked in”. I really had no idea what a huge cottage industry this hobby has become! The net is full of websites with all sorts of do-it-yourself electronics projects and discussion boards for sharing tips and ideas.

In particular, a huge hub of activity has centered around the Arduino board, which is a little circuit board containing a basic 16mhz Atmega CPU. It has multiple digital and analog input and output pins; it can be powered either by a 9V battery or by a USB cable; it’s able to speak to a host computer via that same USB cable as well. The thing is tiny, and the spec is entirely open source. While the original Italian manufacturer still sells them like hotcakes for $30, the open-source spec has spawned a bunch of clone competitors as well. Whatever the case, the Arduino seems to be ground zero for a lot of crazy experimentation these days. All you need to do is add sensors (switches, knobs, photo-sensors, temperature sensors, tilt and accelerometer sensors, microphones, etc.) and add whatever actuators you want (motors, LEDs, or network modules!) You download a simple programming environment, write code in a simplified java/C hybrid language (see the Processing site), and poof, the IDE cross-compiles your code and pushes it down to the Arduino. The CPU starts executing it in a loop right away!

It’s the low barrier to entry that seems to have caused this hobby to take off. The USB cable is an incredibly simple way to supply both power and data/communications. The board itself has +5V to power most simple sensors and actuators: just use jumpers to connect the pins to a solderless breadboard, and you can prototype any gadget in just a few minutes! A whole secondary “accessory” industry has taken off as well: if you look at this list of parts, you’ll see all sorts of Arduino extensions for sale: bluetooth modules, ethernet modules (which speak TCP/IP on-board!), motor modules, wi-fi mesh-network modules, GPS modules, sound modules… even an autonomous blimp you can control via IR or RF!

Youtube and other places are full of all sorts of videos demonstrating how to build things, solder things correctly, test circuits with a multimeter, and so on. I’ve been particularly enthralled with Lady Ada’s site. She’s got instructions to build a dozen crazy-cool projects, and seems to be doing well by selling all the parts to her readers as convenient little “kits”. I particularly like her design for a DIY “TV-B-Gone”, and the pocket-sized RF jammer. No, she won’t sell the parts for the jammer, since it’s technically an illegal device. πŸ™‚

So I dived in last week and bought the Advanced Starter Kit, which is fairly good. Lots of parts (though unlabeled/undocumented), and comes with a big book of recipes. For people starting with very little EE background, however, you’ve absolutely got to get the Getting Started with Arduino book, which is written by a company co-founder and is a quick read. For my first project, I built something similar to what he demonstrates at the end of the book: a tri-color RGB LED hooked up to a solderless breadboard, then linked into the Arduino:



…just pop it all into a travel soap-box, and pop a ping-pong ball on top to diffuse the light:



Voila! Just plug it into a big computer, and write a program to poll some internet data and then send RGB colors to the device. You can make it any color you want, have it flash, pulse, whatever. I’ve set it up in my office in the middle of our cube space, such that it reflects the status of our team’s continuous build. Sweet.

One last thing I’ve discovered: I have no real electronics background. Sure, I remember adding up resistors and capacitors in series and parallel back in high school, but it didn’t mean anything to me. Now I find myself asking questions like “why did they put a resistor at that point in the circuit?”, and it frustrates me not to be able to design a sound circuit the same way I design software. One of the more experienced EE folk here at the office advised me that “hardware engineers do the same thing as software engineers: they use high-level design patterns. They memorize circuits for accomplishing certain things and then plug them together.” I guess that makes sense, but I’m a top-down learner and really craved the underlying theory of semiconductors and such. So I ran off to my local Radio Shack and bought this classic Forrest Mims book on the fundamentals of electronics. It was written in 1983, seems to have been re-printed a dozen times, and seems to be the most popular intro book ever written. It’s really awesome, and I’d recommend it to everyone starting to fool with the Arduino. It’s in stock at almost every Radio Shack store, and the website will even tell you which stores have it.

Mercurial on Google Code

Posted by on Friday, 24 April, 2009

You’re not actually surprised are you? πŸ™‚

Read the official blog post for details.

But yes, this is the project I’ve been leading for the last 9 months. I haven’t written any code, but instead it’s been my first chance to really be a ‘tech lead’ (translation: manager) for some truly brilliant programmers on my team. The mercurial-on-bigtable implementation is top-notch.

Note that the feature isn’t finished yet — lots of missing things, lots of bugs to fix still. We’ve not yet fully launched to the public. But you can sign up to be an ‘invited tester’ (if you’re willing to give us feedback), and meanwhile we’ll continue to finish the feature in the public view.

An Exhausting Week: Google Code, Winesburg, Haskell.

Posted by on Friday, 6 March, 2009

What a long week!

I was in San Francisco all week visiting Google teammates, cooking up our latest exciting plans for Project Hosting on Google Code. Our whole team is eagerly awaiting the upcoming Google I/O developer conference in May (for programmers who want to use Google technologies in their own works). Still, it’s really exhausting to sit in conference rooms all day with co-workers while working out designs and strategies.

At the end of that trip, I stopped in Kansas City for a day on the way home to Chicago, to check in on the latest re-mounting of our musical Winesburg, Ohio going up at KC Repertory. (This is a huge production, and you can even hear a sample of a song on the theater’s website.) Andre and I got to rehearse the 5-piece pit orchestra, and listen to an unbelievable cast sing the show. The cast is made up of local folks, Chicago folks, and a bunch of famous Broadway pros. I’ve truly never heard the musical sound better… it just gave me goosebumps hearing the vocal harmonies stack on each other in various climax sections!

Now I’m finally home, and I can try to remind my kids who I am again.

On the plane, though, I finally finished my mini “learning Haskell” project. Because, you know, I wasn’t feeling like enough of an oppressed minority — I had to start teaching myself an elitist functional programming language just for kicks. πŸ™‚ I’m having a blast re-wiring brain to solve problems functionally. I wrote a cute little program to compute a Julia Set on the complex plane. Here’s a sample session with the Haskell interpreter:

*Main> :load complex.hs
[1 of 1] Compiling Main ( complex.hs, interpreted )
Ok, modules loaded: Main.

*Main> let win = ComplexWindow (ComplexNum (-2) 2) (ComplexNum 2 (-2))
0.1 100 100

*Main> juliaWindow (ComplexNum 0.1 0.2) win
[[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,3,3,3,3,3,3,4,4,4,5,5,5,5,5,6,6,5,5,4,4,4,3,3,3,3,3,3,3,2,2,2,2,2,2,2],[2,2,2,2,2,3,3,3,3,3,4,4,4,5,5,6,7,7,7,8,0,0,0,7,6,5,4,4,3,3,3,3,3,3,2,2,2,2,2,2,2],[2,2,2,2,2,3,3,3,3,3,4,4,5,7,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,3,2,2,2,2,2,2],[2,2,2,2,3,3,3,3,3,4,4,5,7,0,0,0,0,0,0,0,0,0,0,0,0,8,6,5,4,4,3,3,3,3,3,3,2,2,2,2,2],[2,2,2,2,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,6,5,4,4,3,3,3,3,3,2,2,2,2,2],[2,2,2,2,3,3,3,3,4,4,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,5,4,4,3,3,3,3,3,3,2,2,2,2],[2,2,2,3,3,3,3,3,4,5,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,2,2,2,2],[2,2,2,3,3,3,3,3,4,5,11,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,2,2,2,2],[2,2,2,3,3,3,3,3,4,5,9,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,5,4,4,3,3,3,3,3,2,2,2,2],[2,2,2,3,3,3,3,3,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,2,2,2],[2,2,2,3,3,3,3,3,4,4,5,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,2,2,2],[2,2,2,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,3,2,2,2],[2,2,2,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,5,4,4,3,3,3,3,3,2,2,2],[2,2,2,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,3,3,3,3,3,2,2,2],[2,2,2,2,3,3,3,3,3,4,4,5,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,9,5,4,3,3,3,3,3,2,2,2],[2,2,2,2,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,11,5,4,3,3,3,3,3,2,2,2],[2,2,2,2,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,5,4,3,3,3,3,3,2,2,2],[2,2,2,2,3,3,3,3,3,3,4,4,5,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,4,4,3,3,3,3,2,2,2,2],[2,2,2,2,2,3,3,3,3,3,4,4,5,6,8,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,5,4,4,3,3,3,3,2,2,2,2],[2,2,2,2,2,3,3,3,3,3,3,4,4,5,6,8,0,0,0,0,0,0,0,0,0,0,0,0,7,5,4,4,3,3,3,3,3,2,2,2,2],[2,2,2,2,2,2,3,3,3,3,3,3,4,4,5,6,0,0,0,0,0,0,0,0,0,0,0,7,5,4,4,3,3,3,3,3,2,2,2,2,2],[2,2,2,2,2,2,2,3,3,3,3,3,3,4,4,5,6,7,0,0,0,8,7,7,7,6,5,5,4,4,4,3,3,3,3,3,2,2,2,2,2],[2,2,2,2,2,2,2,3,3,3,3,3,3,3,4,4,4,5,5,6,6,5,5,5,5,5,4,4,4,3,3,3,3,3,3,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,4,4,4,4,4,3,3,3,3,3,3,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,3,3,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,3,3,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2],[2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2]]

In all seriousness: if you’re a programmer, it’s important to always be learning new things and new ways of thinking. It keeps your brain in good shape!

Random Act of Kindness

Posted by on Wednesday, 25 February, 2009

The old saying goes, “the world is full of jerks, and the internet just makes it seem like they’re all next door.” In fact, even if they’re only a tiny minority among the communities we participate in, they tend to have a disproportionately large impact on our social behaviors. Occasionally a nice surprise happens, though. I got a really nice email today:

This is kind of a strange letter to write, but I just wanted to say “thank you” for your various work in the open source community. I’ve used Subversion for years, but didn’t come to know any of the faces behind it until I started hosting a project at Google Code Hosting (and reading the lists there).

I’ve been impressed by your ability to stick to the philosophies you’ve set up at Google Code, and tireless efforts to defend them. Your patience with some of the more irritating “contributors” to the list should serves as an excellent example for other project leaders.

I know these sorts of fawning e-mails can make one uncomfortable, but (a) one of my best professors taught me to send Thank You notes, and (b) I know that you rarely hear from the people who *appreciate* your work, so having something in your inbox that’s not invective is, hopefully, pleasant.

Keep up the good work!

I guess we tend to forget the majority of folks out there are nice, happy, appreciative folks. They just usually don’t say much on mailing lists. πŸ™‚

A Week in Portland

Posted by on Friday, 25 July, 2008

Just got home from OSCON the big Open Source computer convention in Portland. This is the only convention I attend regularly, and every year my buddy Fitz and I give talks about the culture and methodology of developing software in a “volunteer driven” environment (to put it kindly.) Our clik-and-clak routine of bickering, questioning each other, and finishing each other’s sentences has become a bit of a famous gimmick at this point, though we certainly never intended that to happen. Still, it’s one the reasons we record a podcast now and then.

Normally we only give one or two talks at the conference. After all, the real reason people go to conferences isn’t to watch presentations, but it’s to hang out in divey bars with other well-known members of your field and blather gossip. (Right?)

This year we got two 45-minute talks accepted, and were also talked into doing a 4-hour “tutorial” session with four other lecturers. Quite a bit of work! However, a couple weeks before the conference we were reminded that we had also agreed to be panelists in a public discussion, and then once we arrived at the convention we got asked to do another talk at an “unconference” for newbies. And then O’Reilly asked us to do a 40-minute video interview about the 2nd edition of our upcoming book.

So in total, that makes six talks in three days. Absurd! I was so busy running around to blab, I only had time to watch two presentations! And I developed a nasty head cold in the middle of it all. After three days of being hopped up on Dayquil and talking till I was hoarse, I told Fitz that next year we were going to do ONE talk. That’s it, no more. Our routine had officially crossed the line from “fun talky guys” into mouth-flapping whores. On our sixth talk, we had the pleasure of announcing to the audience that it would be the last time we even gave our “Poisonous People” talk, ever. If
anyone ever wants to see that talk again, it’s been up on YouTube for more than a year. πŸ™‚

We had a lot of fun outside the conference too. We got to hang out with our buddies Jim Blandy (now a Portland native!) and Karl Fogel quite a bit, as well as Bryan O’Sullivan. I took a three hour self-guided walking tour of Portland with my big SLR camera too. I’m amazed at how beautiful the city is. I’ve never felt so “politically compatible” with a city before… every corner seems to have either a vegetable stand, bike shop, or microbrewery. Free range meat is absolutely everywhere! Upon wondering into the wondrous neighborhood of Ladd’s Addition to attend an ad-hoc bluegrass jam in the park, I discovered my very first Burgerville restaurant. I had never heard of this fast food chain before; it looks like Burger King or In n’ Out Burger, but if you read the signs it’s about as food activist as one can be. Local vegetables (Walla Walla onions), local cheese (Tillamook), non-frozen beef from free-pastured Oregon cow herders. I was in heaven.

Really, truly. I could move to Portland right now. I’ve never said that about another city before. I hope Chicago forgives me.

Photos are forthcoming!

Text Adventures on the iPhone… or not.

Posted by on Friday, 11 July, 2008

As many folks know, I’m a huge fan of Interactive Fiction (text adventures). I’ve been working on a z-machine interpreter for Android, as well one that runs in python.

As of today, my iPhone is able to download ‘legitimate’ apps from the AppStore, and there’s still no z-machine interpreter available. For over a year now, there’s been one which requires a jailbroken iPhone out there, but jailbreaking isn’t an option for me (since Google owns my phone.)

My hopes got up when I discovered that the author of Zoom (the best z-machine app for Mac OS X) is actively working on a legitimate iPhone port. However, something he posted really disturbs me:

“A more serious issue is that AppleÒ€ℒs SDK license prohibits downloading code to interpret: this means that it would be impossible to load any games that were not bundled with the interpreter. I think this is probably a fatal problem: it seems doubtful that many IF authors will be willing to pay the $99 required to get their work onto the iPhone – plus it would mean no Zork, ever.”

While it sure is convenient that iPhone users only have one place to check for apps, this really scares me. I’m guessing that the license is intended to prevent people from distributing generic JVM or CLR machines that can download and run any old code, thereby circumventing Apple’s ability to vet applications. But clearly their Safari web browser already downloads and interprets Javascript apps, right? Where does one draw the line? We’re talking about a VM to play text-adventures — would Apple consider the fetching of text-adventures dangerous?

More and more, it’s clear to me that Apple is just as evil as Microsoft, they’re just not as big and powerful (yet)… and they have better taste. Maybe I should give up on issue and just wait for my Android phone at the end of the year. It will be a truly open OS, and I’ll be able to download and run whatever the heck I want.

What I Did on my Summer Vacation

Posted by on Sunday, 6 July, 2008

I’m done with a nice 12-day vacation. I was definitely on the verge of burning out; unproductive at the office and cranky at home all the time. I really needed to step back and forget about computers for a while.

What I did instead:

  • Went on a family vacation to Dubuque, Iowa, a mere 3 hour drive from Chicago.
    • Stayed in a hotel-waterpark with wife and 2 year old. Waterpark every day.
    • Horse-carriage rides.
    • Mississippi paddleboat rides.
    • Mississippi Aquarium Museum.
    • Lots of ice cream.
  • Finally finished reading Watership Down.
  • Started reading The Compassionate Carnivore, which gives me a warm fuzzy feeling that I’m not alone in being a freerange-itarian.
  • Read the through the new 4th edition D&D Player’s Handbook. I’m a geek. I like roleplaying games. Sue me.
  • Went to the Indiana Dunes — at a friend’s house — for the 4th of July.
  • Went to the Bristol Renaissance Faire
  • Shot 300 photos. A few of them were pretty good.
  • Beta-tested an excellent new text-adventure game written by a friend; it should be available to the public by August 1st.
  • Played my banjo at the usual Friday night jam.

Time to go back to Google; I’m continuing to lead a team whose goal is to make Google Code’s Subversion service as fast and scalable as possible.

Subversion 1.5.0 released

Posted by on Thursday, 19 June, 2008

No, really. Seriously!

After nearly two years of work, it’s been released to the public. Semi-intelligent tracking of merges, sparse directories, interactive conflict resolution, and much much more all described here. I had previously posted about how easy it is to manage feature branches; now you can try it yourself.

Visit subversion.tigris.org to download. (It make take a few days for volunteers to update binary packages from the source code.) Also, we’ve just about finished up the new edition of the Subversion Book, which now covers 1.5. You can read it online, or wait a couple of months to buy a hardcopy from O’Reilly.

Programmer Insecurity

Posted by on Thursday, 12 June, 2008

I’ve got a lot to say today!

I want to chat about something that I’ve never noticed before, but probably should have. There’s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your shoes!). But my revelation of the week is that most programmers seem to be really insecure about their work. I mean: really, really insecure.

My buddy Fitz and I have long preached about best practices in open source software development — how one should be open and transparent with one’s work, accept code reviews, give constructive criticism, and generally communicate as actively as possible with peers. One of the main community “anti-patterns” we’ve talked about is people writing “code bombs”. That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.

And yet over and over, I’m gathering stories that point to the fact that programmers do not want to write code out in the open. Programmers don’t want their peers to see mistakes or failures. They want to work privately, in a cave, then spring “perfect” code on their community, as if no mistakes had ever been made. I don’t think it’s hubris so much as fear of embarrassment. Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.

Check out some of these stories I’ve collected:

  • Requests at the Google I/O booth: A couple of weeks ago when my team was at the Google I/O conference, we ran a booth demonstrating our Open Source Project Hosting service. Over and over, we kept getting requests like this:

    “Can you guys please give subversion on Google Code the ability to hide specific branches?”

    “Can you guys make it possible to create open source projects that start out hidden to the world, then get ‘revealed’ when they’re ready?”

    Translation: “I don’t want people to see my work-in-progress until it’s perfect.”

  • Requests on the Google Code mailing list: Sometimes users need their googlecode.com svn repositories wiped clean. Legitimate reasons include the accidental commit of sensitive data, or the need to load code history in from a different svn repository. But most of the time we get (invalid) requests like this:

    “Hi, I want to rewrite all my code from scratch, can you please wipe all the history?”

    Translation: “I don’t want people to be able to find my old code, it’s too embarrassing.” Call it vanity, call it insecurity… the bottom line is that coders want prior mistakes or failures to be erased from history.

  • Code-reviews taken as personal attacks. Fitz tells a funny anecdote about a friend of his who went from the open source world to a corporate software job. Vastly paraphrased:

    During his first week, he started emailing friendly code reviews to each of his coworkers, receiving strange stares in turn. Eventually his boss called him into his office:

    “You know, you really need to stop with the negative energy. Your peers say that you’re constantly criticizing everything they do.”

    Moral: not only is code review not the norm in corporate environments, most programmers are unable to separate their fragile egos from the code they write. Repeat after me: you are not your code!

  • Distributed version control — in a cave. A friend of mine works on several projects that use git or mercurial. He gave me this story recently. Basically, he was working with two groups on a project. One group published changes frequently…

    “…and as a result, I was able to review consistently throughout the semester, offering design tweaks and code reviews regularly. And as a result of that, [their work] is now in the mainline, and mostly functional. The other group […] I haven’t heard a peep out of for 5 months. Despite many emails and IRC conversations inviting them to discuss their design and publish changes regularly, there is not a single line of code anywhere that I can see it. […] Last weekend, one of them walked up to me with a bug […] and I finally got to see the code to help them debug. I failed, because there are about 5000 lines of crappy code, and just reading through a single file I pointed out two or three major design flaws and a dozen wonky implementation issues. I had admonished them many times during these 5 months to publish their changes, so that we (the others) could take a look and offer feedback… but each time met with stony silence. I don’t know if they were afraid to publish it, or just don’t care. But either way, given the code I’ve seen, the net result is 5 wasted months.”

    Before you scream; yes yes, I know that the potential for cave-hiding and writing code bombs is also possible with a centralized version control system like Subversion. But my friend has an interesting point:

    “I think this failure is at least partially due to the fact that [DVCS] makes it so damn easy to wall yourself into a cave. Had we been using svn, I think the barrier to caving would have been too high, and I’d have seen the code.”

    In other words, yes, this was fundamentally a social problem. A team was embarrassed to share code. But because they were using distributed version control, it gave them a sense of false security. “See, we’re committing changes to our repository every day… making progress!” If they had been using Subversion, it’s much less likely they would have sat on a 5000 line patch in their working copy for 5 months; they would have had to share the work much earlier. Moral: even though one shouldn’t depend on technical solutions to social problems, default tool behaviors matter a lot. This was my main theme way back when I wrote about the risks of distributed version control.

OK, so what’s the conclusion here? People are scared of sharing their unfinished work, plain and simple. I know this isn’t headline news to most people, but I really think I’ve been in deep denial about this. I’m so used to throwing my creative output up for constant criticism, that I simply expect everyone else to do it as well. I think of it as the norm, and I can’t comprehend why someone wouldn’t want to do that… and yet clearly, the growing popularity of distributed version control shows just how thrilled people are to hide their work from each other. It’s the classic “testimonial” for systems like git (taken from a blog comment):

“Don’t tell me I should cooperate with other people at the beginning and publish my modification as early as possible. I do cooperate with other people but I do want to do some work alone sometimes.”

Hm, okay. Please just don’t work alone for too long!

Sidetracking a wee bit, I think this is why I prefer Mercurial over Git, having done a bit of research and reading on both systems. Git leans much more heavily towards cave-hiding, and I don’t like that. For example, the ‘git rebase’ command is a way of effectively destroying an entire line of history: very powerful, sure, but it’s also a way of erasing your tracks. Rather than being forced to merge your branch into a parent line, just pretend that your branch was always based on the latest parent line! Another example: when it comes to pushing and pulling changesets, Mercurial’s default behavior is to exchange all history with the remote repository, while git’s default behavior is to only push or pull a single branch — presumably one that the user has deemed fit for sharing with the public. In other words, git defaults to all work being private cave-work, and is happy to destroy history. Mercurial shares everything by default, and cannot erase history.

I know this post has been long, but let me stand on my soapbox for a moment.

Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.

Phew, I feel better now.

(This page has been translated into Spanish language by Maria Ramos.)