Google Tech Talks

Google, a mecca for top notch programmers, attracts many top speakers to give talks on (generally) technical topics. They graciously record these talks and upload them to Google Video. You can get a list of most of them by searching video.google.com for “engEDU”. Think of these as virtual user group talks, but usually with bigger “name” speakers than a typical local group offers.

Here are just a few that’s I’ve enjoyed recently, there are many more worth watching.

How Debian (Ubuntu) packages work

Seth Godin (marketing guru)

Mary Poppendieck (“Lean Software Development” author) – Competing on the basis of speed

A new Way to look at Networking – Fascinating

The Mercurial distributed source control system

Added later:

Fission is the New Fire

Jessica Livingston, talking about “Founders at Work”

Still later:

Subscribe to this feed to find out about each talk

Disconnecting to Keep Distraction Away

I’m back from AYE. The last session I attended was Dwayne Phillips‘s on “Distraction”. Distraction is a recurring enemy here, always ready to strike, to divert me from the task at hand. I’ve recently been using “disconnection” to fight distraction and focus on an intense task for a few hours, and noticed the same notion on the 37 Signals’ blog, a post by Matt entitled “Get Off”.

There is an ongoing flow of incoming data in our online lives. Hundreds of emails per day. Hundreds of RSS feed items. Dozens of IM contacts. Phone calls. Voice mail. The “water cooler”, physical or virtual. The disconnection idea is simple: Go offline, physically and network-wise. Leave your office and go somewhere away from your normal environment, away from email, RSS, instant messaging, the web, etc. Reduce your inputs, to make room for more output.

My implementation is to go to restaurant or cafe, in the mid-morning or mid-afternoon (out of politeness, to avoid disrupting their business by using up a table during peak times); preferable one without “WiFi” to remove that temptation. Then I sit, sip, and Just Work on something important. I write code; I write text; I review documents; I brainstorm. I use my notebook PC with a 12” screen, a stark contrast to my 2560×1024 resolution desktop configuration. The latter is wonderful for many kinds of work; but it is also more distraction-prone.

If you find yourself struggling to task on large important tasks, instead distracted by a thousand smaller things, give disconnection a try.

Heading to AYE

I’m heading to the AYE conference shortly, as I did last year. My strategy then was to attend many Weinberg sessions, which has turned out to be wise in retrospect, as Jerry won’t be there this year, he is home recovering from illness. I am eager to see how the rest of the AYE team divvies up the load of his sessions.

If you work in software development and haven’t read Jerry’s books (The Secrets of Consulting, Becoming a Technical Leader, The Psychology of Computer Programming, etc.), I heartily recommend doing so.

How To Do Deployment (Dave Thomas RailsConf Keynote)

I just attended Dave Thomas’s keynote at RailsConf. He had many interesting things to say, most notably that 60%+ of his Java-centric conference-circuit friends, mostly people who have written books on Java, speak regularly on Java, and have lots of experience as Java “architects”, are now making a living with Ruby / Rails.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

At RailsConf, Sitting Around Ignoring Each Other

I’m at RailsConf. In a flagrant attempt to be one of the cool kids, I’ve set up a Flickr account to share my RailsConf Photos.

Of the few dozen conference I’ve attented, this one has the highest incidence so far of people sitting around, in large groups, working alone on their notebook computers; some of the groups are having conversations, but most of the attendees (including me, as I type this) are staring intently at their own PCs. It makes me wonder why we are all here – are we all so accustomed to interacting online that we don’t bother to interact offline, even when sitting in the same room (and at considerable expense?)

Going to RailsConf. Be wary of software religion.

I’m going to RailsConf 2006 in Chicago next month:

The interesting thing about this is that I signed up before I knew how popular it would be – it sold out in a few days, so the pent-up demand must have been remarkable. More remarkable is that it sold out long before the full list of speakers and talks was released (or even existed). Me and 500 other people didn’t even need to know what/who would be there, to decide to go. For me, that is because I have a project going that uses Rails, and I generally enjoy software conferences, and this one is close.

But maybe there is more. Is Ruby+Rails a fad? A cult? I nearly always enjoy the Ruby on Rails Podcast, but its intro music proudly and bizarrely claims that “we’re building a religion”.

I don’t know who “we” are, but I’m not on board with that.