[Feedhenry-raincatcher] Raincatcher feedback from a newbie

Thu Jan 26 15:09:38 UTC 2017

On Thu, Jan 26, 2017 at 10:01 AM, Sebastien Blanc <sblanc at redhat.com> wrote:

>
>
> On Thu, Jan 26, 2017 at 3:58 PM, Summers Pittman <supittma at redhat.com>
> wrote:
>
>> Reattaching the list because I think something got lost.
>>
>> On Thu, Jan 26, 2017 at 9:41 AM, Damien Murphy <damurphy at redhat.com>
>> wrote:
>>
>>> I think this is a really valuable discussion, and think as a
>>> community-focussed project, Raincatcher is a great opportunity to give
>>> thought and consideration to things we might otherwise not prioritise so
>>> much.
>>>
>>> As a community project as such, and one in which we want to gain as much
>>> buy-in as possible & build a thriving community of contributors, I agree
>>> with much of what has been spoken about so far.
>>>
>>> I think the project needs to be as friendly as possible to get involved
>>> in, which goes across a number of fronts, from documentation to codebase to
>>> technologies used.
>>>
>>> I think while we're stuck with angular 1 for the moment, it would be
>>> good to change that when the opportunity presents itself, with the use of
>>> interesting and more current technologies in Raincatcher helping draw
>>> people in & want to contribute/ be a part of things.
>>>
>>
>> Right.  I'm a developer so burn it all to the ground and start over is in
>> my DNA :).
>>
>> What we should be mindful of is taking some time at some point this year
>> is to make some blog posts or demo applications which show how to use
>> Raincatcher with other technologies.  Right now it is VERY angular, but I
>> am aware that Nial is working on some refactorings which may make this
>> easier in the future.  However, these blog posts don't have to be
>> "supported" outside of "yeah we did an experiment once, it is possible,
>> tell us what you think and file some JIRAs"
>>
> Also keep in mind that "only" 50% is Angular, the other 50% are the NodeJS
> backend bits, the mediator itself is also framework "agnostic".
>

Right, but as it stands if you want to use the client APIs but don't want
to use angular your only options are to write a bucket of initialization
code, unless I'm missing something.

