Slashdot Mirror

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

I'm about to finish my fourth book for O'Reilly, Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders (which should be out in stores by March).

As far as tools go, my coauthor, Jenny, and I wrote our first book using Microsoft Word, but could just as easily have been using OpenOffice, Pages or any other word processor. One thing that was enormously useful was EndNote for managing the bibliography. Our next two books were in O'Reilly's Head First series (PMP and C#), and we wrote them entirely in Adobe InDesign. (People think that there's a whole team of people designing and laying out Head First books -- it was just us, our editor, and an awesome but overworked graphic designer, Lou, who helped improve our layouts once we had them in reasonable shape.) InDesign isn't exactly the easiest tool for a book author, but it was sufficient. But it made me really appreciate word processors!

A few things that really became clear to me over the course of working on these books:

a) Pay attention to what you're delivering to your editor, and what they'll do with it. Publishers have their own set of templates and production stuff to get camera-ready copy together. Head First was a very interesting lesson in that, because Jenny and I actually produced a lot of camera-ready copy ourselves. But for most books, whatever you turn over to your publisher will get transmogrified into their own internal format.

b) The production editor people I've worked with and talked to (not just at O'Reilly, but at other publishers, too) have been extremely competent, and it's their job to take whatever it is you give them and make it work. It needs to be copyedited, typeset, and reviewed, and sent to a printer. I highly recommend getting to know them, and being as flexible and agreeable as possible (they generally won't ask you to compromise your vision for the book -- it's generally about technical stuff, like how to deal with footnotes, references, images, etc.)

c) You asked about version control. One of the best authors I've ever worked with, Karl Fogel -- he's a contributor to Beautiful Teams, and also just a great guy -- wrote a fantastic book called Producing Open Source Software, which you can buy from O'Reilly or download for free from the website. (Anyone who's interested in starting or contributing to an open source project absolutely needs to read that book. Disclosure: I was a technical reviewer for it.) In true open source fashion, Karl made his version control repository for the book available, and that's a good model to copy. Jenny and I didn't do anything quite so formalized; we just shared folders, and that was sufficient for us (even with hundreds and hundreds of image files for each Head First book).

d) This is the most important thing: make sure you have a clear idea of what it is you want to write! It's easy to get started on a project, only to have it trail off because you don't really have a whole book's worth of material. The more you can outline, the more research you do, and the more you prepare, the better the book will be.

Now, that's all assuming that you have a publisher lined up and a contract signed. If you don't, I highly recommend reading through the excellent Writing for O'Reilly section on their website. They walk you through all of the steps of proposing a book and the mechanics of actually working with a publisher -- and from everyone I've talked to, it's very similar

Throwing hardware at a problem means the writer failed to use his sysadmin staff to do basic capacity planning while there wasn't a problem.

And as johnlcallaway, said, the problem isn't usually CPU: most bottlenecks are either disk I/O or code-path length.

I'm a professional capacity planner, and it seems only the smartest 1% of companies ever think to bring me in to prevent problems. A slightly larger percentage do simple resource planning using the staff they already have. A good example of the latter is Flickr, described by John Allspaw in The Art of Capacity Planning, where he found I/O was his problem and I/O wait time was his critical measurement.

Failing to plan means you'll hit the knee in the response-time curve, and instead of of a few fractions of a second, response time will increase (degrade) so fast that some of your customers will think you've crashed entirely.

And that in turn becomes the self-fulfilling prophecy that you've gone out of business (;-()

Alas, the people who fail to plan seem to be the great majority, and suffer cruely from their failure. The last few percent are those unfortunates whose professional staff planned, warned, and were ignored. Their managers pop up, buy some CPUs or memory to solve their I/O problem, scream at their vendor for not solving the problem and then suddenly go quiet. The hardware usually show up on eBay, so I think you can guess what happened.

--dave

It's not only in the far east that such different subjects are sometimes juxtaposed for effect.

Don't forget our own utterly fantastic Britney Spears' Guide to Semiconductor Physics on this side of the world, which really deserves a medal. If a blend of pop culture and highly mathematical science raises a smile at the same time as presenting some serious physics, maybe the approach isn't as barmy as it seems.

Also remember that we do something similar in computing too, for instance in Head First Design Patterns and other books in the series, which present their material through silly little stories. A lot of people seem to like that approach.

There's more than one way to skin a cat, and that seems to apply to technical literature too.

