[Feedhenry-raincatcher] Raincatcher feedback from a newbie

Thu Jan 26 14:26:54 UTC 2017

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

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/feedhenry-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170126/7101b3b3/attachment.htm>