On Sun, Dec 10, 2000 at 06:13:13PM +0800, Gunther Birznieks wrote:
> It sounds to me like you have hit the nail on the head. Perhaps what is
> needed in terms of recouping costs for a mod_perl hands-on development
> course and/or online course is the open source/collaborative approach.
>
This seems to be a good solution to this problem. Instead of
one person sucking up the costs of developing these courses, we could
get a group together to do this. Sounds good to me.
> I would be willing to donate my time to write and initially test the
> exercises to the slides that are taught for the days. If a couple people
> were to donate their time to writing the slides based on an outline
> produced by Stas and Randal.
>
So would I. I'm more than willing to proof read, test, and be a guinea pig.
> We could host it on sourceforge as the modperltraining project. Sourceforge
> could also host the mailing list.
>
> Then regardless of if Randal would then be willing to take the course
> material and beta test it as a class he offers (eg maybe giving the course
> itself would not be profitable for him), we ourselves could be giving this
> course all over the world in beta-test Perl Monger groups.
>
Yet another good idea. We all love open-source, and collaborative efforts, so
let's create a good set of training materials, and then let people teach this
material in their own neighborhoods.
> I know there are still issues such as getting people of the same level of
> expertise in the same room and mod_perl not being a "core" technology, but
> I think mod_perl can be taught assuming similar requirements as the PROM
> class you offer as an initial thought? mod_perl doesn't require all of
> PROM, but probably about a day of it would be integrated to bring people up
> to speed on the basics?
You lost me here. I'm not sure what "core" technology means. I always thought
it would be relatively easy for an experienced teacher to develop a coherent,
reliable course for mod_perl, as long as some requirements are met (able to program
perl and able to configure and administer an apache server). Once those guidelines
are met, discussing the Apache API, going into detail on each of the response phases,
and going through examples and exercises, would flow somewhat unfettered.
1. the Apache server life cycle
2. the request loop
3. Discussion of the API for each phase of the loop with examples
4. Exercises
This would take about 3 (maybe 4) days with someone who meets the pre-reqs. 1 for the
intro and terminology
1 long day to discuss the APIs for each phase (maybe two), and 1 day to go over
exercises and have some "lab" work.
This is just a rough estimate, and if someone thinks I've lost my coconuts let me know.
Getting someone up to speed on mod_perl (not Apache::* modules, but the perl API to
Apache),
shouldn't take too long. I'd say about 1-1.5 hours for each stop in the request loop.
4-5
hours to teach someone the guts of Apache, including terminology and the real base
knowledge
stuff, and 8-10 hours to go over exercises, and develop skeleton handlers.
We are looking at about 30 hours of hard, hard work. They don't call some training
sessions
"boot camps" for nothing.
Again, feedback is good. Just make it constructive. Calling me a "moronic putz"
isn't helpful,
but saying "Hey, Moronic Putz, you underestimate ...." is good.
> helping with this project, please email me privately. If I get enough
> people willing to contribute (at least 5), I'll set up the sourceforge
> project to start the ball rolling Oh yeah, did I say I didn't mind donating
> my admin time as well to this experiment. :)
Count me in. I'll be willing to guinea pig stuff and give feedback, as well
as do research and help out more experienced teachers.
>
> Later,
> Gunther
>
>
JJ
--
J. J. Horner
[EMAIL PROTECTED]
Apache, Perl, mod_perl, Web security, Linux
