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

Fri Mar 11 12:11:02 2005

Sounds good, as for lanuges, I was not intending to be a core programer, but
could be if it was J2EE...  This is just a time issue...  although I have been
looking for an excuse to learn Python ;)
As long as I am not a lead on anything I am good, as I can honestly only
devote about 2 hours a week.

But I stick by the need for a stand alone implementation, but again, this
should not be too harded to implement.

On Fri, 11 Mar 2005, Trent Shipley wrote:

> (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/>
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
> 