[Feedhenry-raincatcher] Fwd: Raincatcher feedback from a newbie

Thu Jan 26 14:42:40 UTC 2017

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.

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