> > > :) I'm writing it. Really though, I am writing a three part paper
> > > that I am going to donate to the Avalon project--I just need a word
> > > processor to write it at the beginning.
> >
> > Good you repeated that. I think I'll go and work on the phoenix
> > design documentation and javadoc then (I am assuming you are just
> > doing a 'hands-on' for your presentation?)
>
> 'hands-on'?
When you have like an hour you cannot really go into theoretical
advantages of component development, possible designs solutions
or detailed product comparisons on a high level.
> The ApacheCon specifies all papers and slides need to be
> made available in RTF (not HTML, Doc, PDF, or anything else).
> If only FOP handled RTF....
You could write in xml, xsl to html, open that in word, apply
some word template and save that as rtf - it's what I've done
occassionally.
> Here is my biggest delimna: I don't think I requested enough time
> with my session. There is just too much information.
fact: the average college graduate has trouble focusing on a given
subject for more than 50 minutes. The first ten minutes of a class,
lecture, session or whatever are almost completely non-productive.
Peak productive lasts from around minute 20 to minute 35. After that,
performance drops. How much depends on how motivated the audience is.
In any case, a 15 minute break (at least) is wise to have once an hour
(depending on your audience, preferably once every 40 to 70 minutes).
> I think that
> it's a double edged sword, and if I make the session too long, it
> will be a deterent, and if I make it too short I won't be able to
> disseminate the information.
Yep. When you are assuming intelligent, motivated people attending
the session, I'd go for a 15 minute introduction, then use the
most productive time to discuss design with programming examples
(I would always mix the two; design illustrated with example) for
40 minutes or so, and have a 5 min wrap-up at the end giving a
summary, pointing to the next session and allowing questions.
The next session should begin with a recap of the first (again, 15
min or so), then delve deeper into more advanced topics and filling
holes left in the first session. Ideally, that would be 20 minutes
followed by a 5 min break followed by a 40min workshop.
For ApacheCon, this is probably not an option so it should probably
be 40 minutes to fill the full hour (allow 5 min for wrap-up).
> I may have to break it down into 2 or three sessions. But, I would
> need to know--if you were at the ApacheCon (hypothetically speaking)
> how many sessions on Avalon would you attend?
I would never plan to attend more than one session about a project
I had not seen before (and I assume the vast majority of your
audience isn't very familiar with Avalon).
> I am thinking of doing the following approach:
>
> 30min: Introduction to Avalon
> 60min: Programming with Avalon
> 60min: Designing with Avalon
>
> Is this too much? Or, should I do two sessions:
>
> 60min: Designing with Avalon (introduction and analysis techniques)
> 60min: Programming with Avalon
I feel you should have two, where the first one is 'complete' in the
sense that following the second one is optional for those that are
interested in it after the first, like I outlined above.
> I am finding that it is very difficult to cram everything into one hour.
;) My advice: don't try to.
It took me about - i dunno - 10 hours to learn how to work with
Avalon, then another week to learn how it works internally, and
then another week to learn how to work with avalon properly;
how it will/should work internally is something we're still all
trying to figure out. That is never going to fit in 2 hours =)
Here's a suggestion:
"Avalon 101: use a cutting-edge Component Oriented framework to
build more reliable software while reducing costs and increasing
reusability. 1 hour session with Berin Loritsch."
"Designing with Avalon: learn more about the Avalon COP framework
and the components that come with it. In a 1 hour session, Berin
Loritsch will show you how to build applications so they make the
most out of Avalon."
(i.e. you need catchy descriptions =)
I have about 6 months of experience teaching kids of age 11-13
mathematics. What I've learned there holds true for adults as
well: within 3 minutes of getting interested in something, they
should have a clear picture of why it useful to them and what
steps they have to take to grasp the subject. My guess is that
for programmers with a masters degree, you can stretch minutes
into 6 or 7...if your first 6 minutes go well, the entire
session will thereafter be a success. If not...well, that 2nd
session will be a quiet one >:)
Some things to leave out of the picture:
- Cornerstone. Mention it exists, nothing more.
- LogKit. Most will be familiar with logging; logkit does the
job perfectly.
- threading, pooling, and similar topics. Each of them deserves
a separate session. Simply mention that avalon has implementations
for all the most neccessary problems, and perhaps use one or
two classes in examples.
You get the idea. I think an explanation of COP and patterns
along with their advantages, and then how Avalon provides and
enforces COP and pattern usage, followed by how to use
Avalon is 90% of your first session. The rest goes to fancy
talk about all the features of Avalon and why it will make you
rich.
Session 2 can go into provided components, which lifecycle method
to use for which task, .sars and .bars and the process to follow
when creating an avalon-based app.
That'd be my 2 cents*,
LSD
* perhaps I should speak of euros...I seem to have managed to
turn this into quite of a rant :-D
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