Of course it's not. Well, assuming you're talking about the Windows kernel anyway. http://oreilly.com/catalog/opensources/book/appa.html [oreilly.com]

What ? As Tanenbaum points out, Windows NT is a microkernel (-ish) OS. That's about as 'modular' as it gets, from the perspective of the kernel.

The entire mechanism for building the OS is based on it being modular.

Of course it's not. Well, assuming you're talking about the Windows kernel anyway. http://oreilly.com/catalog/opensources/book/appa.html

Considering that the kernel is highly relevant to how an operating system performs on benchmarks, I'd say both its design and structure are critical in determining speed. That said - you are correct. 7 is feature complete and we shouldn't see any big game changers very soon.

I am amazed that anyone in education doesn't know the first thing about the Google. Let alone getting as far as the intricacies of the free software wars. JFGI: linux

Then, with some background, the online book Free as in Freedom on Stallman is a good, in-depth discussion.

If bountyquest couldn't get enough high quality prior art submissions by offering 10k, what makes IBM think they'll get better submissions without offering anything? Bountyquest's failure to bust the 1-click patent was quite telling of its patent-busting power. Salon.com's postmortem explained "BountyQuest tried to overcome the inability to build momentum [from a few big patent busts] by cold-calling patent lawyers and trying to sell them on the idea of running a contest for one of their cases [b]ut few have proved willing to bite." "There just didn't appear to be a market for its service." O'Reilly (one of the sponsors of the project) said in his postmortem of the project, "the patent mess is a thorny thicket that doesn't lend itself well to penetration by amateurs."

Apart from paying less to hunters and charging less to clients, how is IBM addressing these problems?

Can go one better: The weight of evidence is in the real world sales: http://torrentfreak.com/alchemist-author-pirates-own-books-080124/
http://toc.oreilly.com/2008/08/pirates-convince-game-develope.html
The weight of real-world evidence is in favor of the hypothesis posted above. The only anti-hypothesis you've got is 1 Pirate == 1 lost sale. *cough* Your data prove your hypothesis?*cough**cough*

I am Ashamed of you people, this is slashdot and someone here has just given us a Dorothy Dixer. (Please note this is my interpretation I'm tiny whinny bit biased) Well you see there was this Operating system called Unix that was written in the 1960's.... AT&T which was a phone company couldn't sell, due to the laws at the time, software so they allowed Unix to used by University's for a small fee. [this is probably a bit loosely based on truth here] In the 1980's the laws changed and AT&T could sell software. Well AT&T said everything to do with Unix is ours and any software that has been added to Unix by the University's is also ours and pays us Mega amounts of cash to use it. Well some people at University of California Berkeley (UCB) got very annoyed with this and released a version of UNIX without any AT&T code. This version was called BSD 4.4-lite a court battle then ensued that ran until the mid 1990's. Novell then purchased Unix from AT&T and some sort deal was done and UCB no longer distributes BSD. heres a link to the story. http://oreilly.com/catalog/opensources/book/kirkmck.html so lessons learnt 1) You will get sued 2) If you hang in there you might just win 3) Be prepared to cut a deal 4) [maybe this should have been first] Get a good lawyer !!! 5) You ever here of a guy called Richard Stallman ? - sort of the same thing happened to him but he started something called the free software foundation. http://www.fsf.org/

I liked the interview of its CEO at Web 2.0 summit. http://radar.oreilly.com/2008/11/a-conversation-with-shai-agass.html

Gahh!!! If you follow the downward spiral even more you might end up watching those movies you downloaded with rtorrent with mplayer via aalib!!!

Why not use the framebuffer output of mplayer for a real CLI experience? ;-)

Parents keep your kids away from Apple, they could be come CLI Junkies. Vista is the one true path to salvation.

Gahh!!! If you follow the downward spiral even more you might end up watching those movies you downloaded with rtorrent with mplayer via aalib!!! You might as well sell your sole to Richard Stall..erm Satan!!

heh :-P

Perhaps you should report O'Reilly to the police, as clearly you must believe they are selling a whole range of books aimed at criminals.

A lot of hackers ARE criminals, depending on your definition...

When the guys at nytimes.com and OED.com reverse the meaning of "hacker" back to its hobbyist definition, give me a call...

Who cares what the mainstream usage is? Slashdot is not a mainstream website. It is targeted at nerds, and it uses words with the meanings nerds give them. There is no ambiguity going on here. "Kernel hackers" is the correct terminology for Slashdot's target audience.

