Slashdot Mirror

chromatic writes "Imagine managing a million lines of code to send over seven hundred pounds of equipment millions of miles through space to land safely on Mars and perform dozens of experiments. You have C, 128 MB of RAM, and very few opportunities to retry if you get it wrong. O'Reilly News interviewed Peter Gluck, project software engineer for NASA's Mars Phoenix Lander, about the process of writing software and managing these constraints — and why you're unlikely to see the source code to the project any time soon."

chromatic writes "Larry Wall's State of the Onion 11 address is now online. Every year, he describes the state of Perl and its community through metaphor and analogy. This year, Larry explored the history of scripting languages, from their dimly-lit beginnings to their glorious future. Along the way, he also describes several of the design principles invoked in the design of Perl 6. 'When I was a RSTS programmer on a PDP-11, I certainly treated BASIC as a scripting language, at least in terms of rapid prototyping and process control. I'm sure it warped my brain forever. Perl's statement modifiers are straight out of BASIC/PLUS. It even had some cute sigils on the ends of its variables to distinguish string and integer from floating point. But you could do extreme programming. In fact, I had a college buddy I did pair programming with. We took a compiler writing class together and studied all that fancy stuff from the dragon book.'"

chromatic writes "Larry Wall's annual State of the Onion addresses cover subjects such chemistry, science, music, lingustics, and screensavers. They occasionally discuss Perl too. This year's, State of the Onion 10 compares raising children into productive adults to guiding the development and design of a programming language. Perl turns 19 soon; Larry says that she'll truly grow up with Perl 6."

chromatic writes "Perl.com has a new article entitled What is Perl 6?. It analyzes the changes to the language in light of the good and bad points of Perl 5 and provides new information about the current state of the project: Perl 6 exists, you can write code in it today, and it's more consistent and easier to use than Perl 5."

chromatic writes "It's hard to overestimate the influence that Babylon 5 had on American television, especially science fiction and dramas. When it debuted, it was a smaller, scrappier competitor to Paramount's revitalized Star Trek franchise. When it ended, it had proven that not only could you tell a complex, layered story over multiple years (and through the demise of syndication, yearly struggles with funding, and often frustrating and unexpected troubles with schedules and actors), but that a lean, creator-driven show could succeed artistically." Read on for chromatic's review. The Scripts of J. Michael Straczynski, Vol. 1 author J. Michael Straczynski pages 454 publisher Synthetic Worlds Publishing rating Worth reading for B5 fans and television students. reviewer chromatic ISBN none summary Notes on and scripts to the first half of Babylon 5 season 1.

Through the course of the show, its creator J. Michael Straczynski (JMS) wrote 92 of the 110 episodes filmed, including every episode of seasons three and four and all but one episode of season five-- a record-breaking achievement. Now he's publishing all of his scripts, as written, in multiple volumes from Babylon5Scripts.com.

There are plenty of books about screenwriting and many include a few examples of actual scripts (another book from JMS himself reprints the script to the Hugo-award winning second season episode "The Coming of Shadows"). Yet what other book or series of books even promises to show the development of a series from inspiration to the final frame of the final episode? What's in the book (and the forthcoming volumes) for a Babylon 5 or sci-fan, let alone someone interested in the mechanics of television?

The Scripts of J. Michael Straczynski, volume 1 includes the first five JMS-penned episodes from season one, as well as the unfilmed draft of the pilot movie "The Gathering". Each episode includes a short essay with notable information about the writing, planning, or filming of the episode. There's also a short section of photos at the end, along with seven memos from the start of the project through the filming of the pilot.

Subsequent volumes reportedly will include similar information. The second, including the remaining seven episode JMS wrote for season one, is out and shipping now. The rest will follow every few weeks. Positives

The big draw, of course, is the scripts themselves. In particular, the draft of the pilot episode, "The Gathering", has a few major changes from the filmed version. Delenn, the Minbari ambassador, is still a masculine character in this draft. Kosh, the Vorlon ambassador and victim of an assassination plot, has a lifemate travelling with him on the station. For the most part, the changes made before filming are obviously for the better. (Though cutting Kosh's lifemate was the right choice, losing a line of dialogue about one reason for the Vorlons's obvious paranoia about their biology was a pity.)

The scripts appear as written, including typos and, occasionally, vague hints to what will occur later in the series. For example, the first appearance of a First Ones ship (the Walkers at Sigma 957 in the episode "Mind War") has an explicit note that the as-yet unmentioned "Shadowmen" ship will look very different. Another suggestion during the scene of the battle with raiders recommends using real-world physics for the Starfury crafts to differentiate from other dogfights-in-space shows.

If you're interested in scriptwriting, directing, acting, or editing, comparing the script to the finished product may be very educational. Straczynski writes sparse action, leaving most of the interpretation out of the script. Of course, the episodes so far are mostly character and background pieces with comparatively few action or effects scenes needing guidance. It may be that larger battles and flashbacks have more description; it's too early to tell.

The new material is interesting, and in a few places tells stories that never actually left the set. One explains why the change of station telepath from Lyta Alexander to Talia Winters took place between the pilot and the first episode. Another expands on the trials of pitching a show to television executives, especially during the first few attempts of the late '80s. None of this is essential to enjoying the show, but it does provide background for why things in the series happened the way they did. Drawbacks

Other scripts contain scenes that never actually aired. It's not always obvious whether this was due to time constraints, edits, or other decisions. Aside from a few mentions in the episode introductions, there are no notes in the scripts themselves related to what did and didn't make it to the screen. This may not be a drawback; they're much more readable this way and serious students may want to watch and read the episodes simultaneously anyway.

Though the scripts represent the bulk of the show and the introductions and memos provide some detail, there are plenty of decisions made during filming that don't actually have explanations in the book where you might expect them. Walter Koenig's character of Bester, the Psi-Cop, has a crippled hand, yet the book doesn't mention this at all. It's difficult to know how much detail to include -- and the permissions and availability of the material may make it difficult to include (production notes? director notes?) -- but this is by no means the whole story. Keep the Lurker's Guide handy for more details.

The book itself is solid but not remarkable. The script formatting reproduces faithfully an actual shooting script in length and layout. The print quality is good.

Very picky readers may quibble about the length and weight of the book -- most of the non-script material uses whitespace a little too generously, with large top and bottom margins and more than double-spaced type allowing only around twenty lines of text on a letter-sized page. Hopefully subsequent volumes will tighten the layout somewhat. Conclusion

While it's always possible to find bootleg or transcribed scripts online or at conventions, often at vastly inflated prices, the chance to read the official versions as filmed is worth considering for serious students of film or television as well as Babylon 5 fans. The bonus materials are nice, but they're probably more interesting to fans than students; more information about the process of how a script went from the paper to film might satisfy both groups.

The quibbles are minor; if you're already a Babylon 5 fan, you know what to expect here. If you're not a fan or a screenplay geek, this isn't the place to start -- but if you find the creative processes behind television or movies fascinating, this is an easy way to soak up wisdom and hard-earned experience. It's well worth your time to compare a few episodes in script and filmed form.

chromatic's life goals include writing a novel (done), a comic book, and an episode of a television series. Then he can sleep. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

chromatic writes "It's hard to overestimate the influence that Babylon 5 had on American television, especially science fiction and dramas. When it debuted, it was a smaller, scrappier competitor to Paramount's revitalized Star Trek franchise. When it ended, it had proven that not only could you tell a complex, layered story over multiple years (and through the demise of syndication, yearly struggles with funding, and often frustrating and unexpected troubles with schedules and actors), but that a lean, creator-driven show could succeed artistically." Read on for chromatic's review. The Scripts of J. Michael Straczynski, Vol. 1 author J. Michael Straczynski pages 454 publisher Synthetic Worlds Publishing rating Worth reading for B5 fans and television students. reviewer chromatic ISBN none summary Notes on and scripts to the first half of Babylon 5 season 1.

Through the course of the show, its creator J. Michael Straczynski (JMS) wrote 92 of the 110 episodes filmed, including every episode of seasons three and four and all but one episode of season five-- a record-breaking achievement. Now he's publishing all of his scripts, as written, in multiple volumes from Babylon5Scripts.com.

There are plenty of books about screenwriting and many include a few examples of actual scripts (another book from JMS himself reprints the script to the Hugo-award winning second season episode "The Coming of Shadows"). Yet what other book or series of books even promises to show the development of a series from inspiration to the final frame of the final episode? What's in the book (and the forthcoming volumes) for a Babylon 5 or sci-fan, let alone someone interested in the mechanics of television?

The Scripts of J. Michael Straczynski, volume 1 includes the first five JMS-penned episodes from season one, as well as the unfilmed draft of the pilot movie "The Gathering". Each episode includes a short essay with notable information about the writing, planning, or filming of the episode. There's also a short section of photos at the end, along with seven memos from the start of the project through the filming of the pilot.

Subsequent volumes reportedly will include similar information. The second, including the remaining seven episode JMS wrote for season one, is out and shipping now. The rest will follow every few weeks. Positives

The big draw, of course, is the scripts themselves. In particular, the draft of the pilot episode, "The Gathering", has a few major changes from the filmed version. Delenn, the Minbari ambassador, is still a masculine character in this draft. Kosh, the Vorlon ambassador and victim of an assassination plot, has a lifemate travelling with him on the station. For the most part, the changes made before filming are obviously for the better. (Though cutting Kosh's lifemate was the right choice, losing a line of dialogue about one reason for the Vorlons's obvious paranoia about their biology was a pity.)

The scripts appear as written, including typos and, occasionally, vague hints to what will occur later in the series. For example, the first appearance of a First Ones ship (the Walkers at Sigma 957 in the episode "Mind War") has an explicit note that the as-yet unmentioned "Shadowmen" ship will look very different. Another suggestion during the scene of the battle with raiders recommends using real-world physics for the Starfury crafts to differentiate from other dogfights-in-space shows.

If you're interested in scriptwriting, directing, acting, or editing, comparing the script to the finished product may be very educational. Straczynski writes sparse action, leaving most of the interpretation out of the script. Of course, the episodes so far are mostly character and background pieces with comparatively few action or effects scenes needing guidance. It may be that larger battles and flashbacks have more description; it's too early to tell.

The new material is interesting, and in a few places tells stories that never actually left the set. One explains why the change of station telepath from Lyta Alexander to Talia Winters took place between the pilot and the first episode. Another expands on the trials of pitching a show to television executives, especially during the first few attempts of the late '80s. None of this is essential to enjoying the show, but it does provide background for why things in the series happened the way they did. Drawbacks

