![]() |
![]() |
![]() |
|
|
|
|
|
|
|
|
|
Toys of the Trade Your mission today is to teach the principles of client/server computing to 20 people who either:
In short, you've got the students from hell. Moreover, nothing is drier than the principles of client/server, except, maybe, networks. And to teach client/server principles, you need to review networks. Boring! So, how do you introduce complex technical concepts to people without putting them to sleep? I do it with a bunch of high-tech tools and a series of simulations I call "crazy stuff" - a derivative of androgogy. Ann Angel-Parker, president of Technology Training of the Triad in Winston-Salem, N.C., explains androgogy this way: "Adult learning theory is developing, designing, and delivering training targeted to meet the immediate needs of adult learners. Adults learn in order to accomplish goals. If an adult does not see a reasonable return on the investment, he or she will not make the transition to the new skill or tool." Androgogy says that the best way to teach adults is to teach them the way they learn best - by engaging in the learning process. In other words, by doing. By example. By case study, which combines doing and example. By reference to what they already know, especially via analogy or metaphor. And by having fun. My high-tech tools? Legos, Barbie dolls, decks of cards - whatever works. I use Legos to teach client/server principles, and I orchestrate games of Family Feud to introduce Internet and intranet issues. I've used Barbie and Ken to explain objects. And I've held complicated four-deck games of War to demonstrate how a data warehouse works. Calling "JaneNet" Back to your classroom of aggressive programmer wannabees, teeth bared, waiting to trip you up. Put them to work building a "Client/Server House" and you'll disarm them in a moment-and teach them basic client/server architecture to boot. Build the client/server house out of Legos. This is a simulation exercise that demonstrates the key principles and issues of client/server. It does double duty by simulating client/server as both a development environment (a project to build the house one time) and a production application environment (a repeatable production-line process to build multiple houses.) Since client/server is inherently a network architecture, start the simulation by building the network. Ask a student to volunteer to role-play the network, which involves carrying messages and "data" between the other simulation participants. If no one volunteers, ask the class to volunteer someone who:
Once selected, the network person gains a new name, at least for the duration of the simulation. Thus, Jane becomes JaneNet. Now that the network is "up," break the class into "server" teams. Since one of the major reasons for using a client/server architecture is to improve performance via parallel processing (multiple independent processes operating simultaneously), the simulation should involve multiple teams, each separately and concurrently performing their own tasks. After extensive research at Toys 'R Us, I chose the Lego System 545 kit since it builds a house in five distinct sub-assemblies: first floor, second floor, picnic table, landscaping, and pickup truck. Unfortunately, Lego no longer makes the System 545, but you will find numerous other systems that will work just as well. Qualify the students to work with Legos by asking, "Are you now, or have you ever been, four years old?" Break the qualifying students into groups of three to five: one group per sub-assembly plus one group for final assembly. Prepare the exercise pre-class by separating the Lego pieces by subassembly. I keep mine in labeled self-locking baggies. You also need to make a copy of the instructions that come with the set for each sub-assembly team. Breaking down the initial work into sub-assemblies and distributing it to server groups simulates the decomposition and application partitioning that client/server design teams must perform to achieve the benefits of parallelism. It also demonstrates assignment of partitioned components to specialized servers, which in real life would improve overall performance if each server were optimized for its specific sub-assembly tasks. Explain to the teams that they will get their instructions and building materials (baggie full of parts) from the "database server," which can either be the instructor or another student. To get their parts, the teams must make requests over JaneNet. Just like with real client/server systems, the only way to communicate is via the network. While each team operates independently, using the pieces and instructions they receive from the database server, a team can request resources - a missing block, for instance - from another team, via JaneNet. Faulty Foundations, Missed Deadlines As each team completes its sub-assembly, they request JaneNet to deliver it to the final assembly team for, well, final assembly. Now the real fun begins. The final assembly team has to make the individual house parts fit together and work as a complete unit, demonstrating the critical importance of shared specifications. Often, the second floor sub-assembly falls apart as it's being attached above the first floor, or sub-assemblies won't fit together because a team didn't follow the instructions perfectly. So the house faces rework, adjustment and delay - just like a normal client/server application development or production environment. Time the exercise and make the teams aware of the world record - eight minutes, achieved twice in five years. Normal is about 15 minutes. (If the simulation takes more than 20 minutes, stop it and discuss why and how it went so wrong.) Timing emphasizes that the principle objective of client/server is to improve performance through parallel processing and server specialization and customization. As a point of comparison, assembling the house serially (step-by-step) rather than in parallel takes approximately 40 minutes. I call out the elapsed time and have the class whistle or hum the Jeopardy theme during final assembly to encourage (harass?) the integration team, simulating the typical pressures that come to bear during the final stages of a project. Of course, immediately after the exercise talk about what happened during the simulation. This way, you explicitly cement the connections between building a Lego house and building or operating a client/server system. The processes the teams invent and the problems they encounter are as instructive as is completing the house. These exercises work because they furnish the immediacy that adult learners require by engaging the learners and because they're fun-fun to watch and, most of all, fun for the learners to do. Clearly, there's a lot of work involved with crazy stuff. Why go to all the trouble to research and develop these exercises? Because learners remember what they do better than what they're told. Legos work better than lecture. Ultimately, there may be no better foundation for a real client/server house than a plastic pickup truck full of toys. Advanced Crazy Stuff Crazy stuff works best when it's also humorous. It's fairly easy to create crazy stuff, but more difficult to add the humor that makes it work the best. Since few of us are Robin Williams funny, we need a formula to create crazy stuff that works. (Keep in mind that humor is tricky business.) Do stuff in class that's mildly outrageous in at least one of these ways:
Reprinted from Inside Technology Training April/May 1997. Copyright © 1997 Ziff-Davis Inc.
|