I'm interested!

[Rob Wehrli]

"Douglas R. Jerome" wrote:
> 
> Rob Wehrli wrote:
> >
> > C++ is a good choice for languages, any comment on topic?  Mechanics?
> > Design/Architecture?  Libraries?  3rd party tools?  C++ is a very broad
> > topic!
> 
> Design/Architecture
> I think the other things are more easily selftaught (just read the
> docs).
> 
> I wouldn't mind help tackling someone's design/architectural issues
> in each meeting.

I think that it is a bit optimistic to think that we could adequately
confront real-world design "issues" in a meeting of not more than about
45-minutes available for such discussion.  If the issues were relatively
academic in nature, we'd have a better chance.  More often, I think we
would find that "real world" issues are fairly involving and requiring
of more due-dilligence than a "devel session" allows.  Additionally,
since I don't see much, if any, of that happening here, where it would
do the most good, I feel less inclined to believe that it would
facilitate more readily in a group meeting environment.  I don't mean to
take the wind out of any sails by these statements, however, such could
evolve into it given a bit more interaction through this medium.  I've
seen entire sessions devoted solely to discussing dynamic arrays, and
they aren't exactly what I'd call "design issues," though they do
represent some mechanical options.

We'd probably be better off sticking to fundamentals initially where the
goal would be to (hopefully quickly) bring the group up to a common
level.  Topics might include exception handling, iostreams, templates,
advanced pointers, memory management, etc.  However, we're back to
mechanics.  If not mechanics, then we're on to APIs/Libs.  Granted,
these are relatively easily self-taught compared to sharing heated
philosophical design debates.  Maybe we're better off posing the
question of WHY are we doing this again?  What are our expectations and
what do we feel, as a group, the minimum goals for the group are from
these actions?

Don't get me wrong: I certainly like the idea of sharing discussion
about architectural and design choices implemented using C++ from the
real-world, but I'm not very sure that we'd really ever solve anything
:)  If we could at least gain some fresh insight and new problem solving
techniques, I think our general purposes for doing this would be solved.


> 
> > Someday, it would be fun to talk about some of cool things we could do as a
> > group to demonstrate distributed systems using OO and related technologies.
> > Perhaps we could all decide on a game idea using OpenGL and implement its
> > various facets using a distributed model where everyone who comes online
> > adds a piece to the puzzle in a cool way?  We define an object model and
> > interface specification for interactive objects (or borrow from an existing
> > standard) and a suitable class library and bang out a few pieces?  As the
> > pieces grow, so does the capability of the game...then, as more people get
> > involved through the 'net, more objects flow back into the library/server
> > components?
> >
> > Just a thought...
> 
> Whoa... sounds BIG.

My goal in making this statement was to illustrate that our group
learning process may better happen as a result of a "real" project. 
Having a project and working on it are the only practical ways to solve
problems, IMHO.  By having to go through the process of integrating code
and having a public demonstration of our results through a web
site/other 'net-accessible method, our need for recognition and for
ensuring that we move the project along in a useful way are gained.

> 
> I've got a small, threaded, follower-leader model server (front end)
> that

Follower-leader requires that the leader expect rationality from the
follower.  In distributed architectures, rationality is much less easily
"assured."  It may be implied, especially if the result is desirous. 
Generally speaking, I'd look to common, existing distributed
architectures for proof of "what worked" and adopt or extend those lines
of thinking.  In any software "creation" are we trying to accomplish
some given task/tasks?  ...or are we trying to create the newest,
coolest meaning-of-life app/lib/algo?  If our goal ends up being the
production of some functional representation of work, then our focus
tends to orient toward appling the existing set(s) of tools that further
that goal,  (Connect the dots API) while creating only those pieces
where buy -vs- build is clearly build.  When we think of a game, we have
a lot we *must* create in terms of character frameworks, rules and
decision support mechanisms, graphical entities and storyboard in
addition to all of the "realism" elements needed for a suitable gaming
world.

