Slashdot Mirror

Noiser writes "The Israeli pop singer Aya Korem published her new song "Computer Engineer" as a website that shows translation to the Perl programming language along with the lyrics. Perl is quite a good match, given that the Perl community has a long tradition of publishing "Perl poetry", and this song proves that this tradition is very much alive. No Flash is required to view the website, so if you are an HTML5 geek, have no worries."

parasew asks: "I am searching for Web-based Project Management Software, which should be (mod-)perl based, so I can enhance it or put it into an existing environment using MovableType, which is in a sort of alpha-state. I found a site about Call Center, Bug Tracking and Project Management Tools for Linux and also this short listing, but sadly they are just a bunch of projects which only come close to the kind of tool I am searching for. Gantt and Chronos, seem to be a very nice Web-Calendar packages written in Perl. I was just wondering why no one is using iCalendar (does anyone know of Perl-based Software using iCalendar), as most of the Agenda Software uses iCalendar, and even Mozilla Calendar is capable of subscribing to remote-Calendars. This looks very interesting to me. In general, I wanted to ask you Monks for the best way to do this. Should I create a new app from scratch or reusing existing stuff?"

"Here are the features I am looking for:

• The use of Calendars (multiple users) and iCalendar Support
• File-Pool for projects (CVS-based or similar)
• Progress-bar for showing the current state of a project
• A public calendar where users can publish events from their private calendars

I found a simple Calendar script from PerlMonks, and another easy one here. Of course, there are really lots of Calendar scripts out there, but I am asking you for hints. Which ones do you know of that comes close to my needs? There are several existing Modules for iCalendar on CPAN, and i thought about reusing stuff to maybe create a dirty hack of Chronos, Bricolage and add the CVS and iCalendar support on my own.

Please also see my topics on PerlMonks and MovableType

Thanks for any help, hints or suggestions."

parasew asks: "I am searching for Web-based Project Management Software, which should be (mod-)perl based, so I can enhance it or put it into an existing environment using MovableType, which is in a sort of alpha-state. I found a site about Call Center, Bug Tracking and Project Management Tools for Linux and also this short listing, but sadly they are just a bunch of projects which only come close to the kind of tool I am searching for. Gantt and Chronos, seem to be a very nice Web-Calendar packages written in Perl. I was just wondering why no one is using iCalendar (does anyone know of Perl-based Software using iCalendar), as most of the Agenda Software uses iCalendar, and even Mozilla Calendar is capable of subscribing to remote-Calendars. This looks very interesting to me. In general, I wanted to ask you Monks for the best way to do this. Should I create a new app from scratch or reusing existing stuff?"

"Here are the features I am looking for:

• The use of Calendars (multiple users) and iCalendar Support
• File-Pool for projects (CVS-based or similar)
• Progress-bar for showing the current state of a project
• A public calendar where users can publish events from their private calendars

I found a simple Calendar script from PerlMonks, and another easy one here. Of course, there are really lots of Calendar scripts out there, but I am asking you for hints. Which ones do you know of that comes close to my needs? There are several existing Modules for iCalendar on CPAN, and i thought about reusing stuff to maybe create a dirty hack of Chronos, Bricolage and add the CVS and iCalendar support on my own.

Please also see my topics on PerlMonks and MovableType

Thanks for any help, hints or suggestions."

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

Jodrell writes: "(via PerlMonks) Bernd Dulfer has posted a Quick Reference Guide to Perl 6, based on Larry's Apocalypses and Damian's Exegesises, as well as Parrot. The Guide is available in POD and RTF formats."

BorrisYeltsin writes "Big news in the Perl community this week is that Parrot 0.0.7 now out. New in this release is "Perl 6 grammar (with small, partial compiler), functional subroutine, coroutine and continuation PMCs, global variables, an intermediate code compiler (imcc), a pure-Perl assembler and working garbage collection." Also there are more Parrot docs! Check out the news here."

cascadefx writes "It appears that this programmer has created an Open Sourced Unix Desktop, PerlBox, written in Perl and Tk. I found this posted in response to an article on Perl Monks asking if Perl was obsessed with CGI?. Apparently not. Check it out, it looks pretty interesting." I wonder how fast it runs?

