On Jun 28, 2013, at 11:52 AM, Kris Borchers wrote:
On Jun 28, 2013, at 10:42 AM, Pete Muir <pmuir(a)redhat.com> wrote:
>
> On 27 Jun 2013, at 22:39, Kris Borchers <kborcher(a)redhat.com> wrote:
>
>>
>>
>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas(a)redhat.com> wrote:
>>
>>>
>>> On Jun 27, 2013, at 8:39 AM, Kris Borchers wrote:
>>>
>>>>
>>>> On Jun 26, 2013, at 5:15 PM, Jay Balunas <jbalunas(a)redhat.com>
wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> As discussed in the team meeting I wanted to restart discussions
around the demos for the project. I know it is long but it is also very important that we
agree on our example strategy because it is one of the primary ways that people will learn
about AeroGear - especially just starting out. We also need to balance this with the fact
that maintenance of multiple examples can be time consuming (src, docs, tests, etc...).
>>>>>
>>>>> Let me state what I think would be a good model for us at a high
level, and then when we come to a consensus about this we can dig into the individual
example ideas, specifically around the "showcase" demo (likely in another
thread).
>>>>>
>>>>> All of this is my opinion, not law ;-)
>>>>>
>>>>> _Showcase Demo_
>>>>>
>>>>> One larger scale demo that we can cover all (or nearly all) of the
planned functionality up to 2.0. There has been several ideas tossed around from stock
broker, prodoctor, etc... I don't want to focus on the specific app at this point.
Functionality would be additive as we completed it, so the idea would need to be easily
"upgraded" as we go.
>>>>>
>>>>> The app should include all client types as examples (iOS, Android,
Hybrid, Web), have a central backend, be deployable to OpenShift, and run on Wildfly/EAP.
It would require documentation to discuss complexities and usage for an advanced
application, but would not need to cover the bread and butter imo (that is what the
quickstart tutorials are for). We would have to commit to long term maintenance of this
as well.
>>>>>
>>>>> There are pros and cons for this type of application. The
maintenance and development burden is high. Also we need to be careful not to devote so
much time to the application that it takes on a life of its own. I.e. we are not really
trying to make a fully competitive stock broker app.
>>>>>
>>>>> We also want to consider if/how this application would be deployed to
an appstore. Depending on the application it may be very appropriate for it to be there,
but we'll need to discuss.
>>>>>
>>>>> Does this sounds acceptable as the scope and starting point for a
showcase demo?
>>>>
>>>> Yes, this sounds good to me. One comment - I would say that being
deployable to OpenShift and run on Wildfly/EAP should be "possible" but not a
requirement.
>>>
>>> Not sure what difference is between having it be possible and having it be a
requirement. You mean it might not be able to deploy to these, or just that it would be
just one of the options? From the comments below I think you mean the latter - right?
>>
>> I mean for a JS demo for example, I would prefer it not be in a maven based file
structure with a pom.xml. It would be better to just be an HTML app that someone could
drop in a maven project I'd that's what they wanted to use but they shouldn't
have to be familiar with that setup to understand where the demo files are.
>
> I would agree this makes sense, and that is why I'm asking you guys help us
update guidelines for other environments :-) The ones we have are definitely Java (EE)
centric.
>
> Maybe, the way to express it is
>
> "If the project can be deployed on WildFly or OpenShift, instructions to do so
should be included"?
Yeah, a section of the README that just stated something like:
This web application can be run on any server or local machine that can server HTML, JS
and CSS. Just clone the repo and you're off.
If you would like to deploy this web app to Wildfly or EAP:
First, clone this empty application template <include link to an empty project that
can be cloned> and add your app <instructions>.
Deploy to Local App Server
<instructions for deploying to local server>
Deploy to OpenShift
<instructions for deploying to OpenShift>
We could also just include all of those general instructions in a wiki article or
something and link to it so there is only one place to update when needed and any
demo/example could link to it in the README.
Agreed, I'm good with with approach. It allows for both without scaring non-JEE folks
away - at least not at first :-)
>
>>>
>>>> IMO, if possible, this backend should be flexible enough to deploy to
multiple backends, in fact, at some point it might be nice to provide a choice of backend.
I agree that our central backend should have those requirements and by default the clients
would point there but it should be clear that the clients aren't tied to one backend
as well.
>>>
>>> +1 I would like to see that too. We've talked from time to time about
vert.x, torquebox, node.js, ruby, etc... I think these are optional, at least at this
point, but would certainly be nice to have in place. I'd love to see a /servers
directory right next to the /clients directory :-)
>>>
>>>>>
>>>>> _Topic Demos_
>>>>>
>>>>> I'm not sure about this category of demo yet, but wanted to bring
it up. There are use-cases, and functionality that by their definition are beyond the
scope of quickstart, and yet we would likely not want to have the showcase demo be the
only location we demo the functionality.
>>>>>
>>>>> The best example of this I can think of is Unified Push. I think we
all agree, just the basic setup and requirements around push make it more than a
quickstart. With the various servers, configuration, certs, etc... At the same time, we
need a demo (both sooner, and simpler) than the showcase demo for the related tutorials,
docs, etc...
>>>>>
>>>>> So this category would be for this type of "topic" - I
could see the possibility of some security functionality falling into this too, but
I'm not 100% on that.
>>>>>
>>>>> It would have the same type of requirements as the other demos -
docs, tests, maintenance, etc...
>>>>>
>>>>> Pros would be a more focused demo for specific functionality, cons
are another non-trivial demo to maintain.
>>>>>
>>>>> My personal opinion here would be take it on a case by case basis.
>>>>
>>>> I think this is where multiple uses out of a single showcase could come
in handy. We could write tutorials around a single portion of the larger showcase demo,
highlighting the topic at hand (unified push for example). I think that could be useful
both for highlighting a single piece of functionality and for breaking that large app down
into digestible pieces.
>>>
>>> That is a good point, and something we should do for the showcase app for
sure.
>>>
>>> It actually sounds like from Pete and JDFs definition of quickstarts that the
"topic examples" might really still fit that classification anyway.
>>>
>>>>>
>>>>> _Quickstarts_
>>>>>
>>>>> This category sounds like it might be the simplest, but as a whole I
think it represents a fairly large amount of work. Imo a quickstart is a focused demo,
that highlights 1-2 specific use-cases. JDF has a lot of good definitions and
requirements for quick starts that we should consider as well, where they don't
conflict. For example build tools, deployment options, etc...
>>>>>
>>>>> The trick here comes with how to manage and handle all of our
different "parts". Do we group by client type, by functionality, etc... So for
example, take a security related quickstart. It should show how to integration security
across the various client types. Is that 1 quickstart for security, or 3 by client type.
>>>>
>>>> So I would say there is no single solution here. My thought would be that
if this is a server side quickstart (demoing a new feature in security for example), it
would be a single quickstart with 3 (or 4 with hybrid) very simple clients included. For
client quickstarts, an idea I had would be that they could be there own quickstart so
there would be 3 or 4 of them and to solve the single backend, we have one more repo for
the backend and it can be included as a git submodule to each quickstart. I'll wait
for qmx to object here :) as I am also not a huge fan of submodules but I think they could
solve a problem here and with appropriate instructions in the README could be handled
properly.
>>>
>>> Can you break this down in hypotedical directory/repo structure?
>>>
>>> /foo
>>> /bar
>>> etc...
>>
>> I'll respond here later as I am on my phone right now :)
>>>
>>>>>
>>>>> Related to this is the cookbook idea that the Android team is using.
Imo I think it is VERY important that all of our client types share a similar approach
(cookbook or not). We don't want completely different approaches by client type. If
we do group quickstarts (some or all) by client how will we handle common server-side
functionality such as that security example above.
>>>>
>>>> I am a fan of the cookbook idea and I think my comment above addresses
that concern.
>>>>>
>>>>> All of these items get complicated quickly, but I think we need to
nail this down asap because we should start thinking about our quickstart libraries soon
imo.
>>>>
>>>> +1 we need to start on quickstarts ASAP
>>>>>
>>>>> _One off examples_
>>>>>
>>>>> Another type of example was mentioned in the ML, and that is of
one-off examples for presentations, blogs, etc... Imo these are useful, and likely needed
some of the time.
>>>>>
>>>>> I think we should re-use our other examples when possible, but I also
know that will not alway work for various reasons. These examples carry no maintenance
expectations, and should not be in the AeroGear repositories either imo.
>>>>
>>>> +1
>>>>>
>>>>> I also think it is possible for one-off examples to
"become" quickstarts, but would have to meet the standards for a quickstart as
we describe them.
>>>>
>>>> Sure
>>>>>
>>>>> _Repositories_
>>>>>
>>>>> This is a related topic that I think will likely become its own
thread or document, and that is about repository usage for the example types above. In
general we need a better policy imo around this topic in general.
>>>>
>>>> I don't think we need a spelled out document for this but agree that
this should probably be its own thread. I would prefer that this be discussed after we
figure out our demo strategy, then we'll have a better idea of repo needs and can plan
from there.
>>>
>>> Agreed on holding back the conversation while we discuss the examples, but
with as complex a project as this I really believe we need to have and maintain standards
for things like this, or we'll end up with spaghetti.
>>>
>>>>>
>>>>> * Showcase example: I believe it should have a single repository with
/server, /client, and /docs directories as needed. I believe having separate repositories
is confusing and leads to clutter. The intent of the showcase app is to demo how
everything integrates in one place, and should be easily accessed.
>>>>>
>>>>> * Topic examples: I believe these should have a similar requirement
as the showcase example. The point of the topic example is to cover a specific topic, not
specific individual clients.
>>>>>
>>>>> * Quickstart examples: This again gets complicated, and may depend
on the way we choose to group them. However we group them, I think we should have a
limited number of *-quickstart repositories, we should not have a repo for each
quickstart. We'll need to discuss this as we discuss quickstart planning in general.
>>>>>
>>>>> * One off examples: should not be in AeroGear's repository at
all. Imo, if we aren't committing to maintain it we should not have it our
repository.
>>>>>
>>>>> _Forge and JBDS_
>>>>>
>>>>> We also need to discuss how any of these examples relate to forge and
JBDS efforts. At the very least, imo, some of our quickstarts should be based on
scaffolding, and tooling. Imo many of the example (where possible) should be compatible
with forge, and JBDS.
>>>>>
>>>>> Not all examples would need to be compatible. Obviously that does
not apply to iOS, and we would need to balance the effort required on a case-by-case basis
for others. It just might not make sense or have a different target than forge or JBDS.
That is fine, I don't want to use this as a handicap, but we should be considering
both of these as we go.
>>>>
>>>> I agree that we need some forge and tooling specific examples,
quickstarts, what ever. My only concern is that unless we can get the code generated by
forge prettier (proper white space being one of my biggest pet peeves) so that someone
looking at the generated code doesn't struggle to read it, I don't want the demo
code scaffolded. Not sure how possible this is but IMO is very important for the usability
of our demos as learning tools.
>>>
>>> This is another standard is needed imo, or at least updated and used. Coding
standards for the various languages, IDE config files where possible. There is one in the
repos now, but it has not been updated, review, or maybe even used in a long time.
>>>
>>>>> ----------
>>>>>
>>>>> Again, I don't want this thread to break down into specific
use-case discussions, I want us to discuss the example strategies for the project, then we
can kick off separate thread for break down specific examples, and plans for them.
>>>>>
>>>>> -Jay
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev