Slashdot Mirror

Robert Nagle writes "Over the last year, Zope and Plone have gained mindshare as open source web application servers. In the last few months, two books have come out about how to use, extend and administer Plone. One is Andy McKay's Definitive Guide to Plone (available for free online), and the other is Julie Meloni's Plone Content Management Essentials." Read on for Nagle's review of both books. (See each) author (See each) pages (See each) publisher (See each) rating (See each) reviewer Robert Nagle ISBN (See each) summary McKay's book is indeed definitive; Meloni's book is a good introduction

The Zope/plone combination offers a variety of advantages to the open source developer: robust workflow capabilities, conformity to Web standards, cross-platform support and a sophisticated security model. On the other hand, it has a steep learning curve and deals with objects in an object database (instead of the usual RDBMS/LAMP data model).

First, here's 30 seconds of what Plone is all about (the Slashdot editors can provide the bunnies). Zope is a Python-backed web application server which includes a Zope Management Interface (or ZMI), a web-based interface to modify templates and interact with/administer the Zope Object Database (ZODB). Although Zope can be a standalone webserver, in fact people usually put it behind Apache for reasons of security, performance and caching. Years ago, Zope used a custom scripting language (DTML) to do its business logic, but later switched to an XML-based templating language called ZPT and let users use Python-based scripts to perform actions. Zope is the application server; CMF is the content management framework, and Plone is the standards-compliant front end that lets you manage skins, slots, styles, portlets, forms, actions, content types and installation of products. Then there's archetypes, which make it easier to create new content types and web forms. Oh, have I mentioned that we're dealing with objects here? In other words, we're not just throwing data and text into SQL); we're creating different types of content (documents, events, multimedia objects), storing them as objects (with actions, metadata, etc) and then summoning them (or parts of them) from the object database with ZPT using macros and indices.

From a design perspective, Plone is elegant although so multi-layered that it's often hard to figure out where to make changes. Also, while the Plone front end is snazzy, most users end up having to go to the ZMI to modify the template and edit actions (which, depending on how you look at it, can be an advantage or disadvantage). Finally, although the list of open source products for Plone and Zope is impressive, they don't necessarily play well together, and many products for Zope don't work in Plone and vice versa.

Definitive Guide to Plone author Andy McKay pages 584 publisher Apress rating 5 ISBN 1590593294

That is where Andy McKay's book and Julie Meloni's book come in. Of the two books, Andy's is more comprehensive and geared toward the experienced developer (and typical Slashdot reader); Julie's book does more hand-holding and provides more thorough explanations of introductory concepts.

As a lead plone developer, McKay has intimate knowledge of the good, the bad and the ugly for plone. Although his chapters fly by certain introductory tasks at record speed, he explains things well and offers lots of tips and hints throughout the book. (I can't tell you how many times I've put the book down and exclaimed, 'Aha, so that's how you ...'). The sequence of presentation is generally logical with one exception: in chapter 14 (page 459), the book mentions that you can use Zope Enterprise Objects to debug a live server without having to shut down Plone. That is valuable -- even vital-- information, and belonged in the earlier chapter on installing Zope. Although the chapters don't go into great depth, his code examples and commentary are sufficient to explain what is going on.

It's not the main focus of the book, but the sections on system administration (caching, tuning, scaling) are well done although some things are missing (like Virtual Host Monster). It's assumed that readers will be able to find this information elsewhere.

The best parts about McKay's book are how it relates Python programming to Plone. The deeper you get into Plone, the more important it is to write Python scripts and do basic Python debugging. Even basic sysadmin tasks like product management seems to require an understanding of object-oriented concepts. One initial difficulty comes with the idea of URL paths corresponding not to actual directories but objects being contained within other objects. (So that login_form in http://foobar/login_form doesn't necessarily reside within the foobar directory, but is in any directory or object acquired by the foobar object). This type of URL (called a traversal) is explained well enough in the book, but often makes it difficult to figure out where to find things within the ZMI and the file system. Who would have ever thought that the place to edit the login_form object for http://foobar/login_form is /foobar/portal_skins/plone_forms/login_form within the ZMI (which is actually /zopeinstance/products/CMFPlone/skins/plone_forms/ login_form.pt on the file system)? That's why McKay's skin example (in Chapter 7) accomplishes so many things; it provides a "guided tour" through the layers (i.e., scripts, templates, etc) contained within portal_skins; it also runs through the process of creating custom templates and forms based on existing ones. This, by the way, is one of the niftiest features of Zope/Plone; you push a Customize button in the ZMI, and voila! you've cloned an object for customizing. This is dense stuff, but after reading this chapter, I have a better sense of the beast I'm dealing with.

I particularly liked the book's chapters on archetypes and manipulating content types. If Zope/Plone is about manipulating objects, then it helps to have a variety of objects to manipulate. Archetypes lets you create new content types and new views for content types. By providing Python libraries for fields and widgets, archetypes makes it relatively easy to create web forms for data input. McKay's book covers this topic thoroughly and clearly. I also appreciated the chapter on searches and indexing (and the helpful table of indices and index types); this filled in a lot of gaps in my knowledge. The sections on security and workflow contained good examples, and the book also contained a section on internationalization. The programming chapters are the best parts about the book.

On the negative side, I wish there were more charts and tables in the book (perhaps as appendices). A lot of this is already found within Zope help or the Plone site, but it would have been handy to have these things as reference. Although McKay's book contains a good (though brief) introduction to Zope Page Templates, the explanation of the syntax is scattered throughout the ZPT chapter; it would have been much better to summarize all the tal tags in a single table.

Also, at many points during the ZPT chapter and other chapters, McKay refers to Plone and archetype API classes that are described nowhere else in the book. It took me a while to figure out where these things were coming from (and I would refer you to here for API descriptions). The book would have benefited from a better description of APIs, even a high level view of it (You can find some quick references here).

Because of its focus on development, McKay's book spends almost no time on third-party products or "sanctioned" products available in the plone collective. This is somewhat understandable (given the mercurial nature of product development), but the casual reader might finish the book without realizing that additional additional products even exist. (Here's a fairly comprehensive list of Plone and Zope products).