cascadefx writes "It appears that this programmer has created an Open Sourced Unix Desktop, PerlBox, written in Perl and Tk. I found this posted in response to an article on Perl Monks asking if Perl was obsessed with CGI?. Apparently not. Check it out, it looks pretty interesting." I wonder how fast it runs?

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

elfdump writes "Tilly, one of the Perl Monks, has been threatened with lawsuits from his employer for performing open-source development. His company claims ownership on all of the GPL'd work he has performed since he was hired, including rights to portions of the Carp and Exporter modules. In addition to his code being pulled, Tilly's revolutionary ideas on regular expression engines (1, 2) may now never be fulfilled. In this statement, Tilly warns open-source developers of the dangers of the "work for hire" provision in contracts, which entitles a company to all of its employee's intellectual products, regardless of their applicability to the company or whether or not the ideas were developed on work time. Definitely something to consider if you perform OSS development." One thing to clarify: your employer does not own everything you do by law - only by the contract you may have signed. Brief rant below.

A lot of people think they have no negotiating ability. You do. When you're thinking of signing on with some company, and they send you a boiler-plate contract to sign, don't just sign it and send it back. Read it carefully. Alter it as you see fit, striking out sections, adding sections, and initialing each change. Then sign it, make a copy for yourself, and send it back.

Where it says:

company owns the rights to all work produced during the term of employment

Just strike it out, and change it to:

company owns the rights to code written during working hours and in direct furtherance of any tasks assigned by the company

See how much nicer that reads? Now, when you do this, there are two possibilities: either the company will ignore it and hire you, or they will object to your alteration of the contract. In the second case, if they stand firm on the boiler-plate contract, I suggest you simply ask for more money - for instance, if you were expecting an 8 hour/day job and their contract asserts that they own what you do 24 hours/day, then you'll need at least three times as much salary to compensate.

And if you and the company cannot reach an agreement, well, maybe you didn't want to work for them anyway. If they're already screwing you before you've even signed on, that's not a good omen.

There's already some good advice in the comments on the perlmonks story, so I'll leave it at that.

BorrisYeltsin writes: "A couple of updates for Parrot are in a recent This Week on Perl 6, most imporantly Parrot 0.03 is out! Get it here , the release notes are here. Also Adam Turoff has got together the Parrot FAQ version 0.2 which addresses some of the more common questions about Parrot and Perl 6."

Puppet Master writes: "Just remembered that Perl was created on this day (12/18) in 1987 by Larry Wall..." Check out the Time Line and the discussion on use.perl.org and I'll take this chance as a reminder to donate to the Damian Conway/Dan Sugalski slavery fund.

buzzcutbuddha asks: "I have been tasked with creating/finding a Collaboration and Knowledge Management tool for work, and while there are some good commercial ones out there like Intraspect and Microsoft Sharepoint, but I want to look at it from another angle. Most people are aware of online community models like Slashdot, Kuro5hin.org, Everything2.org, it's Perlmonks derivative, and Wikki Wikki Web. Some may even remember SixDegrees from before it was retired. But are there any other notable online communities that have similar functions to the systems described above? I'm looking for a way to let people load documents or link to documents, discuss the documents, moderate the submissions and comments, and do searches. At this point, the underlying technology is not important."

Eric asks: "I am a software developer getting acclimated to the bioinformatics space by reading through introductory texts like 'Genome : The Autobiography of a Species in 23 Chapters' by Matt Ridley, 'Genomes' by T.A. Brown, and bio journals. I find these sources to be exceptionally interesting but frequently the information is too detailed or too light for my purposes. I think the ideal information would come from a monthly magazine or online forum (like Slashdot) that is geared towards bright non-biologist computery folk (think Dr. Dobbs with an emphasis on computational biology -- light but definitely not fluff). I am particularly interested in new discoveries, research techniques, and experiments in this space. I am also budget constrained, and only have $100 a year set aside to access this kind of material. Does something like this exist, if so which ones do you recommend?" I think this question serves as a fine follow-up to our last question on Bioinformatics, may I suggest yet another starting point for those interested in this subject?