Perhaps you should report O'Reilly to the police, as clearly you must believe they are selling a whole range of books aimed at criminals.

Seriously, whenever I hear someone mention that they do iPhone development, they usually follow up with "And I don't really feel comfortable talking about it, because of the agreements Apple made me sign."

And now you can tell them that they needn't be uncomfortable any longer.

The Atmel AVR Butterfly is a $20 microcontroller on a board intended to be an introduction to AVR microcontrollers or microcontrollers in general. Low cost of entry, plenty of real world I/O (temp sensor, LCD, speaker, light sensor, ADC) and easy to program (free tool-chain, including gcc C compiler). Available from Digi-Key or Mouser online.

Illustrated Guide to Home Chemistry Experiments from O'Reilly and Make-zine. Check out the author's associate website, HomeChemLab including their small but friendly and supportive forum.

Finally, for free, teach the lessons that freedom comes with the price of responsibility, and that knowledge and understanding are powerful (physics jokes aside) tools. Also honesty and integrity, include admitting to making mistakes and being unsure are valuable currency for building a reputation that can lead to being trusted (and respected). And that it is okay to be curiosity (though sometimes some tact is also needed). -- My parent's tolerance and patience were important factors in developing my good "geekiness" qualities, so I encourage an environment that is supportive not punitive about failure (mistakes).

"Anyone who has never made a mistake has never tried anything new." - Albert Einstein

You posting as AC proves that you know not what you speak of. May I point you here: http://broadcast.oreilly.com/2008/10/how-linux-supports-more-device.html

dojo is natively supported by the Zend Framework (from version 1.6 onwards).

That may be enough on itself as a deciding factor for you... or not. Since I wanted to start with any of this Javascript libraries, the fact that ZF supported this one made my choice much easier.

Dojo documentaion is slowly getting better, but it is still sorely lacking.

O'Reilly has two other books for dojo: Mastering Dojo and The Definitive Guide.

dojo is natively supported by the Zend Framework (from version 1.6 onwards).

That may be enough on itself as a deciding factor for you... or not. Since I wanted to start with any of this Javascript libraries, the fact that ZF supported this one made my choice much easier.

Dojo documentaion is slowly getting better, but it is still sorely lacking.

O'Reilly has two other books for dojo: Mastering Dojo and The Definitive Guide.

They are rare but are designed for your exact situation. I've created one at my company. More thoughts at http://softwarecraftsmanship.oreilly.com/news/2008/7/17/comparing-apprenticeship-programs

They don't? The methodology isn't perfect, but we're not talking about calculating tolerances for a bridge or determining what hunk of tissue to excise during brain surgery here. In other words, a blunt metric is all we're looking for (and is certainly more reliable than a quote from an individual with a direct interest in promoting the language).

And it's not like there aren't corroborating sources like Google trends, Sourceforge statistics (a bit old but still relevent), book sales and so forth.

However I am looking for a good book on programming threads from an applied point of view. I am looking for one or more texts that provide thorough coverage and provide meaningful exercises. Anyone have any ideas?

I went through grad school not too long ago for Computer Science (disclaimer: it was the kind of computer science degree that doesn't focus on hardware so I might not be the best expert on this). Anyway there were two books for the class.

One dealt with coding regular old C on a plain jain Unix machine and method of (I believe there are others) doing multithreaded in that environment is PThreads (or the super short overview). The book we used is the Addison Wesley book (ISBN 0-201-63392-2). It was informative and comprehensive ... wasn't concentrated specifically on applications like you ask but very good reference. Also, I think there are a lot of good books free online in respect to that topic.

As for Java, there was an O'Reilly book (there's probably a new version out for Java 6) that was pretty good. Not as great of a reference but better on applications of threads in Java. Although, as far as introductory material, I personally learned it all from java.sun.com. Although I can't vouch for whether this is an applied approach or not, I would suggest the concurrency tutorial and a good book on Java Patterns or even a design pattern wiki.

I've never done concurrent programming in C# or Python so I do not know first hand what is best. I do know that erlang has been fun to mess around with in my spare time though!

Recently I have been incorporating them more in my solutions for clients.

Most important rule of thumb of multi-threaded programming is to avoid it if possible. Maybe hardware (multi-core) will change that, maybe you feel the scheduler can't do its job as well as you can and maybe you feel it's more intuitive. But, often is the case, that you're just adding more complexity to your code resulting in more difficult bugs and harder maintenance for others. Keep it simple.