Also, I would have liked better explanation about change management. Plone has its own product installer, but I always have difficulties upgrading products. How do you test products before actually deploying them? How do you manage upgrades (and how do you upgrade Zope itself?) For such an extensible project as Plone, managing the installation, testing and upgrade of third-party products can be a disaster waiting to happen.

Plone Content Management Essentials author Julie C. Meloni pages 258 publisher SAMS rating 3 ISBN 0672326876

Julie Meloni's book takes a different approach to the subject, one geared less to Python development and more to deploying third-party products and customizing site appearances. I'm tempted to say that the typical Slashdot reader would find this book "shallow," but really that is not fair. Although Meloni's book contains a short appendix on Python, it focuses more on how Plone works out of the box and how to take advantage of core functionality. In fact, Meloni's slender book contains many useful sections probably deemed too elementary for McKay's book: how structured text works, for example.

Rather than trying to cover everything Plone-related, Meloni identifies a small number of typical tasks and explains them in detail. For example, the book documents the Plone style sheets and how to modify them in the ZMI. Too basic, you say? Well, yes, but it's still useful reference material. Rather than trying to teach you how to write your own Plone product or content type from scratch, she walks us through using that nifty Customize button to clone existing templates for customization (although to tell the truth, you still need would need to know a good bit about Python and ZPT syntax to complete the task). Although the book's section on skins focused mainly on how they relate to style sheets, I found the section on customizing slots to be particularly useful.

In contrast to McKay's book, Meloni spends a separate chapter on deploying and using several popular plone products: a discussion board, a weblog and a photo album. Given that several competing products exist for each category, and that better products are likely to come out later, this chapter will probably be the first to go out of date.

Perhaps the book could have spent less time on the products themselves and more on managing products and testing/troubleshooting them.

