It was a good day, but there's one thing that wasn't so good. Maybe.
Above is the entire technical book stock at Fry's Indy. The entire shelf. There's lots and lots of shelves, and once, they were filled with all sorts of technical books. It fills my heart with joy to see a wall of O'Reillys. For the longest time, my first-pass rule for judging a technical project or tool was "Is there an O'Reilly book for it?" The books for learning Perl are Learning Perl and Programming Perl, and I judged Python harshly because the book a Python person would suggest is not Learning Python.
These days, though, your first pass for a technical question is asking Shub-Internet and ending up with a discussion thread, IRC log, or hopefully a Stack Overflow answer. I have editions 1 through 4 of Programming Perl, and they are decreasingly dogeared and beverage-stained as time goes on. I haven't really dug into Programming Perl, Fourth Edition, in part because I know how to write Perl, but in part because, even when I don't know what I'm doing, dead trees are not my go-to.
And, even from the perspective of the writer, writing tech books is a losing game. Jeff Atwood of Coding Horror writes about it when pushing a book, ASP.NET 2.0 Anthology, that he contributed to. xkcd did a comic (which I can't find) which compares the staying power of different book types, grouping math and physics texts as books that can stay without revision for decades, sometimes centuries, while a book on a language or protocol will be out of date very soon, sometimes before publication.
And really, at places like Fry's, you want as much floor space devoted to things that can only be atoms, like motherboards, cases, LEDs, cables, trackpads and MacBook Pros, and things that can be bits should be bits. Plus, of course, the fact that you can put a whole lot of bits into your tablets and newsreader.