>
>>
>>
>>
>>>
>>> On Thu, Jan 26, 2017 at 2:30 PM, Summers Pittman <supittma at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 26, 2017 at 9:26 AM, Austin Cunningham <aucunnin at redhat.com
>>>> > wrote:
>>>>
>>>>> Hi All,
>>>>> Being a noob tutorials on Raincatcher are definitely needed. The one
>>>>> tutorial I found on adding a gps module to the demo app became difficult to
>>>>> follow after a few steps. There are learning curves with all front ends so
>>>>> weather it is Angular 1.0 or  another doesn't make much of a difference. I
>>>>> agree that the strongly decoupled nature of Raincatcher can make it hard to
>>>>> see how the modules interact
>>>>>
>>>>>
>>>> Well it isn't the learning curve for the Angular vs something else I am
>>>> worried about.  It is the fact that we are pushing something which is
>>>> already based on a legacy technology that Google is already moving away
>>>> from.
>>>>
>>>> I'm fine with an up front "If you don't know Angular (or React or
>>>> whatever), go do this tutorial and come back here".
>>>>
>>>>
>>>>> Regards
>>>>> Austin
>>>>>
>>>>> On 25 January 2017 at 14:49, Summers Pittman <supittma at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Because I didn't want to influence people's responses, I've included
>>>>>> my thoughts inline.
>>>>>>
>>>>>> On Wed, Jan 25, 2017 at 9:29 AM, Summers Pittman <supittma at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> We were chatting on the devXP slack today and had an interesting
>>>>>>> take on Raincatcher's shortcomings from a newbie's perspective.
>>>>>>>
>>>>>>> TL;DR; Raincatcher is HARD
>>>>>>>
>>>>>>> Here is a list of some of the issues we've run across.
>>>>>>>
>>>>>>> 0.  I've had Raincatcher described to me as a architecture for
>>>>>>> writing Raincatcher applications using Raincatcher modules.  For workforce
>>>>>>> management.
>>>>>>>
>>>>>>
>>>>>> I think we can learn some things from jBPM (a similar project to
>>>>>> Raincatcher, just it is larger in scope [I think, RC isn't well defined]).
>>>>>>
>>>>>> For instance let's compare https://github.com/fee
>>>>>> dhenry-raincatcher/raincatcher-documentation to
>>>>>> https://docs.jboss.org/jbpm/release/6.5.0.Final/jbpm-docs/html/
>>>>>>
>>>>>> the jBPM has "What is jBPM" as its very first entry in docs.  The
>>>>>> Raincatcher documentation never makes this case.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 1.  The highly decoupled nature of the codebase hides how the
>>>>>>> modules should interact with each other. By should I mean you can't look at
>>>>>>> the demo project and quickly get an idea of how one should architect a
>>>>>>> greenfield RC application.
>>>>>>>
>>>>>>>
>>>>>> Let's take workorders and workflows as examples here.  The first
>>>>>> thing that I was told was that Raicatcher uses workflows to move workorders
>>>>>> through their lifecycle.  However, the documentaiton for these modules
>>>>>> doesn't try to explain this relationship and the code is intentionally
>>>>>> decoupled despite the fact that the examples have workflowIds on the
>>>>>> workorder with no real explanation.
>>>>>>
>>>>>> More tutorials, whitepapers, and documentation will help this.  Also
>>>>>> I think we can gain a lot from taking the time to write our own, personal,
>>>>>> Raincatcher applications to get a "feel" for how the framework works.
>>>>>>
>>>>>>
>>>>>>> 2.  Angular is a huge, opinionated framework with lots of gotchas,
>>>>>>> and Angular went the route of "Let's add a bunch of custom tags and
>>>>>>> attributes to html elements".  This has the effect of breaking lots of
>>>>>>> tools and making learning Raincatcher even harder.
>>>>>>>
>>>>>>>
>>>>>> The only way to solve this problem is to be upfront : If you don't
>>>>>> know Angular don't come near Raincatcher.  I don't think it makes sense to
>>>>>> "abstract" angular away.
>>>>>>
>>>>>> Also we are launching a Angular 1.x project when Angular 2.x is where
>>>>>> Google is pointing people.  This will be a hard sell as it is already
>>>>>> "legacy"/
>>>>>>
>>>>>>
>>>>>>> 3.  Feedhenry makes it very difficult to deploy applications which
>>>>>>> have dependencies on auth services.
>>>>>>>
>>>>>>
>>>>>> This is a problem for all Feedhenry applications which we should
>>>>>> probably take up on feedhenry-dev.  However, until we can get a community
>>>>>> cluster this really isn't a barrier to adoption.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 4.  Raincatcher uses message passing, but the APIs themselves don't
>>>>>>> make discovering available namespaces easy or automatic.  Developers have
>>>>>>> to be highly aware of the name spacing, what modules are available, and the
>>>>>>> RC conventions.
>>>>>>>
>>>>>>
>>>>>> This is hard to solve because JavaScript really sucks for this type
>>>>>> of discovery.  We could probably write plugins for a few IDEs that will
>>>>>> examine the package.json file of a project and make suggestions based on
>>>>>> that.
>>>>>>
>>>>>> There is actually a lot we can do with tooling and IDE integration
>>>>>> which will be very helpful.  Just having a way to quickly navigate between
>>>>>> a event handler and an event emitter inside of a project would be a huge
>>>>>> win.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 5. Raincatcher lacks tutorials and simple sample applications. We
>>>>>>> have the portal which is a kitchen sink project (great for excitement and
>>>>>>> presentations, not for learning), and the demo application (an example of
>>>>>>> how to add a custom module).
>>>>>>>
>>>>>>>
>>>>>> This is probably the easiest to solve.  We write apps using
>>>>>> Raincatcher and publish why we made the decisions we made and how someone
>>>>>> else can do the same thing.
>>>>>>
>>>>>> I'm working on a tutorial that is inspired by the Android Notepad
>>>>>> tutorial.  Hopefully I will have something this week for people to chew on
>>>>>> and give feedback on.
>>>>>>
>>>>>>
>>>>>>> So what do you guys think?
>>>>>>>
>>>>>>> Summers
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Feedhenry-raincatcher mailing list
>>>>>> Feedhenry-raincatcher at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Austin Cunningham
>>>>> Rapid Mobile Application Development Team
>>>>> <https://docs.jboss.org/pages/viewpage.action?pageId=9470209> (RMAD)
>>>>> <https://docs.jboss.org/pages/viewpage.action?pageId=9470209>
>>>>> Email:aucunnin at redhat.com
>>>>>
>>>>> Red Hat Mobile,
>>>>> Communications House
>>>>> Cork Road
>>>>> Waterford
>>>>> X91NY33
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Feedhenry-raincatcher mailing list
>>>>> Feedhenry-raincatcher at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Feedhenry-raincatcher mailing list
>>>> Feedhenry-raincatcher at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Feedhenry-raincatcher mailing list
>> Feedhenry-raincatcher at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170126/6d4f3050/attachment.htm>