Announcemnt: PLUG Devel Event Planner Project [was]Re: Event Planning Project

[Trent Shipley]

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.

In any event, predicting the market for Fenix Event Planner (FEP?, we could 
get PEP, hmmm.  PEP it is, it sounds so very marketable.) amounts to setting 
requirements and setting them prematurely.  I think we have a lot of reason 
to expect that we will eventually want to make PEP a  GNUe module, but at 
this point we do not know that for certain.

More importantly, we DO know that eXP recommends that projects be built to 
size, no more, and no less.  For PLUG InstallFest automation GNUe is 
overkill.  If we are eXP purists then we want solid project architecture, but 
no overbuilding, and you want to deliver working tools to consumers rapidly 
and steadily.  Our current project is to help automate InstallFests, so the 
architecture should be oriented to efficiently solving the InstallFest 
automation problem, probably on our existing LAMP server.

If the problem domain outgrows the architecture THEN we see a weakness of 
agile methodologies.  We will probably need to go back to the drawing board, 
get a new architecture, do new engineering, and write new code.  But that is 
fair, in terms of agile methodologies we have a totally new problem.

That said, we already know that there is a high PROBABILITY that we will want 
to make the Phoenix Event Planner a GNUe module.  That does not mean that the 
solution to InstallFest automation will be a GNUe module.  

In practical terms, it does mean that we do not keep a nearsighted focus on 
the immediate problem.  We should use Python and do things like use GNUe 
standards for style and coding.  In no way should we forclose our option to 
migrate to GNUe later on.

> The current suggestion that uses Python (GNUe) does not improve the
> speed of development over J2EE, and it also does not offer the option of
> a later move to Java, as GNUe will never support it (AFAICT).

If we stay with eXP and solve the immediate problem at hand in a short amount 
of time, namely InstallFest automation, then using Python with minimal 
reference to GNUe should result in faster completion of the InstallFest 
automation project than using either GNUe or J2EE.

> The choice of language and platform is more dependent on architecture
> than speed of development, as the former has a lot more impact on the
> quality of the final result.

Plan to throw one away.

We can look at the InstallFest automation project as a trial run and proof of 
concept; not just of the event planning software but more importantly of the 
PEP software production process itself.  In that case, the first edition of 
InstallFest automation by the PEP development group will have many attributes 
of an advanced prototype, should be put together quickly (even at the cost of 
substantial quality), and we pretty much expect to radically revise the 
architecture anyway.

The idea is not just to shake out "requirements" with a working prototype.  By 
producing a solution fast we go through an entire development cycle fast.  
This will help shake down our tools, our team, and PEP's architecture for the 
next increment in overall project complexity or quality.

> I'm primarily expecting this to appeal to a combination of small groups
> (like PLUG) who would probably run it on a spare system somewhere, and
> large enterprises (who would likely set up a dedicated intranet
> system).  If we decide to expand the focus, then we need to be much more
> careful how we design to ensure the system is usable on a wider variety
> of platform options, not fewer.

Yes, but right now we have a vision for the future of PEP, not a project.  At 
this point Phoenix_Event_Planner=InstallFest_automation.  If we want to be 
exP-ish then we need to stay focused on Install Fest automation.

We will re-architect for quincenieras and Presidential inaugurations in due 
time.  For now, the Architect and Engineer should have coders code to 
patterns that are likely to be modular and reusable.  Also, they should avoid 
impeding likely paths, such as GNUe compatibility.

> IMNSHO agility actually puts a premium on clean architecture,
> discipline, clear design, and real results; certain decisions, platform
> in particular, are tightly tied to the architecture chosen if these
> goals are to be met.  This is one of the reason why ports of software
> from one platform (i.e. .Net) to another (i.e. LAMP) rarely do well.

OK, I'll agree to that.  Let's pick a platform **For This Phase**, design for 
that platform, and code with discipline.

Nevertheless, I am arguing that the problem at hand, namely InstallFest 
automation, should be designed over LAMP because eXP privileges what comes 
next over designing for the "grand vision".

God willing, we will be very successful and will need to re-architect and 
re-code for a 3+ tier architecture.  Hopefully, PEP will become a module in a 
larger FOSS enterprise resource planning and management project, like GNUe.


> ==Joseph++
>

<snip/>

> >If we REALLY want to be lightweight then we should design and prototype
> > FAST. The need for speed heavily favors Python.  This is even more true
> > if Python can be pre-byte compiled and called from a JVM.  If later we
> > WANT to redo core modules to Java we should be able to do the conversion
> > piecewise.  On the otherhand I am not certain we can do the reverse and
> > convert Java piecewise to Python.
> >
> >Agility implicitly puts a premium on keeping your options open.  It
> > follows that critical decisions should be delayed as long as practical.
> >_______________________________________________
> >PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> >http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel