undees

I ride a short wheel base recumbent, and regularly pass upright bicycles on moderate uphills.

I have an LG Optimus, and the touch response is horrid. The phone works well in other areas, but UI responsiveness and text input accuracy aren't among them.

ClearCase is certainly popular, but I don't think it ever had a feature that was a big milestone in version control history. Client side software with a view of the source is already covered in the author's point #4, and ClearCase doesn't do this better than the others (quite the contrary, in my experience).

Is there a Vim equivalent of Emacs's C-h k followed by the key combo, which basically says, "Tell me what the official command name is for this keystroke?"

On the Mac, you can Cmd-Tab to an app and then hit Ctrl-F2 to navigate the menu from the keyboard: http://support.apple.com/kb/ht1343

I concede that this doesn't address other objections to a single menu bar, such as identifying the active window / application.

As a (mild) counterpoint, I've worked in Win16 code bases that were a nightmare to port to Win32, Win32 code bases that had to be half rewritten to run under the Win32-like API of WinCE, Visual Studio upgrades that broke swaths of MFC/ATL/STL code, and so on. As an end user, I've run apps that were designed for Win95 that choked under NT4, XP that choked under Vista, and so on.

I'm in awe of the backward-compatibility efforts that Raymond Chen and crew have put forth and explained in their blogs. No doubt things could be much worse. But I'm still tired of fighting Windows APIs, both as a developer and as an end user.

Indeed, the ability to work on code now and think about a commit later is freeing. As for the particular abstraction of how to represent the commit in progress... I like the working tree for that, rather than the index. It's just a better mental fit for me to unstage stuff I don't want to commit (via shelve/stash), _rerun unit tests_, do a simple diff without needing to remember the incantation for seeing what's in the index, and commit.

The term "strong" appears overloaded here. A language can be dynamically typed, but still have strong typing (in the sense that the language, whether at compile time or runtime, enforces what operations are allowed on a particular value).

There are a few reasons to do this. One is to at least nominally separate code that's licensed differently than yours (something your lawyers may ask you to do). Another is to make it easier to share your tweaks to the third-party code among several of your own projects.

If you use something like Git submodules, Mercurial subrepos, or Subversion externals, you can get the best of both worlds. Your repo contains just your code, but a fresh clone will set up dependencies automatically.

I've also seen really simple projects get by with just an "install_deps" task in the Makefile, which you run first thing on a new clone. ("The simplicity of Maven meets the dependency management of Make," the wags will say.)

Seconded. AsciiDoc is enough like writing a plain-text e-mail that everything but the writing just falls away.

For a little more control, you can feed the generated DocBook to something like Remko's DocBook kit (https://github.com/remko/docbook-kit), which downloads and runs the various document processors for converting to PDF in stages--with gnarly XML config files available for each stage. This can be helpful for trying to match a specific conference template, for instance.

The hg-git plugin for Mercurial worked fine on Heroku the last time I tried it: http://bitbucket.org/durin42/hg-git

GitHub and Mercurial aren't mutually exclusive; hg-git works pretty well.

It's an advantage because you can make commits that are the same size and scope as the ones you'd normally make when connected. You don't have to save up for one big giant commit that has a bunch of unrelated changes.

Offline commits also make it easy to switch contexts quickly: to go from adding a new feature to fixing a bug you just noticed.

I thought all the font snobs saw Helvetica as pedestrian, and wanted us to use Frutiger or something instead....

I was one of the early reviewers (which means getting to read a PDF for free, so take what I say with a grain of salt). The book didn't strike me as particularly prescriptive in the "you have to do this to be Agile-with-a-capital-A" sense. The whole samurai thing was kind of like a running gag to keep the tone light. I don't think I'd have noticed this book on the shelf ("Agile? Don't we already know what that's about?"), but having it dropped into my lap, so to speak... it was a fun read.

No kidding! Right now, it's about as thick as a sheet of vapor.

"life in a shanty town is not worse than death"

Honest question: how do you know?

The overall feel of the sequence is a mixed bag. On the plus side, kneath offers a workaround (filtering + APIs), apologizes for initially misunderstanding which feature the customer was talking about, and doesn't promise miracles. On the minus side, the "hard time believing" and "sort of heartbreaking" lines don't sit so well.

I doubt kneath was trying to belittle his customer--which reinforces your point that customer support is hard. My original question should have been, "Why this particular title?" Was the poster holding this up as an example of perfect support, or mocking it as an example of terrible support? In reality, it was neither.

What am I missing? This seems like a reasonably okay exchange, but what's special about it that makes it worth singling out as an example that all other tech support folks should aspire to?

Call me insane, but I kind of like GDB + Xcode's wrapper. Yes, once or twice it has said dumb things about variables, but no more so than Visual Studio.

Likewise, I can't remember a time when I've seen Xcode's Intellisense-like feature fail, though I can recall several times when Visual Studio's has. (Xcode's method to advance to the next parameter--Ctrl-slash or something--is pretty non-obvious, though.)

At my last job, I was certain they'd tell me to go home for the two weeks (that was their usual practice). But I didn't want my projects to suffer. So I had my closest work friend and his family over for dinner and gave him a quick brain dump of the projects. Over the next few days, we'd find a few spare moments to make sure he knew all the ins and outs.

Now, finally, I could give notice. As it turns out, they "let" me stay pretty much the whole two weeks.

I've been trusting my precious source code to Hg-Git for a while. The sort of "something goes wrong" moments have usually been fixable with a bit of grubbing around in Hg-Git's source. They've got themselves a pretty inviting code base, FWIW.

It maps git branches to hg bookmarks (http://mercurial.selenic.com/wiki/BookmarksExtension) instead of hg branches, because bookmarks turn out to be a better fit.

I wondered about that, too---how fragile will this be in the face of minor GUI changes? (A fuzzy-match parameter would be a nice addition to the API.) One encouraging sign is that the screenshots are stored as .pngs in the file system. If an app update does nothing but change button graphics or text, the script could presumably pull new graphics from the same place.

That just leaves the other 90% of GUI changes that involve moving a setting to another screen, or changing the way an entire interaction works. ;-)

All the stuff you said about GUI automation being klunky is true. Still, this thing could come in handy as a kind of "GUI batch file," or perhaps as a tool to help produce screencasts.

Sharing the secrets behind the parlor tricks can help with this feeling. Some particular technique may feel easy for you, but there could be people out there who haven't discovered it yet, and are stuck on some task.

You're contrasting Ruby as an upstart and Java as an established language, but they're basically the same age. They both had their first public releases in 1995.

(Of course, this doesn't invalidate your point about relative popularity.)

I love the ideas behind rip, but I think even Chris would say it's not quite ready to replace gems yet. For one thing, it depends on specific bash-isms.

Dilettantes?

Well, except that the bowling scores thing had a clear spec from the beginning, and was an easier fit for a blog post. The Sudoku thing seemed more like thrashing around in the how-to-represent-data space to avoid thinking about the algorithm.