This project was presented at the MySQL Users Conference 2008 in a dedicated talk and a keynote.

The storage will be organized in clusters based on MySQL databases.

Astronomy, Petabytes, and MySQL

The Science and Fiction of Petascale Analytics

This project was presented at the MySQL Users Conference 2008 in a dedicated talk and a keynote.

The storage will be organized in clusters based on MySQL databases.

Astronomy, Petabytes, and MySQL

The Science and Fiction of Petascale Analytics

I like this print layout soo much better!

http://broadcast.oreilly.com/print/33520.html

Taxes? Don't come the "Private is best" crap with me whilst your government is propping up failing banks.

The problem is, that the government tried to regulate the economy which in turn caused the banks to fail (along with some stupid decisions by the CEOs). Ever heard of the FDIC, Taxes and the minimum wage? All those things are things that the government put in to regulate (and thus end up ruining) the economy.

Space being classified? Not really.

In that talk, he suggested that all software developed by the Federal Government should be released to the public domain or a very, very liberal open-source license. That's not even a copyleft license. Does the American public have any access to the source code currently on the Phoenix? Are there plans to make some of the source code available? Well, no. There are no plans to make that available. And one of the issues that we have is that our spacecraft are designated as subject to international trafficking and arms regulations. So even -- Crypto regulations in exporting and such? Yeah. Yeah. I mean even though these are not military spacecraft, the technology used in them is space technology. And so the State Department does not allow us to release anything that we've done in terms of technical details to foreign scrutiny. Now, in fact as I said, we have a team of Canadians. The Canadians delivered our meteorology instruments, and we had to be very careful about our relationship with them and how much we could disclose to them.

From http://news.oreilly.com/2008/07/the-software-behind-the-mars-p.html from the /. article http://developers.slashdot.org/article.pl?sid=08/07/10/213211

I'm not so sure about the quality of random perl fragments from google searches.

I found the perlipc docs quite useful - if you're not just writing throwaway scripts you are going to have to handle signals and exceptions.

http://search.cpan.org/~rgarcia/perl-5.10.0/pod/perlipc.pod

Then there's also:
http://faq.perl.org/

Some people use the perl cookbook - http://oreilly.com/catalog/9780596003135/

So far I haven't really had need to look at that much.

O'Reilly Safari Bookshelf has been a lifesaver.
Start on one package, read up and learn about the first service, then start on the next.
A commenter further down calls them 'glorified man pages', and a man page is an excellent place to start, but O'Reilly goes far more in-depth with topics like security, concurrency, etc.
Can't recommend them enough!

. They usually run 35-50 bucks depending on topic and you'll want to page through one in a store before purchasing.

Or for 40 bucks a month, you can get the whole O'Reilly Library at:

http://safari.oreilly.com/

Well worth the money.

If you want a more hands on, how do I accomplish a specific task type approach to things, I've been very happy with the books in the O'Reilly Cookbook line. They usually run 35-50 bucks depending on topic and you'll want to page through one in a store before purchasing. All the information in the books can be found online, but they usually organize them nicely in the books. Most of the topics are 1-2 pages responding to a specific "How do I do X" type question. The Linux Networking Cookbook, bash cookbook, and Linux Cookbook and Linux Security cookbook might be a good set to start with for what you are currently playing with.

I find that I have to disagree. Paper books have advantages. But so do electronic versions.

It's not that I don't like books. I do. I have a large library of books covering various subjects. I like curling up to a good book or sitting on the back porch with an interesting book and cool drink on a lazy summer day.

But I've found myself turning to electronic books just as often as paper copies. I have electronic versions of a lot of my leisure books and, while not flawless, I find my old Zaurus a sufficient platform to read them. Paper books have the advantage of battery life and ruggedness. But my Zaurus packs a lot of books in a compact form factor, offers a night light, and auto-bookmarks.

Subject matter is also important. I find my technical books, while nice to have in my library, aren't as convenient as electronic copies. I have an assortment of animal books on my bookshelf. But I prefer the ability to search (and even copy-and-paste from) CD Bookshelf copies when working on something.

As for credibility - that's an interesting subject in itself. I find the more subjective something is, the more likely you're going to find questionable information. I haven't had much trouble with IT related sources (unless I'm getting my IT advice from gamers). But I've seen some really popular kite books that are, frankly, crap. Putting ink to paper doesn't negate the fact that their information is incorrect both factually as well as in technical detail.

