Forcasting PEP consumers [was]: [snip] Event Planner Project
[was]Re: Event Planning Project
Joseph Sinclair
plug-devel@lists.PLUG.phoenix.az.us
Fri Mar 11 16:24:02 2005
This is a multi-part message in MIME format.
--------------060405060505000409050106
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I never viewed the Installfest as the primary customer. They are
providing a convenient focus to the initial iterations, but I never
intended to create software specific to installfests, I think I
mentioned earlier that if that had been my preference, I would have
created something really simple.
I don't think we ever discussed integrating the solution developed here
into the existing PLUG site. I, personally, don't think that's such a
good idea, given that the best way to do that would involve writing the
system as an extension of PostNuke in PHP. I think we did discuss
having an easy-to-use link, and perhaps permitting the
look-and-feel(L&F) to match the PLUG site L&F, but that's easy enough to
do in any reasonable architecture.
I've been working with lightweight methodologies, primarily XP, for
around 5 years now, and I have never been able to find in the XP
methodology anything that suggests you build your system as though the
current iteration is the entire system. You don't build *functionality*
not needed by the current iteration, but you do build this iteration's
functionality with the understanding of the entire release, and you make
architectural and design decisions with the entire project vision in mind.
I think these three things start to bring light to this discussion,
Trent. You are trying to see the "best" (i.e.
simplest/cheapest/easiest) way to build an installfest application, with
the installfest as a primary customer, and a strong desire to place the
final solution in GNUe. I am trying to see the "best" way to build a
full-out enterprise event planning and management system with PLUG/AZOTO
as the primary customer (much broader needs there), the installfest as a
nice proxy customer for a few iterations, a strong desire to see the
software built using the platform preferred by those willing to
volunteer as core developers, and a desire to ensure it actually gets
built, whether I like the final PAD(Platform/Architecture/Design) or
not. Neither position is inherently right or wrong, they're just different.
As far as Bryan's request that a single-user solution be available, I
agree that, at some point, a single-user system should be available.
Since it's utterly insane to expect an unsophisticated user (i.e. church
admin, "soccer mom", etc...) to install the LAMP components (or GNUe or
J2EE) on their workstation, I would expect the single-user solution to
be an easily downloadable (PDM, Java WebStart, etc...) client
application capable of running in both online and offline modes, and
with the option to have no parent server at all. This sounds a lot like
a user story, so I'll keep a story card for it, assuming Bryan agrees
with my description.
==Joseph++
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
>
>
>
--------------060405060505000409050106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">I never viewed the Installfest as the primary
customer. They are providing a convenient focus to the initial
iterations, but I never intended to create software specific to
installfests, I think I mentioned earlier that if that had been my
preference, I would have created something really simple.<br>
<br>
I don't think we ever discussed integrating the solution developed here
into the existing PLUG site. I, personally, don't think that's such a
good idea, given that the best way to do that would involve writing the
system as an extension of PostNuke in PHP. I think we did discuss
having an easy-to-use link, and perhaps permitting the
look-and-feel(L&F) to match the PLUG site L&F, but that's easy
enough to do in any reasonable architecture.<br>
<br>
I've been working with lightweight methodologies, primarily XP, for
around 5 years now, and I have never been able to find in the XP
methodology anything that suggests you build your system as though the
current iteration is the entire system. You don't build
*functionality* not needed by the current iteration, but you do build
this iteration's functionality with the understanding of the entire
release, and you make architectural and design decisions with the
entire project vision in mind.<br>
<br>
I think these three things start to bring light to this discussion,
Trent. You are trying to see the "best" (i.e.
simplest/cheapest/easiest) way to build an installfest application,
with the installfest as a primary customer, and a strong desire to
place the final solution in GNUe. I am trying to see the "best" way to
build a full-out enterprise event planning and management system with
PLUG/AZOTO as the primary customer (much broader needs there), the
installfest as a nice proxy customer for a few iterations, a strong
desire to see the software built using the platform preferred by those
willing to volunteer as core developers, and a desire to ensure it
actually gets built, whether I like the final
PAD(Platform/Architecture/Design) or not. Neither position is
inherently right or wrong, they're just different.<br>
<br>
As far as Bryan's request that a single-user solution be available, I
agree that, at some point, a single-user system should be available.
Since it's utterly insane to expect an unsophisticated user (i.e.
church admin, "soccer mom", etc...) to install the LAMP components (or
GNUe or J2EE) on their workstation, I would expect the single-user
solution to be an easily downloadable (PDM, Java WebStart, etc...)
client application capable of running in both online and offline modes,
and with the option to have no parent server at all. This sounds a lot
like a user story, so I'll keep a story card for it, assuming Bryan
agrees with my description.<br>
<br>
==Joseph++<br>
</font><br>
Trent Shipley wrote:
<blockquote cite="mid200503111327.23230.tshipley@deru.com" type="cite">
<pre wrap="">(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:
<a class="moz-txt-link-freetext" href="http://www.u.arizona.edu/~tshipley/Engineering/Transite.html">http://www.u.arizona.edu/~tshipley/Engineering/Transite.html</a>
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, <a class="moz-txt-link-abbreviated" href="mailto:Bryan.ONeal@asu.edu">Bryan.ONeal@asu.edu</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Wednesday 2005-03-09 17:57, Joseph Sinclair wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
<big snip/>
_______________________________________________
PLUG-devel mailing list - <a class="moz-txt-link-abbreviated" href="mailto:PLUG-devel@lists.PLUG.phoenix.az.us">PLUG-devel@lists.PLUG.phoenix.az.us</a>
<a class="moz-txt-link-freetext" href="http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel">http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel</a>
</pre>
</blockquote>
</body>
</html>
--------------060405060505000409050106--