Along those lines, wouldn't it be "fun" to take a thoroughly documented
storyline, create the appropriate objects for it and allow the play
mechanisms to effectively change the outcome of the story based on the
interaction of players as characters in the story?  The general theme
here from the sw-dev perspective is to not have to come up with an
exciting story, hundreds of little characters with personalities, places
and locations all on our own, but to implement documented ones already. 
Then, so that the story doesn't end like book, allow the story "board"
to diverge wherever player/characters interact differently from the
story.  Build in a bit of ELISA "AI" and allow the objects to decide for
themselve from a suitable interface implementation how they'll proceed. 
Allow a variety of "influences" to be randomized and create a suitable
log of play paths for review and eventual "handlers" for unexpected
paths.  The point is all of it becomes a useful exercise that, once
accomplished, serves as a tremendous value to the entire group from the
perspectives of having learned, played and created elements of the
game.  Since the characters are already largely "defined," the challenge
to implement them becomes more of a "modeling real life" (even though
they're story characters) expression of skills rather than a "I'm a
software GOD, I can create it however I wish because my status as deity
says I can!"  ...which really does little to serve "real world"
interests of employers and most software development projects. 
Typically, we all have to write code that maps some real world domain
into a software/object model representation so that its usefulness is
made mechanized and therefore more readily/easily/predictably/reliably
accomplished.

Here is a not un-serious suggestion:  Take the story of Alice's
Adventures in Wonderland.  There are a bunch of characters, places and
things along with a fairly well-documented set of (at least implied)
personalities and event history lessons useful in initially
representing/mapping that world to software.  I believe that Alice's
author is still dead and that the copyright is now public domain...and
that the full, unabridged text is a publicly available download.  There
are countless objects to implement to add to the realism.  I'd recommend
an initial design take on only the mechanics of implementing the
functional aspects of the objects and leave all representation of action
to a series of function calls and/or property changes and resultant
event/event propagation models.  Then, as that becomes facilitated, the
GUI "presentation" methods can be added to actively adapt to prop
changes/reimplementation of the function call.  The idea here is a clear
separation so that the proper abstraction/encapsulation and (eventually)
polymophism "promises" of OO are realized.  We strictly simplify the
output as much as possible to a common data definition language such as
XML.  Subsequent phases take either direct messaging or XML-based
messages and parse them into whatever presentation is appropriate to
either the data or the presentation interpreter's discretion.  The
obvious overhead of XML is at least partially mitigated by its
extensibility...remembering, of course, the X in XML :)  Given suitably
lightweight data messaging and the assumed instantiation of a
"real-time" parser and perhaps a XML<->Object conversion/interpreter, it
may be suitable for an applet-based brower-delivery mechanism suitable
for any desktop.

Oh well, these ramblings are little more than representative steps
needed to conquer some of the challenges Microsoft is currently
addressing in their latest offerings.  A "GPLd" version of our
accomplishments given back to the community might serve to help move
more tools into the channels for developers seeking something other than
Big M, Big S, Few $ Left in Pocket...even fewer choices left in
mainstream corporate America where we eventually huddle for that
biweekly homage to the payroll god.

> I wouldn't mind having comments on how to link together amoungst several
> computers. Its STDC though.

RPC is my life, man.  Seriously, no problemo.  There are about 7 million
ways to get there.  Deciding which one(s) to try is the hard part!  I
implemented a distributed object server system using sockets and high
level messaging along with cautiously few-ish uses of RPC under
Objective C on HPUX and NextStep some many moons ago.  The key to all of
it tends to be keeping it simpler first, and adding functionality atop
of basic features.  Scalability ends up being a gotcha unless you've got
a lot of experience working in such systems.  My experiences tend to be
on the order of 10s of thousands of connections rather than in the
millions of them the way "big" enterprise seems to need to manage.  The
most exciting thing in terms of big numbers I've done was with a web
site that averaged 6 million hits a week.  Places like Yahoo! and Amazon
probably see that during their peak hour...I don't know.  So from that
perspective, there are about a bazillion things each of us have to
learn, yet ...in this field of exponentially growing confusion :)  A
project like Alice might give us more experience in large distributed
systems ;)

Just so that you know, "Alice" isn't a "pet project" of mine or
anything, but it seemed "game-worthy" from the sense that madness could
ensue with divergent player interaction and, the whole world of GUI
presentation is wide open in terms of scene creations, etc.  Think about
it, what if Alice didn't DRINK ME?  This would give our distributed
world of "game writers" lots and lots to do and think of for such
patrons of the game.  Perhaps we could even get Grace Slick to do a
special version of GAA for us?

http://sailor.gutenberg.org/etext91/alice30.txt  (full text of Alice)

> 
> > Take Care.
> >
> > Rob!