[aerogear-dev] AeroGear project demo planning

[Matthias Wessendorf]

On Fri, Jun 28, 2013 at 10:47 PM, Jay Balunas <jbalunas at redhat.com> wrote:

>
> On Jun 28, 2013, at 5:15 AM, Matthias Wessendorf wrote:
>
> > Some "Polyglot" toughts on "topic demos" and/or the show-case
> >
> >
> > I'd like to see at least one "topic example", written in something
> > else than Java(EE). This makes it easier for us promoting the mobile
> > libraries to native iOS developers (or JS guys), since a JavaEE based
> > backend is not something they would prefer using (most of them).
> >
> > For us the point is really "promoting" our MOBILE efforts, and we know
> > our mobile lib's don't care about the backends. (E.g. take the
> > integration tests we have for Android, iOS or JS - they go against
> > Reddit or Github API - we have no clue (perhaps a guess) what they use
> > for implementing these "services")
> >
> > Ok, now this ProDoctor is based on Forge/JavaEE, which is fine with
> > me, since that's IMO the classical JBoss target. Also, if I understood
> > Luke's comments from Summit, these guys
> > are looking into "mobile" (Android, JS, iOS), so that's a good spot for
> them.
> >
> > However, the other platforms are also important (especially when
> > talking to JS/iOS hackers).
>
> +1
>
> >
> > I'd say, yes - why not build another topic-example, based on a
> > different "backend technology".
> > I'd prefer Node.js over Ruby/Sinatra... (I can't read Clojure, so I am
> > not proposing that :-))
>
> +1 for node.js/nodej instead of Ruby/Sinatra.
>
> >
> > I mean another topic demo, not a rewrite (aka "ProDoctor.js" ;-))
>
> I'm not against a new topic demo, but at the same time why not reuse the
> ProDoctor clients?
>
> /clients
>    /ios
>    /android
>    /etc..
> /servers
>   /nodejs
>   /wildfliy
> README.md
>
> If go with something completely separate we would need to commit to
> maintenance of it in the same way as the others.
>

true :-)  Also the ProDoctor "backend" is not that complicated yet.



>
> >
> > Or maybe even the "Show-Case" in some other language??
> > Take JRuby/Sinatra for example: But I am not 100% sure what that means
> > if the "show-case" should/would also demonstrate our java libs (e.g.
> > AG-Security).
>
> I'm -1 to this for the first iteration of the showcase example, although
> as I mentioned we could certainly talk about multiple backend support
>

yeah, the multiple backend is not wrong :)


>
> >
> > I *think* with TorqueBox/JRuby we can use most of our "java libs", but
> > does require JRuby (and TB), right? So I am not 100% sure on that....
> >
> >
> > Greetings,
> > Matthias
> >
> >
> >
> >
> > On Fri, Jun 28, 2013 at 8:00 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> >> On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers <kborcher at redhat.com>
> wrote:
> >>>
> >>>
> >>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas at 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 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, 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.
> >>
> >> I agree
> >>
> >>> 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.
> >>>
> >>>>> 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 at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> aerogear-dev mailing list
> >>>>> aerogear-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> 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/20130629/85c52bad/attachment-0001.html