Other scripts contain scenes that never actually aired. It's not always obvious whether this was due to time constraints, edits, or other decisions. Aside from a few mentions in the episode introductions, there are no notes in the scripts themselves related to what did and didn't make it to the screen. This may not be a drawback; they're much more readable this way and serious students may want to watch and read the episodes simultaneously anyway.

Though the scripts represent the bulk of the show and the introductions and memos provide some detail, there are plenty of decisions made during filming that don't actually have explanations in the book where you might expect them. Walter Koenig's character of Bester, the Psi-Cop, has a crippled hand, yet the book doesn't mention this at all. It's difficult to know how much detail to include -- and the permissions and availability of the material may make it difficult to include (production notes? director notes?) -- but this is by no means the whole story. Keep the Lurker's Guide handy for more details.

The book itself is solid but not remarkable. The script formatting reproduces faithfully an actual shooting script in length and layout. The print quality is good.

Very picky readers may quibble about the length and weight of the book -- most of the non-script material uses whitespace a little too generously, with large top and bottom margins and more than double-spaced type allowing only around twenty lines of text on a letter-sized page. Hopefully subsequent volumes will tighten the layout somewhat. Conclusion

While it's always possible to find bootleg or transcribed scripts online or at conventions, often at vastly inflated prices, the chance to read the official versions as filmed is worth considering for serious students of film or television as well as Babylon 5 fans. The bonus materials are nice, but they're probably more interesting to fans than students; more information about the process of how a script went from the paper to film might satisfy both groups.

The quibbles are minor; if you're already a Babylon 5 fan, you know what to expect here. If you're not a fan or a screenplay geek, this isn't the place to start -- but if you find the creative processes behind television or movies fascinating, this is an easy way to soak up wisdom and hard-earned experience. It's well worth your time to compare a few episodes in script and filmed form.

chromatic's life goals include writing a novel (done), a comic book, and an episode of a television series. Then he can sleep. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

chromatic writes "Geoff Broadwell has written an analysis of optimizing an open source project for fun, specifically the Pugs project. Broadwell argues that making development fun and easy leads to higher quality code and a faster velocity of development, even when implementing a frivolous project (a toy Perl 6 interpreter) in an uncommon language (Haskell). The Pugs leader, Autrijus Tang, will speak about both Pugs and Haskell at EuroOSCON."

chromatic writes "Perl.com has just published Larry Wall's Ninth Annual State of the Onion address from OSCON 2005. In previous talks, he's used screensavers, music, and Unicode to explore Perl and open source. This year, he introduced the cast of characters in the Perl community in terms of spy movies and metaphors."

Slashback tonight with more on the Microsoft start page project vis-a-vis Google's similar one, a wee $40 million slap on the wrist for Amazon over shopping-cart patent infrigement, new animals for the CodeZoo, and a strong denial that WikiPedia has announced a more stringent editorial policy. Details on these stories and more, below.

What's done is done, and in a certain order. MSN.com general manager Hadi Partovi writes:

"A few days ago I read your Slashdot post about start.com.

Thank you for the promotion :-). Meanwhile, I wanted to make sure you know that the work we've been doing on the start.com project actually predates the Google personalized page. I manage a tiny incubation team that has been building start.com since November, and it was first live on the Web in February, 3 months before Google released their personalized page. Of course we are missing some capabilities that Google has, and vice versa. It's a tight competition. But I'm emailing you because our team takes a lot of pride in its innovation. You may point out at a lot of place where Microsoft is following competitors, but if you track the functionality and UI changes that the companies have made over the past 6 months, this has clearly been a place where Google has been following Microsoft's lead.

(Our main engineer on the project has written a bit more about this to respond to your post.)

Anyway, I'm not sending this to be defensive. Heck, I have a lot of work to do to bring an innovation culture to the MSN organization and in many areas we have our work cut out for us. But I guess I want my small incubation team to get credit for being the leading innovators on this one small product :-)"

Thanks for the note!

Always clean out the trashcan. dotpavan writes "The Register and Cnet have this report about Kai-Fu Lee not cleaning his recycle bin at his previous workplace and now MS has stumbled upon some interesting document, which shows that Google anticipated the MS move, and had planned top put him on a leave of absence or have him as a consultant to thwart any attempt of MS getting him back."

Amazon Settles Patent Suit For $40M theodp writes "In today's SEC filing, Amazon.com disclosed it will pay $40 million to settle an e-commerce patent infringement lawsuit that was reported earlier on Slashdot. The terms of the settlement also provide for dismissal of all claims and counterclaims and grant Amazon a nonexclusive license to Soverain's patent portfolio."

29+36 more = 65 vector drawing apps. Anonymous Coward writes "There were many useful comments made for 29 Vector Drawing Programs. After incorporating most of them, the revised column has 65 Vector Drawing Programs."

And each after its own kind. chromatic writes "As seen on the O'Reilly Radar and announced at OSCON 2005, CodeZoo now lists Python and Ruby components. CodeZoo is a human-edited directory of useful, well-maintained, and redistributable software components in various languages. (Slashdot previously covered CodeZoo's launch.)"

The chair recognizes Mr. Wales for a point of clarification. brajesh writes "There has been news on Slashdot and others about Wikipedia announcing tighter editorial control. It seems that everyone jumped the gun. Jimmy Wales, a founder of Wikipedia, has clarified his stance on the idea of freezing stable content on Wikipedia. Apparently, [Jimbo writes] 'I spoke in English, and this was translated to German. Then the German was translated back to English, and then translated again into the Slashdot story.' Also, 'There was no "announcement." We are constantly reviewing our policies and looking for ways to improve, but we have not "announced" anything. We don't even really work that way ... if you know how Wikipedia works, it's through a long process of community discussion and consensus building, not through a process of top-down announcements.' This has also been covered on Ars Technica."

Google Earth not a security risk after all. mister_tim writes "In a follow-up to yesterday's story about ANSTO's request that Google censor images of Australia's only nuclear reactor, the Australian government has now come out and said that Google Earth poses no security risk. Australia's Attorney General has come to the view, also noted by many /. readers, that the Google images have been available for several years from other sources and add nothing to the existing publicly available data. Chalk this one up as a victory for common sense."

chromatic writes "Many people recognize that the cost to duplicate a piece of software is a fraction of the number on its price tag. Many people also understand that software without support and maintenance loses much of its value. Is there a way to put a price on the software, support, maintenance, and the option for future upgrades itself? Robert Lefkowitz recently applied an options pricing model to software in ONLamp.com's Calculating the True Price of Software. Don't let the description fool you; it's both a readable and serious apologia of the common free software business model."

chromatic writes "A constant question for software developers is 'What is the nature of programming?' Is it art or science? Does creativity or engineering lead the design and implementation of a program? John Littler talked to several well-known and well-respected programmers (including Guido van Rossum, Andy Hunt, Bjarne Stroustrup, Paul Graham, and Richard Stallman) to find their answers; he shares their thoughts and his own in Art and Computer Programming." From the article: "What the heck is art anyway, at least as most people understand it? What do people mean when they say 'art'? A straw poll showed a fair degree of consensus--art is craft plus a special degree of inspiration. This pretty much explains immediately why only art students and art critics at a certain sort of paper favor conceptual art. Conceptual art, of course, often lacks a craft component as people usually understand the term."

chromatic writes "After the hoopla about OSRM's study of patent risks in the Linux kernel, I talked to Dan Ravicher, the patent attorney and free software afficionado who conducted the study. Contrary to my initial reaction, I've come to believe that the study is actually very valuable. Linux and Patent Risks on the O'Reilly Network explains why."

chromatic writes "Perl.com has just published Exegesis 7, Damian Conway's explanation of how text formatting will work Perl 6 (and now, Perl 5, thanks to his Perl6::Form module) will work. Think of it as Perl 1 for the 21st century. Also, Parrot 0.1.0, the virtual machine for Perl 6 and several other dynamic languages, released on Leap Day -- ever wanted to program in an object oriented assembly language?"

chromatic writes "O'Reilly & Associates is working with COMDEX to create an Open Source Innovation Area. We've nominated 21 important, interesting, and useful applications. Here's your chance to vote on the six most deserving applications. Steve Mallet has more details in his weblog." There's lots of good choices for applications on the list as well. Chances are that you've used one of them at least once.

chromatic writes "The O'Reilly Network has just published an interview with Paul Vixie, chairman of the board of the Internet Software Consortium and a primary author of BIND. Topics include the recent VeriSign controversy, ISC's BIND patch in response, and other potential issues that might come to light in the near future." On a related note, dmehus writes with a link to the letter sent by David Maher, chairman of the Public Interest Registry -- the .org registrar, to ICANN President and CEO Paul Twomey. "The letter says that it supports ICANN's call for VeriSign to voluntarily suspend SiteFinder and the Internet Architecture Board preliminary position paper. It goes on to say that PIR will not be implementing any DNS wildcard to the .ORG zone. It urges ICANN to stand its ground, but also to implement a policy preventing registries from taking this kind of unilateral action in the future." The letter is in .doc format, but AbiWord and OpenOffice.org both open it fine.

chromatic writes "ONLamp has just published an interview with Andrew "Bunnie" Huang, author of Hacking the Xbox. Bunnie discusses the effect of the DMCA on his work and the state of Xbox hacking as he sees it."

chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."

chromatic writes "One of the highlights of every OSCON is Larry Wall's annual State of the Onion address, covering Perl, philosophy, linguistics, music, theology, science, and usually a few other things thrown in for good measure. His talk from OSCON 2003, State of the Onion 7, is now online."

chromatic writes "Perl programmers like punctuation. Python programmers like indentation. Every programming language has its own syntax, stemming from its philosophy. What I Hate About Your Programming Language examines the issues that shape languages as they grow. It's not advocacy, I promise."

chromatic writes "It's easy to write code that works fine on single-processor systems but dies horribly on multi-processor boxes. Instead of spending thousands of dollars on a four- or eight-way system, you can use UML to emulate a multi-processor machine."

chromatic writes "Howard Wen has written two pieces on Falcon's Eye (an alternate interface for Nethack). The first is a description of Falcon's Eye and its features. The second is an interview with Jaakko Peltonen, the project's creator."

chromatic writes "Following up on an earlier story on NetBSD's fledgling Mach and Darwin binary compatibility layer, I've interviewed Emmanuel Dreyfus, who leads the project. The key questions are "what is it?", "what is it not?", and "what does it mean?""

chromatic writes "Several of the trends that make open source development possible are affecting other programming worlds. I've written an article about independent game development. Perhaps the gaming industry is ready for the craftsman-team approach."

chromatic writes "Rafael Garcia-Suarez has just penned an article about adopting Subversion for multi-user projects. (He also has a previous article on Single-User Subversion). With the recent release of Subversion 0.16 (see the File sharing link), the successor to CVS looks very good."

