Announcemnt: PLUG Devel Event Planner Project [was]Re: Event
Planning Project
plug-devel@lists.PLUG.phoenix.az.us
plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 11 10:33:02 2005
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.
>
> 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
>
> _______________________________________________
> PLUG-devel mailing list - PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>