andy@petdance.com asks: "Any programmer who's used an online programming resource or community has had the frustration of answering programming questions for non-programmers. This is especially true with web-centric technologies like Perl and PHP. I've always wondered where to point these newest of the new, and O'Reilly's latest Ask Tim article addresses this. Unfortunately, Tim suggests picking up an ORA book on ActionScript, which seems a bit too specific. Are there any good introductions to the concepts of programming? And is any such book necessarily tied to a language?"

Saint Aardvark the Carpeted writes "Check this out for sheer genius...This guy has posted to Perl Monks a script that uses the Perl Eliza module to respond to spam. Check it and contribute your suggestions for improved vocabulary." The downside of course is that spammers never set their reply correctly (which I think is forgery, and should be treated as such) so this is probably more academic then useful, but its definitely funny.

Saint Aardvark the Carpeted writes "Check this out for sheer genius...This guy has posted to Perl Monks a script that uses the Perl Eliza module to respond to spam. Check it and contribute your suggestions for improved vocabulary." The downside of course is that spammers never set their reply correctly (which I think is forgery, and should be treated as such) so this is probably more academic then useful, but its definitely funny.

raelity writes: "The O'Reilly Network is featuring An Introduction to Extreme Programming, by Chromatic (of Slashdot and PerlMonks fame). 'The central tenet is, "Find the essential elements of creating good software, do them all of the time, and discard everything else." Programmers should program and make schedule estimates. Managers should make business decisions. Customers should choose the features they want and rank them by importance.'"

We've been at LinuxWorld for the last couple days, and some interesting stuff has been going on: The SAMBA folks won the $25,000 IDG/Linus Torvalds award, and SGI announced the availability of RH7-based distro using XFS ^[?] . In other news, our BOF went well with many questions about Slashcode - and the Perl Monks booth has been doing great in donations. Update: 02/01 05:18 PM by CT : The highlight for me so far was judging the "Coveted" Golden Penguin Awards w/ Don. Actually, I seriously did covet the award, beautiful hand blown glass penguin made me wish I was a contestant. We judged that Linus got the definition of BogoMIPS wrong. Fortunately his still won, but it was truly joyous seeing the surprise on his face.

Jonas Acres writes: "Lowtax of the [in]famous Something Awful has posted a commentary on the future of Internet advertising. It's a pretty interesting read. He's bounced from dying ad network to dying ad network, so he has a decent platform to preach from." I've also had to deal with a number of ad networks over the years - both for Slashdot prior to the Andover acquisition and a couple of other projects. It definitely sucks. Companies that break contracts, don't pay you, and never getting any return phone calls or anything is the norm that I dealt with.

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.

In addition to all the other books he has insightfully reviewed, chromatic has written this review of CGI Programming With Perl. This books sounds like a great resource for the builder of dynamic Web sites with a Perl background. And isn't it nice to see a book with "an unapologetic Unix flavor"?

CGI Programming with Perl author Scott Guelich, Shishir Gundavaram, & Gunther Birznieks pages 451 publisher O'Reilly & Associates rating 9 reviewer chromatic ISBN 1-56592-419-3 summary Your guide to the protocols and practices of CGI programming, with a look at current tools, tips, and tricks.

The Scoop Static web pages sufficed back when the web was young. Information flowed one way (like it does on most corporate sites today). Those days are long behind us -- if you want dynamic and interactive content, a whole host of technologies have appeared to fill in the gaps.

Enter Perl and CGI -- the original Swiss Army chainsaw of programming met the standard for exchanging data over HTTP and it was good. Thousands and thousands of programmers discovered this combination of power and simplicity, and the web has never been the same. Now, it's your turn to descend into the mysteries of query strings and stateless transactions, hoping to emerge successfully with the knowledge of simple -- yet interactive -- web programming.

In this second edition, the authors have gone far beyond CGI circa 1996. New topics include XML, search engines, security, and high performance Perl-based alternatives to CGI. How far we've come...

What's to Like? The book begins with an explanation of HTTP. Understanding the underlying protocol gives a picture of the whole process. The same is done for CGI, examing the interface -- the environment, input, output, and headers. It's simple enough that the description never bogs down, but detailed enough to explain difficulties CGI authors must work around (session management being high on the list).

From there, it's on to forms and HTML and, before spending much time trying to write a custom decoder for form data, it's off to CGI.pm. (That's important, because it's hard to get this right, even for authors of some other CGI programming books.) As befits the module, this chapter explains handling input, generating output, and handling errors.

