[aerogear-dev] AeroGear project demo planning
Summers Pittman
supittma at redhat.com
Tue Jul 2 11:22:19 EDT 2013
On 07/01/2013 02:49 PM, Jay Balunas wrote:
> So is it the conclusion that this sort of structure is acceptable for
> showcase & topic demos at least?
>
>> /clients
>> /ios
>> /android
>> /etc..
>> /servers
>> /nodejs
>> /wildfliy
>> README.md
>>
>
> Any strong objections to this? I would say quickstarts are more
> case-by-case.
>
No objections to this.
Somehow I feel like quick starts aren't really case by case but more
platform oriented
IE
----repo areogear-android quickstart
/quickstarts
/auth
/pipe
/paging
/etc...
README.md
Maybe even (for Android) quickstarts could just be maven archetypes.
>
> On Jun 29, 2013, at 3:46 AM, Matthias Wessendorf wrote:
>
>>
>>
>>
>> On Fri, Jun 28, 2013 at 10:47 PM, Jay Balunas <jbalunas at redhat.com
>> <mailto: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 <mailto:matzew at apache.org>> wrote:
>> >> On Thu, Jun 27, 2013 at 11:39 PM, Kris Borchers
>> <kborcher at redhat.com <mailto:kborcher at redhat.com>> wrote:
>> >>>
>> >>>
>> >>> On Jun 27, 2013, at 16:04, Jay Balunas <jbalunas at redhat.com
>> <mailto: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 <mailto: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
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> aerogear-dev mailing list
>> >>>>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> aerogear-dev mailing list
>> >>>> aerogear-dev at lists.jboss.org
>> <mailto:aerogear-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >>>
>> >>> _______________________________________________
>> >>> aerogear-dev mailing list
>> >>> aerogear-dev at lists.jboss.org
>> <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto: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
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130702/9011e9dc/attachment-0001.html
More information about the aerogear-dev
mailing list