chromatic writes "Jerry Cooperstein has written an excellent article summarizing the features removed from the upcoming 2.6 kernel. One controversial change may be tightening restrictions on binary-only modules." And Lovechild writes with some more 2.6 news: "I recently did an inteview with famous kernel hacker extraordinare and all round nice guy Robert M. Love for Tinyminds.org, about kernel 2.6 and what can be expected for desktop Linux users, when the new kernel series is released.

chromatic writes "Dustin Puryear has written a nice article summarizing the new and upcoming features of Samba. He's included a nice overview of what will be available when version 3.0 escapes. Let's hear it for interoperability!"

chromatic writes "Jerry Cooperstein has just written an excellent article explaining the competing threading implementations in the upcoming 2.6 kernel for the O'Reilly Network."

chromatic writes "I've published an essay about building online communities on the O'Reilly Network. It pulls together several thoughts gathered from observing sites like Slashdot, Everything2, and Perl Monks."

Patrick writes "The transcript of the oral arguments in Eldred v. Ashcroft is now online." Such exciting lines as: "CHIEF JUSTICE REHNQUIST: Well, but you want more than that. You want the right to copy verbatim other people's books, don't you?". See previous stories about the oral arguments and Lessig's thoughts on them. chromatic writes "The O'Reilly Network has just published Richard Koman's Lessons from the Internet Bookmobile about his travels with Brewster Kahle to Eldred v. Ashcroft. I particularly like how he describes the universal positive reception."

chromatic writes with the review below of Writing Perl Modules for CPAN, which explains at a level "between novice and intermediate user" (and in a minimum of space) how to contribute to Perl's own Library of Alexandria. Writing Perl Modules for CPAN author Sam Tregar pages 288 publisher Apress rating Recommended. reviewer chromatic ISBN 159059018X summary A guide to the use and production of Perl modules, from start to finish, in C and in Perl. The Scoop

Besides Perl's abilities as a rapid development language, it's widely believed that the CPAN is its most valuable feature. This network of freely distributable code allows competent developers to achieve great heights of productivity, reusing the work of a generous community of programmers.

Of course, just as some will argue that Perl's copious documentation (spread over two thousand pages) is not immediately obvious to beginners, neither is how to use and even to contribute to the CPAN. For every coder who's successfully published a module, how many more would jump at the chance? How many registered CPAN authors would like to improve their skills?

With that audience in mind, Sam Tregar's Writing Perl Modules for CPAN plants itself firmly in the gap between novice and intermediate user. While much of the book presents information present in a multitude of FAQs, manpages, and the bittersweet experiences of those of us who did things the hard way, he's collected much knowledge into a short and readable guide.

What's to Like?

Tregar starts by describing the history and usage of the CPAN itself. This includes the three most popular approaches to building modules: through the CPAN shell (including its configuration), by hand, and with ActiveState's PPM tool. Next, he explains module development in forty pages. This is pretty dense stuff for the intended audience and might require several passes by newer coders. Only after re-reviewing the chapter for this summary did I realize how much he covered. The next chapter covers design and style, from naming schemes to appropriate laziness through code reuse. It's more philosophical and more important.

The next two chapters cover bundling and submitting modules to the CPAN, as well as being a good author and maintainer. The general tone is quite similar to the impressive Open Source Development with CVS. While manpages usually describe the mechanics of making a distribution, for example, they rarely explain the reasons why things are done that way. As with previous chapters, several code examples illustrate the concepts under discussion.

After a brief chapter discussing a few very effective CPAN modules, Tregar dives into XS (the interface between Perl and C). In 60 pages, he describes just enough of XS and the Perl API to teach careful programmers how to be effective at extending Perl. This introduction compares favorably to the first few chapters of the new (and excellent) Extending and Embedding Perl. As expected in an overview, he provides links to more information. The writing and example style is clear enough that a decent coder with sufficient C knowledge should be able to write a Perl wrapper to a C library with relative ease.

The last two chapters describe Inline::C, an abstraction layer that makes XS much easier, and CGI::ApplicationC, a state machine framework for Perl CGI applications. It's not quite clear why the last chapter was included (besides Tregar's desire to see more CPAN modules extending CGI::Application), but it serves as an example of using and extending a CPAN module. Perhaps a future version of the book will elaborate further.

What's to Consider

The book's code samples are generally good. In the first half, they are all related parts of a larger project. The rest of the book moves away from this approach. Perhaps it would have been worthwhile to continue the theme, though the nature of the material makes it difficult to see exactly how to accomplish this.

Tregar also avoids the use of strictures and warnings in his code examples, claiming that they would make the examples too verbose. I disagree with the given reasoning -- teaching is the best time to enforce good habits, especially when encouraging the students to distribute their code to the world. This is a minor issue, though, as the code is readable and reasonable.

In the past few months, two projects have gained a great deal of momentum in Perl space. These are the CPANPLUS (disclaimer: I am contributing to this project and have contributed to CPAN.pm) and Module::Build. They may become the new standards, replacing CPAN.pm and MakeMaker as early as Perl 5.10. The book omits mention of these. This is understandable, given the time frame -- and the current tools will not be disappearing any time soon. Potential replacements for h2xs are described in a sidebar, though.

The Summary

This is a readable book. It took only a couple of hours to read (though I'm assuredly not the target audience), and is well packed with good advice. Fresher Perl programmers who aren't yet comfortable enough with packages and interfaces will get the most benefit, but there's plenty of information for intermediate hackers as well.

Table of Contents

1. CPAN
2. Perl Module Basics
3. Module Design and Implementation
4. CPAN Module Distribution
5. Submitting Your Module to CPAN
6. Module Maintenance
7. Great CPAN Modules
8. Programming Perl in C
9. Writing C Modules with XS
10. Writing C Modules with Inline::C
11. CGI Application Modules for CPAN

You can purchase Writing Perl Modules for CPAN from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

chromatic asks: "I've been working with promising prospective programmers for a while. They're interested in college, but as non-traditional students with young families, the financial burdens are overwhelming. We're aware of FAFSA, financial aid officers, and standard grants (all of which have a bias toward traditional students). What other resources (grants, work study programs, low interest loans) should we explore?"

lisam writes: "The Wiki plugin integrates nicely with Slash and has a lot of cool features, says Chromatic who introduces Wikis and gives a detailed explanation of how and why the Wiki plugin works in this OnLamp article. (chromatic is coauthor of O'Reilly's upcoming Running Weblogs with Slash.)" A lot of people just think of Slashdot style sites when thinking of the Slash codebase, but this article goes on about how to extend slash in cool ways. If you are interested in plugins, the repository is a good place to start.

chromatic writes: "Larry Wall's latest explanation of Perl 6 features, Apocalypse 4 has been posted on Perl.com. That means Damian Conway's explanatory Exegesis can't be far behind. Looks like some nice simplifications this time around."

Compulsive reviewer chromatic takes a break this time from the ultra-serious by reviewing a kids' book to help fill the need for reading material aimed at kids which don't treat them as idiots. It also sounds like good reading for post-kids, in the same way that Dr. Seuss is. The Space Child's Mother Goose author Frederick Winsor pages 100 publisher Purple House Press rating 9 reviewer chromatic ISBN 1-930-900-07-4 summary Rhymes and verse for budding (or budded) cosmologists and scientists.

The Scoop

In the mid-fifties, a poetry and science fiction fan teamed up with a pen illustrator to produce The Space Child's Mother Goose. Decades later, enough people still remember this book fondly that existing copies sold for up to $150 apiece. Purple House Press, a small Texas publisher, continues to reprint influential books from that era. Their reprint of this classic doggerel (in the best sense of the word) will appeal to children of the 50s through the 00s.

What's to Like?

This is a clever, fun book. Instead of making up alien names, or substituting "robot" for characters in traditional nursery rhymes, the scientific concepts are integral to the poems themselves. Consider this excerpt:

Three jolly sailors from Blaydon-on-Tyne
They went to sea in a bottle by Klein.
Since the sea was entirely inside the hull
The scenery seen was exceedingly dull.

Fortunately, the glossary in the back has (brief) explanations of some of the weightier terms. Combined with a good encyclopedia, there's nothing here an inquisitive eight-year-old couldn't decipher.

Winsor pays tribute to the classics, postulating how the king's men could have saved Humpty Dumpty with a time machine, or waxing eloquent about the theory Jack built. There's a general air of... excitement, maybe, surrounding the book. (Something else reminds me of Kit Williams' Masquerade riddle, though I can't put my finger on it.)

The illustrations nicely complement the text. The simple, anthropomorphic birdmen seem oddly familiar, like undamned Bosch characters. They're appropriately Spartan, though with plenty of important details. The gestalt evokes the feel of an old Tom Swift novel. Maybe it's the matter of fact, "let's fly to the moonbase in our rocket car" post-Sputnik optimism.

This is a fine book for children, and adults with child-like spirits. It might stir a latent interest in astronomy or mathematics. Even if it doesn't, the new and interesting words and witty rhymes are worth memorizing. This book's been due a reprint for several years.

Be sure to catch the recurring poem about a chronologically gifted black hen. It's reprinted in French, German, Greek, Swahili, and Chinese, with pictures to match.

What's to Consider

Some kids might not like the book -- it takes a certain kind of mindset to absorb new concepts normally reserved for middle-school geometry class. It's hard to resist trying it out, though. Find an elementary school-aged friend or relative and spend an hour working through the riddles.

The Summary

Hemos recommended this book as "cute." It is. It's not cute in a saccharine way. It's almost as if the author were reciting his poems to a straight-laced Nobel committee -- before turning backstage to give the rest of us a great big wink. He's hoodwinked the establishment.

You can purchase this book at Fatbrain.

chromatic writes "On the heels of Larry's most recent revelation, the mad scientist of Perl (Damian Conway) has followed up with Exegesis 3. His article gives working Perl 6 code examples of Larry's design decisions." Lots of good stuff in here.

Chromatic slipped this review under our door. You need a few laughs at this point in the summer (ok, Northern hemisphere residents at least) to distract you from the heat of summer and the cost of air conditioning, and Joy of Linux has some esoteric geek humor in store, even if it's intended mostly as a mostly serious field guide to Linux nerddom for amateur anthropologists, like parents, girlfriends and bosses.

Joy of Linux author Michael Hall, Brian Proffitt pages 340 publisher Prima Tech rating 8 reviewer chromatic ISBN 0-7615-3151-3 summary A witty introduction to the wild world of Linux, suitable for the friend, relative, or significant other of a devoted geek.

The Scoop It's 2001. Do you love your operating system?

That's a silly question for the average user -- a computer's made to do stuff. The operating system hides in the background, usually dormant, sometimes hostile. Besides Solitaire at lunch, the best thing about a computer is turning it off and going home for the day. Of course, to an unrepentant Amiga, Mac, OS/2, *BSD, BeOS, or Linux fan, the question makes perfect sense. An OS has personality and history. They collect followers who put up with quirks and kinks, defending their platform even past the point of practical death.

The Joy of Linux explores this phenomenon as it relates to Linux and Open Source. It's written in a friendly, easy-reading manner, punctuated with Joy of Tech style cartoons (from Nitrozac and Snaggy). There's just enough information to teach your mother something and just enough sly innuendo to keep your brother reading. Aimed at potential and new users, die-hard penguinistas will find chuckles but few surprises.

What's to Like? Joy begins with detailed but readable looks at the allure of Linux, the history of Unix, and the growing popularity and commercial rollercoasters of Open Source in recent years. Next, the text explores the question, "What do I do now?", distilling hard experience into suggestions for finding help. More than a list of newsgroups and websites, chapter two explains the concept of sweat equity and promotes self-reliance. Chapter three talks about FUD -- both pro and contra Linux. It's fair and reasonable, with potshots reserved for the shrill faddish fanboys who spend more time complaining than contributing.

Tackling delicate topics, the next two chapters shy away from few controversies. First come three perpetual flamewars: vi versus Emacs, GNOME versus KDE, and the distribution wars. The honest assessments will disappoint everyone hovering over carefully crafted flames, ready to e-mail the authors. (That's probably a good thing, for the rest of us.) Chapter five explores the seeming juxtaposition of women and technology, with three case studies (Linux Chix, WITT, and Helix Code).

The book's second half pushes the innuendos further. Several serious discussions lie couched in metaphors and double entendres. These chapters cover system security, dual booting, migrating from Windows to Linux, hardware support, embedded devices, gaming, and multimedia. Aimed slightly above a novice level, this should be accessible to anyone capable of installing Linux.

The authors pepper their prose with personal anecdotes, some related to Linux and computers, others as analogies. They both write with a single voice, so it's difficult to tell where Hall breaks off and Proffitt starts. It makes for a mostly seamless narrative. The text is also readable, written with genial humor and occasional subtle winks.

What's to Consider? This is a book for Linux newcomers. If you can compile a kernel without having to look up directions, you may enjoy this book, but it's not aimed at you. Instead, it would serve well as a companion piece to something more technical. If 'Running Linux' is your manual, this is the cultural and philosophical guide.

Some of the cartoons require a little more insider knowledge than the rest of the book. For example, if you don't recognize aliens dressed up as maddog, ESR, Larry Wall, and Linus, you won't understand the comic on page 34. Consider that incentive to read conference speaker lists, if you dare.

The Summary Clever, but not too clever, The Joy of Linux answers two questions: "What is this Linux thing?" and "Why do you like it?" Written for home users more interested in getting things done than salivating over new hardware, it's a good introduction to a confusing, vibrant culture. If you're in the mood for a light read to amuses and inform, this book will meet that need. Table of Contents

1. Do You Know Who Your Millions of Partners Are?
2. 1. The Penguin on Top
   2. Are You Experienced?
   3. I Don't Do Windows
   4. Kissing Cousins, Lovers' Quarrels
   5. Chix Who Don't Fake It
3. Doin' It
4. 1. I'm Clean! I Swear!
   2. Switch Hitters
   3. The Joy of Toys
   4. You Want to Put That Where?
   5. Messing around: The Penguin Plays Games
   6. Loud and Graphic
   7. Breaking up Is Hard to Do
   8. The Linux Sutra: Resources
5. GNU GENERAL PUBLIC LICENSE

You can purchase this book at Fatbrain.

Chromatic has done it again, with his tripartite review below -- this time, he presents a trio of books designed for easy digestion. They won't teach you to program in obscure languages, how to track down (and hopefully garrote) abusive kiddies, or make better looking web sites. But hopefully, these three books from the pens of Ian McDonald, Peter Abrams and Bill Holbrook (and all from the network-aware Plan 9 publishing house) will still lighten your day.

Three Books From Plan 9 author (Various) pages (Var publisher Plan 9 Publishing rating 8.5 reviewer chromatic ISBN (Various) summary Online comics come to real life as books; unlikely scenarios that work to loosen the old laughter mucus.

Plan Nine Publishing has done a wonderful thing for the online comic. Founded in 1996, they've helped to legitimize the medium. Dedicated (and new!) fans can now purchase printed collections of their favorite comics, bringing financial stability to a new generation of artist. The books themselves are lovingly designed, if one step below mass-market professional. Never underestimate the bandwidth of a hundred pages (and several months) of art.

Bruno Most Wanted author Ian McDonald pages 168 ISBN 1-929462-22-0 summary Witty, episodic satire about Rothland's most notorious criminal.

Ian McDonald's Bruno the Bandit chronicles the misadventures of an increasingly inept thief and his micro-dragon sidekick. In this second collection of daily strips, the appropriately named Bunkleyutz tangles with everyone from the Imperial Guard to an undead, mostly evil sorcerer turned bartender. Despite (or because of) Bruno's mind-numbing incompetence, he's always a sympathetic character.

McDonald is an extremely talented artist. His detailed drawings convey a good blend of action and humor, his gags land true, and somehow everything looks easy. Logically, the comic is naturally divided into smaller stories, generally between two and seven weeks long. This gives McDonald a chance to explore an episodic format.

Bruno doesn't shy away from controversy. This collection includes McDonald's edgiest story ever, "No Offense!" It's a sympathetic look at faith, religion, and television. Other topics include unionization, syndication, the forbidden topic, fame and publicity, and raising children. (It makes more sense in stories.) A special bonus color story of Bruno's youth rounds things out.

Lavishly illustrated and wittily plotted, Bruno Most Wanted is a clever and thought provoking collection.

Yippy Skippy, the Evil! author Pete Abrams pages 154 ISBN 1-929462-23-9 summary Aliens, vampires, robots, assassins, demons, rabbits, magic, Evil, and college students.

Pete Abrams' Sluggy Freelance continues to break new ground creatively. A simple description could not do it justice -- Abrams weaves bizarre threads into twisted patterns. What kind of evil lurks in the heart of an ordinary kitten? Attempting to unravel things even further without delving into the entire twisted history is probably NP-hard. At heart, it's a simple tale about a freelance web designer and his lovable pet bunny. Think Calvin and Hobbes meets Aliens meets Red Dwarf.

Yippy Skippy, The Evil, the fifth Sluggy Freelance, picks up with a chilling tale of Y2K disaster. Ferret-spread nanobots threaten the world, and only a rogue vampire and time traveling scientist can fix things. From there, a love spell goes wrong, leading to mishaps involving a killer robot gymnast assassin and a shotgun wedding. After a brief detour explaining half of the title (and setting events in motion for the next book), Abrams raises the question, "What happens when your alien secretary eats too many potatoes?"

What follows is a fun-filled attempt to escape an enraged rabbit. (Baywatch hath charms to soothe the savage breast. No pun intended.) From there, Adams tries his hand at mostly-straightforward horror. "The Evil" tracks the adventures of several college students on vacation in a small town. Unbeknownst to them, the devil has been there already. Who will survive? What do you serve his spawn?

Admittedly, this kind of humor is not for everyone. It can be alarmingly irreverent, and the body count is surprisingly high for not being graphic. It's terribly creative, though, and Abrams continues to tell a fine story. Book 5 may not be the best place to start, but Yippy Skippy, The Evil has the potential to recruit a new army of Sluggites.

For the Birds author Bill Holbrook pages 142 ISBN 1-929462-18-2 summary Divorced herbivore + widowed carnivore = nature's truest blended family.

The unbelievably prolific (cyborg?) Bill Holbrook writes three (cyborg!) regular strips. For the Birds is his ninth Plan 9 collection, and the fifth featuring his Kevin and Kell strips. The deceptively simple artwork and matter-of-fact tranquility belie the harsh rule of nature. (Where else would a parent's biggest dilemma be whether to raise a baby hybrid rabbit/wolf to eat meat or not?)

Through the anthropomorphism, Holbrook pokes fun at modern, geeky subjects. Where else would a hunter track prey by waiting for their cell phones to ring? The gags don't get in the way of a sweet story, though. At heart, Kevin and Kell is a gentle story punctuated with several surprises. Holbrook has created a rich world with interesting characters.

The book explores several themes, including family, responsibility, and love. Though nature can be brutal, the world is full of good "people". Holbrook examines ideas of prejudice (domesticated versus wild species, love between predator and prey) but never comes across as preachy. Throughout the several storylines, he always finds time to insert a chuckle or two. (Who else but a chameleon would stoop to typo-squatting?)

After five books, there's plenty of backstory, but the characters are compelling and the humor gentle. For The Birds should appeal to a wide audience looking for something a little more compelling than the daily comics but a little tamer than the Slugfest.

You can't currently purchase Yippy Skippy, the Evil or For the Birds and Bruno Most Wanted at Fatbrain, but you may be able to special order from there or some other vendor.

Systems administrators -- good system administrators -- are worth their weight in coffee beans weekly, probably more if you count overtime. Getting to be a competent admin for a network of GNU/Linux machines isn't easy, especially when so many organizations rely on Windows. Today, chromatic reviews a book that can give a boost to Windows administrators learning to step up. It's definitely Red Hat-centric, right down to the title, but may be useful even if you're using some other flavor of Linux.

Red Hat Linux System Adminstration Handbook author Mark F. Komarinsky & Cary Collett pages 405 publisher Prentice Hall rating 8 reviewer chromatic ISBN 0-13-025395-2 summary A good introduction to Linux, aimed at power users and current Windows administrators.

The Scoop In a bookcase-breaking extravaganza last summer, Slashdot reviewed several books intended for new Linux users. While the kernel, Free Software and Open Source applications, and distributions often undergo periods of rapid change and improvement, the basic principles of use and administration remain constant.

On those lines, Red Hat Linux System Adminstration Handbook is a solid book. Though it specifically discusses Red Hat, most of the information can be applied to other distributions. It strikes a unique balance between the needs of an end user and an administrator. Additionally, the authors go out of their way to explore proprietary and libre software for certain needs.

What's to Like The book imparts a good sense of flexibility. In just a few pages, the RPM chapter enumerates several installation options, covers SRPMs in decent detail, and lists helper applications to simplify life. Many of the other chapters are similarly dense. This doesn't detract from the book's readability, and it covers most of the common details. Readers will learn the necessary basics while being made aware of extra information available. This is also evident in the Networking chapter. While focusing on medium-sized networks, there's enough data provided to get a few boxes up and running with little fuss. The backup chapter is excellent, and so is the chapter on Samba.

This book covers several details often omitted from other books. For example, the installation chapter discusses dual booting with both FreeBSD and Windows NT. Another section outlines PAM (Pluggable Authentication Modules, used to configure finer-grained access). Even the chapters on sendmail and wu-ftpd talk about more secure alternatives, such as qmail, BeroFPT, and ProFTPD.

It's hard to quantify what makes a good system administrator. Part of it is wisdom and experience, part is natural talent. Another component develops with time. Tucked into corners here and there, the authors provide useful nuggets designed to spark intuition in a budding junior administrator's mind. This is very subtle, but there's definitely an underlying theme.

What's to Consider

The book covers Red Hat 6.0. Only a few spots have gone out of date with recent releases. For example, the kernel configuration and hardware support information describes the 2.2.x family. As well, packet filtering and masquerading use ipfwadm and ipchains, instead of iptables (available in the 2.4.x family). Most configuration and administration advice still applies.

Some chapters are short. Linux handles printing much differently from Windows, but it receives only 7 pages. The material is good, if skimpy. (Luckily, the Samba chapter fills in some blanks.) Adding more links to sources of additional information would improve this. On the whole, this is a workable reference book, but it won't replace a Nutshell handbook.

Summary and Table of Contents On the whole, the Handbook packs in a lot of data. Administrators already familiar with Windows will get the most from the book. It will require some sense of exploration and adventure, but that's one of the most compelling parts of free software.

Bundled with a CD-ROM, this book forms part of a Training course. It includes several demonstration videos and animations accompanied by audio. Each course corresponds to a book chapter (minus the chapters describing available software or the programming languages) along with practice tests. Easily installed, everything runs in a web browser under Linux or Windows. It won't substitute for a live teacher, but corresponds nicely with the text. This could come in handy for a small business or group on a budget.

1. Introduction
2. Installation
3. Linux Boot and Shutdown
4. Account Administration
5. RPM
6. Networking with Linux
7. Printing and Print Sharing
8. Samba
9. Email
10. Setting up FTP Services
11. Applications for Linux
12. Linux Database Software
13. Programming Languages
14. Web Serving
15. X Windowing System
16. Securing Linux
17. Kernel Administration
18. System and Network Monitoring
19. Backing Up Your Data
20. Talking to Your Peripherals
21. Connecting to the Internet

1. Appendix A (URLs)
2. Appendix B (miscellaneous)

You can purchase this book at Fatbrain. Note: Also available with audio/video CD and tests in The Complete Red Hat Linux Training Course , available as ISBN 0-13-088223-2.

For those inundated with data -- numbers, names, dates, temperatures, colors, seismographic sensor output, voting records(!), or anything else -- the paltry concerns of user interface may be less important than the assurance that they can make something useful from all that stuff. Data munger extraordinaire chromatic has again delivered his insightful dissection of a programming book aimed at people with Perl knowledge and a lot of data to wade through, and No, it's not from O'Reilly. Maybe it's for you.

Data Munging with Perl author David Cross pages 283 publisher Manning Publications rating 9 reviewer chromatic ISBN 1-930110-00-6 summary Dave explores Perl's unique and compelling abilities tomanage and manipulate data of all types, sizes, and shades.

The Scoop Larry Wall, so goes the story, needed to glue together two systems on opposite sides of the country. Calling on the virtues of Laziness (why throw together something for just one job) and Hubris (why not write a new language?), he created Perl. Though it's found new niches in the post-web world, Perl earns its bread and butter munging data.

Dave Cross has put together a friendly and handy compendium of techniques, tricks, and best practices. Suitable for raw novices to experienced intermediates, Data Munging with Perl is a gentle but firm romp from flat text, past structured and binary files, to the realm of custom parsers. Clean examples and lots of modules accompany the explanations.

What's to Like? The book plots a natural course through topics ordered by complexity. It opens with a theoretical overview of data processing. This introduces terminology and outlines the general types of data one might encounger. Additionally, the author writes with the authority of experience when exploring the basic approaches and best practices. While other books aimed at novice users shy away from programs-as-filters and data structures, Cross prefers to instill good habits from the start.

Beyond munging data, the book provides a decent introduction to idiomatic and effective Perl programming. While the brief tutorial won't magically produce new JAPHs, the thoughtful and continual devotion to good technique and skill will inspire smarter programmers. More important than knowing many useful tricks is knowing when and how to use a handful of tools -- and where to go for more.

The overall level of quality is excellent. The binary data chapter stands out as the clearest explanation available, and the information on munging dates and times will save readers plenty of grief. Additionally, the entire parsing section introduces a handful of powerful but sorely-underused tools to handle HTML, XML, and even creating custom parsers. Rounding out the curriculum is an appendix that explores the larger modules, mentioned earlier, in more detail (XML::Parser, DBI, Date::Manip).

What's to Consider? Only two things might turn readers from this book. The first is its deceptive length. While the text is short, the examples are clear and the text packs a lot of wallop in what's there. Careful readers who follow the links to other resources will have little trouble supplementing their education. (On the other hand, another ten pages describing Parse::RecDescent would have been a nice addition. It's hard to fault the author for deferring to the module's voluminous documentation.)

Second, longtime Perl programmers may find little new material, particularly if they are familiar with the wealth of modules on the CPAN. The intended audience is clearly new and underexperienced programmers. While there's plenty of good advice presented well, the book falls more toward the tutorial side of the aisle than the reference section. This does not detract from the book, but it does narrow the base of potential readers slightly.

The SummaryManning Publications continues its fine line of Perl books with the consistent and powerful Data Munging with Perl. Coders looking to transform data somehow and hackers who want to take advantage of Perl's unique features will improve their knowledge and understanding. If you find yourself working with files or records in Perl, this book will save you time and trouble. Table of Contents

1. Introduction
2. 1. Data, data munging, and Perl
   2. General practices to use when munging data
   3. Generally useful Perl idioms
   4. Pattern matching
3. Data Munging
4. 1. Unstructured data
   2. Record-oriented data
   3. Fixed-width & binary data
5. Simple Data Parsing
6. 1. More complex data formats
   2. HTML
   3. XML
   4. Building your own parsers
7. Conclusion
8. 1. Looking back -- and ahead
   1. Modules reference
   2. Essential Perl

You can purchase this book at ThinkGeek.

While Ruby isn't new, it's one scripting-and-everything else language which has yet to break out (in the U.S. at least) the way Perl and Python have. Chromatic may help buck that non-trend -- he says that Ruby is one polished gem of a language, and below he introduces a book on Ruby that he compares in importance with the O'Reilly Camel book.

Programming Ruby author David Thomasand Andrew Hunt pages 564 publisher Addison-Wesley rating 9 reviewer chromatic ISBN 0-201-71089-7 summary A no-nonsense, clear guide that's as clean and usable as Ruby itself.

The Scoop Ruby is a growing language that combines the power and conciseness of Perl with the Smalltalk object model. Though popular in Japan, it hasn't reached its potential in English speaking countries, lacking appropriate documentation. Enter Dave Thomas and Andy Hunt. On the heels of The Pragmatic Programmer, they've produced the Ruby equivalent of Perl's Camel. What's to Like? Programming Ruby starts with a general language overview. A dozen short and sweet chapters form this tutorial. Readers with no programming background won't feel too out of place, though they will need to be comfortable with terminology explained once and used throughout the rest of the book. Topics range from language basics to multithreading and using the debugger. Rather than starting from syntax rules, the authors introduce concepts as their context dictates. There is some conceptual overlap between chapters, but this approach is preferable to discussing one topic at a time, referring briefly to future chapters.

The next section shows how to connect Ruby to other languages and tools. Besides information on Ruby modules and the command line, chapters include CGI programming, Ruby GUI programming with Tk, and automating Windows. The chapter on embedding Ruby in C is short but comprehensive. Within the 200 pages of these two sections, experienced programmers will have learned enough Ruby to be quite productive.

Section three expands further on the core language. Though covering the same areas as the tutorial, these chapters delve into the gory details. (As gory as Ruby gets, which is to say, surprisingly little spit and bailing wire.) Thomas and Hunt write with the authority of language designers producing a standard reference. Chapter 19, Classes and Objects, particularly stands out. It describes Ruby's simple object model, using a handful of well-chosen examples and clean diagrams to punctuate the point.

The final section takes up nearly half of the book. This library reference lists Ruby's built-in and common classes and objects. Each class has a description, a named parent, and a list of mixins and class and instance methods where appropriate. Modules fare similarly. Most explanations include common usage examples.

Four appendices and an impressive index round things out.

What's to Consider? Ruby itself makes a fine starting language. To get the most benefit from the book, it's handy to have experience with OO programming and a similar scripting language. (Python and Perl hackers will have little trouble, Smalltalk coders will feel right at home, and Java and C++ fans will do well.) Beginning programmers won't have their hands held for very long.

A handful of advanced concepts are mentioned but not explained. This is only a minor gripe -- techniques like runtime code generation are beyond the scope of the average hacker's needs. The flexibility of Ruby's object model and the loose distinction between compile-time and run-time obviate the need for much of this trickery anyhow.

Some might find the class reference section slightly hard on the eyes. The repeated horizontal lines are visually distracting -- indentation would improve readability. On the positive side, the class, library, and module sections are arranged alphabetically, with a tabbed margins to improve navigation.

The Summary This attractive tome ought to be on the desk of any serious Ruby programmer -- and Ruby itself deserves consideration as a clean and powerful development language. Aimed at moderately experienced programmers, Programming Ruby is a great introduction and a handy reference. Read it online here! Table of Contents

1. Roadmap

1. Facets of Ruby
2. 1. Ruby.New
   2. Classes, Objects, and Variables
   3. Containers, Blocks, and Iterators
   4. Standard Types
   5. More About Methods
   6. Expressions
   7. Exceptions, Catch, and Throw
   8. Modules
   9. Basic Input and Output
   10. Threads and Processes
   11. When Trouble Starts
3. Ruby in Its Setting
4. 1. Ruby and Its World
   2. Ruby and the Web
   3. Ruby Tk
   4. Ruby and Microsoft Windows
   5. Extending Ruby
5. Ruby Crystallized
6. 1. The Ruby Language
   2. Classes and Objects
   3. Locking Ruby in the Safe
   4. Reflection, ObjectSpace, and Distributed Ruby
7. Ruby Library Reference
8. 1. Built-in Classes
   2. Built-in Modules
   3. Standard Library
   4. Object-Oriented Design Libraries
   5. Network and Web Libraries
   6. Microsoft Windows Support
9. Appendices
10. 1. Embedded Documentation
    2. Interactive Ruby Shell
    3. Support
    4. Bibliography

Besides reading online, you can purchase this book at ThinkGeek

However skeptical the ads make you, it's hard to deny that what used to be considered supercomputing power keeps showing up in consumer-priced boxes, and the threshold of what really is extreme has crept steadily upward. If you're planning a project of more than average size, though, the review that chromatic contributed below of Planning Extreme Programming could be a valuable read, and the ideas in the book itself could save you a lot of money and time. Even if you have no plans to desire to install a beowulf in your broomcloset, it's interesting to consider what sort of thought must go into any large-scale programming project.

Planning Extreme Programming author Kent Beck & Martin Fowler pages 139 publisher Addison-Wesley rating 9 reviewer chromatic ISBN 0-210-71091-9 summary Guidelines, anecdotes, and tested techniques to plan and track your Extreme Programming projects.

The Scoop Last year's Extreme Programming Explained argued that all of the good activities of software engineering (planning, designing, testing, refactoring, estimating, reviewing, and releasing) ought to be done all the time. Dividing the technical and management tasks, forcing each group to work to its strengths, the technique has gathered several proponents. Until now, there's been no general presentation of the HOW of XP, suitable for management and customers.

Planning Extreme Programming covers the practice of XP, the techniques other groups have used while applying its principles. Data and anecdotes from XP practitioners contribute to this collection of lessons.

What's to Like? The book fits the XP philosophy handily, with short, simple chapters hitting a single point apiece. This is a book suitable for busy managers (weaned on slide presentations) and customers (who don't want to learn any more about programming than necessary). Without the support of both, projects will fail. An afternoon invested reading this thin tome will pay off handsomely, whether or not you use XP.

It's hard to pin down the main emphasis in the face of the gestalt. The strongest lesson relates a simple driving anecdote. Reaching your destination requires a successful combination of small steps and course corrections. You can't just point the car at Boston and accelerate. Back out of the garage first. Ready, fire, aim aim aim aim aim.

Instead, the authors suggest breaking a project into self-contained, testable components (stories). The customer creates the stories. The programmers estimate the time it will take to complete each. The customer selects the stories for the next iteration (period of time between release dates, generally three to six weeks). The programmers write their tests, write their code, ask the customer to postpone a story instead of slipping a release date. Finally, the customer runs the test and selects the stories for the next iteration.

It's a powerful concept, and just might work. The text examines each step of the process, with a consistently simple emphasis on the big picture. Of particular note are the sections on estimates (you can do as much work as you did in the last iteration) and the role of customers. The big benefit of XP is that it minimizes risk over the long term by producing working software as soon as possible, continually revising the overall plan with fresh data.

What's to Consider? This book really assumes readers already have some understanding of the part they play in Extreme Programming. (One might argue that there's no reason to read this book without having read Beck's first XP book.) The more open-minded in the audience may jump right in, while the cautious and practical will want proof to go with the manifesto. Invest in reading this and Extreme Programming Explained.

Related to the previous point, XP is not free of jargon itself. Readers unfamiliar with the role of 'stories' or the duties of the customer will have some difficulty with the first few chapters. A short glossary of terms and duties would alleviate this.

A criticism of Extreme Programming Explained also applies here -- there's still too little data about which projects and software types fit XP best. This book does present some criteria: projects running on Internet time, outsourced projects, and projects with medium-sized teams (six to twelve developers) are possible candidates. Only experience and more data can provide hard answers.

The Summary More practical and less controversial than its predecessor, Planning Extreme Programming makes the XP manifesto workable. Better for people already sold on the practice, the book is also appropriate for people considering Extreme Programming, whether programmer, manager, or customer. Improve software quality and your quality of life by embracing change. Table of Contents

1. Why Plan?
2. Fear
3. Driving Software
4. Balancing Power
5. Overviews
6. Too Much to Do
7. Four Variables
8. Yesterday's Weather
9. Scoping a Project
10. Release Planning
11. Writing Stories
12. Estimation
13. Ordering the Stories
14. Release Planning Events
15. The First Plan
16. Release Planning Variations
17. Iteration Planning
18. Iteration Planning Meeting
19. Tracking an Iteration
20. Stand-up Meetings
21. Visible Graphs
22. Dealing with Bugs
23. Changes to the Team
24. Tools
25. Business Contracts
26. Red Flags
27. Your Own Process

You can purchase this book at ThinkGeek.

Years after the virtues of XML were first extolled (and plenty of uses both front-and-center and behind-the-scenes later), XML still isn't the do-all, be-all wonder we were led to believe. Book reviewing genius chromatic here dissects a book that sounds aimed at intermediate or advanced programmers (of other languages) who want extend their grasp with a greater understanding of the flexibility inherent to XML. How well it succeeds? Well, see what he's got to say about that.

Inside XML author Steven Holzner pages 1102 publisher New Riders rating 7 reviewer chromatic ISBN 0-7357-1020-1 summary A detailed but uneven treatment of XML and related topics.

The Scoop People love it, but XML won't save the world. If properly applied, it will improve the transfer of information between different individuals, platforms, and programs. A language that describes languages, XML in the real world has spawned hundreds of applications. In Inside XML, Steven Holzner attempts to make sense of the basic principles and more popular implementations as things stand right now. What's to Like? Holzner's caught platform independence fever, and he imparts a healthy sense of respect for W3C standards to his readers. While the current state of XML handling, especially in web browsers, is mediocre at best, he varies platforms when possible. Though most examples use IE on Windows, the author occasionally examines offerings from Mozilla and IBM.

The book's strength is describing a technology. The first five chapters explore XML's essential concepts, including DTDs and schemas, in as good an explanation as you'll find anywhere. Later chapters cover XSL (used to format and to transform documents), XHTML (the successor to HTML), CSS (governing the presentation of XML and XHTML documents) and RDF and CDF (to describe available resources) in sufficient detail. The explanations here are good, with accurate information and plenty of examples.

Java programmers will appreciate the extended descriptions of the DOM and SAX parsing styles. Though the examples themselves are in Java, most concepts translate fairly well to other languages. JavaScript also gets some attention, mostly in the confines of IE5.

What's to Consider? Though the cover blurb claims otherwise, most programming examples use Java. Perl earns a brief 13-page treatment, while ASP and Java Servlets share just eight pages in the same chapter. Exotic languages like C and C++ are conspicuously absent. A detailed description of the DOM and SAX approaches would benefit everyone, not just Java hackers.

This massive tome could have stood another round of editing. Many examples run up to a page and a half in length when only two to four lines have changed from the previous listing. Other material is arguably filler, such as four and a half pages of JavaScript events supported in IE, or fifteen pages detailing XML DOM objects and associated methods before giving a single example of DOM usage. The publisher could have cut between 100 and 200 pages, instead adding footnotes to authoritative sites.

Worse yet, the book's organization is questionable. After describing the basics of XML, it veers off into a 50-page JavaScript tutorial. Java soon suffers the same fate. These chapters break the flow of subjects, use no XML in their examples, and should be appendices. (They're decent, as far as tutorials go. They just don't belong in the middle of the book.) Readers will have difficulty finding useful reference material mixed in with tutorials.

English majors will also find Holzner's transitions awkward. Logical sections often conclude with a phrase such as "Now I will talk about the topic named in the heading immediately following this sentence." XML is not a serial radio cliffhanger, and most readers can find their way down the page by themselves. It occurs often enough to be distracting.

The Summary Besides the reservations above, most of the information is solid and usable. Inside XML is at its best when describing technologies instead of how to work with them. Uneven presentation hinders (not hobbles) the book, making it a better introduction than a definitive guide. Though falling short of its claims, cautious readers will learn plenty. Table of Contents

1. Essential XML
2. Creating Well-Formed XML Documents
3. Valid XML Documents: Creating Document Type Definitions
4. DTDs: Entities and Attributes
5. Creating XML Schemas
6. Understanding JavaScript
7. Handling XML Documents with JavaScript
8. XML and Data Binding
9. Cascading Style Sheets
10. Understanding Java
11. Java and the XML DOM
12. Java and SAX
13. XSL Transformations
14. XSL Formatting Objects
15. XLinks and XPointers
16. Essential XHTML
17. XHTML at Work
18. Resource Description Framework and Channel Definition Format
19. Vector Markup Language
20. WML, ASP, JSP, Servlets, and Perl

1. The XML 1.0 Specification

You can purchase this book at FatBrain.

Much has happened in the world, some of it even worth reading about. For instance ... More on BIND and where it's headed regarding openness, licensing and other things; an update on Protozilla, and what is undoubtably not the final word on Linuxgruven, SAIR and company.

Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!

The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"

Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:

I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).

Let it not be said that Bugtraq is a controlled substance.

Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.

Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."

Continuing with his campaign to rid the world of lousy software, chromatic is back with this review of Extreme Programming Installed. It sounds like what the authors are advocating is a truly programmer-centric environment; does anyone have experience in a workplace even close to this?

Extreme Programming Installed author Ron Jeffries, Ann Anderson, Chet Hendrickson pages 244 publisher Addison-Wesley rating 8.75 reviewer chromatic ISBN 0-201-70842-6 summary How to implement Extreme Programming, with strategies,examples, and practical advice. More interesting than it sounds.

The Scoop Last year's Extreme Programming Explained was a manifesto of sorts. Wouldn't it be nice if customers, management, and programmers could work together to produce good software on schedule and under budget? If planning, peer review, testing, and design are good, why not do them all the time? It even put forth the radical notion that customers should set business value while programmers create -- and revise -- technical schedules.

Yet another 'silver bullet' Fred Brooks debunked years ago? The authors of Extreme Programming Installed disagree. The book breaks XP into workable chunks, hanging flesh on the bones of Kent Beck's manifesto. It explains each element of XP in turn, based on the authors' personal and collective experiences.

For example, the Iteration Planning chapter describes planning meetings. The customer presents stories, the developers break the stories into tasks, and individual programmers estimate and sign up for tasks. Each element has further detail on best practices and potential traps. Finally, the chapter describes an average meeting.

What's to Like? As with other titles in the series, the text is clear and easy to read. The short chapters have no fluff, saying only what's needed. Concise explanations and a gentle, conversational tone add up to a book that can be finished in an afternoon.

This book is the most practical of the series so far. Drawing on personal experiences and data gleaned from early adopters, the authors distill XP practices into their purest and most essential forms. Anecdotes from programmers in the trenches line the pages. Though everyone practices the processes slightly differently, a clear picture begins to emerge.

Though listed in the table of contents as "bonus tracks," the last 11 chapters may prove the most valuable. Each track addresses a common concern or criticism of XP, from "Who do you blame when something goes wrong?" to "How do you write unit tests for a GUI?" and "You can't possibly make accurate estimates." This won't satisfy all the nay-sayers, but it adds a healthy dose of reality.

What's to Consider? The testing and refactoring sections, needing the most explanation, have a strong Smalltalk bias. While these chapters have strong supporting text, a decent programmer unfamiliar with the language will have to invest extra time to understand the examples fully. This is the most detailed portion of the book, and may be the hardest to read.

While some readers may like the open-ended nature of the presented techniques, others, familiar with more formal development processes, will want authoritative proclamations. XP actually installed, argue the authors, depends on the nature of the task and the team. The controversial axiom of embracing change by continually performing a certain few practices while discarding the rest, will raise some blood pressures. Clearly, this is not for the faint of heart.

Developers and managers interested in the whys of XP would do well to read Extreme Programming Explained instead. Though the authors present a brief business case for the process, most of the text assumes the reader has already decided to install it. Customers receive more text (a few chapters), though there's clearly room for an expanded treatment of their roles and responsibilities.

The Summary Extreme Programming Installed will not silence the critics, but it makes great progress in showing how XP can work, in the right places. Beyond that, it demonstrates the flexibility of the approach, with numerous real-world examples. This book deserves a place next to Beck's manifesto, showing off XP as it's actually practiced. Table of Contents

1. Extreme Programming
2. The Circle of Life
3. On-Site Customer
4. User Stories
5. Acceptance Tests
6. Story Estimation
7. Small Releases
8. Customer Defines Release
9. Iteration Planning
10. Quick Design Session
11. Programming
12. Pair Programming
13. Unit Tests
14. Test First, by Intention
15. Releasing Changes
16. Do or Do Not
17. Experience Improves Estimates
18. Resources, Scope, Quality, Time
19. Steering
20. Steering the Iteration
21. Steering the Release
22. Handling Defects
23. Conclusion

Bonus Tracks

1. We'll Try
2. How to Estimate Anything
3. Infrastructure
4. It's Chet's Fault
5. Balancing Hopes and Fears
6. Testing Improves Code
7. XPer Tries Java
8. A Java Perspective
9. A True Story
10. Estimates and Promises
11. Everything That Could Possibly Break

You can Purchase this book at ThinkGeek.

That much software sucks -- perhaps most of it -- is hard to dispute. Except for the simplest programs, it seems like the price of complexity is a tendency to failure. Commands don't work, user interfaces are neglected to the point of ruin, and components of even the same piece of software often clash with each other. And once you start combining them and try to use more than one application at once, sometimes the best you can hope for is an operating system that neatly segregates the problems so that your word processor doesn't take down your web browser, your IDE or your e-mail client. At least those are desktop applications for individual users, though -- the trouble compounds briskly when the common faults of software manifest in multiuser environments, where one machine going down means a wasted time and frustration for a lot of people at once. In an effort to outline the ways that software could suck less is coding, reading and writing dervish chromatic.

Making Software Suck Less - Processes Once upon a time, a prominent writer and programmer rose to declare "I want software that doesn't suck!" He then explained that certain successful free software projects have similar development features that contribute to software quality. Most of us aren't gifted with the organizational clarity of a Linus, or the brilliant non-orthogonal design of a Larry.

There's hope, though. Improving the ways in which we produce software can dramatically improve the software itself. Extreme Programming suggests that simple habits, acting in concert, produce extremely powerful results. By adapting these techniques to the unique world of free software, we can improve the quality of our programs. We start by restating some common truths about free software development.

Distributed Development Open development, of course, means that anyone with the time and the inclination can look at the code. Developers and dabblers have the opportunity to modify it to their needs. This by no means guarantees that anyone will do so. Making source code available is no silver bullet. Many qualified eyes actively looking for bugs make bugs shallow.

To harness the power of additional developers, you must attract them to the project. A simple design and clear documentation reduce the amount of work needed to come to grips with the system. XP suggests an overall metaphor to describe the system as a whole and to provide good names for the components and subsystems.

Test First The most powerful weapon in your toolbox is comprehensive unit testing. (Unit tests are automated, independent procedures that exercise the smallest possible pieces of functionality individually.) Extreme Programming recommends a test-first approach. Before adding a new feature, the programmer writes a test for the feature and runs all the unit tests. The new test fails, so he writes code to pass the test. When all tests pass, the feature can be checked in. Tests cover everything that could possibly break.

When a bug appears, the programmer writes tests to demonstrate it. After fixing the bug in the code, he runs all tests again. This not only proves that the fix corrects the defect, but it proves that the correction did not break any other features. Besides that, it can prompt the programmer to write additional tests he had not previously considered.

Test-first programming ensures that all features have unit tests. Coders receive immediate feedback -- it's almost like a game. It produces a different mindset, freeing the programmer to concentrate solely on the task at hand. Code becomes easier to write, in the same way that finding the correct piece for a jigsaw puzzle is easier with its neighbors in place. Finally, it gives programmers the confidence to refactor, modifying existing code, by identifying the effects of a change.

Consider providing your test suite with the project. Add a 'test' or 'check' target to the Makefile. Projects designed to run on multiple platforms and distributions can generate better bug reports by including test results. Make it easy for users to report failures.

Simple Solutions First After writing a test, write the simplest possible code that could pass it. Resist the tendency to make things more flexible than you need at the moment. Concentrate only on the task at hand, programming only what you need to pass the test. Don't sacrifice current elegance and simplicity for a feature months down the road.

"It's true that 'simple and tested code means less bugs'.... Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs."
-- Linus Torvalds

Good tests free you to change things in the future by identifying the effects of a change. Simple code localizes changes, reducing interconnections. Besides that, your design will change. Adding a feature will take the same amount of time whether you do it now or in the future. Don't spend time and energy overgeneralizing for something six months away when no one will use it in the meantime. Reduce the need for costly and time-consuming rewrites by avoiding extraneous complexity. Have a Plan, Code For Your Users Write a plan for the software. Describe each feature in a paragraph or less, with sufficient detail that people will know when it is complete. Arrange the stories by importance, then tackle them in that order. This allows you to identify the work that will provide the most value to the customer. (In a free software project, the lead developers may be the customers.)

Dividing the project into stories allows delegation, especially in free software projects. Some tasks require an experienced hacker, while others serve as a gentle introduction to the program. Writing stories also provides sane goals and a project roadmap. Choose a few stories for each release. This gives end users a clear view of project progress.

Continuous Design, Refactor With tests in place, you have the freedom to refine your initial design. By using the simplest solution first, you avoid investing time in hard to follow and difficult to maintain code. Your initial design will change. Your plan will change. Expect this and allow it to happen.

"Premature optimization-including premature low-level design--is the root of all evil."
-- Michael Abrash

When you see an opportunity to refactor, do it! Eliminate duplicate code. Relocate common features into a new object or a function. Reduce complexity and interconnections. Don't maintain the same functionality in multiple places. Use simple, well-defined, and consistent interfaces. This, along with your test suite, will allow you to overhaul individual pieces without having to track down holes in far-flung files. Release Often, Release Working Features Commit to regular release dates. This shortens the feedback loop. Users who can count on regular, stable releases with valuable new features will be more likely to use the software. It also provides more frequent entry points for new developers.

Follow your plan to add a few important features to each release. Focus programmer time and effort towards a simple, reachable goal. Allow time for design, testing, documenting, and packaging. The more often you have to do this, the more likely you are to streamline these processes. Resist the urge to add features you cannot complete in time. Instead, break them up into smaller stories and implement the most important parts. As usual, the unit tests help to stabilize the codebase and keep it in a state of stability. After completing a release, take time to modify your stories, shuffling priorities as necessary. Then commit to the next release.

Conclusion If we truly want excellent software, with well-developed features and no messy surprises, we need more discipline in our approach to creating software. In my experiences with these techniques (and in talking to other developers), I have found that even simply migrating to a test-first approach, though painful, has increased my productivity and my confidence. It's scary at times, but immensely satisfying. Taken together, who knows what levels of excellence we can reach?

Another chromatic review, this time of Disappearing Cryptography. It is a fortunate circumstance that even as governments -- and others -- are becoming more interested in peering over your shoulder, or at least at your data traffic, the exchange of large files suitable for hiding messages has become commonplace. Peter Wayner is also the author of Free For All , reviewed here on Slashdot a few months back.

Disappearing Cryptography author Peter Wayner pages 293 publisher AP Professional rating 7.5 reviewer chromatic ISBN 0-12-73867108 summary A study of steganography, making secret informationinvisible to prying eyes. A suitable, though dated, introduction.

The Scoop Cryptography, argues the author, has the potential to balance power relationships between individuals and governments. Forcing people to conduct all communications in publicly-readable forms allows the honest to be oppressed by tyrants, criminals, and pranksters. Why should the innocent suffer to help authories track stupid criminals?

Wayner mainly concentrates on steganography, hiding secret communications in plain sight. Instead of using ciphers and algorithms to generate a message mathematically indistinguishable from pure random noise, one might instead replace the lowest significant bits of a JPG image with the message. Only those who analyze the image may potentially reconstruct the text.

What's to Like? Each chapter has three sections, arranged by increasing complexity. The first contains a short anecdote to illustrate the point of the chapter. (Some make immediate sense, while others seem only tangentially related.) The second section discusses the theory. The final section gets into the guts, mathematics and algorithms, analysis and common problems. This division allows readers to go only as deeply as they prefer.

Early sections on information theory lay the framework for later chapters. While discussions of error correction and density don't have the cloak and dagger thrill of spy stuff, they're fundamental to serious analysis of techniques. Serious students would do well to use Wayner's extensive and excellent bibliography of books and papers to improve their knowledge.

The middle of the book is excellent. A lengthy discussion of text mimicry starts with analysis techniques, producing in a program hiding a secret message in an innocent-seeming baseball play-by-play. (It includes a dissertation on effective and reversible context-free grammars.) The next chapter, on Turing machines and reversable computing, is particularly interesting (especially after reading The Diamond Age).

More than just data hiding, the final section of the text covers privacy. Anonymous remailers can provide double-blind communication (but see the caveat below). The Dining Cryptographers algorithm of chapter 11 may be used to send a secret message without divulging the sender's identity. The final chapter adds a philosophical spin, explaining the author's biases and his reasoning for promoting secrecy. (He's Cypherpunk friendly.)

What's to Consider? This is not a book for beginners. Some of the initial theory throws around summations and other pre-calculus constructs as an integral (pardon the pun) explanation of entropy. One of the two large examples is written in Pascal. A second year computer science student should have no trouble understanding the text. A layman might not get past the second chapter (though he could safely skip most of the math.)

This book is also dated -- in fact, Hemos recommended it for review partly to prompt the author and publisher to produce a new version. The anonymous remailer chapter is seriously out of date, and it would be nice to have new information about distributed.net, secure peer-to-peer communications, and web stuff. In addition, some of the softwares described have been superceded by new versions and successors.

The Summary Aging but written with the future in the mind, Disappearing Cryptography favors theory and principles, for the most part. It makes a good introduction to steganography and the study of patterns in digital communications, leading naturally to more detailed works. It may also serve as a starting point to new ideas and discussions. Perhaps 2001 will bring us a new version. Table of Contents

1. Framing Information
2. Encryption
3. Error Correction
4. Secret Sharing
5. Compression
6. Basic Mimicry
7. Grammars and Mimicry
8. Turing and Reverse
9. Life in the Noise
10. Anonymous Remailers
11. Secret Broadcasts
12. Coda

1. Mimic Code
2. Baseball CFG
3. Reversable Grammar Generator

You can purchase this book at Fatbrain.

chromatic writes: "Looks like a company called TransGaming Technologies has been improving DirectX support in Wine. They plan to use a modified Street Performer Protocol to make money, and will eventually relicense their patches under the Wine license. Maybe I'll finally be able to run Thief!" And maybe one day Xbill will run on Windows.

Chromatic, indefatigueable, has come up with another review. This time through the door he's gathered his reactions to Perl for System Administrators, one of the growing list of titles to help bridge the gap between SysAdmin and programmer.

Perl for System Administrators author David N. Blank-Edelman pages 430 publisher O'Reilly and Associates rating 9 reviewer chromatic ISBN 1-56592-609-9 summary A royal buffet of ideas to stimulate system administrators

The Scoop Despite being what some call 'the purest distillation of Unix thought,' Perl has earned a place on many Windows and Macintosh machines for its power and flexibility. Unix administrators have developed and honed small scripts for decades, but their brethren elsewhere have had no such luck until recently. Enter ActiveState, IndigoPerl, and MacPerl, to provide the tools, this book the knowledge. Floating subtle suggestions between pragmatic tips and tricks, David N. Blank-Edelman weaves nets, strong and sophisticated, for the perpetual battle against encroaching entropy. What's to Like? Anything that saves a beleagured sysadmin time is very good. Any one chapter read in isolation will yield at least one new idiom, if not many ideas on improving efficiency and accuracy. The central theme of the book ('make things better by using a database to store all of your information') is an excellent and timely idea. It's not essential to the presented examples, but has the potential to simplify your work dramatically. Besides maintaining a central repository for usernames, accounts, network information, and passwords, it allows automated configuration file building. Imagine never hand-editing DNS records again, or having to enter user data only once.

The sample code is clean and understandable, taking full advantage of many CPAN modules. When competing modules exist, Blank-Edelman demonstrates each, with an eye to advantages and disadvantages. This pragmatic analysis governs other discussions, especially concerning cross-platform and Pure Perl versus glue-code isses. Realizing that most networks combine many different clients (Unix flavors, the Windows cousins, and Apple machines), the author provides solutions to the same problem on all applicable platforms.

Though pushing the envelope on certain technologies (at the expense of others), the Appendices provide adequate introduction. The LDAP and SNMP sections stand out in particular. The author provides enough background, whether on Active Directory, TCP packet construction, or e-mail headers, to flesh out his examples. A table at the end of each chapter lists all modules covered, authors and versions, CPAN ids, and alternate download sites. In addition, the book provides many links to further information on techniques, RFCs, references, and vendors. If you're left wondering where to go to learn more, it will be your own fault.

What's to Consider? The book assumes a working knowledge of Perl. Anyone who's made it through 'Learning Perl' or 'Elements of Programming With Perl' should have no trouble -- complex idioms and module peculiarities receive sufficient explanation. Beware, though, that the sample code does not enable warnings or run under strict mode. (Production programs need error checking, which, the author explains, could easily double the size of his examples.)

Not all sections apply to all OSs. The Macintosh, for example, has no concept of multiple users (OS X not being covered). These differences could hinder the text, but are clearly marked and can be skipped with no ill effects. Besides, few networks are homogenous, and astute readers will learn more about the system in general from the similarities and differences.

Some common administrative tasks have been left out in favor of emerging or more complex technologies. There's nothing on managing printers or backups. A sysadmin of reasonable experience who makes it through the book will have gained a proper mental framework to tackle other tasks, though.

The Summary Perl for System Administrators is packed with useful tips, making the most of Perl's ecological niche. Whether you're a junior administrator venturing out into the wild world for the first time, or a seasoned BOFH, you'll find something to digest here. You might even get some free time out of it. Table of Contents

1. Introduction
2. Filesystems
3. User Accounts
4. User Activity
5. TCP/IP Name Services
6. Directory Services
7. SQL Database Administration
8. Electronic Mail
9. Log Files
10. Security and Network Monitoring

1. The Five-Minute RCS Tutorial
2. The Ten-Minute LDAP Tutorial
3. The Eight-Minute XML Tutorial
4. The Fifteen-Minute SQL Tutorial
5. The Twenty-Minute SNMP Tutorial

You can purchase this book at ThinkGeek.

Sure, you know that Netcraft tests have for a while provided empirical evidence of Apache's usefulness and ubiquity. But if you're called upon to use Apache in your workplace (or if you care to serve pages for fun off your home box), you might need more to go on. Chromatic took some busy time out of his life to write this review of Administering Apache, which he says takes a "calculated, strategic approach" to what has become one of the world's most important pieces of software.

Administering Apache author Mark Arnold, Jeff Almeida, & Clint Miller pages 513 publisher McGraw Hill rating 8 reviewer chromatic ISBN 0-07-212291-9 summary This task-oriented guide presents a comprehensive overview of Apache's features, suitable for the small homepage provider and the huge virtual-domain farm.

The Scoop It's hard to know where to begin using something as powerful and flexible as Apache. Serving basic pages is easy, but how do you keep track of visitors? How do you provide unique and appropriate content? What happens when you need more than just a static server?

Adminstering Apache takes a calculated, strategic approach. Dedicating the first chapter to the needs of various entities (corporation, small business, large ISP, small ISP), it discusses the Apache features that will come into play. While the book can be read from start to finish as a tutorial, following one of the roadmaps is the quickest way to get things up and running.

What's to Like? People who love details will appreciate many sections, like the comprehensive configuration information. The book passes the usefulness test, having served as an authoritative reference on multiple occasions. For example, the installing/compiling chapter has an excellent list of modules and configuration suggestions that came in handy with a recent project. (The index alone fills 19 full pages of two-column, small print text.)

Instead of grouping all of the possible httpd.conf directives in one section, the authors cover them by topic. Localisation information can be found in the content chapter, while logging directives live in chapter 5. This division of information fits the topical philosophy, increasing the work's reference value.

While by no means essential data or a comprehensive reference, the chapter on creating new Apache modules was very interesting. The authors write a sample module in C to implement a new MIME type handler. The program's evolution and refinement demonstrates Apache's design and API, as well as good module programming practices.

The scope of the book covers more than just Apache. Aside from obvious topics of security and networking issues, the text includes firewall and proxy information, pages of related Internet sites, and even sample bash scripts to create new homepage users and directories for ISPs. Other sections discuss HTTP and CGI from protocol and implementation standpoints. (Besides, any other book dedicated to Apache business use that doesn't have a section on paid referrer logs is incomplete.)

What's to Consider? As with Apache itself, there is a strong Unix flavor to the text. The single Windows NT chapter is only five pages long, focusing on a few important differences from the Unix version. The other chapters are reasonably cross-platform (though most of the CGI examples are shell scripts, not Perl or PHP).

While a definitive guide would easily double the size of the book, precious little space covers common modules. Besides brief descriptions of distributed modules, the only real discussion involves mod_ssl, though a few have links provided. Also, the book concentrates on Apache in a commercial environment. Perhaps the corporate intranet server best approximates the single-user, small-site setup common for developers' personal pages.

From a writing standpoint, some sections are best left as references. The authors deserve sympathy for writing two pages describing log format string substitutions -- let alone testing and editing them. Though filled, in places, with almost too much information, the writing never becomes muddied. Still, you won't stay awake nights reading some chapters.

The Summary While not the most exciting book to grace your shelf, Administering Apache is a detailed and useful guide to the Apache web server. More than an introduction, it will be a good reference, not just for the mechanics of the software, but for the technique and mindset necessary to maintain an installation in a business environment. Table of Contents

1. Planning Ahead
2. Creating the Web Server
3. Creating the Web Site
4. Manipulating Content
5. Using Logs
6. Securing the Server, the Content, and the Connection
7. Creating Homepage Web Sites
8. Creating Virtual Domain Web Sites
9. Proxying with Apache
10. Troubleshooting
11. Using Apache on Windows NT
12. Programming the Apache Server

Appendix

You can purchase this book at Fatbrain.

Chronic reviewer chromatic writes again, this time with a review of the newest iteration of what is probably the emblematic Perl book, the O'Reilly camel book. Read on to see how it stacks up to earlier versions of that work, and whether your Perl skills would benefit from reading through it.

Programming Perl (third edition) author Larry Wall, Tom Christiansen, & Jon Orwant pages 1067 publisher O'Reilly & Associates rating 9.5 reviewer chromatic ISBN 0-596-0027-8 summary The definitive guide to the Perl language, updated for 5.6.1.

The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.

Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.

While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.

What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.

The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.

The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.

Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.

What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.

The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.

The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)

The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents

1. Overview
2. 1. An Overview of Perl
3. The Gory Details
4. 1. Bits and Pieces
   2. Unary and Binary Operators
   3. Statements and Declarations
   4. Pattern Matching
   5. Subroutines
   6. Formats
   7. References
   8. Data Structures
   9. Packages
   10. Modules
   11. Objects
   12. Overloading
   13. Tied Variables
5. Perl as Technology
6. 1. Unicode
   2. Interprocess Communication
   3. Threads
   4. Compiling
   5. The Command-Line Interface
   6. The Perl Debugger
   7. Internals and Externals
7. Perl as Culture
8. 1. CPAN
   2. Security
   3. Common Practices
   4. Portable Perl
   5. Plain Old Documentation
   6. Perl Culture
9. Reference Material
10. 1. Special Names
    2. Functions
    3. The Standard Perl Library
    4. Pragmatic Modules
    5. Standard Modules
    6. Diagnostic Messages
    
    Glossary
    Index

You can purchase this book at ThinkGeek.