Slashdot Mirror

prostoalex writes "Jeffrey E. F. Friedl, author of newly published 2nd edition of Mastering Regular Expressions, wrote a feature article for O'Reilly Network on the recent innovations in the regular expression world. You'd think that such area as regular expressions would be fairly stable, but according to the author, 'when I started to work on the second edition of Mastering Regular Expressions and started refocusing on the field, I was rather shocked to find out how much had really changed'. The article's behind-the-scene purpose is apparently to push a new book that O'Reilly published this month, but it has great educational value for anyone involved with practical extracting and reporting."

caseywest writes "For those of you attending the Open Source Conference, there is a golden opportunity to get some free coaching and consultation on your work. A Birds-of-a-Feather session on "Perl Mentoring/Code Reviews" will be given for the third year running. Some of the top Perl People will be on hand as resident experts to advise you on your own Perl projects. This is *one-on-one* coaching: No spectators, no audience, no distractions; just the kind of personal mentoring, targeted to your specific application, from some of the best people qualified to give it. We encorage other communities to hold mentoring sessions, you still have time to register your BOF, email me if you want to make it happen and need advice. "

Here's how it works: You bring some Perl code (ideally at most 3 pages, as a printout, or on a laptop, handheld, or floppy) and receive specific advice which would normally cost a large amount of money in consulting fees. Feel free to ask for advice on anything from style to improving efficiency.

Time spent with the expert will depend on supply and demand.

Date: Thursday 7/25
Time: 7:00pm - 9:00pm
Location: Grande Ballroom A in the East Tower"

caseywest writes "For those of you attending the Open Source Conference, there is a golden opportunity to get some free coaching and consultation on your work. A Birds-of-a-Feather session on "Perl Mentoring/Code Reviews" will be given for the third year running. Some of the top Perl People will be on hand as resident experts to advise you on your own Perl projects. This is *one-on-one* coaching: No spectators, no audience, no distractions; just the kind of personal mentoring, targeted to your specific application, from some of the best people qualified to give it. We encorage other communities to hold mentoring sessions, you still have time to register your BOF, email me if you want to make it happen and need advice. "

Here's how it works: You bring some Perl code (ideally at most 3 pages, as a printout, or on a laptop, handheld, or floppy) and receive specific advice which would normally cost a large amount of money in consulting fees. Feel free to ask for advice on anything from style to improving efficiency.

Time spent with the expert will depend on supply and demand.

Date: Thursday 7/25
Time: 7:00pm - 9:00pm
Location: Grande Ballroom A in the East Tower"

caseywest writes "For those of you attending the Open Source Conference, there is a golden opportunity to get some free coaching and consultation on your work. A Birds-of-a-Feather session on "Perl Mentoring/Code Reviews" will be given for the third year running. Some of the top Perl People will be on hand as resident experts to advise you on your own Perl projects. This is *one-on-one* coaching: No spectators, no audience, no distractions; just the kind of personal mentoring, targeted to your specific application, from some of the best people qualified to give it. We encorage other communities to hold mentoring sessions, you still have time to register your BOF, email me if you want to make it happen and need advice. "

Here's how it works: You bring some Perl code (ideally at most 3 pages, as a printout, or on a laptop, handheld, or floppy) and receive specific advice which would normally cost a large amount of money in consulting fees. Feel free to ask for advice on anything from style to improving efficiency.

Time spent with the expert will depend on supply and demand.

Date: Thursday 7/25
Time: 7:00pm - 9:00pm
Location: Grande Ballroom A in the East Tower"

simonstl writes "Three unnamed W3C participants have suggested a new RAND policy that would let the W3C into the business of charging royalties for patent-encumbered specs. No consensus yet, but they sure seem to keep trying."

Lisa writes "I don't know if you've seen Julian (SuperSnail) Cash's amazing photos from last year's O'Reilly Open Source Convention , but they are worth checking out." Julian also took some pictures of the 2000 OSCON too. We figured since OSCON 2002 is almost upon us that this would be a fun thing to post.

Idmat writes "Tim's latest opus, "The Strange Case of the Disappearing Open Source Vendors," starts with Sherlock Holmes ruminating on "the curious incident of the dog in the night-time" and winds up explaining why open source is good for businesses even if it isn't always good for software vendors."

elucidus writes "Matt Jones has put out a PDF and EPS outlining symbols to use in Warchalking the WLAN nodes of your community. Here's a pic. Ben Hammersly dubs them Hobo Runes." Brings to mind pictures of scruffy individuals around a fire with picturebooks, taking a pull from some ripple while reading slashdot.

bjepson writes: "Shaun Bangay of the Rhodes University Computer Science Department has released a port of Rotor for Linux. You can find more details, including a download, at the O'Reilly Network."

bjepson writes: "Shaun Bangay of the Rhodes University Computer Science Department has released a port of Rotor for Linux. You can find more details, including a download, at the O'Reilly Network."

Lisam writes "Jon Udell, in a fascinating column titled "Seeing and Tuning Social Networks", writes: "New forms of social software are one of the most hopeful green shoots erupting from a still-bleak technology landscape." Software is catching up with what we know about social networks: the greater the reach of your array, the more effective an actor you can be within an organization.In this column, Jon talks with two observers about software that maps social networks and their patterns..."

prostoalex writes "In his weblog on O'Reilly Network Gordon Mohr suggests the ultimate solution for the music and movie industry to plug that analog hole. The solution, of course, is a helmet with built-in Digital Rights Management system that would automatically "fog up" any time you lay your eyes on something that you haven't bought license for."

_aargh writes "This ZDNet article by John Carroll makes the claim that open source is flawed because there isn't a way for programmers to earn money by developing open source software. It annoyed me so much that I wrote this response to it on the O'Reilly Network."

gnat writes "The IT Director for Weta Digital, Peter Jackson's company doing the digital effects for the Lord of the Rings movies, is keynoting at the O'Reilly Open Source Convention. They use a ton of Linux and Perl." FWIW I believe Hemos and I are speaking too, but I'm much more interested in seeing this LotR thing.

mpawlo writes "Creative Commons just opened to the public. From the initial statement: "We are building a Web-based application for dedicating copyrighted works to the "public domain," and for generating flexible, generous licenses that permit copying and creative reuses of copyrighted works." Read also the article in the New York Times." There's also an older story that summarizes the concept behind the site, although I think their FAQ's do a pretty good job. A page at the Berkman Center documents some of the development of the project (although it doesn't render properly in konqueror for whatever reason). rbeattie describes it like so: "At O'Reilly's ongoing Emerging Technology Conference today, Creative Commons gave a presentation about their new service, an "easy way for people (like scholars, musicians, filmmakers, and authors--from world-renowned professionals to garage-based amateurs) to announce that their works are available for copying, modification, and redistribution." They've provided an online wizard where you can choose the type of license and restrictions you want to put on your work, and then they'll provide a circled CC logo you can put on your website with links to the license. In addition they are providing search functionality for those looking for public domain content - the license is provided in "machine readable form" (read: XML probably) so that it can be easily indexed/searched."

tadghin writes ""Under the current regulatory regime, 802.11 would never have been legalized." Andy Oram reports this comment by David Reed in his summary of a wireless policy BOF session at the O'Reilly Emerging Technology conference. Andy discusses some of the hidden regulatory threats to wireless networking and what we might do about them, as well as many of the other sessions he attended, in a conference report on Wednesday's sessions."

tadghin writes ""Under the current regulatory regime, 802.11 would never have been legalized." Andy Oram reports this comment by David Reed in his summary of a wireless policy BOF session at the O'Reilly Emerging Technology conference. Andy discusses some of the hidden regulatory threats to wireless networking and what we might do about them, as well as many of the other sessions he attended, in a conference report on Wednesday's sessions."

tadghin writes "Rob Flickenger has an amazing take on what's happening in the wireless noosphere at the O'Reilly Emerging Technologies Conference. Rob used EtherPeg, a great Mac OS X hack that lets you see the GIFs and JPEGs flying around on the local network, to key off on an amazing visual commentary on what people were doing during Steven Johnson's keynote."

Arkham writes "Tim O'Reilly gave a speech at WWDC called 'Watching the Alpha Geeks: Mac OS X and the next big thing', in which he suggested that Apple is doing the right things to be a big success. Specifically, Apple should continue to 1) adhere to standards, 2) keep things small and modular, and 3) document as you go -- man pages and RFCs. Anyone who has used Mac OS X can see that Apple is trying hard to be a good open-source citizen (for example, the new zero-config Rendezvous technology). The question is, at what point will these efforts pay off (more users, and thus more money)?" What is this "money" you speak of?

lopati writes "O'Reilly Network is running the first of a two part series about the intertwined histories of Apple and NeXT, and more specifically NeXTSTEP and the foundations of Cocoa. Nothing really new, but a nice overview of Mac OS X and a quick rundown of how old missteps (no pun intended :) evolved into the present product and company. I thought this was an interesting tidbit: 'But NeXT wasn't just a software company -- Jobs was also obsessed with building hardware. And this proved to be the company's downfall.' Ironic, because this has been Apple's salvation, or portentous, because history is doomed to repeat itself? You be the judge!"

Lisa writes "O'Reilly announced Monday, at WWDC, the O'Reilly Mac OS X Conference to be held in Santa Clara Sept 30-Oct 3rd. The call for papers has gone online if you're interested in presenting, and they're soliciting ideas for 'a panel discussion or a particularly provocative group of panelists that you'd love to see square off.' To submit your suggestions, send email to: macosx-idea@oreilly.com."

Lisa writes "O'Reilly announced Monday, at WWDC, the O'Reilly Mac OS X Conference to be held in Santa Clara Sept 30-Oct 3rd. The call for papers has gone online if you're interested in presenting, and they're soliciting ideas for 'a panel discussion or a particularly provocative group of panelists that you'd love to see square off.' To submit your suggestions, send email to: macosx-idea@oreilly.com."

An Anonymous Coward writes "There is a story on oreillynet.com on the response by a Peruvian Congressman to Microsoft's letter opposing a proposed Free Software Law. Here's the translated letter and this is the original letter that Microsoft submitted in response to the proposed law. It's always cool to see governments trying to enact these kinds of laws and watch the Microsoft backlash against them :)."

Raju writes: "For many years we were told that SCSI is superior to IDE. I always made my systems with SCSI and the others in the household got el-cheapo IDE disks. In the past SCSI beat IDE hands-down but now according to Simson Garfinkel, "today's IDE drives are significantly faster than SCSI drives". In the article at O'Reilly Network he talks about the tests they had run for storage of network data on disks. In the light of this article does anyone see any reason for going with SCSI in a desktop machine? For servers with heavy disk usage patterns it might be different due to command queuing." Disk types aren't what the article's really about, though -- it's a top-level look at network forensics (including advice on building a traffic-analysis system), and makes some interesting points about the unbalanced growth of storage and bandwidth.

flynn_nrg writes: "O'Reilly has an interesting article about vulnerabilities in common programs found on most FreeBSD boxes. From the article: "Welcome to Security Alerts, an overview of recent Unix and open source security advisories. In this column, we look at buffer overflows in OpenSSH, Squid, Listar/Ecartis, slrnpull, and IRIX's syslogd; problems in Sudo, MHonArc, and Mosix; and a local root hole and denial-of-service attack vulnerability in FreeBSD.""

Lisa writes "An Apple iBook turns out to be a great choice for running Debian GNU/Linux. Edd Dumbill, the editor of XML.com explains why." This could also be an argument for why to use Mac OS X instead of Linux in the first place, but if you do want to use Linux, then a Mac is a good choice. :-)

andyo writes "Mailing lists are abuzz with the news that wireless Internet providers may have to pay fees to support plain old telephone service. My own perspective is at the O'Reilly Network." The Universal Service Fees are taxes set up long ago to assure that telephone service was provided to everyone, even people who it would normally be uneconomical to serve. The theory is a good one, the execution maybe not. (Maybe if the fees went towards Universal Broadband?)

paradesign writes "O'Reilly is running a nice article on AltiVec in the G4 chip. The article includes examples, with code, showing its effectiveness. For everyone who is uneducated as to exactly what Altivec is, this is a must read."

paradesign writes "O'Reilly is running a nice article on AltiVec in the G4 chip. The article includes examples, with code, showing its effectiveness. For everyone who is uneducated as to exactly what Altivec is, this is a must read."

hank writes "The O'Reilly Network is running an interview with Lawrence Lessig -- author of "Code and Other Laws of Cyberspace" and "The Future of Ideas" -- on the future of the public domain, reaction to his calls to arms, and his next venture, Creative Commons, "machinery to build licenses that allow people to mark their content as available in any number of ways to the public domain.""

Lisa writes: "As part of Microsoft's Shared Source initiative, the company announced Tuesday the public availability of more than 1 million lines of Windows and Microsoft .NET source code--aimed primarily at universities. I guess Microsoft hopes to slow down academic support for the open-source Linux OS. Don't know why they expect this to work, but Brian Jepson has a nice overview of this shared source release."

cascadefx writes: "The O'Reilly Network is currently running an article that showcases the much talked about Playstation 2 Linux distribution. Nice parts of the article include analysis by a Blizzard developer on the Linux PS2 as a gaming platform and a screenshot and pic of the hardware that comes with it."

Milo_Mindbender writes: "Over the weekend I was attempting to improve my CD ripping performance and discovered RedHat 7.2 was running my Ultra/ATA 100 hard drive in a very slow non-DMA mode. After a fair amount of searching for how to fix this, a trivial change (look here) improved drive performance from 3MBs to 38MBs! FSCK on my 40gb partition went from over 5 minutes to under 1! This issue wasn't documented in RedHat's manuals but it effected a number of boxes in our office so I'm betting many other people in the world have the same problem. This made me wonder how many other common Linux tuning snafus there might be that a lot of people are probably missing. Do you know of any?"

Cory Doctorow has a article on oreillynet called "How I Learned to Stop Worrying and Love the Panopticon," which begins "How much ass does Google kick? All of it." (We linked to it a few days ago.) Reader Richard Seltzer writes with a reaction to Doctorow's article, below. Your results may vary, but this kind of skepticism can only make the competing search engines better.

Some people love the results they get at Google, others are often disappointed. To a large extent, both the pluses and the minuses derive from Google's ranking system, which (as the folks at Google explain www.google.com/technology) depends largely on the number links to a particular page and the relevance of the content on those linking pages to the content on the target page, and the quality of the pages doing the linking.

Thanks to that complex and brilliant system, over time, the best pages often rise to the top of search lists. But that takes time -- a lot of time.

It works great for old, established sites to which many other old, established sites have linked. (It works great for my site :-) www.samizdat.com ). But new sites, regardless of the quality of their content, get short shrift. It takes 2-3 months for the new pages to get into the Google index. Then it takes time -- perhaps years -- for other "important" sites to discover the new site and link to it; and then months more for the new versions of those pages with those new links to get into the Google index.

So if I'm looking for content that is likely to have been on the Internet for a year or more, Google is great. But if I'm looking for fresh content, I'll go elsewhere.

For me, for years "elsewhere" meant AltaVista -- for two reasons. AltaVista used to add new pages to its index, for free, within two days of submission, while other search engines typically took weeks or even months. That meant they had the freshest content. In addition, AltaVista provided you with a set of very precise commands that couldn't be matched anywhere else.

