[Feedhenry-raincatcher] Raincatcher feedback from a newbie

Thu Jan 26 15:14:47 UTC 2017

On Thu, Jan 26, 2017 at 4:09 PM, Summers Pittman <supittma at redhat.com>
wrote:

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

>
>
>>
>>>
>>>
>>>
>>>>
>>>> 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/03d850a7/attachment.htm>