[aerogear-dev] AeroGear project demo planning

Thu Jun 27 05:10:41 EDT 2013

On Thu, Jun 27, 2013 at 12:15 AM, Jay Balunas <jbalunas at 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, makes sense.

>
> _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.
>

Not sure I fully understand the "topic demos". Since you mentioned the
tutorials. For iOS push we have this:
http://staging.aerogear.org/docs/guides/aerogear-push-ios/

and for Android we have this:
https://issues.jboss.org/browse/AGPUSH-21

Both have very simple client applications. cURL is used for triggering a
push message. The demo itself is very simple, but the getting started
(especially on iOS/Apple) is covered there as well. Do you mean something
like that ?

Another topic could be (taking push again), using CDI events: Show how to
fire CDI-events and a CDI-Observer will just use Java-Sender API to send a
simple Push message (like the cURL does). For that, we can also reuse the
client apps.

>
> My personal opinion here would be take it on a case by case basis.
>
> _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.
>

Like: OTP Quickstart for Android, iOS, JavaScript (and the server part)?

>
> 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).

yes, I like that: they are simple and isolated (if I recall correctly). So
it's not a gigantic app/mess :)

>  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.
>
> 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.
>
> _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.
>
> 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.
>
> _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.
>
> * 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.
>

I think that makes sense

>
> * 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.
>

"Tooling for iOS": Not sure how our Xcode template falls into that
"Tooling" category, but it helps a lot when getting started.

>
> 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 think the Xcode template we have is good enough, for "iOS tooling"

> ----------
>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130627/a110225c/attachment-0001.html 