Over the last year, as AltaVista has struggled to become profitable, they have destroyed their beautiful free submission process, trying to force Web sites to pay for submission. Free submissions (which typically come from the kinds of content-rich sites that I'm interested in) now seem to take three months or more -- no better than the other search engines and often worse.

Fortunately, the powerful commands remain -- for instance, the ability to exclude as well as include terms in your query. AltaVista lets you use minus signs and plus signs to indicate what you really don't want and what you do want. And for some specialized searches the exclusion is essential.

For instance, say you want to know what Web pages outside of your own site have links to your pages. At Google, I can do a search for link:samizdat.com or get the same results by going to their "Advanced" search and using their "page specific search" to find pages that link to a particular page. But my results are then littered with pages from my own site -- information I don't need and don't want. At AltaVista, I can search for +link:samizdat.com -host:samizdat.com and get exactly what I want -- finding out who thinks enough of my pages to have linked to me without my having contacted them: a valuable list of well-wishers and potential partners.

Similarly, Google lets me restrict a search to a particular Web site. For instance, if I include in my query the term site:samizdat.com or in Advanced search under Domains I choose to restrict the search to that domain, Yes, I get results only from that site. But to use that command, I need to have additional query terms: site:samizdat.com alone generates no results.

At AltaVista, however, I can search for host:samizdat.com and get a complete list of all the pages at my site that are in the AltaVista index. Or I can search for url:samizdat.com/isyn and get a list of all the pages in that directory at my site are in the AltaVista index. Or I can search for url:samizdat.com/consult.html to see if that particular page is in the index.

In other words, AltaVista provides a higher level of precision and the ability to get information that is particularly valuable to people in charge of Web sites and Web-based marketing projects. And if they'd just fix their free submission process and provide the service they used to, they'd kick Google's ass for searches for current information.

P.S. -- The folks at Google are very proud that their system defies human tampering. In fact, what they've done is encouraged the development of bizarre business models structured to take advantage of their link-based ranking system. For instance, Webseed Publishing now has over 1000 sites, all with different domain names. These content-rich sites are each run by different dedicated individuals. (I'm one of them :-) In many cases, the content deserves high rankings for its quality. You might wonder why the umbrella business for all these sites bothers to maintain over a thousand different domain names, when it would be far simpler and cheaper to have them as directories under a single domain. But because the domains are different, the many thousands of links these sites have to one another all count toward the automated calculation of their popularity and quality at Google, giving them all a boost in the rankings and hence bringing Webseed more traffic and hence more revenue.

P.P.S. -- AltaVista appears to be making a comeback. Six years ago, when I was in the Internet Business Group at Digital and Digital owned AltaVista, about a third of the traffic to my Web site came by way of AltaVista. Whenever AltaVista had a glitch, I saw it immediately in my traffic stats. In fact, I sometimes was able to alert the engineers at AltaVista about problems before they had noticed them themselves. Over the years, due to increased competition from other search engines and also due to the business folks at AltaVista making bad decisions and jettisoning great capabilities/services (like 2-day free submissions, their affiliate program, LiveTopics, and newsgroup search), the number of people finding my pages by way of AltaVista plummeted. By January 2002, only 1% of my traffic was coming by way of AltaVista, despite the fact that as a long-standing fan and also as co-author of the book The AltaVista Search Revolution, I had lots of information about AltaVista at my site. I was actually getting twice as much traffic from the International Atomic Energy Agency (part of the UN), when I had no information at all related to atomic energy. But in recent weeks the traffic from AltaVista has climbed sharply. It now amounts to 6% of my total. I wish I knew why that was happening. In any case, I hope that trend continues.

rgraham writes "Derrick Story (O'Reilly Network editor) has written a follow-up article to The New Mac User, titled The Changing Mac Community. He makes some interesting observations about how Mac OS X's Unix underpinnings have greatly 'broadened the landscape' of the Mac community beyond that of typical artists to now include hardcore Unix users and the like." I personally believe this is the single most important component to Apple's continued success for the near future.

rgraham writes "Derrick Story (O'Reilly Network editor) has written a follow-up article to The New Mac User, titled The Changing Mac Community. He makes some interesting observations about how Mac OS X's Unix underpinnings have greatly 'broadened the landscape' of the Mac community beyond that of typical artists to now include hardcore Unix users and the like." I personally believe this is the single most important component to Apple's continued success for the near future.

mitd writes: "Cory Doctrow has written an insightful article about Google, search engines and how he stopped worrying."

Oink.NET writes "The O'Reilly Network reports on an unannounced BOF session at BSDCon 2002 regarding Rotor, a shared souce implementation of Microsoft's Common Language Infrastructure that currently runs on Windows and FreeBSD. It relies on a Platform Adaptation Layer, similar to Apache's Portable Runtime, that simplifies porting to other OS's. As to the licensing terms, the Rotor FAQ says "Microsoft intends to provide very liberal non-commercial licensing terms and is interested in gathering community input on the design of the license." Wonder if that includes Slashdot community input..."

Oink.NET writes "The O'Reilly Network reports on an unannounced BOF session at BSDCon 2002 regarding Rotor, a shared souce implementation of Microsoft's Common Language Infrastructure that currently runs on Windows and FreeBSD. It relies on a Platform Adaptation Layer, similar to Apache's Portable Runtime, that simplifies porting to other OS's. As to the licensing terms, the Rotor FAQ says "Microsoft intends to provide very liberal non-commercial licensing terms and is interested in gathering community input on the design of the license." Wonder if that includes Slashdot community input..."

Marsee writes: "Mike Beam looks at two Aqua enhancements -- one seemingly frivolous and the other not: animated window resizing and drawers." O'Reilly's really invested in Mac OS X, and they often have nice articles for developers on a wide range of subjects in their Mac DevCenter.

Marsee writes: "Mike Beam looks at two Aqua enhancements -- one seemingly frivolous and the other not: animated window resizing and drawers." O'Reilly's really invested in Mac OS X, and they often have nice articles for developers on a wide range of subjects in their Mac DevCenter.

Reader amoon writes: "With the rise of XML-based RPC (e.g. SOAP, XML-RPC, APEX), the distributed computing world is starting to really unsettle from the CORBA-RMI-DCOM oligopoly of the 1980s and 1990s. Yet, XML-based RPC is not a panacea (though it is quite cool), especially for those of us involved in the legacy and client-server worlds. Now, what is fascinating: the publishing world is revving up the engines on not only the XML-based RPC stuff, but also the RMI and CORBA stuff -- while rarely applied to the tech industry, the old adage, "what was old is new again," seems to fit well here. This review describes this über-cool trend from the RMI perspective, with a focus on Java RMI (O'Reilly) by William Grosso." Read on for the rest of the review. Java RMI author William Grosso pages 545 publisher O'Reilly rating 8 reviewer amoon ISBN 1-56592-452-5 summary Solid practical insight into the nitty-gritty details of RMI.

The Scoop

Remote Method Invocation (RMI) is the object-oriented remote procedure call (ORPC) facility for distributed programming in Java, since the 1.1 days. RMI also served as motivation and a proof-of-concept for jini, javaspaces, and numerous other solid distributed networking technologies. Of course, anyone from the academic distributed programming world knows Wollrath, Waldo, and Riggs.

Yet, despite a myriad of books over the past five years on network programming, RMI always seemed to be the stepchild: relegated to a single chapter (buried on page 496, of course) that always said that RMI was "better" than sockets and "worse" than CORBA. Now, granted that RMI is operationally rather trivial compared with CORBA and was (prior to RMI/IIOP) a unilanguage distributed ORPC technology -- but still. For those of us who have to interoperate with RMI (whether welcome from the Java world or not), the lack of in-depth technical analysis (beyond the spec) has been a hindrance.

Fortunately, this trend is finally starting to buckle with the release of several in-depth RMI books including: Java RMI, Java.rmi, and Mastering RMI: Developing Enterprise Applications in Java and EJB. As evidence of this problem, Grosso states the same in his introduction – and actually pulls it off without sounding self-serving.

I chose Grosso's text because of the cute squirrel (aka the O'Reilly brand), Grosso's recent series of articles on the hashbelt algorithm, and his unadulterated academic knowledge management and mathematics bent. Fortunately, I was rewarded: this animal returns to O'Reilly's pre-bubble quality. Koodoos to both Grosso and his editors (Knudsen, Loukides, and Eckstein) for getting the train back on the track.

What's to Like

Bottom line is that Grosso simply covers the topics and does so with solid conceptual and code coherence – even by O'Reilly standards (over 40 animals grace my shelves). His prose and explanatory patterns make it clear that he has actually gotten into the real-world of RMI, and doesn't hesitate to highlight both good and bad parts. You cannot be dozing off when you read this (at least not if you expect to understand it) -- this is written by someone with solid analytic thinking skills and it shows. After too many years of "there are no caveats" journalism and publishing, this is a nice reversion. Further, I can only imagine that his current employment is a testament to his real-world knowledge of RMI.

Grosso hits on a vein which is not well-appreciated: when not smoothed over by marketing people, RMI is actually a mostly-capable ORPC technology. Certainly activation and RMI/IIOP really began to make things interesting, from Java2 and EJB respectively. Discussion of reference-counted distributed garbage collection, a feature missing from CORBA and other popular ORPC standards, also contributes a nice bonus (although Grosso's ardent attempt to debunk the "RMI doesn't scale" argument is rather weak, even going so far as to rehash the definition of Threads and threadpools – this complexity mismatch is an ugly giveaway that a well-intentioned editor went astray).

What sets this text apart is the tight focus on nitty-gritty implementation details of RMI itself. After all, these RMI texts are way too late to the game to reteach how to write "baby RMI" code: 5 years after the original spec, you either know how to write RMI or you don't. Grosso simply gives you a solid in-depth analysis of all the obscurities of the RMI runtime, custom sockets, dynamic classloading, activation, MarshalledObjects, and HTTP tunneling. In other words, all the interesting real-world topics whose official documentation is poor and which the various RMI tutorials (written many years ago) ignored.

While canonical, the single banking example followed through the text was well-executed, although authors continue to underestimate the prevalence of readers who consume textbooks non-linearly.

What's Not to Like

RMI/IIOP is shaping up to be a fascinating contributor to the "cleanup the EJB mess" discussion. Dedicating a measly 13 pages (beginning on page 503, no less) to this critical topic seems a bit of an oversight – but maybe that is just my CORBA sentiments speaking. Either way, the mechanics of CORBA are sufficiently intricate in real-world deployments that saying "if you can build an RMI system, you can build a CORBA system" (p. 511) is a bit brazen (or naïve) for my tastebuds. I can only chalk up this oversight to deadline pressure, which is probably a Good Thing, since the book was supposedly in production over almost 2 years.

A minor point: the top-level organization of the book (Part I, II, III) is arbitrary, ignore it -- use the chapter organization instead.

The Summary

Quality: solid practical insight into the nitty-gritty operational implementation details of RMI in the real-world. You simply are not going to find solid O'Reilly-quality coverage of the topics elsewhere.

Relevance: If you are responsible for making RMI actually work in production systems, this might well be the next animal on your shelf – either now or later. If you want a breezy afternoon saunter around RMI, skip this. Instead, google one (of the many) free tutorials online."

You can purchase Java RMI from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

Two Slashdot (and Slashcode) readers -- Alex McLintock of Openweb Analysts Ltd, and Dave Aiello of CTDATA -- have graciously contributed their impressions of the new O'Reilly book Running Weblogs With Slash. Since the Slash code is now used to run sites covering a huge number of topics (fly fishing, mountain biking, "news for nerds," etc.), it's time there was at least one printed reference to it. Running Weblogs With Slash author chromatic, Brian Aker, Dave Kreiger pages 262 publisher O'Reilly rating (see each) reviewer Alex McLintock ISBN 0-596-00200-2 summary It's the first book I know about slash: That means it's the best, and the worst.

dave_aiello's review:

I have been running two small-scale Slash sites since 1999. When I began developing web sites using Slash the only code available was Version 0.3, one of the first tarballs ever released by Rob Malda. That code was almost totally undocumented and not at all modular.

The Slash project has grown and the code has improved since then. Slash has now reached the point where it is a feature-laden, open source web publishing platform. However, documentation that can help new users has always been hard to come by.

I found a paragraph near the beginning of the book that I thought was important because it may help you to decide whether this book will be helpful to you:

This book is aimed at anyone interested in setting up and running a weblog with the Slash software. This includes system administrators and programmers, but attempts have been made to keep the discussion readable for people who have no desire to compile their own kernel or to rewrite the moderation system. It concentrates much more on how to accomplish things than how things work underneath, though it doesn't shy away from the greasy gears and wheels when appropriate.

The authors' choice of audience might also be why you have seen comments from some experienced Slash site maintainers indicating that they weren't entirely satisfied with the finished product. That's OK -- it wasn't written for them. But, if you have a desire to build a web site running on Slash and you don't want to spend the months that it took me to read the code line-by-line, "Running Weblogs with Slash" is a good place to start.

The main part of the book begins with an overview chapter. It starts with a brief history of the Slash project. The next ten pages are a review of the user interface of Slashdot, including a number of screenshots. This is followed by three important short sections: The Slash Author Interface (administration), The Slash Publishing Cycle, and The Slash Architecture. These sections do not contain screenshots, but author interface is discussed in detail later in the book, and the publishing cycle and architecture parts have diagrams to help you visualize the concepts being discussed.

The next chapter, Installing Slash, may be the most important one of the book. This chapter is surprisingly short (about 21 pages) considering the difficulty that some people have installing the software. Two of the most critical pages of the chapter cover getting help with the key underlying software: mySQL, Perl, Apache, mod_perl, and Slash itself. All of the important URLs and mailing lists are documented here. A short outline of the installation process, and a set of step-by-step installation instructions follow. There are also short sections on building sites that are distributed across multiple machines, and running multiple virtual Slash sites on the same server.

Although the installation chapter is clearly written, some users may have difficulty completing it without a little frustration. For instance, the book says "Although many UNIX-like operating systems come with Perl already installed, building Apache with mod_perl requires the Perl source." It would help if the detailed installation section of the chapter indicated how to uninstall a binary version of Perl from at least one of the major Linux distributions. The authors have been consistent, however, in focusing this chapter on critical, Slash-specific installation issues.

The next five chapters of the book focus on Slash site administration. The topics covered include editing and updating stories, reviewing and approving submissions, comment-related functionality, moderation, and managing sections and topics. These chapters are important because most people who want to implement a Slash site have never seen the administration interface and need some help understanding the tools that are available. These chapters are also helpful to people who have experience with other web publishing systems, because a quick comparison can be done between the Slash author interface and the system with which the reader is more familiar.

The main part of the book concludes with chapters on managing a Slash-based community, basic and advanced customization, and advanced administration. The customization chapters are the only places in the main part of the book where the Perl code that makes up Slash is discussed in any detail. Now that Slash implements much of the web site's look and feel through the Template Toolkit, modification of the application source is much less important than it used to be. The advanced administration chapter is primarily about the Slash daemon (slashd), the tasks it performs (dailyStuff, moderatord, portald), and how tasks can be added and modified.

The appendices are easily the most technical part of the book. They begin with a detailed discussion of the Slash architecture, which includes several process diagrams, and a discussion of the Slash directory structure. The second appendix discusses the Slash database schema. The appendix on the Slash Template Language looks quite useful to people trying to modify the appearance of their Slash site. The Slash API appendix covers some of the important high-level functions that would be useful in building your own Slash plugin or theme. The last appendix covers Slash configuration variables, which can be important if you have to modify the location of Slash content in your file system, or you need to change other fundamental aspects of your site's configuration.

I would strongly recommend this book to you if you plan to build a Slash-based site and you want to develop a basic understanding of the Slash software as quickly as possible. You will also need to find resources (either in print or on-line) to help you understand administration of the underlying operating system, Perl, Apache, and mySQL, if you have little or no background in these subjects.

I'm sure that many people will be able to successfully install and operate Slash by using this book as their primary reference. And, if they have difficulty, they will have sufficient understanding of the architecture and terminology to ask "good questions" on the mailing lists or the Slashcode web site.

Alex McLintock's review:

Executive Summary:

This review basically lists the flaws and missing features in the book. But that doesn't mean it is a bad book - just that it is easier to find fault than praise. If you need a book on running a weblog with slash then buy this book.

About the Reviewer:

My slash experience is in running a book reviews website http://news.diversebooks.com/ using slashcode. I did set up a site years ago called "mines-a-pint.com" using a pre 1.0 version of slashcode but the site fell over due to lack of spare time.

I am also a perl programmer and web developer so I can figure out a huge variety of problems with Apache, mod_perl, and MySQL. This is lucky because slashcode depends quite greatly on the administrator having those skills. Sadly this book doesn't look into them in great detail. Were this a Wrox book the publishers would have copied a few chapters from different books - or at least given more details on how to troubleshoot those systems. The O'Reilly strategy is that you can perfectly well buy their book on MySQL, their Apache book, and their mod_perl book(s).

Choosing Slash:

I was expecting more of a comparison of Slash to other weblogs. Why chose slash over others? It is in fact a hard question to answer unless you require a site really quite like http://slashdot.org The big benefit of being able to cope with a lot of traffic probably don't apply to most sites just starting out.

The book assumes you have greater than Slash 2.2.0, but presumably quite a few people such as myself have 2.0 installed and not upgraded yet. (I don't know how many people are running pre 1.0 slash sites). It doesn't mention how you upgrade. Lets face it - even if you installed the latest version today (2.2.5) you *will* have to upgrade at some point.

Setting Up Sites:

I expected this section to be a lot more detailed than the basic instructions - but it isn't so much better. When setting up slash sites there are at least three different types of user (slash, unix, and database) and these are not differentiated properly. The authors of the book fall too easily into using slashcode jargon without realising that someone coming to this for the first time wont know the slash-speak. I understand it because I've been reading the mailing list for nearly a year. However, someone picking up this book may not have.

Most jargon terms are introduced but they could be better explained - perhaps with more diagrams. As a typical example, it took me ages to understand the difference between topics and sections. It would have been great to see examples of how different slashcode sites decided what their topics and sections would be. Originally I just saw topics and sections as being a matrix of slots into which one would pigeonhole each article. However there are some things you can do with sections (the columns of the matrix) which you can't do with the topics (the rows). This seemed to me to be an arbitrary limitation of slashcode which an installer needs to be aware of when choosing topics and sections.

More screenshots of the default theme are needed. For instance it talks about the various slashboxes which are configurable but doesn't show them.

Virtual Slash Sites:

I pretended I was a newbie at this and tried to follow their instructions for installing virtual slash sites (ie multiple weblogs on the same machine). The instructions for setting up virtual users aren't complete. EG how do you *add* a new user to DBIx::Password I figured it out because I know perl but others may have significant problems....

Slightly Unusual Config:

I wanted to see if the book would tell me how to put all slash URLs inside a directory of a pre-existing site. (eg http://mysite.com/newsdir/slashpages ) but no found info on doing this at all....

This is a shame because it means that if you wish to combine slashcode with some other html you have to take the approach of installing slash and then adding the extra html content rather than the other way around. It should have considered the situation where someone already has a pre-existing website which they just want to enhance with some news capability.

Running a Slash Site:

There is not much description of the workflow of submitted articles through the system. Instead it is explained by describing what slashcode editors (aka "Authors") do. Looking at the article workflow is important because many other organisations will have different workflows and thus will need to change their behaviour to match Slashcode and not vice versa. This is generally a "bad thing".

Would I Buy This Book?

If I were installing slash for someone and I wasn't being paid to do all the maintenance I would have no hesitation in buying this book to help whoever is doing first line support. However I don't feel a desperate need to keep the book myself since I've already learned most of what it contains just by running a slash site. I know how to read the docs, look at the perl and database, and use the mailing list.

Ok - I can't do entirely without the book because it has some useful reference sections: a full third of the book is made from Appendices and index! One of the most useful of these is the chapter on Andy Wardley's Template Toolkit. I have a bit of an advantage here since I have used Andy's code before in a different web project. However most of my future slash site design will be done by a more junior web developer who doesn't have any perl experience and I expect this will be his most used chapter. (Check back to http://news.DiverseBooks.com in a few days for his additions to this review). The final appendix is useful too -- the list of configuration variables and their meanings.

You can purchase Running Weblogs with Slash from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form. (Psst! O'Reilly has also made available a 20% discount for Slashdot readers ordering by phone (800-294-4747), email (order@oreilly.com) or from the O'Reilly web site. Use discount code "#E1EW36."

Two Slashdot (and Slashcode) readers -- Alex McLintock of Openweb Analysts Ltd, and Dave Aiello of CTDATA -- have graciously contributed their impressions of the new O'Reilly book Running Weblogs With Slash. Since the Slash code is now used to run sites covering a huge number of topics (fly fishing, mountain biking, "news for nerds," etc.), it's time there was at least one printed reference to it. Running Weblogs With Slash author chromatic, Brian Aker, Dave Kreiger pages 262 publisher O'Reilly rating (see each) reviewer Alex McLintock ISBN 0-596-00200-2 summary It's the first book I know about slash: That means it's the best, and the worst.

dave_aiello's review:

I have been running two small-scale Slash sites since 1999. When I began developing web sites using Slash the only code available was Version 0.3, one of the first tarballs ever released by Rob Malda. That code was almost totally undocumented and not at all modular.

The Slash project has grown and the code has improved since then. Slash has now reached the point where it is a feature-laden, open source web publishing platform. However, documentation that can help new users has always been hard to come by.

I found a paragraph near the beginning of the book that I thought was important because it may help you to decide whether this book will be helpful to you:

This book is aimed at anyone interested in setting up and running a weblog with the Slash software. This includes system administrators and programmers, but attempts have been made to keep the discussion readable for people who have no desire to compile their own kernel or to rewrite the moderation system. It concentrates much more on how to accomplish things than how things work underneath, though it doesn't shy away from the greasy gears and wheels when appropriate.

The authors' choice of audience might also be why you have seen comments from some experienced Slash site maintainers indicating that they weren't entirely satisfied with the finished product. That's OK -- it wasn't written for them. But, if you have a desire to build a web site running on Slash and you don't want to spend the months that it took me to read the code line-by-line, "Running Weblogs with Slash" is a good place to start.

The main part of the book begins with an overview chapter. It starts with a brief history of the Slash project. The next ten pages are a review of the user interface of Slashdot, including a number of screenshots. This is followed by three important short sections: The Slash Author Interface (administration), The Slash Publishing Cycle, and The Slash Architecture. These sections do not contain screenshots, but author interface is discussed in detail later in the book, and the publishing cycle and architecture parts have diagrams to help you visualize the concepts being discussed.

The next chapter, Installing Slash, may be the most important one of the book. This chapter is surprisingly short (about 21 pages) considering the difficulty that some people have installing the software. Two of the most critical pages of the chapter cover getting help with the key underlying software: mySQL, Perl, Apache, mod_perl, and Slash itself. All of the important URLs and mailing lists are documented here. A short outline of the installation process, and a set of step-by-step installation instructions follow. There are also short sections on building sites that are distributed across multiple machines, and running multiple virtual Slash sites on the same server.

Although the installation chapter is clearly written, some users may have difficulty completing it without a little frustration. For instance, the book says "Although many UNIX-like operating systems come with Perl already installed, building Apache with mod_perl requires the Perl source." It would help if the detailed installation section of the chapter indicated how to uninstall a binary version of Perl from at least one of the major Linux distributions. The authors have been consistent, however, in focusing this chapter on critical, Slash-specific installation issues.

The next five chapters of the book focus on Slash site administration. The topics covered include editing and updating stories, reviewing and approving submissions, comment-related functionality, moderation, and managing sections and topics. These chapters are important because most people who want to implement a Slash site have never seen the administration interface and need some help understanding the tools that are available. These chapters are also helpful to people who have experience with other web publishing systems, because a quick comparison can be done between the Slash author interface and the system with which the reader is more familiar.

The main part of the book concludes with chapters on managing a Slash-based community, basic and advanced customization, and advanced administration. The customization chapters are the only places in the main part of the book where the Perl code that makes up Slash is discussed in any detail. Now that Slash implements much of the web site's look and feel through the Template Toolkit, modification of the application source is much less important than it used to be. The advanced administration chapter is primarily about the Slash daemon (slashd), the tasks it performs (dailyStuff, moderatord, portald), and how tasks can be added and modified.

The appendices are easily the most technical part of the book. They begin with a detailed discussion of the Slash architecture, which includes several process diagrams, and a discussion of the Slash directory structure. The second appendix discusses the Slash database schema. The appendix on the Slash Template Language looks quite useful to people trying to modify the appearance of their Slash site. The Slash API appendix covers some of the important high-level functions that would be useful in building your own Slash plugin or theme. The last appendix covers Slash configuration variables, which can be important if you have to modify the location of Slash content in your file system, or you need to change other fundamental aspects of your site's configuration.

I would strongly recommend this book to you if you plan to build a Slash-based site and you want to develop a basic understanding of the Slash software as quickly as possible. You will also need to find resources (either in print or on-line) to help you understand administration of the underlying operating system, Perl, Apache, and mySQL, if you have little or no background in these subjects.

I'm sure that many people will be able to successfully install and operate Slash by using this book as their primary reference. And, if they have difficulty, they will have sufficient understanding of the architecture and terminology to ask "good questions" on the mailing lists or the Slashcode web site.

Alex McLintock's review:

Executive Summary:

This review basically lists the flaws and missing features in the book. But that doesn't mean it is a bad book - just that it is easier to find fault than praise. If you need a book on running a weblog with slash then buy this book.

About the Reviewer:

My slash experience is in running a book reviews website http://news.diversebooks.com/ using slashcode. I did set up a site years ago called "mines-a-pint.com" using a pre 1.0 version of slashcode but the site fell over due to lack of spare time.

I am also a perl programmer and web developer so I can figure out a huge variety of problems with Apache, mod_perl, and MySQL. This is lucky because slashcode depends quite greatly on the administrator having those skills. Sadly this book doesn't look into them in great detail. Were this a Wrox book the publishers would have copied a few chapters from different books - or at least given more details on how to troubleshoot those systems. The O'Reilly strategy is that you can perfectly well buy their book on MySQL, their Apache book, and their mod_perl book(s).

Choosing Slash:

I was expecting more of a comparison of Slash to other weblogs. Why chose slash over others? It is in fact a hard question to answer unless you require a site really quite like http://slashdot.org The big benefit of being able to cope with a lot of traffic probably don't apply to most sites just starting out.

The book assumes you have greater than Slash 2.2.0, but presumably quite a few people such as myself have 2.0 installed and not upgraded yet. (I don't know how many people are running pre 1.0 slash sites). It doesn't mention how you upgrade. Lets face it - even if you installed the latest version today (2.2.5) you *will* have to upgrade at some point.

Setting Up Sites:

I expected this section to be a lot more detailed than the basic instructions - but it isn't so much better. When setting up slash sites there are at least three different types of user (slash, unix, and database) and these are not differentiated properly. The authors of the book fall too easily into using slashcode jargon without realising that someone coming to this for the first time wont know the slash-speak. I understand it because I've been reading the mailing list for nearly a year. However, someone picking up this book may not have.

Most jargon terms are introduced but they could be better explained - perhaps with more diagrams. As a typical example, it took me ages to understand the difference between topics and sections. It would have been great to see examples of how different slashcode sites decided what their topics and sections would be. Originally I just saw topics and sections as being a matrix of slots into which one would pigeonhole each article. However there are some things you can do with sections (the columns of the matrix) which you can't do with the topics (the rows). This seemed to me to be an arbitrary limitation of slashcode which an installer needs to be aware of when choosing topics and sections.

More screenshots of the default theme are needed. For instance it talks about the various slashboxes which are configurable but doesn't show them.

Virtual Slash Sites:

I pretended I was a newbie at this and tried to follow their instructions for installing virtual slash sites (ie multiple weblogs on the same machine). The instructions for setting up virtual users aren't complete. EG how do you *add* a new user to DBIx::Password I figured it out because I know perl but others may have significant problems....

Slightly Unusual Config:

I wanted to see if the book would tell me how to put all slash URLs inside a directory of a pre-existing site. (eg http://mysite.com/newsdir/slashpages ) but no found info on doing this at all....

This is a shame because it means that if you wish to combine slashcode with some other html you have to take the approach of installing slash and then adding the extra html content rather than the other way around. It should have considered the situation where someone already has a pre-existing website which they just want to enhance with some news capability.

Running a Slash Site:

There is not much description of the workflow of submitted articles through the system. Instead it is explained by describing what slashcode editors (aka "Authors") do. Looking at the article workflow is important because many other organisations will have different workflows and thus will need to change their behaviour to match Slashcode and not vice versa. This is generally a "bad thing".

Would I Buy This Book?

If I were installing slash for someone and I wasn't being paid to do all the maintenance I would have no hesitation in buying this book to help whoever is doing first line support. However I don't feel a desperate need to keep the book myself since I've already learned most of what it contains just by running a slash site. I know how to read the docs, look at the perl and database, and use the mailing list.

Ok - I can't do entirely without the book because it has some useful reference sections: a full third of the book is made from Appendices and index! One of the most useful of these is the chapter on Andy Wardley's Template Toolkit. I have a bit of an advantage here since I have used Andy's code before in a different web project. However most of my future slash site design will be done by a more junior web developer who doesn't have any perl experience and I expect this will be his most used chapter. (Check back to http://news.DiverseBooks.com in a few days for his additions to this review). The final appendix is useful too -- the list of configuration variables and their meanings.

You can purchase Running Weblogs with Slash from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form. (Psst! O'Reilly has also made available a 20% discount for Slashdot readers ordering by phone (800-294-4747), email (order@oreilly.com) or from the O'Reilly web site. Use discount code "#E1EW36."

Two Slashdot (and Slashcode) readers -- Alex McLintock of Openweb Analysts Ltd, and Dave Aiello of CTDATA -- have graciously contributed their impressions of the new O'Reilly book Running Weblogs With Slash. Since the Slash code is now used to run sites covering a huge number of topics (fly fishing, mountain biking, "news for nerds," etc.), it's time there was at least one printed reference to it. Running Weblogs With Slash author chromatic, Brian Aker, Dave Kreiger pages 262 publisher O'Reilly rating (see each) reviewer Alex McLintock ISBN 0-596-00200-2 summary It's the first book I know about slash: That means it's the best, and the worst.

dave_aiello's review:

I have been running two small-scale Slash sites since 1999. When I began developing web sites using Slash the only code available was Version 0.3, one of the first tarballs ever released by Rob Malda. That code was almost totally undocumented and not at all modular.

The Slash project has grown and the code has improved since then. Slash has now reached the point where it is a feature-laden, open source web publishing platform. However, documentation that can help new users has always been hard to come by.

I found a paragraph near the beginning of the book that I thought was important because it may help you to decide whether this book will be helpful to you:

This book is aimed at anyone interested in setting up and running a weblog with the Slash software. This includes system administrators and programmers, but attempts have been made to keep the discussion readable for people who have no desire to compile their own kernel or to rewrite the moderation system. It concentrates much more on how to accomplish things than how things work underneath, though it doesn't shy away from the greasy gears and wheels when appropriate.

The authors' choice of audience might also be why you have seen comments from some experienced Slash site maintainers indicating that they weren't entirely satisfied with the finished product. That's OK -- it wasn't written for them. But, if you have a desire to build a web site running on Slash and you don't want to spend the months that it took me to read the code line-by-line, "Running Weblogs with Slash" is a good place to start.

The main part of the book begins with an overview chapter. It starts with a brief history of the Slash project. The next ten pages are a review of the user interface of Slashdot, including a number of screenshots. This is followed by three important short sections: The Slash Author Interface (administration), The Slash Publishing Cycle, and The Slash Architecture. These sections do not contain screenshots, but author interface is discussed in detail later in the book, and the publishing cycle and architecture parts have diagrams to help you visualize the concepts being discussed.

The next chapter, Installing Slash, may be the most important one of the book. This chapter is surprisingly short (about 21 pages) considering the difficulty that some people have installing the software. Two of the most critical pages of the chapter cover getting help with the key underlying software: mySQL, Perl, Apache, mod_perl, and Slash itself. All of the important URLs and mailing lists are documented here. A short outline of the installation process, and a set of step-by-step installation instructions follow. There are also short sections on building sites that are distributed across multiple machines, and running multiple virtual Slash sites on the same server.

Although the installation chapter is clearly written, some users may have difficulty completing it without a little frustration. For instance, the book says "Although many UNIX-like operating systems come with Perl already installed, building Apache with mod_perl requires the Perl source." It would help if the detailed installation section of the chapter indicated how to uninstall a binary version of Perl from at least one of the major Linux distributions. The authors have been consistent, however, in focusing this chapter on critical, Slash-specific installation issues.

The next five chapters of the book focus on Slash site administration. The topics covered include editing and updating stories, reviewing and approving submissions, comment-related functionality, moderation, and managing sections and topics. These chapters are important because most people who want to implement a Slash site have never seen the administration interface and need some help understanding the tools that are available. These chapters are also helpful to people who have experience with other web publishing systems, because a quick comparison can be done between the Slash author interface and the system with which the reader is more familiar.

The main part of the book concludes with chapters on managing a Slash-based community, basic and advanced customization, and advanced administration. The customization chapters are the only places in the main part of the book where the Perl code that makes up Slash is discussed in any detail. Now that Slash implements much of the web site's look and feel through the Template Toolkit, modification of the application source is much less important than it used to be. The advanced administration chapter is primarily about the Slash daemon (slashd), the tasks it performs (dailyStuff, moderatord, portald), and how tasks can be added and modified.

The appendices are easily the most technical part of the book. They begin with a detailed discussion of the Slash architecture, which includes several process diagrams, and a discussion of the Slash directory structure. The second appendix discusses the Slash database schema. The appendix on the Slash Template Language looks quite useful to people trying to modify the appearance of their Slash site. The Slash API appendix covers some of the important high-level functions that would be useful in building your own Slash plugin or theme. The last appendix covers Slash configuration variables, which can be important if you have to modify the location of Slash content in your file system, or you need to change other fundamental aspects of your site's configuration.

I would strongly recommend this book to you if you plan to build a Slash-based site and you want to develop a basic understanding of the Slash software as quickly as possible. You will also need to find resources (either in print or on-line) to help you understand administration of the underlying operating system, Perl, Apache, and mySQL, if you have little or no background in these subjects.

I'm sure that many people will be able to successfully install and operate Slash by using this book as their primary reference. And, if they have difficulty, they will have sufficient understanding of the architecture and terminology to ask "good questions" on the mailing lists or the Slashcode web site.

Alex McLintock's review:

Executive Summary:

This review basically lists the flaws and missing features in the book. But that doesn't mean it is a bad book - just that it is easier to find fault than praise. If you need a book on running a weblog with slash then buy this book.

About the Reviewer:

My slash experience is in running a book reviews website http://news.diversebooks.com/ using slashcode. I did set up a site years ago called "mines-a-pint.com" using a pre 1.0 version of slashcode but the site fell over due to lack of spare time.

I am also a perl programmer and web developer so I can figure out a huge variety of problems with Apache, mod_perl, and MySQL. This is lucky because slashcode depends quite greatly on the administrator having those skills. Sadly this book doesn't look into them in great detail. Were this a Wrox book the publishers would have copied a few chapters from different books - or at least given more details on how to troubleshoot those systems. The O'Reilly strategy is that you can perfectly well buy their book on MySQL, their Apache book, and their mod_perl book(s).

Choosing Slash:

I was expecting more of a comparison of Slash to other weblogs. Why chose slash over others? It is in fact a hard question to answer unless you require a site really quite like http://slashdot.org The big benefit of being able to cope with a lot of traffic probably don't apply to most sites just starting out.

The book assumes you have greater than Slash 2.2.0, but presumably quite a few people such as myself have 2.0 installed and not upgraded yet. (I don't know how many people are running pre 1.0 slash sites). It doesn't mention how you upgrade. Lets face it - even if you installed the latest version today (2.2.5) you *will* have to upgrade at some point.

Setting Up Sites:

I expected this section to be a lot more detailed than the basic instructions - but it isn't so much better. When setting up slash sites there are at least three different types of user (slash, unix, and database) and these are not differentiated properly. The authors of the book fall too easily into using slashcode jargon without realising that someone coming to this for the first time wont know the slash-speak. I understand it because I've been reading the mailing list for nearly a year. However, someone picking up this book may not have.

Most jargon terms are introduced but they could be better explained - perhaps with more diagrams. As a typical example, it took me ages to understand the difference between topics and sections. It would have been great to see examples of how different slashcode sites decided what their topics and sections would be. Originally I just saw topics and sections as being a matrix of slots into which one would pigeonhole each article. However there are some things you can do with sections (the columns of the matrix) which you can't do with the topics (the rows). This seemed to me to be an arbitrary limitation of slashcode which an installer needs to be aware of when choosing topics and sections.

More screenshots of the default theme are needed. For instance it talks about the various slashboxes which are configurable but doesn't show them.

Virtual Slash Sites:

I pretended I was a newbie at this and tried to follow their instructions for installing virtual slash sites (ie multiple weblogs on the same machine). The instructions for setting up virtual users aren't complete. EG how do you *add* a new user to DBIx::Password I figured it out because I know perl but others may have significant problems....

Slightly Unusual Config:

I wanted to see if the book would tell me how to put all slash URLs inside a directory of a pre-existing site. (eg http://mysite.com/newsdir/slashpages ) but no found info on doing this at all....

This is a shame because it means that if you wish to combine slashcode with some other html you have to take the approach of installing slash and then adding the extra html content rather than the other way around. It should have considered the situation where someone already has a pre-existing website which they just want to enhance with some news capability.

Running a Slash Site:

There is not much description of the workflow of submitted articles through the system. Instead it is explained by describing what slashcode editors (aka "Authors") do. Looking at the article workflow is important because many other organisations will have different workflows and thus will need to change their behaviour to match Slashcode and not vice versa. This is generally a "bad thing".

Would I Buy This Book?

If I were installing slash for someone and I wasn't being paid to do all the maintenance I would have no hesitation in buying this book to help whoever is doing first line support. However I don't feel a desperate need to keep the book myself since I've already learned most of what it contains just by running a slash site. I know how to read the docs, look at the perl and database, and use the mailing list.

Ok - I can't do entirely without the book because it has some useful reference sections: a full third of the book is made from Appendices and index! One of the most useful of these is the chapter on Andy Wardley's Template Toolkit. I have a bit of an advantage here since I have used Andy's code before in a different web project. However most of my future slash site design will be done by a more junior web developer who doesn't have any perl experience and I expect this will be his most used chapter. (Check back to http://news.DiverseBooks.com in a few days for his additions to this review). The final appendix is useful too -- the list of configuration variables and their meanings.

You can purchase Running Weblogs with Slash from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form. (Psst! O'Reilly has also made available a 20% discount for Slashdot readers ordering by phone (800-294-4747), email (order@oreilly.com) or from the O'Reilly web site. Use discount code "#E1EW36."

d6y writes "Over on the O'Reilly weblogs there's an entry on the relationship between Sun's Java Community Process and Apache. Sun have been rubbing people up with wrong way (the problems of licensing open source J2EE containers; stuts v. JavaFaces; log4j v. JDK 1.4 logging....) and I hope this gets sorted out real soon. See also the original VNUNet article and Apache's position paper."

d6y writes "Over on the O'Reilly weblogs there's an entry on the relationship between Sun's Java Community Process and Apache. Sun have been rubbing people up with wrong way (the problems of licensing open source J2EE containers; stuts v. JavaFaces; log4j v. JDK 1.4 logging....) and I hope this gets sorted out real soon. See also the original VNUNet article and Apache's position paper."

Slashback tonight with more updates, responses and corrections on scalability in P2P networks, TV shows which may not actually be cancelled, tentative wireless service in the Mile High City, and what exactly OS X is. Read on below for these and more.

The difference between theory and practice ... Paul Harrison writes: "I see your theoretical discussion of a scalable gnutella, and raise you a working, open source implementaion! Details in this linux.conf.au talk."

I was in Berkeley at a party, and then things got hazy. In response to the recent story on fixing the UNIX configuration mess, jbloggs writes: "OS X is not on top of NetBSD, but rather is a BSD compatibility layer on top of a Mach kernel. Its closest BSD-lite would be FreeBSD, which is used as a reference platform."

The problem with unstated motivations. Reader app writes "Tim O'Reilly responds to the BountyQuest piece on Salon and featued here. Tim makes some interesting points and clarifications -- especially where he refers to theodp as a crank."

You can't watch, and neither can they. UberOogie writes: "Who didn't see this coming? The MPA shut down Movie 88 today. What should be noted by everyone is that they took no legal action: they just went to the ISP, HiNet, and got them to shut off the pipe. (Movie88 was legal through a loophole in Tiawan copyright law.) So much for process, even in Tiawan. Movie 88 vows to find another provider."

I hope they use the time to reconsider. Cynical_Dude writes: "David Cohen, one of the producers of Futurama, was interviewed on Cinescape. He says that Futurama is not really cancelled, but will run for another year or so ... at least that's how many episodes they've got more or less ready now. FOX hasn't ordered any additional episodes, but Cohen asks fans to "write those letters [...] in physical form, not email" to the FOX executives."

And in other TV News, Glitch Tybalt writes: "Working for Hot Topic has its benefits. We recieved an e-mail saying that Invader Zim will not be cancelled after all. It seems that it was getting no ratings whatsoever, because they kept changing the time slot for it. Once they had decided to cancell it, they left it in one slot to finish playing the remaining episodes out. Then, since everyone could figure out when it was on, it got great reviews. (plus, the Schweet Schwag has started selling like crazy)the Invader Zim petition must have been pretty convincing as well. I guess one of them stopped to read it before wiping his ass. Maybe there's hope for a megaconglomo like Nikelodeon after all..."

Won't someone start making money with unmetered wireless? tabbser writes: "According to Aerie networks, the folks that bought bankrupt Ricochet (www.richochet.com) tests are being conducted in Denver, CO with the support of the City and county of Denver's Office of information technology. Ricochet will test and evaluate the network as part of an initial step to reactivating the service. The full story can be found on Ricochet's web site news room at http://www.ricochet.com. Go Aerie!" Aerie announced this a while ago, but in these uncertain times it's nice to see it actually happening.

Ashes to ashes, little blinking lights likewise. spike666 writes: "Blinkenlights.de is coming to an end! The Blinkenlights project by the Chaos Computer Club will be ending its run February 23, 2002. It was exposed to /. back here They are having a big party, and we're all invited. One last chance for Taco to embarrass Kathleen ..."

babbage writes:"As the banner above the title of James Tisdall's Beginning Perl for Bioinformatics indicates, this book is 'an introduction to Perl for biologists.' What the banner doesn't mention is that it's also an introduction to biology and bioinformatics for Perl programmers, and it's also an introduction to both Perl *and* biology for people that have never really been exposed to either field. The author has clearly thought a lot about making one book to please these different audiences, and he has pulled it off nicely, in a way that manages to explain basic topics to people learning about each field for the first time while not coming off as condescending or slow-paced to those that might already have some exposure to it." Read on for the rest of his review. Beginning Perl for Bioinformatics author James Tisdall pages 400 publisher O'Reilly & Associates rating 8 reviewer babbage ISBN 0-596-00080-4 summary Well-balanced approach to applying Perl's sorting and analytical abilities to the field of bioinformatics.

Superficially, this book isn't all that different from a lot of introductory Perl books: the Perl material starts out with an overview of the language, followed by a crash course on installing Perl, writing programs, and running them. From there, it goes on to introduce all the various language constructs, from variables to statements to subroutines, that any programmer is going to have to get comfortable with. Pretty run of the mill so far. Tisdall starts with two interesting assumptions, though: [1] that the reader may have never written a computer program before, and so needs to learn how to engineer a robust application that will do its job efficiently and well, and [2] that the reader wants to know how to write programs that can solve a series of biological problems, specifically in genetics and proteomics.

As such, there is at least as much material about the problems that a biologist faces and the places she can go to get the data she needs as there is about the issues that a Perl programmer needs to be aware of. The author introduces the reader to the basics of DNA chemistry, the cellular processes that convert DNA to RNA and then proteins, and a little bit about how and why this is important to the biologist and what sorts of information would help a biologist's research. The main sources of public genetic data are noted, and the often confusing -- and huge -- datafiles that can be obtained from these sources are examined in detail.

With the code he presents for solving these problems, Tisdall makes a point of not falling into the indecipherable-Perl trap: this is a useful language, well-suited to the essentially text-analysis problems that bioinformatics means, and he doesn't want to encourage the kind of dense, obscure, idiomatic coding style that has given Perl an undeservedly bad reputation. Some of Perl's more esoteric constructs are useful, and they show up when they're needed, but they're left out when they would only serve to confuse the reader. This is a good decision.

Rather, the focus is on teaching readers how to solve biological problems with a carefully developed library of code that happens to leverage some of Perl's most useful properties. The result is pretty much a biologist's edition of Christiansen & Torkington's Perl Cookbook or Dave Cross' Data Munging With Perl. The author presents a series of issues that a working bioinformaticist might have to deal with daily -- parsing over BLAST, GenBank, and PDB files, finding relevant motifs in that parsed data, and preparing reports about all of it. If a bioinformaticist's job is to be able to report on interesting patterns from these various sources, then following the programming techniques that Tisdall explains in clear, easy-to-follow prose would be an excellent way to go about doing it.

And when I say "programming techniques," note that I'm not specifically mentioning Perl. The code in this book is clear and organized, and all programs are carefully decomposed into logical subroutines that are then packaged up into a library file that each later sample program gets to draw from. Each new program typically contains a main section of a dozen lines of code or less, followed by no more than two or three new subroutines, along with calls to routines written earlier and called from the BeginPerlBioinfo.pm that is built up as the book progresses. Each sample is typically preceded by a description of what it's trying to accomplish and followed by a detaild description of how it was done, as well as suggestions of other ways that might have worked or not worked.

This modular approach is fantastic -- too many Perl books seem to focus so heavily on the mechanics of getting short scripts to work that they lose sight of how to build up a suite of useful methods and, from those methods, to develop ever-more-sophisticated applications. It isn't quite object-oriented programming, but that's clearly where Tisdall is headed with these samples, and given a few more chapters he probably would have started formally wrapping some of this code into OO packages.

If I have a complaint with the book, in fact, it's that Tisdall doesn't go any further: everything is good, but it ends too soon. Seemingly important topics such as OO programming, XML, graphics (charts & GUIs), CGI, and DBI are mentioned only in passing, under "further topics" in the last chapter. I also have a feeling that some of the biology was shorted, and the book barely touches upon the statistical analysis that probably is a critical aspect of the advanced bioinformaticist's toolbox. I can understand wanting to keep the length of a beginner's book relatively short, and this was probably the right decision, but it would have been nice to see some of the earlier sample problems revisited in these new contexts by, for example, formally making an OO library, showing a sample program that provided a web interface to some of the methods already written, or presenting code that presented results as XML or exchanged them with a database.

But these are minor quibbles, and if the reader is comfortable with the material up to this point, she shouldn't have a hard time figuring out how to go a step further and do these things alone. It's a solid book, and one that should be able to get people learning Perl, genetics, or both up to speed and working on real world problems quickly.

You can purchase Beginning Perl for Bioinformatics at Fatbrain. Want to see your own review here? Read the review guidelines first, then use Slashdot's webform.

tregoweth writes: "O'Reilly has an interview with Brewster Kahle about how The Internet Archive's Wayback Machine works, with lots of juicy details about how the biggest database ever built works."