Forcasting PEP consumers [was]: [snip] Event Planner Project [was]Re: Event Planning Project

Trent Shipley plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 11 11:55:03 2005


(Now top posting.  Does the devel list have a style preference for top or 
bottom posting.  I'll admit to prefering bottom posting and lagging between 
posting where appropriate.

Alan, we await your sagacious wisdom.)

1 )  Given what has been discussed at the Developer's meetings about project 
zero, namely InstallFest automation (IFA), the current customer's immediate 
desire is for an INTERNET solution.  The most critical feature is that 
prospective InstallFest customers can tell InstallFest managers and other 
volunteers about what they want to do BEFORE they show up on the last 
Saturday of a month.   Furthermore, the publicly visible part of the 
application should appear to the casual user like an organic part of the 
existing PLUG website.

So given an (admittedly dogmatic interpretation of) eXP/lightweight 
methodology the project manager and senior architect (Joseph) should see to 
it that the architecture is tailored to the problem at hand, namely IFA.

It seems to me that for IFA 3+-tier is overkill, violating eXP dogma.  IFA can 
be done on LAMP, and there are a lot of good to do it that way.


2)  Despite #1, Bryan is correct.  There as a strategic vision for PEP, and 
that strategic vision could be in conflict with eXP dogma.  Bryan is 
absolutely right that many potential uses of PEP are not immediately obvious 
and involve agents of small entities with limited IT expertise.  (IT 
expertise is a distraction for the core competencies or missions of these 
smaller entities)

I do think LAMP can be run on a single workstation, especially if you use (the 
now mature) Apache 2.x and mySQL.

See:
http://www.u.arizona.edu/~tshipley/Engineering/Transite.html


3)  As for not being familiar with a language, that should not be an obstacle.  
My experience is that once you have learned two imperative-procedural 
languages with object support, learning the third or n-th is trivial.

You just ask the same questions.  (Starred items are critical.)

* How to I get the thing to run?  This is the 'hello world' problem and is a 
matter of mechanics.

Is it strongly or weakly typed?  
* What are the primitive types?

* What aggregate types or built-in data structures are available.  (Arrays, 
records, a-lists, etc.)

* What are the tools for loops?

* What are the decision control tools?

Does the language allow recursion?  (Some business languages, notably COBOL, 
protect users from themselves by disallowing recursion.)

Does the language allow machine level indirection (real pointers)?

* What tools are available for modularization?  (Procedures, Functions, 
Packages, Namespaces, etc.)

Can you run arbitrary code at run-time?

Does the language include object support?

How do I declare an object.

How to I instantiate an object.


Eventually the first three or four chapters of programming language manuals 
become boring.  If the training material is packaged right, I can start 
reading code in a new imperative + objects language inside a day.  That means 
that I can do simple maintenance work sometime on day two.

Programmers with more experience, education, training, or talent may be able 
to bootstrap themselves into a new object-imperative language even faster 
given a suitable feature chart (which, oddly never seems to exist despite 
it's evident pedagogical utility to experienced technicians).  [Here I 
solicit the wisdom of my betters for feedback.]

Bryan MY POINT IS:  I do not care that you have never been taught Python.  If 
you have no second object-imperative language then it is time to get one -- 
Python is as good as any other.  If you already have experience or 
instruction in two or more object-imperative languages then you should be 
able to learn your Nth language pretty fast (something like Smalltalk may be 
a bit of an exception).


On Friday 2005-03-11 12:01, Bryan.ONeal@asu.edu wrote:
> Just remember most of the event planning comunity (high schools, churches,
> etc) will have one person doing the planning, and that one person would
> logicly have a laptop, it would be quite restrictive for them to be
> requierd to conect to the internet to use the app. (The whole world is not
> wierless, yet ;)  As such I must place a requierment that an easy Stand
> Alone solution be made avalable (J2EE does this nicly, then again so does
> PHP and a number of other langages by running each teir localy, as long as
> we can do this EASLY then it should all be good)
>
> On Wed, 9 Mar 2005, Trent Shipley wrote:
> > On Wednesday 2005-03-09 17:57, Joseph Sinclair wrote:
> > > I don't see this being a system that would be appropriate for LAMP
> > > (BTW, LAMP is implicitly 1-tier, not 2-tier.  Even with client side
> > > scripting, the architecture is topologically a single tier with
> > > ancillary antecedents)
> >
> > OK.  I can see that.
> >
> > 1 tier:
> >
> > Mainframe + dumb terminal.
> > Stand-alone workstation
> >
> > 2 tier:
> >
> > Server + Networked Workstation.
> >
> > 3+ tier
> >
> > Data server + Biz logic server + internet server + thin client.
> >
> >
> > Although I tend to think of my PC as a workstation, when I connect it to
> > LAMP it becomes a thin client, that is, effectively a dumb terminal; so
> > LAMP is back to the future.
> >
> > > As far as virtual hosting, more and more hosting providers are offering
> > > J2EE (usually JBoss or JOnAS) as an option on their Linux-based hosts,
> > > so I don't see that as being a significant limitation.
> >
> > I'm willing to accept that we will see more 3-tier virtual hosting
> > options over the next few years.  LAMP is well entrenched, however, so I
> > expect it to be both more available and cheaper than 3-tier virtual.
> >
> > > The market for event planning is not a mass market in the business
> > > sense, so having a slightly more limited platform choice is acceptable
> > > so long as it improves coherency of design, hence the option to develop
> > > as a GNUe module.
> >
> > Per lack of mass market:
> >
> > Joseph, I still see this tool eventually having a wider market than just
> > individuals who tell the labor department that they are "event planners".
> >  I see it being used by funeral and wedding directors, administrative
> > assistants at civic and convention centers and at arenas and stadia.  I
> > see it being used by concert promoters and by high school student
> > governments and church bake sales.
> >

<big snip/>