Shift gears for a second, and think about embedding your code in your HTML. Try SSI, HTML::Template, or Embperl. (This is just a taste of the techniques available for templating -- see Template Toolkit or Mason for other nice ones.) Following that, grit your teeth and learn some of the JavaScript you've been putting off. Use it to add an additional client-side form input checker, hook it up to your Perl with WDDX, or discover the powerful Bookmarklet.

Consider security in chapter 8 -- now that you've learned some cool tricks but before you know enough to get into real trouble, discover the vulnerabilities and how you can program around them. Use Perl's Taint mode and your web server configuration to help you out. Do not skip this chapter -- read it, then read perldoc perlsec until you get it. (It's a good chapter, but security can be hard, so don't rely on just one source of information.)

The rest of the book is a tour of various tasks you might want to accomplish. They're good too, but things shine again in the last three chapters, with help for the new, curious, frazzled Perl CGI programmer. How do you get rid of that annoying 500 server error? How can you make your program worth using for the next three years instead of worth throwing away every three months? How can you write something that will handle a hundred users a day? A thousand? A front-page link on Slashdot? (The answer is more than just FastCGI or mod_perl, though they're definitely the heavy guns.)

It's definitely time for a second edition of this tome. The expanded coverage of CGI.pm and templating technologies is a welcome addition. Promoting the use of the existing well-tested, documented, and debugged tools will, hopefully, lead to more maintainable code. Unlike some other books, the example code is clean and worthy of emulation. Hit the references and recommendation section in Appendix A for more good information, including relevant RFCs. Really. (It's a good sign for a Perl book to mention both the CPAN and perldoc, as in Appendix B.)

What's to Consider? Be careful about copying code blindly from the first few chapters without reading at least chapter 8 (and perldoc perlsec in Perl's included documentation)! Simple examples are appropriate for teaching and personal testing, but could have disastrous consequences on publicly-accessible servers. To the authors' credit, even the simple example code runs with warnings, taint mode, and the strict pragma.

You'll need to know some Perl -- at least enough to follow along with somewhat-idiomatic code. Platform and portability wise, there's an unapologetic Unix flavor to the examples. Nearly everything should work on Win32 and other operating systems, but be aware of certain differences. As for web server information, it's Apache-specific. (Configuration for other platforms will be similar, but is left as an exercise for the reader.)

Some topics could use more treatment. It would have been nice to have more information on HTML::Mason (though admittedly complex, it's powerful and probably deserves more than a two page introduction) and XML and Middleware. New technologies like RSS and WAP need tools and users and programmers. There's also more to say on debugging CGI applications, though a pointer to the facetiously named Idiot's Guide could be helpful.)

The Summary Newly updated, chock full of good advice and, above all, high-quality code, this book is a great place to learn how to focus your Perl skills in a popular direction. Follow the advice presented, ask around for help if you need it, and have fun. Don't bother spending 24 hours or 21 days or whatever it is now, learn CGI programming with Perl the right way.

special thanks to the amazing Simone at O'Reilly for her help making these and other reviews possible!

Table of Contents

1. Getting Started
2. The Hypertext Transfer Protocol
3. The Common Gateway Interface
4. Forms and CGI
5. CGI.pm
6. HTML Templates
7. JavaScript
8. Security
9. Sending Email
10. Data Persistence
11. Maintaining State
12. Searching the Web Server
13. Creating Graphics on the Fly
14. Middleware and XML
15. Debugging CGI Applications
16. Guidelines for Better CGI Applications
17. Effeciency and Optimization

1. Works Cited and Further Reading
2. Perl Modules

You can purchase this book at ThinkGeek.

With a planned move to San Francisco next summer, last week saw San Jose's last Linux World Expo, at least for now. The future as always is stubbornly uncertain, but it's impressive that the serendipitous combination of Free tools (from GNU) and a Free kernel (from Linus) has inspired enough interest and prosperity to excite a larger group of people each year. If you've not had the chance to attend one of these expositions, we hope this article will give you a flavor of what it's like. Note: Here are a few pictures from the floor (Day 1 & Day 2) contributed by Sensei^); do you have any cool shots to link to in comments?

