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?"
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.
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 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.
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?