Slashdot Mirror
mod_perl Developer's Cookbook
This book uses the popular "cookbook" approach, where the content is broken down into short "recipes" each of which addresses a specific problem. There are almost two hundred of these recipes in the book arranged into chapters which discuss particular areas of mod_perl development. In my opinion the cookbook approach works much better in some chapters than in others.
It's the start of the book where the cookbook approach seems most forced. In chapter 1 problems like "You want to compile and build mod_perl from source on a Unix platform" provide slightly awkward introductions to explanations about obtaining and installing mod_perl on various platforms (kudos to the authors for being up-to-date enough to include OS X in the list). All the information you want is there however, so by the end of the chapter you'll have mod_perl up and running.
Chapter 2 looks at configuration options. It tell you how to get your CGI programs running under mod_perl using the Apache::Registry module which simulates a standard CGI environment so that your CGI programs can run almost unchanged. This will give you an immediate performance increase as you no longer have the performance hit of starting up a Perl interpreter each time one of your CGI programs is run. This chapter also addresses issues like caching database connections and using mod_perl as a proxy server.
We then get to part II of the book. In this section we look at the mod_perl API which gives us to the full functionality of Apache. This allows us to write Perl code which is executed at any time during any of the stages of Apache's processing.
Chapter 3 introduces the Apache request object which is at the heart of the API and discusses various ways to get useful information both out of and back into the object. Chapter 4 serves a similar purpose for the Apache server object which contains information about the web server and its configuration.
In chapter 5 the authors look at Uniform Resource Identifiers (URIs) and discuss many methods for processing them. Chapter 6 moves from the logical world of URIs to the physical world of files. This chapter starts by explaining the Apache::File module before looking at many ways to handle files in mod_perl.
The previous few chapters have built up a useful toolkit of techniques to use in a mod_perl environment, in chapters 7 and 8 we start to pull those techniques together and look in more detail at creating handlers - which are the building blocks of mod_perl applications. Chapter 7 deal with the creation of handlers and chapter 8 looks at how you can interact with them to build a complete application.
Chapter 9 is one of the most useful chapters in the book as it deals with benchmarking and tuning mod_perl applications. It serves as a useful guide to a number of techniques for squeezing the last drops of performance out of your web site. Chapter 10 is a useful introduction to using Object Oriented Perl to create your handlers. While the information is all good, this is, unfortunately, another chapter where the cookbook format seems a little strained.
Part III of the book goes into great detail about the Apache lifecycle. Each chapter looks at a small number of Apache's processing stages and suggests ways that handlers can be used during that stage. This is the widest ranging part of the book and it's full of example code that really demonstrates the power of the Apache API. I'll just mention one particular chapter in this section. Chapter 15 talks about the content generation phrase. This is the phase that creates the actual content that goes back to the user's browser and, as such, is the most important phase of the whole transaction. I was particularly pleased to see that the authors took up most of this chapter looking at methods that separate the actual data from the presentation. They have at recipes that look at all of the commonly used Perl templating systems and a few more recipes cover the generation of output from XML.
Finally, two appendices give a brief reference to mod_perl hooks, build flags and constants and a third gives a good selection of pointers to further resources.
This is the book that mod_perl programmers have been waiting for. The three authors are all well-known experts in the field and it's great that they have shared their knowledge through this book. If you write mod_perl applications, then you really should read this book.
You can purchase mod_perl Developer's Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
blah fdsaf fa asd s fsda fsda fsda fasd asdf asdf s
Ewing retires, accepts coaching job with Wizards
...'''
Associated Press
NEW YORK -- As Patrick Ewing talked about his retirement, there was a softness in his eyes, a relaxed look replacing the glare he used while establishing himself as one of the 50 greatest players in NBA history.
Patrick Ewing
Patrick Ewing will go right from his official retirement as a player to the Wizards' bench as an assistant coach.
Then Ewing saw old pal Charles Oakley in the back of the room and his eyes danced. ''My hit man, Oak! We had some times, didn't we, Oak?'' Ewing shouted from the podium.
Indeed they did.
And for a fleeting moment Tuesday, Ewing was back under the basket with Oakley, the two battling for baskets and bounces, trying to put the New York Knicks over the top.
They never quite got there, but they had fun trying.
For 15 years, Ewing was the centerpiece of the Knicks, New York's go-to guy. There were two wrap-up seasons with Seattle and Orlando, footnotes to a career as one of the league's most dominant centers.
The 40-year-old Ewing finishes his NBA career with 24,815 points and 11,606 rebounds. He'll move on to become an assistant coach for Michael Jordan and the Washington Wizards.
The 11-time All-Star holds a number of Knicks records, including leading scorer (22.8 points) and leading rebounder (10.4). Most of the time, Oakley was right there with him.
''He came to work every day,'' Oakley said. ''He put a lot of effort into what he wanted to do, what he wanted to accomplish.''
Also attending Ewing's farewell news conference were ex-teammates Charlie Ward, Allan Houston, Herb Williams and Mark Jackson; coaches Mike Jarvis, Don Chaney and Jeff Van Gundy; and Miami's Alonzo Mourning, out for the season with the Miami Heat because of his kidney condition.
Ewing was asked how he wanted to be remembered.
''As a hard hat,'' he said. ''A hard nose. The work ethic I brought, I gave it 110 percent. I thought I had a great career. I have no regrets. I wouldn't trade it for anything. I enjoyed every minute.''
The NBA championship was the missing piece of the puzzle for the man who led Georgetown to three NCAA finals, including the 1984 title, before becoming the No. 1 pick in the first NBA lottery draft.
''I'm disappointed I never won a championship -- in the pros,'' Ewing said. ''We did the best we could to help the franchise win one. It didn't happen. That's life. You've got to move on.''
In 1994, Ewing led New York to a 3-2 lead over the Houston Rockets in the NBA Finals before losing in seven games. He said his greatest memory was converting a putback on a shot by John Starks that beat Indiana for the Eastern Conference title and put the Knicks in those finals.
Ewing was injured in 1999 when the team lost in the finals in five games to the San Antonio Spurs.
Now, he'll be an assistant coach with the Wizards, Jordan's team.
After general manager Wes Unseld signed him, Ewing was asked about the irony of working with Jordan, who often denied him his shot at an NBA title.
''Instead of needling me from afar, he'll be needling me in the same town. We'll be in the same organization,'' Ewing said.
Pat Riley, who coached Ewing and the Knicks to the finals in 1994, said: ''I'm sure that his next career in coaching will be just as successful as his playing career.''
For owner Abe Pollin, the signing of Ewing brings an important asset to the Wizards.
''It will be a unique opportunity for our players to be tutored by three of the 50 greatest players of all time -- Michael Jordan, Wes Unseld and now, Patrick Ewing,'' he said.
Ewing said he had thought hard about retiring, discussing it thoroughly with friends and family.
''It's still a hard decision,'' he said. ''It's still 50-50. Should I play? Should I retire? I felt I could still play.
''It's time to move on. It was a great ride.''
So what happens if sometime next season some NBA team decides it needs help in the middle? Is Ewing available?
He laughed at the question.
''A few teams called,'' he said. ''I made this decision anyway. Unless one of the Wizards goes down and they tell me, 'Put down the pad, we need you to go get some shots
Dave Checketts, longtime president of the Knicks, remembered Ewing's work ethic. In a game against Milwaukee, the center banged his knee and, with the Knicks comfortably in front, he went to the dressing room. Checketts came down to join him.
As the two men sat, talking basketball and families, the Bucks sliced the Knicks' lead to single digits. Ewing, watching on the dressing room television, took note of the situation, removed the ice from his knee and stood up.
'''Look,''' Checketts recalled him saying, '''I've enjoyed talking to you, but I've got to go.'''
''He pulled the sleeve over his knee, went back out to check into the game and we won it.''
Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language.
To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I've never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.
C's biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C requires a programmer to laboriously work with chunks of memory.
Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.
Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or - even better - Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.
So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and C#.
Having programmed in both for many years, I believe that C# has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java's source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. Microsoft's "shared source" under which C# is released definately seems to be the most fair and reasonable of all the licenses in existance, with none of the harsh restrictions of the BSD license. It also lacks the GPL's requirement that anything coded with its tools becomes property of the FSF.
I hope to see a switch from C/C++ to C# very soon. I've already spoken with various luminaries in the C coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Alan Cox, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in C#. Richard Stallman plans to support this, and hopes that the great Swede himself, Linus Torvalds, won't object to renaming Linux to C#/Linux. Although not a C coder himself, I'm told that Slashdot's very own Admiral Taco will support this on his web site. Finally, Dennis Ritchie is excited about the switch!
Thank you for your time. Happy coding.
mod_perl is so slow, I heard the U.S. Postal Service wants to use it.
Geoff Young is one of the sexiest men on the planet.
ah, that would make sense.