First, the prelude: If you've worked on the pre-show aspects of anything from a high-school play to a LAN party, you know all those booths, displays, people and computers don't materialize by themselves. For several days before the show floor opened on Tuesday, forklift crews zipped cargos of wooden, fiberglass, plastic, aluminum and steel cases from moving trucks to exhibit spaces. These contained banners, snap-together modules, computers, lighted signs -- and Yes, more gratis logo-imprinted toys than you can wave a TuxTops LED light at.

Spiderwebs of CAT-5 and electric cord (run beneath the show floor) sprouted from the centerpoints of many booths, with strands for each computer to be connected to the Net during the show. Rolls of padding and carpet came next, then the slow assembly of display booths. These ranged from no-nonsense fabric partitions that housed companies like TuxTops and Sendmail (and legions of volunteers from PerlMonks, the Simple End User Linux project, Flightgear, and many others), to elaborate constructions with motorized signs, projected lasers and huge illuminated logos. Note: Slashdot (the site) was put together last week mostly from the comfy chairs of the PerlMonks booth.

The "C" (as in conference) part of LWCE got started on Monday, and for the days that followed, attendees got instruction -- on everything from Linux security to evangelizing Free software to their bosses-- in half-day doses. Meanwhile, the setup work continued into the wee hours, as exhibitors raced the clock to make sure that at least their signs, if not their networks, were up for the next day. And at the OSDN booth (home of the red-carpeted Slashdot stage and beanbags), prep work included stacking thousands of boxed distributions of Debian, and attempted to pawn a few copies off on every passer by.

Tuesday morning, at a shade before 10:00, visitors willing to miss Michael Dell's keynote began to stream into the halls, on a quest to find new distros, old friends, and swag. It's amazing what companies will give away in order to snag a little nook in your brain. Besides the usual trinkets (keychains, T-shirts, stickers) and the distributions that a Linux show would be empty without, booth visitors were handed everything from knives (Sendmail) to cute monkeys (Helixcode) to embarrassing pictures of themselves (BSDi), as well as too many toys with embedded LEDs to bother counting. Rather than a full swag accounting (which would only annoy those unable to attend), let me just say that you won't hurt for toys when the chance presents itself. (CT:I just wanted to note that VA gave away 2300 pounds of shrink-wrapped boxed Debian. Like 5000 copies. It was beautiful)

The things on display around the LWCE floor were more interesting than the toys, though. (And unlike a museum, most were available for hands-on demonstration, not hidden behind glass.) Indrema showed a prototype player (not in the sleek black box you see on their Web site, but still sporting that cool blue LED) hooked up to a HDTV display, playing a very fast game of Quake. (CT:Actually it was an HDTV demo, they promised the real deal will be less vaporous before I have children) In the Intel booth were server clusters populated with quad Itanium processors, demonstrating failover when one system was rudely but intentionally shut down. The amazing-like-emacs-is-amazing Flightgear project showed a really nice looking demo which is enough incentive by itself to invest in a better video card for my system so I can play with it.

Both Helixcode and Eazel made their first LWCE appearance this time around, exciting for those filling their anti-FUD cannon for the perpetual "Linux is tough to use" argument. The Eazel folks showing off Nautilus seemed to be all but cackling as they showed off the smoothness of the zooming information available for documents and the cool music-integration abilities it contains. It would have been cool if they'd had some sample CDs, but they promise a developers' release soon. (CT:They also promised .deb's, but I'll believe it when I see it. The UI was awesome, I just hope that someone hacks in something like the GUI command line in EFM)

Considering that Sun was showing off the GNOME desktop on Solaris (hinting at its inclusion in stock Solaris systems sometime very soon, too) and that the GNOME project itself was not only in one of the small booths against the wall but the subject of a big announcement -- about the advent of the GNOME Foundation -- it looks it's showing up everywhere. Happily, there seems to be no shortage of room for window managers right now: the KDE folks were also there not only in their own booth, but showing up in software demonstrations all over the floor, as SuSE, Caldera and others demonstrated the very slick KDE 2.0. (Can't we all just get along, anyhow?)