When it comes to publishing information it's GIGO. The medium doesn't alter that. So if we're going to compare the merits of paper vs. pixels I'm inclined to go back to where we started - physical advantages of the medium.

Get a copy of Head First Java.

I filly agree. Head First JSP is also a great book. Also if you want to get really good at it you should read the Java Core books. You can get away with not reading them but they can teach you lots of things that are hard to learn other wise. Good for anyone really serious about learning and using Java. For a week I googled the hell out of Java Annotations. It was only when I read the chapter on them in core vol 2 that understood what the JVM did with annotations and why.

Upgrading And Repairing PCs By Scott Mueller
http://www.amazon.com/s/ref=sr_st?rs=1000&page=1&rh=i%3Astripbooks%2Cp_27%3AScott+Mueller&sort=daterank
A+, Network+, Security+ Exams in a Nutshell By Pawan K. Bhardwaj
http://oreilly.com/catalog/9780596528249/
Building the Perfect PC, Second Edition By Robert Bruce Thompson, Barbara Fritchman Thompson
http://oreilly.com/catalog/9780596526863/
Big Book of Windows Hacks By Preston Gralla
http://oreilly.com/catalog/9780596528355/

Upgrading And Repairing PCs By Scott Mueller
http://www.amazon.com/s/ref=sr_st?rs=1000&page=1&rh=i%3Astripbooks%2Cp_27%3AScott+Mueller&sort=daterank
A+, Network+, Security+ Exams in a Nutshell By Pawan K. Bhardwaj
http://oreilly.com/catalog/9780596528249/
Building the Perfect PC, Second Edition By Robert Bruce Thompson, Barbara Fritchman Thompson
http://oreilly.com/catalog/9780596526863/
Big Book of Windows Hacks By Preston Gralla
http://oreilly.com/catalog/9780596528355/

Upgrading And Repairing PCs By Scott Mueller
http://www.amazon.com/s/ref=sr_st?rs=1000&page=1&rh=i%3Astripbooks%2Cp_27%3AScott+Mueller&sort=daterank
A+, Network+, Security+ Exams in a Nutshell By Pawan K. Bhardwaj
http://oreilly.com/catalog/9780596528249/
Building the Perfect PC, Second Edition By Robert Bruce Thompson, Barbara Fritchman Thompson
http://oreilly.com/catalog/9780596526863/
Big Book of Windows Hacks By Preston Gralla
http://oreilly.com/catalog/9780596528355/

The best books for a sysadmin are O'Reilly books, hands down. http://oreilly.com/ Unix Essentials/Linux/Unix in a Nutshell, Systems Administration, BASH, IPTables, Apache, Java, MySQL, PHP, Perl, Sendmail. Thats 10 classes. You could probably cover IPTables and Perl in 9 weeks if the classes were more than once per week. You could probably throw JavaScript and Python in there too.

Talk to the people at O'Reilly, especially their Safari bookshelf. They might be able to cut you a deal for educational use.

http://oreilly.com/
http://safari.oreilly.com/?cid=orm-nav-global

Talk to the people at O'Reilly, especially their Safari bookshelf. They might be able to cut you a deal for educational use.

http://oreilly.com/
http://safari.oreilly.com/?cid=orm-nav-global

If you've done from programming before in an OO language, or even C, the book Java in a Nutshell will offer you a great transition.

The first half of the book explains syntax specifics for the language, while the second half goes through the Java APIs. The middle gives an in-depth teaching of new Java 1.5 features. It's also a great reference manual, and will give you plenty of "I totally didn't know I could do that in Java!" moments.

If you haven't programmed before, or done OO programming before, this book probably isn't for you.

I really like O'Reilly's Java in a Nutshell. Between that and Sun's online Java Tutorial and API Reference, you should be able to get a good start with the language itself.

For more "advanced" topics, there are whole books on Swing, Spring, Servlets, JSPs, EJBs, etc... each with their own encyclopedia of information -- you should definitely learn the core language first, and then decide which of these frameworks interest you, and pick one at a time to learn. Most places will hire you if you have solid Java skills, and will expect you to be able to figure out the framework.

There are many books on individual aspects of the Java language, such as Java Concurrency in Practice -- if you really want to be a Java expert. Most of those job listings you see don't require anywhere near that level of expertise, though.