Of the two books, McKay's book is the more indispensable, even though I still wound up consulting external sources fairly often for clarification. On the other hand, after reading first McKay's book and then Meloni's, I wish I had read Meloni's book first. Meloni's book provides a great introduction to basic plone concepts; McKay's book is great for the power user/developer. (Still another book, recently released, Cameron Cooper's Building Websites with Plone probably goes into more detail on the Python side; read a sample PDF chapter).

Perhaps I sound like a shill for the publishing industry when I say this, but it sometimes make sense to possess two or more books on a topic. The decision-making process for geeks buying books can sometimes differ radically from the general public. Geeks, for example, don't have qualms about paying full price for a new book if the content is up-to-late and relevant to the task at hand. The ordinary reader might make a purchasing decision on the basis of which book constitutes the highest information density (the $20 book with 200 pages vs. the $30 books with 500 pages). Geeks are also more inclined to view the purchasing decision in terms of time saved (i.e., how much time will reading this book save me in the long run?) From the standpoint of saving time, there's a lot to be said for reading an introductory book first and then moving to a book on more advanced topics.

Of course, Andy McKay's book is available already for free on the web (and kudos to Apress Publishing for allowing this).

** Actually, mysql/postgresql DB adaptors make it possible for Zope to fetch/send sql data; and Archetypes has a function, SQLStorage, to allow data from content objects to persist in a sql database (news to me). Other Web Resources:

• Zopezen, Andy McKay's development weblog
• Plone How-to's
• List of Plone Products and Zope Products, Sorted by Category
• Zope & Plone API's. (More here).
• Great Visual Guide to the Zope/Plone Interface
• Handouts from the Plone Conference for 2003 and 2004
• ZopeMag Weekly, an intermittent series of Zope and Plone tips and tricks.
• For general Python introductions, see the Python Tutorial, How To Think Like A Computer Scientist (Python) and Dive Into Python (also published by Apress and free online)

Robert Nagle (aka idiotprogrammer) writes fiction under various pseudonyms. He lives and works in Houston, Texas. In early 2005 he will be launching a plone-backed literary community ezine. You can purchase the Definitive Guide to Plone from bn.com; bn also carries Plone Content Management Essentials . Slashdot welcomes readers' book reviews -- to see your own review here, carefully read the book review guidelines, then visit the submission page.

rjnagle writes "Eric S. Raymond (or ESR) is widely known for the groundbreaking series of essays in his book, The Cathedral and the Bazaar. In TCatB, he makes a credible case for why open source sofware works so well, and why community-supported software won't put developers out of a job. (I once attended a delightful talk he gave where, among other things, he gave sartorial advice to open source developers, urging them to avoid formal suits at presentations to CEO's as a way to give off the auras of foreign dignitaries unused to local customs). The arguments presented in Cathedral and the Bazaar were persuasive and original and now regarded as obvious. In his new book, Art of Unix Programming (available for free on the web), ESR stakes an even bolder claim: that initial design decisions make Unix uniquely well-suited to take advantage of open source's power. This book is an attempt to explain why Unix is so...well, Unixy." Read on for the rest of Nagle's review of The Art of Unix Programming. The Art of Unix Programming author Eric S. Raymond pages 560 publisher Addison Wesley rating great and free on the web! reviewer Robert Nagle ISBN 0131429019 summary Instructive for the Student; Profound for the Professional

On the surface, this book is a gentle introduction to programming; but in reality it is an attempt to explain the Unix aesthetic; at times I felt as if I were reading less a technical guide than an art history book, a chatty account of Gothic Architecture as told by someone who helped build a few churches himself. ESR articulates a set of design principles for Unix, which because of succintness deserve reprinting here.

1. Rule of Modularity: Write Simple Parts connected by clean interfaces.
2. Rule of Clarity: Clarity is better than cleverness.
3. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
4. Rule of Simplicity: Design for simplicity; add complexity only where you must
5. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
6. Rule of Transparency: Design for visibility to make inspection and debugging easier.
7. Rule Of Robustness: Robustness is the child of transparency and simplicity.
8. Rule of Representation: Fold Knowledge into data, so program logic can be stupid and robust.
9. Rule of Least Surprise: In interface design, always do the least surprising thing.
10. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
11. Rule of Repair: Repair what you can--but when you must fail, fail noisily and as soon as possible.
12. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
13. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
14. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
15. Rule of Diversity: Distrust all claims for one true way.
16. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

ESR shows how to follow these general principles while writing Unix programs. The central metaphors of Unix (that everything is a file, and data-streams that can be piped and redirected) are intuitive, and maximize transparency and separation. About pipes, he writes:

A subtle but important property of pipes and the other classic Unix IPC (Interprocess Communication) is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals (p 81, Chapter 3)

Interestingly, the real opposing aesthetic to the Unix aesthetic is not Microsoft (which really is a hybrid), but Macintosh:

The Macintosh's unifying idea is so strong that most of the other design choices we discussed above are either forced by it or invisible. All programs have GUIs. There is no CLI at all. Scripting facilities are present but much less commonly used than under Unix; many Mac programmers never learn them. Mac OS's captive-interface GUI metaphor (organized around a single main event loop) leads to a weak scheduler without presumption... Mac OS applications are not, however, invariably monster monoliths. The system's GUI support code, which is partly implemented in a ROM shipped with the hardware, and partly implemented in shared libraries, communicates with Mac OS programs through an event interface that has been quite stable since its beginnings. Thus, the design of the operating system encourages a relatively clean separation between application engine and GUI interfaces.

ESR's criticism right here (and throughout the book) is not necessarily condemnation. In fact, ESR recognizes that Macintosh as a competing aesthetic has a lot to offer that Unix does not. For example, Mac file attributes (in which a file has both data and resource "forks") provide mechanism for richer GUI support. Thus, we have (ESR says) developers "who work from the interface inward, rather than the engineer outward." In contrast, the Unix byte-stream metaphor may make it hard to conceptualize the meaning of operations such as Create, Open, Read, Write and Delete.

With Unix, the Rule of Least Surprise suggests that the developer delegate interface functions to a GUI or to another program. Instead of creating a built-in editor inside an application, the developer should allow the user to choose which editor to use. Instead of making a robust and easy-to-use interface, the Unix developer should produce a command line utility first, and then let someone else create a separate and independent GUI layer. (Rule of Separation). Xcdroast is a perfect example of a GUI layer for the command line program, cdrecord.

The Command Line Interface (CLI) may scare off new users, but it offers endless scripting and batching capabilities for programs (and smooth IPC). Also, it offers expressiveness to developers. "The Unix programmer," ESR writes, "is likely to see defaulting away from expressiveness as a sort of cop-out or even betrayal of future users, who will know their own requirements better than the present implementer. Ironically, though the Unix attitude is often construed as a sort of programmer arrogance, it is actually a form of humility -- one often acquired along with years of battle scars" (p.304, "Interfaces,")

ESR distinguishes between interface complexity and implementation complexity. Unix projects often involve tradeoffs on these two. The Unix developer prefers a lean and simple implementation at the expense of a usable interface; ESR writes:

Programs that mediate between the user and the rest of the universe notoriously attract features. This includes not just editors but Web browsers, mail and newsgroup readers, and other communication programs. All tend to evolve in accordance with the Law of Software Envelopment, aka Zawinski's Law. 'Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can'".

The book devotes considerable space to showcasing Unix best practices (which in most cases, means readable config files, limiting the program's scope, providing access to sufficient debug information and making it easy to hack). He offers sensible advice about when to use minilanguages ("don't extend your way to it, one patch and crufty feature at a time"), why to limit the number of available command-line switches (each one increases debug time), why optimization has few payoffs ("Moore's law implies a 26% performance gain just by buying new hardware every six months") and why bottoms-up programming can work better than top down design(because "it gives you time and room to refine a vague specification" when "...you are programming in an exploratory way, trying to get a grasp on hardware or software or real-world phenomena you don't completely understand.").

One of the most instructive chapters was about J. Random Newbie, a fictional programmer fresh out of college who understands basic programming concepts and the value of reuse. ESR presents a scenario of how Newbie nonetheless ends up rewriting rather than reusing, relying more on his own code than that of others. When he changes jobs, "he is likely to discover that he can't take his toolkit with him" and may even find it to be useless at a new job with different proprietary tools, languages and libraries. Thus, ESR writes:

Programmers have reuse (and other good practices that go with it, like modularity and transparency) systematically conditioned out of them by a combination of technical problems, intellectual-property barriers, politics and personal ego needs. Multiply J. Random Newbie by a hundred thousand, age him by decades, and have him grow more cynical and more used to the system year by year. There you have the state of much of the software industry, a recipe for enormous waste of time and capital and human skill -- even before you factor in vendors' market-control tactics, incompetent management, impossible deadlines, and all the other pressures that make doing good work difficult. (p.420, "Reuse")

This book is a good introduction for this newbie programmer (as well as a warning about what to expect). It offers practical advice about which license and language to use, how to set up documentation, how to decipher the standards process, how to check things into CVS and how to submit a patch to an open source project.

The chapter on Unix's history puts the current SCO/IBM controversy into perspective. Unix has always been dogged by exertions of commercial control, and ESR accurately conveys how the software world is constantly swinging back and forth from periods of intensely-creative free-spirited openness to periods of commercial control.

I was struck by several of ESR's observations: that Linus Torvald's "refusal to be a zealot" was a contributing reason why Linux was able to succeed; that both the patch utility and email probably did more to advance the Open Source movement than mere "consciousness raising."

In summary, this book is a great help for the student programmer. It synthesizes a lot of ideas and insights from other programming gurus, and is full of insights, aphorisms and fun digressions (no surprise to readers of ESR's other works). The experienced programmer, on the other hand, might find the book more profound than practical. Invoking the Zen metaphor (and even including Unix koans at the book's end), ESR shows us how the abstract nature of programming provides insight into problem-solving, design and yes, even a kind of enlightenment. The book, available for free on the Net, is probably better to read on vacation or an airplane or as a welcome break when stumped by a programming problem. More practical books on Unix programming exist (I happen to recommend Mark Sobell's), but ESR's book will stay with you long after you have finished reading, providing countless hours for reflection and appreciation of Unix's Unix-nature.

Robert Nagle (aka Idiotprogrammer), believes that plone is the best thing since garage door openers, and is a strong supporter of music sharing. You can purchase The Art of Unix Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "When Marc Prensky asked a colleague who had just returned from a training course how it was, she replied, 'AFTRB.' (Another #$#$^&# Three Ring Binder) . In his book, Digital Game-Based Learning , Prensky, an instructional game designer and founder of games2train, argues that computer games are more effective learning tools because they sustain interest and attention in settings where people are normally bored." To follow that train of thought (or if you just liked Ender's Game), read on below for Nagle's lengthy review of the book. Digital Game Based Learning author Marc Prensky pages 442 publisher McGraw-Hill Trade rating 5/5 reviewer Robert Nagle (aka Idiotprogrammer) ISBN 0071363440 summary Visionary book on instructional design and game design.

Digital Game-Based Learning (DGBL) consists of two parts. In the first part, Prensky argues that the prevalence of video games has actually rewired our brains and made traditional learning methods less effective. In the second part, Prensky makes the case that DGBL can be used successfully by corporations to train people and offers practical advice (based on vast experience) about how to deploy game-based training methods. Throughout the book, Prensky examines aesthetic, cognitive and pedagogical questions surrounding such games and provides dozens of case studies to illustrate his points.

Prensky argues that current learning methods for young learners fail to engage learners used to interactive media. Learners now expect interactivity. Prensky writes:

Games Generation workers rarely even think of reading a manual. They'll just play with the software, hitting every key if necessary, until they figure it out. If they can't, they assume the problem is with the software, not with them--software is supposed to teach you how to use it. This attitude is almost certainly a direct result of growing up with Sega, Sony, Nintendo, and other video games where each level and monster had to be figured out by trial and error, and each trial click could lead to a hidden surprise. Games are almost all designed to teach as you go.

Prensky believes that the instructor-led classroom and the teach-test method are actually historical artifacts no more than 200 or 300 years old. The teach-test instructor-led class and its instructional methods arose partially from the rise of the printing press and the widespread availability of reading material.

Why then does the teach-test method still prevail? One reason may be the generation gap and technology gap between learners and teachers. Even technologically savvy educators have biases towards methods that worked while they were learners themselves. The way we learn is to some extent a byproduct of the cultural and technological milieu we mature in. Twenty years ago educators were extolling the virtues of reading books while youngsters (including me) were "wasting" their time before the boob tube. Nowadays, undoubtedly, there is a tension between educators pushing "media literacy" (media, in this case, often equaling conventional TV broadcasting) and students too busy making additions to their online Sims house or watching webcams of friends to care. No matter how much you may try to keep up, I once told a group of middle-aged Ukrainian teachers, your students will always be more hip to the technology than you.

This is not merely a matter of age but of comfort level. Growing up with a technology (especially at an early ago) makes using it second nature. According to the neurology and psychology research that Prensky cites, the brain reorganizes and rewires itself in response to cultural stimuli, so a child who plays videogames at night is bored at class not because of "short attention span" or bad study habits but because the child's brain has programmed itself to respond better to "twitchspeed" interactivity. Prensky cites John Bruer's statement that achieving this kind of brain reorganization requires students to spend "100 minutes a day, 5 days a week, for 5 to 10 weeks to create desired changes because "it takes sharply focused attention to rewire a brain." Then Prensky adds, "Several hours a day, five days a week, sharply focused attention--does that remind you of anything? Oh yes -video games!" (p 43) . Interestingly, Prensky cites research about how children with attention deficit disorder are using video games to retrain their brain and help them to concentrate. For the game-playing child, going to school means having to "power down" and endure teaching methods ill-suited to him. (p44).

After Sesame Street showed that you could educate children by entertaining them (and sustaining their interest), games (and sometimes even instructional technology) have focused on how to sustain this interest. In an age where pop-ups, 15-second promos and CNN updates are everywhere, it is no wonder that "gaining attention share" is the central concern. Children have learned the art of selectively being able to tune out media. How then to keep their attention? Interestingly, this concern parallels that of game developers looking for better ways to sustain gameplay.

A child once described playing educational games as "hard fun." When people are "playing," they forget inhibitions and self-consciousness to concentrate on the game's mission (i.e, "learning objectives"). When I taught English to college students overseas, I was surprised to find that one of my weakest and least confident student interacted adeptly to an immersive role-playing game with a strong English language component. From my viewpoint, she was quickly comprehending spoken dialogue and responding appropriately. From her viewpoint, she had just crossed the bridge and now could start digging for gold. Cognitive breakthroughs often require distracting activity to allow the mind to refocus (visionary Alan Kay wrote, "people have more brainstorms on the jogging path than at their desks."). Educators typically view educational gaming as useful mainly for drill and practice, but as gaming environments become more complex, edugames may be more useful in providing roundabout paths towards concepts hard to reach by traditional methods. To use just one example, computer aids allow students to manipulate data and geometric figures as a way to experiment with mathematical principles. Indeed, one of Prensky's most successful game projects, the Monkey Wrench Conspiracy, taught young learners/players how to do 3D computer design by setting them in a spaceship with a mission to make repairs before the spaceship blows up.

The most fascinating section for me was Prensky's juxtaposition of game design principles alongside instructional design principles. Even if one doesn't accept Prensky's historical analysis (and thoughtful detractors like Kurt Squier have pointed out shortcomings) or his argument that games should be more widely used for training, Prensky's theoretical overview of game design should interest people in both the education and game camps. Both game designers and instructional designers are obsessed with epistemology: how to reveal information to the player/learner in a way that sustains interest; how to use conflict to change the player/learner's behavior or attitudes; how to provide enough feedback for the player/learner to change behavior; how to present a simplified view of the world without distorting it; and how to permit freedom of exploration within the constraints of an object-oriented world or of a lesson plan. These are concerns, by the way, that also interest writers of plays and fiction, except that the "player" is split into two roles: that of character (who is controlled by the playwright/writer controls) and audience (who can emphasize and anticipate, but can't change outcomes).

Prensky's grid that maps learning content to game styles (p156) indicates that sufficient varieties of games exist to tackle any training challenge. Electronic Jeopardy style games can drill employees about company policies (and these templates are commercially available and widely used). Realistic simulation games, although probably more costly to produce, may actually reduce training costs whenever the actual equipment or training environment is expensive to begin with. Better that the potential pilot crash-land a few Flight Simulator planes, or that the combat soldier accidentally kill a few civilians within a simulation environment than for real. Prensky offers good questions for evaluating the educational value of computer games: do people using it think of themselves as players rather than students? Is the experience addictive? Does it encourage reflection? Would the game be considered "fun" by someone outside the target audience? Despite the similarities, there are important differences, Prensky would argue, between games that entertain and those that educate. For one thing, successful games require visual external action to sustain attention. But this is not needed for certain domains of learning. Games may be good for learning the process of putting together a Burger King hamburger (p264), but would a game be practical for learning Java programming? Or Freud's theory of the unconscious? It's probably not impossible to design such a game; both Java and psychoanalysis involve understanding low-level mechanisms of causation, recognizing aberrant patterns and being able to select the correct algorithm from the available repertory of solutions. Role-playing and collaborative simulations would help. But what the learner needs most is FEEDBACK, game or no game. The assumption behind Prensky's advocacy of game-based learning is that content needs "livening up" or that external motivators (like video games) are needed to drive the students toward learning. I am not questioning the value of these "external motivators." But I have to wonder whether Prensky's pedagogical approach implies that certain kinds of learning activities cannot be self-motivating. Sure, a game about Java programming might amuse the CS student, but the more crucial question (I would argue) is whether this student finds the very activity of programming in java to be "hard fun."

To Prensky's credit, he does not insist that game-based learning is the best strategy for every learning situation. Perhaps the most compelling part of the book is a discussion of more than 40 case studies where computer games have been cost-effective at training. They range from an animated courtroom game (Objection) to a customer service game (where in the world is Carmen Sandiego's Luggage?) to a Sexual Harassment gameshow and many fine examples from Prensky's own company (which can be sampled online for free). He offers helpful advice (undoubtedly gained from experience) about how trainers can launch and even manage such a project. Among his suggestions: befriend IT as soon as possible; choose urgent learning needs that are "boring, complex or difficult," and offer game-based learning in conjunction with more traditional methods and give learners the option NOT to learn via the game method. Prensky offers practical suggestions to companies with training budgets ranging from the hundreds of thousands of dollars to nothing. Although the book is two years old, it still gives a good sense of what your money can get you these days.

Critics usually argue that "e-learning" doesn't compare favorably to live teachers. That is missing the point; the real question is whether e-learning (and game-based learning) provides comparable learning at a lower cost. As e-learning and game-based learning becomes more cost-effective, Prensky predicts a fairly radical transformation of the teacher/trainer's role. To some extent, this has already occurred with the advent of collaborative and student-based learning. But trainers may spend more time choosing the best learning tool for students (or creating new ones!) than actually teaching in a classroom. Is this bad? Prensky mentions that "any teacher who can be replaced by a computer, should be." In this world of game-based learning, Prensky argues, teachers can play a vital role in ensuring that students adequately reflect on the problems or conflicts that arose during the game/learning activity. Games are good at interactivity but bad at reflection. They offer ample opportunities for learning by doing, Prensky says, but minimal opportunities for reflection. One student, asked what he learned from playing SimCity, said, "I learned that if I don't feed the people, they will starve and die." That is clearly insufficient. A good instructor can help the student explore issues more deeply: how do politicians decide about allocating resources? Does the feedback offered to politicians give an accurate reflection of society's needs and problems? What strategies worked or did not work within the context of the game? Would these strategies also work in real life? Reflection is not necessary for every learning context, but today's trainers can make sure students have enough reflection to reap the benefits of game-based learning.

Prensky's book is an excellent introduction to this exciting field. He writes superbly and has a good grasp on learning theory and software design. Although clearly an enthusiast, he never implies that DGBL is the only or best teaching method. Many of Prensky's successes involve computer games as a primary component, but computer games don't need to play a central part in a lesson to be useful for learners. For example, a student can attend a traditional foreign language class and practice at home using a computer game. Ultimately computer games may have more value as supplemental material than as primary material.

Prensky's critique of the traditional trainer is sometimes unfair, especially the "generation gap" thing. Technology is not essential for reaching younger learners (and some experts have decried its overuse). Resourcefulness, a well-designed curriculum and motivational ability trumps game-based learning every time (even Prensky would agree with that, I think).

If we accept Prensky's premise that instructional methods are somehow determined by the prevailing state of technology, one starts down the path of saying that instructional methods are subject to obsolescence. New teaching methods may be more cost-effective or more motivating, but they don't necessary repudiate the value of "old-fashioned" methods (indeed, there will come a time when DGBL will be regarded as old-fashioned, so Prensky better watch out what he says). Using teaching methods so dependent on a technology, I would argue, has the unfortunate effect of rendering teachers helpless in the wake of massive technological breakdown. If a trainer/facilitator skilled in DGBL suddenly found his classroom without Internet access, could he still train employees effectively? One of my most edifying experiences as a teacher came at a Albanian university in Vlore lacking not only computers, but also copy machines and yes, sometimes even electricity. Every day I walked to class, mentally having to plan for contingencies (no electricity, inability to obtain photocopies from a nearby shop) for the day's lessons. While I still managed to pull off some funky lessons (with battery-powered cassette players, magic markers, magazine pictures and large posterboards), I couldn't help wondering if my "innovative teaching methods" merely burdened me with more things that could go wrong. The flip side of Prensky's magnificent vision is the nightmare scenario of teachers so overwhelmed with newfangled technological aids that they opt for the tried-and-true (but technologically primitive) methods rather than risk losing a class to downtime.

Although the spectacular successes mentioned in the book were informative, it also might have been helpful to examine cases where DGBL have failed or turned out to be not particularly remarkable. Every so often, a new theory or learning method hits the world, and suddenly educators use this method whether it is appropriate or not. When is DGBL not appropriate?

When making the business case for DGBL, Prensky overlooked two important things. First, the obsolescence of technology and technological standards (and the perception of obsolescence) diminishes the value of custom-built games for corporations. This seems to be an argument for using cheaper mass-market games rather than convincing the CEO to fund an ambitious game project. Also, I'm surprised that the book didn't spend more time on one obvious advantage to DGBL: digital assessments. Computer games make it easier to verify that learners performed required tasks and to keep the performance data in digital form to demonstrate compliance. That would be a big selling point for human resources.

I've written elsewhere that as immersive games become more sophisticated and develop their own society and values, real life will start to resemble a video game and videogame prowess may become an end worth pursuing for its own sake. Now that weapons and radar systems look more like computer games, for example, military recruiters might be happy with legions of game addicts manning their battalions. As it becomes easier to gain knowledge and experience completely from computer games, the notion of having to learn things from real life will start to seem very strange.

Other Resources

Marc Prensky has put generous excerpts from the book online for free. His company website contain a lot of fun free/demo games, including (my favorite) "The Challenge." Expect it to be slashdotted for a while. You can also buy the book here.

Kurt Squire of MIT's Games-to-Teach project , has written a preceptive article, Reframing the Cultural Space of Computer and Video Games and many other things on game-based learning , including an excellent critique of Prensky's book.

Dr. Sivasailam "Thiagi" Thiagarajan writes frequently on using games for training. His Thiagi website contains lots of freebies as well as a free monthly newsletter with lots of game/training ideas.

Gamasutra has a separate section on writings about educational games. Free registration is required.

Although not explicitly about game-based learning, Steven Poole's book, Trigger Happy offers a sophisticated aesthetic analysis of videogame narratives and engagement.

Robert Nagle (aka Idiotprogrammer) is a linux nut, technical writer and trainer with a background in instructional design and game design. He works for Texas Instruments in Houston. You can purchase Digital Game Based Learning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

rjnagle writes "When Marc Prensky asked a colleague who had just returned from a training course how it was, she replied, 'AFTRB.' (Another #$#$^&# Three Ring Binder) . In his book, Digital Game-Based Learning , Prensky, an instructional game designer and founder of games2train, argues that computer games are more effective learning tools because they sustain interest and attention in settings where people are normally bored." To follow that train of thought (or if you just liked Ender's Game), read on below for Nagle's lengthy review of the book. Digital Game Based Learning author Marc Prensky pages 442 publisher McGraw-Hill Trade rating 5/5 reviewer Robert Nagle (aka Idiotprogrammer) ISBN 0071363440 summary Visionary book on instructional design and game design.

Digital Game-Based Learning (DGBL) consists of two parts. In the first part, Prensky argues that the prevalence of video games has actually rewired our brains and made traditional learning methods less effective. In the second part, Prensky makes the case that DGBL can be used successfully by corporations to train people and offers practical advice (based on vast experience) about how to deploy game-based training methods. Throughout the book, Prensky examines aesthetic, cognitive and pedagogical questions surrounding such games and provides dozens of case studies to illustrate his points.

Prensky argues that current learning methods for young learners fail to engage learners used to interactive media. Learners now expect interactivity. Prensky writes:

Games Generation workers rarely even think of reading a manual. They'll just play with the software, hitting every key if necessary, until they figure it out. If they can't, they assume the problem is with the software, not with them--software is supposed to teach you how to use it. This attitude is almost certainly a direct result of growing up with Sega, Sony, Nintendo, and other video games where each level and monster had to be figured out by trial and error, and each trial click could lead to a hidden surprise. Games are almost all designed to teach as you go.

Prensky believes that the instructor-led classroom and the teach-test method are actually historical artifacts no more than 200 or 300 years old. The teach-test instructor-led class and its instructional methods arose partially from the rise of the printing press and the widespread availability of reading material.

Why then does the teach-test method still prevail? One reason may be the generation gap and technology gap between learners and teachers. Even technologically savvy educators have biases towards methods that worked while they were learners themselves. The way we learn is to some extent a byproduct of the cultural and technological milieu we mature in. Twenty years ago educators were extolling the virtues of reading books while youngsters (including me) were "wasting" their time before the boob tube. Nowadays, undoubtedly, there is a tension between educators pushing "media literacy" (media, in this case, often equaling conventional TV broadcasting) and students too busy making additions to their online Sims house or watching webcams of friends to care. No matter how much you may try to keep up, I once told a group of middle-aged Ukrainian teachers, your students will always be more hip to the technology than you.

This is not merely a matter of age but of comfort level. Growing up with a technology (especially at an early ago) makes using it second nature. According to the neurology and psychology research that Prensky cites, the brain reorganizes and rewires itself in response to cultural stimuli, so a child who plays videogames at night is bored at class not because of "short attention span" or bad study habits but because the child's brain has programmed itself to respond better to "twitchspeed" interactivity. Prensky cites John Bruer's statement that achieving this kind of brain reorganization requires students to spend "100 minutes a day, 5 days a week, for 5 to 10 weeks to create desired changes because "it takes sharply focused attention to rewire a brain." Then Prensky adds, "Several hours a day, five days a week, sharply focused attention--does that remind you of anything? Oh yes -video games!" (p 43) . Interestingly, Prensky cites research about how children with attention deficit disorder are using video games to retrain their brain and help them to concentrate. For the game-playing child, going to school means having to "power down" and endure teaching methods ill-suited to him. (p44).

After Sesame Street showed that you could educate children by entertaining them (and sustaining their interest), games (and sometimes even instructional technology) have focused on how to sustain this interest. In an age where pop-ups, 15-second promos and CNN updates are everywhere, it is no wonder that "gaining attention share" is the central concern. Children have learned the art of selectively being able to tune out media. How then to keep their attention? Interestingly, this concern parallels that of game developers looking for better ways to sustain gameplay.

A child once described playing educational games as "hard fun." When people are "playing," they forget inhibitions and self-consciousness to concentrate on the game's mission (i.e, "learning objectives"). When I taught English to college students overseas, I was surprised to find that one of my weakest and least confident student interacted adeptly to an immersive role-playing game with a strong English language component. From my viewpoint, she was quickly comprehending spoken dialogue and responding appropriately. From her viewpoint, she had just crossed the bridge and now could start digging for gold. Cognitive breakthroughs often require distracting activity to allow the mind to refocus (visionary Alan Kay wrote, "people have more brainstorms on the jogging path than at their desks."). Educators typically view educational gaming as useful mainly for drill and practice, but as gaming environments become more complex, edugames may be more useful in providing roundabout paths towards concepts hard to reach by traditional methods. To use just one example, computer aids allow students to manipulate data and geometric figures as a way to experiment with mathematical principles. Indeed, one of Prensky's most successful game projects, the Monkey Wrench Conspiracy, taught young learners/players how to do 3D computer design by setting them in a spaceship with a mission to make repairs before the spaceship blows up.

The most fascinating section for me was Prensky's juxtaposition of game design principles alongside instructional design principles. Even if one doesn't accept Prensky's historical analysis (and thoughtful detractors like Kurt Squier have pointed out shortcomings) or his argument that games should be more widely used for training, Prensky's theoretical overview of game design should interest people in both the education and game camps. Both game designers and instructional designers are obsessed with epistemology: how to reveal information to the player/learner in a way that sustains interest; how to use conflict to change the player/learner's behavior or attitudes; how to provide enough feedback for the player/learner to change behavior; how to present a simplified view of the world without distorting it; and how to permit freedom of exploration within the constraints of an object-oriented world or of a lesson plan. These are concerns, by the way, that also interest writers of plays and fiction, except that the "player" is split into two roles: that of character (who is controlled by the playwright/writer controls) and audience (who can emphasize and anticipate, but can't change outcomes).

Prensky's grid that maps learning content to game styles (p156) indicates that sufficient varieties of games exist to tackle any training challenge. Electronic Jeopardy style games can drill employees about company policies (and these templates are commercially available and widely used). Realistic simulation games, although probably more costly to produce, may actually reduce training costs whenever the actual equipment or training environment is expensive to begin with. Better that the potential pilot crash-land a few Flight Simulator planes, or that the combat soldier accidentally kill a few civilians within a simulation environment than for real. Prensky offers good questions for evaluating the educational value of computer games: do people using it think of themselves as players rather than students? Is the experience addictive? Does it encourage reflection? Would the game be considered "fun" by someone outside the target audience? Despite the similarities, there are important differences, Prensky would argue, between games that entertain and those that educate. For one thing, successful games require visual external action to sustain attention. But this is not needed for certain domains of learning. Games may be good for learning the process of putting together a Burger King hamburger (p264), but would a game be practical for learning Java programming? Or Freud's theory of the unconscious? It's probably not impossible to design such a game; both Java and psychoanalysis involve understanding low-level mechanisms of causation, recognizing aberrant patterns and being able to select the correct algorithm from the available repertory of solutions. Role-playing and collaborative simulations would help. But what the learner needs most is FEEDBACK, game or no game. The assumption behind Prensky's advocacy of game-based learning is that content needs "livening up" or that external motivators (like video games) are needed to drive the students toward learning. I am not questioning the value of these "external motivators." But I have to wonder whether Prensky's pedagogical approach implies that certain kinds of learning activities cannot be self-motivating. Sure, a game about Java programming might amuse the CS student, but the more crucial question (I would argue) is whether this student finds the very activity of programming in java to be "hard fun."

To Prensky's credit, he does not insist that game-based learning is the best strategy for every learning situation. Perhaps the most compelling part of the book is a discussion of more than 40 case studies where computer games have been cost-effective at training. They range from an animated courtroom game (Objection) to a customer service game (where in the world is Carmen Sandiego's Luggage?) to a Sexual Harassment gameshow and many fine examples from Prensky's own company (which can be sampled online for free). He offers helpful advice (undoubtedly gained from experience) about how trainers can launch and even manage such a project. Among his suggestions: befriend IT as soon as possible; choose urgent learning needs that are "boring, complex or difficult," and offer game-based learning in conjunction with more traditional methods and give learners the option NOT to learn via the game method. Prensky offers practical suggestions to companies with training budgets ranging from the hundreds of thousands of dollars to nothing. Although the book is two years old, it still gives a good sense of what your money can get you these days.

Critics usually argue that "e-learning" doesn't compare favorably to live teachers. That is missing the point; the real question is whether e-learning (and game-based learning) provides comparable learning at a lower cost. As e-learning and game-based learning becomes more cost-effective, Prensky predicts a fairly radical transformation of the teacher/trainer's role. To some extent, this has already occurred with the advent of collaborative and student-based learning. But trainers may spend more time choosing the best learning tool for students (or creating new ones!) than actually teaching in a classroom. Is this bad? Prensky mentions that "any teacher who can be replaced by a computer, should be." In this world of game-based learning, Prensky argues, teachers can play a vital role in ensuring that students adequately reflect on the problems or conflicts that arose during the game/learning activity. Games are good at interactivity but bad at reflection. They offer ample opportunities for learning by doing, Prensky says, but minimal opportunities for reflection. One student, asked what he learned from playing SimCity, said, "I learned that if I don't feed the people, they will starve and die." That is clearly insufficient. A good instructor can help the student explore issues more deeply: how do politicians decide about allocating resources? Does the feedback offered to politicians give an accurate reflection of society's needs and problems? What strategies worked or did not work within the context of the game? Would these strategies also work in real life? Reflection is not necessary for every learning context, but today's trainers can make sure students have enough reflection to reap the benefits of game-based learning.

Prensky's book is an excellent introduction to this exciting field. He writes superbly and has a good grasp on learning theory and software design. Although clearly an enthusiast, he never implies that DGBL is the only or best teaching method. Many of Prensky's successes involve computer games as a primary component, but computer games don't need to play a central part in a lesson to be useful for learners. For example, a student can attend a traditional foreign language class and practice at home using a computer game. Ultimately computer games may have more value as supplemental material than as primary material.

Prensky's critique of the traditional trainer is sometimes unfair, especially the "generation gap" thing. Technology is not essential for reaching younger learners (and some experts have decried its overuse). Resourcefulness, a well-designed curriculum and motivational ability trumps game-based learning every time (even Prensky would agree with that, I think).

If we accept Prensky's premise that instructional methods are somehow determined by the prevailing state of technology, one starts down the path of saying that instructional methods are subject to obsolescence. New teaching methods may be more cost-effective or more motivating, but they don't necessary repudiate the value of "old-fashioned" methods (indeed, there will come a time when DGBL will be regarded as old-fashioned, so Prensky better watch out what he says). Using teaching methods so dependent on a technology, I would argue, has the unfortunate effect of rendering teachers helpless in the wake of massive technological breakdown. If a trainer/facilitator skilled in DGBL suddenly found his classroom without Internet access, could he still train employees effectively? One of my most edifying experiences as a teacher came at a Albanian university in Vlore lacking not only computers, but also copy machines and yes, sometimes even electricity. Every day I walked to class, mentally having to plan for contingencies (no electricity, inability to obtain photocopies from a nearby shop) for the day's lessons. While I still managed to pull off some funky lessons (with battery-powered cassette players, magic markers, magazine pictures and large posterboards), I couldn't help wondering if my "innovative teaching methods" merely burdened me with more things that could go wrong. The flip side of Prensky's magnificent vision is the nightmare scenario of teachers so overwhelmed with newfangled technological aids that they opt for the tried-and-true (but technologically primitive) methods rather than risk losing a class to downtime.

Although the spectacular successes mentioned in the book were informative, it also might have been helpful to examine cases where DGBL have failed or turned out to be not particularly remarkable. Every so often, a new theory or learning method hits the world, and suddenly educators use this method whether it is appropriate or not. When is DGBL not appropriate?

When making the business case for DGBL, Prensky overlooked two important things. First, the obsolescence of technology and technological standards (and the perception of obsolescence) diminishes the value of custom-built games for corporations. This seems to be an argument for using cheaper mass-market games rather than convincing the CEO to fund an ambitious game project. Also, I'm surprised that the book didn't spend more time on one obvious advantage to DGBL: digital assessments. Computer games make it easier to verify that learners performed required tasks and to keep the performance data in digital form to demonstrate compliance. That would be a big selling point for human resources.

I've written elsewhere that as immersive games become more sophisticated and develop their own society and values, real life will start to resemble a video game and videogame prowess may become an end worth pursuing for its own sake. Now that weapons and radar systems look more like computer games, for example, military recruiters might be happy with legions of game addicts manning their battalions. As it becomes easier to gain knowledge and experience completely from computer games, the notion of having to learn things from real life will start to seem very strange.

Other Resources

Marc Prensky has put generous excerpts from the book online for free. His company website contain a lot of fun free/demo games, including (my favorite) "The Challenge." Expect it to be slashdotted for a while. You can also buy the book here.

Kurt Squire of MIT's Games-to-Teach project , has written a preceptive article, Reframing the Cultural Space of Computer and Video Games and many other things on game-based learning , including an excellent critique of Prensky's book.

Dr. Sivasailam "Thiagi" Thiagarajan writes frequently on using games for training. His Thiagi website contains lots of freebies as well as a free monthly newsletter with lots of game/training ideas.

Gamasutra has a separate section on writings about educational games. Free registration is required.

Although not explicitly about game-based learning, Steven Poole's book, Trigger Happy offers a sophisticated aesthetic analysis of videogame narratives and engagement.

Robert Nagle (aka Idiotprogrammer) is a linux nut, technical writer and trainer with a background in instructional design and game design. He works for Texas Instruments in Houston. You can purchase Digital Game Based Learning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Robert Nagle writes: "Apache's HTTP server has been by many measures the most popular web server on the web, and perhaps the primary application that drives people to Linux and open source. Three years ago, Wrox published the definitive book on running the Apache server by Peter Wainwright. Excellent though the book was, it badly needed updating. In May 2002, Wrox published another book, Professional Apache 2.0, which covers the new generation of Apache server, as well as older 1.3x versions that are still running production servers around the world." Robert's review continues, below. Professional Apache 2.0 author Peter Wainwright pages 873 publisher Wrox rating 5 Stars reviewer Robert Nagle, Idiotprogrammer ISBN 1861007221 summary Excellent, comprehensive Guide to the latest version of Apache.

Although Apache changed a great deal in its version 2.0, it is a credit to the Apache folk that the config files and command line options have basically remained the same for sys admins. For this reason, the book seems to include a lot of material (CGI security, building, core modules) from the original book. However, a closer look reveals many changes. Almost every chapter includes a discussion about how features differ in both versions of Apache. The book does a good job of giving an overview of Apache's architectural changes and how the use of multi-processing modules (MPM) allow the admin to choose an optimal implementation of apache. This edition, noticeably bigger than the previous one, contains many more examples of how one can extend apache functionality (configuring for binary distribution, setting up virtual interfaces, load sharing). Many sections have been expanded. The discussion of security and SSL is more detailed, yet more succinct; so is the section on content negotiation, (which is twice as long as the previous book), doing proxy server configurations, rsync and benchmarking performance. The discussion on hardening the server was great and up-to-date, although I wish the book spent more time discussing on patching and upgrading.

What is new to the book? We find a longer discussion of graphic administration tools for Windows and Unix, including webmin (which actually I wanted more of). We also have discussions of newer modules such as mod_ruby, mod_python, mod_dav as well as a brief description on how to install tomcat alongside apache. The discussion of mod_dav was especially helpful and interesting to me (and I was especially glad that the author acknowledged the Subversion DAV module, something which is bound to become more important). The php stuff hasn't changed much (although at the time the book was published, 2.0 compatibility with PHP was still an iffy proposition). The book's discussion of mod_perl isn't significantly different, although it does point out migration issues and some additional features.

Generally, the book is clearly written and contains enough examples to find any configuration you want. A few parts required rereading (especially the part about proxies and proxypasses), and occasionally I needed a better explanation of what the example code was supposed to do.

No book can be everything for everybody, and nobody can accuse the book of not having enough content (it is after all more than 700 pages!). I found myself wishing for other things. The book briefly discussed 2.0's support for ipv6, but I longed for a fuller explanation and a more detailed example (Fortunately, I had seen a good ipv6 tutorial on Linux Journal ). Also, I would have liked more information about other web application servers (like zope that Apache sometimes coexists with, content frameworks (such as cocoon) and other goodies produced by the Apache Foundation. The author might legitimately feel that such subjects lie outside the book's scope, but such topics are becoming more important.

In summary: for newbies who are looking for a guide to start with: this is the definitive book to read. It's definitive and a little imposing, but it is well written and logically arranged.

For people already familiar with Apache 1.3 but looking for more depth about ipv6, php, content frameworks or Tomcat, it might be better to read books on those specific subjects instead of this one. Indeed, Wrox will soon be coming out with a book specifically on Apache and Tomcat.

For experienced system administrators, the material in this book may not be terribly new, but they will still appreciate the variety of configuration examples for managing large numbers of virtual hosts and the convenience of having documentation of the 1.3/2.0 differences at their fingertips.

You can purchase Professional Apache 2.0 from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.