SuSE, by the way, was the only distributor I noticed showing off Linux on Apple hardware, and their current distro was sweet and fast on a G4. Beyond the curious lack of Apples, and the obvious ubiquity of x86 machines, there were machines based on everything from microcontrollers to StrongArm, MIPS, Alpha, Itanium ... even the IBM S/390s which have gotten attention for the ridiculous number of concurrent Linux systems they can support.

For all the cool hardware and cusp-of-reality, bleeding-edge distros, it's interesting that the announcement which seemed to generate the most buzz of the entire show was the long-awaited release of Debian's Potato. Considering the reputation that Debian has for intelligent upgrading, stability, and diligence in guarding the license of the software which makes it up, it's not as surprising as it might otherwise be that Debian's new release made people sit up a bit more than the newest offerings from the large commercial distros.

(CT: Also extremely impressive was the Pocket Linux booth, where they actually had iPaq's running Linux. The first dude that demoed the box to me was very nice, but what I really wanted to see was X11 running on it ... oddly enough, I encountered one of his cohorts in the bar later that night who showed it to me: X, xeyes, xterm, and twm running on an iPaq. When they get the wireless action going on these things I'm totally there ... I'll just need to hack minimalist interfaces onto pronto and my MP3 player software and use the thing as a portable X terminal on the local 802.11 wireless lan. Yum.)

Oh, and there were people on the floor as well -- close to 20,000, all told. I met some folks I've known previously only through IRC, and quite a few I might never have otherwise encountered.

It's interesting to see in the space of a few hours many of the smart people who you may experience vicariously through writings, speeches, code, art or IRC chatter -- and it also belies the idea that software celebrities of the Free software world are becoming celebrities of the traditional variety, since everyone from ESR to Jon "maddog" Hall (and Linus himself) are willing to talk to anyone who catches up with them long enough to say hello. The atmosphere (especially outside the mondo corporate-castle booths) is mellow and accomodating, and suprisingly so even within most of those castles. There were undoubtably personality conflicts at work, but it seems like most people have the good grace to deal nicely with each other for these few days at least.

At the close of each day, people shuffle out to drop laptops, T-shirts and bags of stuff at their hotels, then thousands of them show up to parties sponsored by companies from AMD to Red hat to VA, which are full-blown events in themselves. Mandrake's party, for instance, had go-go dancers in cages, which may be the most bacchanal thing I have ever witnessed. Ironically, though, many coders couldn't attend even events sponsored by their own companies, or thrown in the honor of their projects, because of strict carding policies. Wouldn't a chem-free party or two be a thoughtful way to include people?

(CT: This has been a consistent problem for several years. Although I know at "Someones" party (no names *grin*) they weren't carding, and I recieved many a happy note from fellow attendees proclaiming that they were able to get in. The parties themselves weren't bad: the OSDN/Potato release party was fun, with San & Zak spinning the tunes (next time we'll force CowboyNeal to scratch for us under threat of death). They had 2 buildings: one was a pool hall, where we tormented The Pope for nearly an hour, carefully distracting him, and then returning his balls to the table. He never noticed. We also met up with Nitrozac from After Y2k, and I snuck accross the street to the Eazel party for a bit, and got to meet Dave "You might remember me from cheat codes in some first person shooter" Taylor.) Attendeees mostly filed out for flights or drives home Thursday and Friday, but some are still in San Jose for the Intel Developers Conference, or otherwise enjoying the Northern California weather. It's a strange familiarity that many of them will feel when the next big conference rolls around, to see many of the same fellow attendees or workers -- of course, by the time the next big conference happens, perhaps we'll all be too excited by the release of 2.4 to notice.

Couple of Perl Bits fell into the bin worth noting today: dlc writes, "The results of the Perl Poetry Content are in, and are available." If you're into this sort of thing, you'll dig it. A lot of clever stuff there. Course the sonnet generator is probably my favorite... hack it to generate rock lyrics, and I can start a band and record a debut album. ;) If that's not weird enough for you, check out the PerlOS Project. A PerlWM, a PerlSH, and more. It will strike fear into even the most hardened of Perl Monks.

Simon Cozens writes "I've written a summary of what's new in the 5.6.0 release of Perl for this www.perl.com article. " The article does a good job of evaluating what's come out - worth reading if you're a Perl Monk