My first Java book was: head first. http://oreilly.com/catalog/9780596004651/

This great if you have little experience with an object oriented language. They state that they are funny...Well sometimes they are :-).

Another way to learn java is to code a little Java mobile App. This is fun, the API is quite limited usually and so you don't need hours of documentation before seeing something nice.

The blackberry IDE was free and really nice to use back in my early days. You get the basic before heading to more serious things.

There is a free HTML version of the book here. One of the demands, for writing the book, that is was to published under a free license. It was definitely an interesting read.

PS -- since lick my asshole

Suck my balls -- I'm calling your shit and you fail it.

Our look is the result of reader comments, our own experimentation, and feedback from distribution channels. Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects. The cover of this book was designed and produced in Adobe Photoshop 5.5 and QuarkXPress 4.1 with Interstate and Sabon fonts. The cover photograph of Richard Stallman was taken by Sam Ogden/Photo Researchers Inc. The interior of the book is set in Adobe's Sabon font and was produced in FrameMaker 5.5.6. Sabon was designed by Jan Tschichold in 1964. The roman design is based on Garamond; the italic is based on typefaces created by Robert Granjon, one of Garamond's contemproaries. Sabon is a registered trademark of Linotype-Hell AG and/or its subsidiarie

While I believe it would be great for people to contribute to Free Software by buying a copy of Free as in Freedom from Amazon I would like to also point out (in a spirit that I hope RMS will appreciate) that you can read it online for free as well here.

As far as I'm concerned, pay or not, the more people that read it the better.

On usage vs distribution, from Eben Moglen's Questioning SCO paper (my highlighting with bold):

In general, users of copyrighted works do not need licenses. The Copyright
Act conveys to copyright holders certain exclusive rights in their works. So
far as software is concerned, the rights exclusively granted to the holder
are to copy, to modify or make derivative works, and to distribute. Parties
who wish to do any of the things that copyright holders are exclusively
entitled to do need permission; if they don't have permission, they're infringing.
But the Copyright Act doesn't grant the copyright holder the exclusive
right to use the work; that would vitiate the basic idea of copyright.
One doesn't need a copyright license to read the newspaper, or to listen
to recorded music; therefore you can read the newspaper over someone's
shoulder or listen to music wafting on the summer breeze even though you
haven't paid the copyright holder.

....

But don't users of free software make copies, and need a license for
that activity? The Copyright Act contains a special limitation on the exclusive
right to copy with respect to software. It does not infringe the copyright
holder's exclusive right to copy software for the purpose of executing
that software on one machine, or for purposes of maintenance or archiving.
Such copying also requires no license.

Eben has defended the freedom of usage from constraints on several occasions, so it's hard to see how anyone could gain the opposite impression. For example, in his public discussion with Tim O'Reilly he said:

"We've got to conclude that what Google does, they have a right to do in freedom. They shouldn't need anyone's permission to run programs. Stallman was right about that at the very beginning. If you have to ask other people's permission to run a program, you don't have adequate freedom.

I'm not too sure which statement of Stallman's he had in mind there, but it's certainly reflected in the FSF's general position on free use of GPL software.

And presumably this is why the FSF has phrased the GPL to be consistent with the above: the GPL doesn't limit usage whatsoever, only distribution. The GPL is not a usage license, neither by intent as expressed by the FSF ("the freedom to use the software for any purpose"), nor by legal applicability of Copyright as a constraint on use as Eben Moglen explained in the SCO paper.

If you're giving the situation of trying to deal with older code, I'd also recommend Perl Medic: Transforming Legacy Code by Peter J. Scott. It has advice for dealing with existing code of questionable quality, rather than the case of writing good code from the beginning. (in the case of dealing with existing code, I'd actually recommend it before Higher Order Perl and possibly Perl Best Practices -- I've never read the other two you mentioned, so can't gauge their relative usefulness).

Another book that might be useful is Perl Testing: A Developer's Notebook by Ian Langworth and chromatic, so that you can write better test suites to determine what you're breaking as you update the code.

http://oreilly.com/catalog/9780596526788/toc.html

Perhaps the author intended to write, "...to be very timely", realised that made no sense, but left in the aside?

I was thinking it maybe was somehow based on the chapter title, so I looked up the book, but the chapter title was "Chapter 11: Working with Dates and Times". Maybe AC above got it right with Chapter 11 meaning bankruptcy. Or something got edited out of the review?