[Feedhenry-raincatcher] Raincatcher feedback from a newbie

[Summers Pittman]

On Fri, Jan 27, 2017 at 3:18 AM, Niall Donnelly <ndonnell at redhat.com> wrote:

> Apologies for my late reply. Comments inline below.
>
> On Thu, Jan 26, 2017 at 7:28 PM, Paolo Haji <phaji at redhat.com> wrote:
>
>> I'd like to try adding my individual inputs to each point as well because
>> I think they're very nicely put
>> On Wed, Jan 25, 2017 at 12:29 PM, Summers Pittman <supittma at redhat.com>
>> wrote:
>>
>>> 0.  I've had Raincatcher described to me as a architecture for writing
>>> Raincatcher applications using Raincatcher modules.  For workforce
>>> management.
>>>
>>
>> From my start with the team I considered the project a set of apps with a
>> feature set around workforce management that would be minimally configured
>> to cater to customers' business needs (and maybe cosmetics/branding as
>> well), and that a lot of that would be covered mostly by Forms.
>> I think I formed this mental image due to the development process
>> focusing on the demo projects (both for new features and for verification
>> of issues), and the starting point being the template in Studio that just
>> gives you all the demo projects.
>> It's very important for us to have a vision of what Raincatcher should be
>> to progress toward, specially with the opensourcing efforts.
>>
>
> [Niall] Yes, the intention is to produce a set of loosely-coupled modules
> that implement the functionality required to build a workforce management
> application. The intention is for the modules to be the building blocks of
> a larger application, using the mediator pattern to communicate between
> them. The modules should also be able to stand alone. Any interaction with
> functionality outside the remit of their own domain (e.g. fh-wfm-workorder
> only deals with logic related to workorders) should be done using mediator
> topics. By building the solution from loosely coupled modules, the
> intention is to make the process of customising the solution much easier
> for the developer as they can swap out the fh-wfm-user module for their own
> user module that has different authentication mechanisms. The internal
> working of the fh-wfm-user or my-wfm-user module should be abstracted from
> the consumer of the application. As long as the module publishes and
> subscribes to the same topics it should just plug into the existing
> solution.
>
> The same principle applies to developers that want to extend the
> functionality of the demo solution. Developers should be able to create
> their own modules that publish their own topics and subscribe to topics
> published by other modules.
>
> That is the goal of the project, however we are not there yet. I am
> spiking Epics at the moment around how we can better improve the boundaries
> between the modules and application code. Ideally, the applications would
> just initialise the relevant modules (both fh-wfm- and custom developer
> defined modules) with configuration.
>
>>
>>
In order to achieve this goal then we need to much better document the
expectations the message queues expect of their messages.

As an example, it seems like there is a relationship between workorders and
workflows.  This relationship is alluded to in the workorder README in the
example workorder, but it is never ever documented.  I'm sure I can repeat
this example ad nauseum.

Is there a JIRA to document these dependencies and expectations?  Is there
some kind of language tooling we can use to check that data provided meets
those expectations at compile time?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-raincatcher/attachments/20170127/3ea0de47/attachment.htm>