How to use ruote with rails 3.2.12 engines?

[emc_lab]

We plan to integrate ruote into our rails 3.2.12 engines. Our 3.2.12 rails app consists of multiple rails engines. There are a few questions we have now:

1. Where to implement ruote? Can we add the ruote to each individual engine which needs ruote? Or add the ruote to rails app and provide its features to whichever engine who needs it.
2. If implementing ruote in rails app level, can all the ruote engines share a single table for workitems? Or we have to create a unique table for each and every ruote engine.
3. Is it possible to implement a workflow spanning over more than one engines? I guess this is related to how and where ruote is added to the rails app (with rails engines).


There are not much online about ruote and rails engine. Any comments are appreciated!

[John Mettraux]

On Wed, Jun 19, 2013 at 10:13:38AM -0700, emc_lab wrote:
>
> We plan to integrate ruote into our rails 3.2.12 engines. Our 3.2.12 rails
> app consists of multiple rails engines. There are a few questions we have
> now:

Hello,

others will probably chime in. Here is my first take at answering.

Just to be clear: Rails engine != ruote engine.

> 1. Where to implement ruote? Can we add the ruote to each individual engine
> which needs ruote? Or add the ruote to rails app and provide its features
> to whichever engine who needs it.

I'd add a ruote dashboard singleton to the Rails app via an initializer.

I'd probably go for ruote workers outside of the Rails app, with the ruote
dashboard in the Rails app containing no ruote worker.

> 2. If implementing ruote in rails app level, can all the ruote engines
> share a single table for workitems? Or we have to create a unique table for
> each and every ruote engine.

OK, the conversation switches from Rails engines to ruote engines.

I'd go for a single ruote engine for your Rails web application, with a
single db.

If you implement a participant that stores workitems in a table, you can sure
have this participant use the same table whatever the engine. Please note
that the Ruote::StorageParticipant does not store workitems in a dedicated
workitem table, it stores them in the common ruote table (ruote-sequel).

> 3. Is it possible to implement a workflow spanning over more than one
> engines? I guess this is related to how and where ruote is added to the
> rails app (with rails engines).

No, it's not possible. A workflow instance is limited to one ruote engine.

It's OK for a workflow instance to launch other workflow instances in
different ruote engines.


Best regards,

--
John Mettraux - http://lambda.io/jmettraux

[emc_lab]

John,

Thanks for quick reply. For Q#3, I should be more specific that it is more than one rails engine. If there is only one ruote engine in the rails app, is it possible to run a workflow spanning over more than one rails engine? From your answer to Q#1&2, the answer seems to be yes.

Thanks again.
-emclab

[John Mettraux]

On Wed, Jun 19, 2013 at 11:10:20AM -0700, emc_lab wrote:
>
> Thanks for quick reply. For Q#3, I should be more specific that it is more
> than one rails engine. If there is only one ruote engine in the rails app,
> is it possible to run a workflow spanning over more than one rails engine?
> From your answer to Q#1&2, the answer seems to be yes.

Hello,

if all the Rails engines in the Rails webapp share the same ruote engine,
then all the Rails engines see the same workflow instances.

[emc_lab]

John,

In answer#1, you mention workers outside of rails app. Is there any document or post explaining workers outside of an app (vs inside)? There is a snippet of code for workers outside of rails app in ruote document. But there is no explanation of what it is and what kind of impact it has on the app.

Also any document or post or open source project which may help us to better understand ruote and its integration with rails are appreciated.

Best Regards

-emclab

On Wednesday, June 19, 2013 12:56:06 PM UTC-5, John Mettraux wrote:

[John Mettraux]

On Thu, Jun 20, 2013 at 06:00:11AM -0700, emc_lab wrote:
>
> In answer#1, you mention workers outside of rails app. Is there any
> document or post explaining workers outside of an app (vs inside)? There is
> a snippet of code for workers outside of rails app in ruote document. But
> there is no explanation of what it is and what kind of impact it has on the
> app.

Hello,

it's a bit discouraging to read that after having written lots of
documentation. Is it my fault? Or is it your fault because you can't read
between the lines? All the time I invest in helping you, it will never pay
back. I give you precise help, you make vague affirmations about a "ruote
document" that exists somewhere and talks about worker outside of Rails apps
(can't remember writing it)...

Anyway...

To run workflows, a ruote engine (one could say a ruote system) has to have
at least one ruote worker running.

Ruby on Rails is used to build web applications. When it was a baby
framework, Ruote on Rails was running on top of Webrick, a pure Ruby web
server. Nowadays, there are many web servers to run Rails on top of. Mongrel,
Passenger, Puma, Unicorn, ...

Some of them fork Ruby processes while other use threads with a single Ruby
process, etc... Many choices, many sets of pluses/minuses.

What if you run a ruote worker inside of a Rails app? Well it steals some of
the resources of the rails app itself and the response time may go down or
not. If the Rails app is run on top of a forking server, you may end up
having one ruote worker per Rails app fork, etc...

Running ruote workers externally to the rails app has its advantages, as
said, ruote doesn't eat Rails resources (if we make a parallel, with most of
the database servers, your client doesn't run background indexation work,
your Rails app isn't running indexation work, etc).

Some web servers Rails run on, can go in some "quiet mode" when no process is
running (a new one will be spawned if the need arise), that means that if you
rely on such a web server and your run the ruote worker inside of the Rails
app, you could have times when no ruote worker is on, it shouldn't too bad,
expect when using schedules: if there is a timeout or some work scheduled at
time t and at that time there is no ruote worker, the work will not happen
{on time}.

Should I write documentation for all of this or should I expect the people
integrating my library to know that beforehand?

Are you entitled to such documentation or am I entitled to believe you [want
to] understand what you are building?

> Also any document or post or open source project which may help us to
> better understand ruote and its integration with rails are appreciated.

In order:

* http://www.ruby-lang.org/
* http://rubyonrails.org/
* http://guides.rubyonrails.org/
* http://ruote.rubyforge.org/

[emc_lab]

John,

Thanks for the long answer. Well there are a lots of information there and we probably need to spend sometime time to understand it inside and out.

I am an average programmer (maybe a little better than average) and has spent last week or two opening up http://ruote.rubyforge.org/documentation.html everyday (3-4 hours a day) and comb through the document trying to learn ruote. It is a good place to start with. But I don't feel I am good enough after reading all the document (at least 2 times) to start coding comfortably knowing what I am doing exactly. Probably it is like that when learning new tricks in programming and we learned rails pretty much the same way. For rails there are large number of programmers and help/document are easy to come by on stackoverflow.com or online. For ruote, the community is much smaller and the document other than yours is hard to come by. It seems that most of time you are the person answering the questions and it certainly wouldn't be easy for you or anyone else. There is another member on our team who has integrated ruote-kit within a rails engine a year ago. He like ruote and said it was very stable. But about why and how he did this not that, he could not have the answer easily as he did it a year ago with a test project.This time we are looking into integrating ruote directly into rails without going through ruote-kit which is an extra layer and uses haml and sinatra (we use erb and rails (rails engines)).

If you don't mind, I would like to post the question and your answer to stackoverflow so the answer will be available for others who want to know more about ruote. It is a quality piece information from the author of ruote and is worth to keep.

Best Regards
-emclab

[John Mettraux]

On Thu, Jun 20, 2013 at 10:36:08AM -0700, emc_lab wrote:
>
> Thanks for the long answer. Well there are a lots of information there and
> we probably need to spend sometime time to understand it inside and out.
>
> I am an average programmer (maybe a little better than average) and has
> spent last week or two opening up
> http://ruote.rubyforge.org/documentation.html everyday (3-4 hours a day)
> and comb through the document trying to learn ruote. It is a good place to
> start with. But I don't feel I am good enough after reading all the
> document (at least 2 times) to start coding comfortably knowing what I am
> doing exactly. Probably it is like that when learning new tricks in
> programming and we learned rails pretty much the same way. For rails there
> are large number of programmers and help/document are easy to come by on
> stackoverflow.com or online. For ruote, the community is much smaller and
> the document other than yours is hard to come by. It seems that most of
> time you are the person answering the questions and it certainly wouldn't
> be easy for you or anyone else. There is another member on our team who has
> integrated ruote-kit within a rails engine a year ago. He like ruote and
> said it was very stable. But about why and how he did this not that, he
> could not have the answer easily as he did it a year ago with a test
> project.This time we are looking into integrating ruote directly into rails
> without going through ruote-kit which is an extra layer and uses haml and
> sinatra (we use erb and rails (rails engines)).

Hello,

yes, ruote is much smaller than Rails. And yes, I'm mostly the only one to
answer, although Danny Northox and Doug are helping these days (many thanks
guys, it's much much appreciated :-) )

Somehow, ruote is a Ruby library. I don't want to focus on writing
documentation on how to integrate it in Rails, there are many ways to
build/deploy a Rails application. I trust integrators to know their tools,
their requirements, their deployments. I cannot feed with a spoon every one
and write docs about their specific deployments.

I strive to answer quickly on this mailing list to fill the gap between the
generic doc and the specific requirements people may have.

I am a programmer mostly because I can tinker with stuff and make mistakes,
lots of small mistakes. When people ask about how to integrate X with Y, I am
thinking: "hey, why don't you just try?".

I wrote lots of documentation, it's never enough, it's never enough
hand-holding, I can't cover everything.

I don't want to write documentation about Rails, I just want to write
documentation about ruote, the Ruby library. Too many facets to the Rails
integration. Somehow who can do 2 * 2 = 4 can figure it out, or at least make
mistakes that'll make him better.

> If you don't mind, I would like to post the question and your answer to
> stackoverflow so the answer will be available for others who want to know
> more about ruote. It is a quality piece information from the author of
> ruote and is worth to keep.

I don't think it's a good idea. It's merely duplication of the info found /
created in the mailing list.

Maybe I could switch and say "let's stop using the mailing list and let's do
all the support via StackOverflow", but it then makes it impossible to
announce stuff... Well, I could use my blog to make such annoucements, but
I'm not the only one to make announcements...

Conversation...

Ruote is a tiny project, not used by many people, it's not worth
StackOverflow.


Best regards,

John, very tired

[emc_lab]

John,

Let me put a few more words about it. I don't expect you writing the documents such as how to integrate with rails and I don't know who should have that kind of expection. I don't expect you know how every other people are going to use the ruote. But I just assume that you as the author are happy to see ruote is used in others' projects and the people on this list like to share their knowledge if they happen to know the answer.

Best Regards
-emclab

[marsbomber]

Hi emclab, 

Fill in some background info, I did quite some work with Ruote last year and believe or not, John could be the single most proactive gem author/maintainer I came across ...

So ... back to your very original questions. I think you may get a much better recommendation from the experts here if you explain what you want to achieve from your application. The answer to if you should implement Ruote at the main Rails app level or at each Rails engine level will probably be worked out naturally...

My 2 cents from not understanding what you want to achieve is this

As John already explained, since Ruote maintains its own states (jobs to run, workitem states, etc), why don't you just treat Ruote as a single work horse, map it to your main Rails app? I'd question if you indeed need to implement all those Rails engines ... If you want to use each engine to process parts of a workflow, you can achieve it via messaging (even if you do go down the Rails engine path, messaging will still give you a much loose coupling to other parts of your overall system, compare to implementing Ruote at Rails Engine level ...)

I guess all I want to say is jump out the implementation details, look at your overall architecture of the app a little more, maybe you'll find a better solution. And of course, let's give OSS authors credits for even caring about their mailing lists. To me, we shouldn't take that as granted.

[emc_lab]

First of all, I only solicit answer  to technical question. 2nd I do not see the need to overreact to questions which may be naive or obvious for experts.

Back to the business. In our rails app, there is a need for approve process. For example, company A may need a quote to be approved by the manager and ceo before it is sent out. Company B may only needs approval by the manager. So we don't exactly know which person needs to approve the quote beforehand (i.e. we can not hard code the approve process and can not even prepare the database for it. We need to customize the approve process for every software client). Also we would like to keep the info about who approves at when or reject because of what for tracking and future reference. ruote provides storage and seems capable to do what we are looking for. Our rails app consists of multiple rails engines and this is the architecture ruote is going to be integrated into.

Thanks for the comment.

[John Mettraux]

On Sat, Jun 22, 2013 at 03:08:48AM -0700, emc_lab wrote:
>
> First of all, I only solicit answer to technical question.

Hello,

Put a "s" to question and factor in your requests for documentation.

Next time, I'll simply point it to the existing documentation.

> 2nd I do not
> see the need to overreact to questions which may be naive or obvious for
> experts.

It's very tiring to help you because you need to be explained Ruby things,
Rails things and computer things in general. The ruote part is very minimal.

Also, you tend to report immediately the technical issues you encounter,
without reading error messages. You immediately assume it's ruote's fault.

I named a ruote "worker" a "worker" and people so far understood the concept
of more workers to get more work done. Not you, you requested an explanation
(and you got one).

I have like 1-2 hours per day that I can steal for open software. If I have to
spend 1 hour to teach you about computers every day, well, that's painful.

Economically it might be better for me to tell you to go elsewhere for free
support. Even if you tell to 10 persons that ruote (or anything I make) is
crap (which may be true), then I could assume safely that those 10 persons
would be help vampires as well and that I somehow avoided them, happily.


> (...)

[emc_lab]

>Put a "s" to question and factor in your requests for documentation.

thank you for pointing out my poor EN.

>Next time, I'll simply point it to the existing documentation.

fair enough. Thanks again.

>It's very tiring to help you because you need to be explained Ruby things,
>Rails things and computer things in general. The ruote part is very minimal.

Please ignore my question if you are tired. No offend taken here. I am certainly on a different level with ruby and linux in general compared to expert like you.
But I don't pretend to be one.

>Also, you tend to report immediately the technical issues you encounter,
>without reading error messages.

I can read. For that nil thing, I probably was seeking an easy & quick answer after long hour.
Just like you, I was tired.

>You immediately assume it's ruote's fault.

Wrong here and the assumption made you upset.Not working for me does not mean it does not work for someone else and certainly
it does mean it is certainly a bug in ruote. I treat programming as mix of art and science but not a pure science and need to learn the trick.

>I named a ruote "worker" a "worker" and people so far understood the concept
>of more workers to get more work done. Not you, you requested an explanation
>(and you got one).

What you answered is not what I have asked.

>I have like 1-2 hours per day that I can steal for open software. If I have to
>spend 1 hour to teach you about computers every day, well, that's painful.

If you assume you are a teacher and do not get paid, then it is painful.
Try a different role and you may feel different.

>Economically it might be better for me to tell you to go elsewhere for free
>support.

I did not take free support or OSS for granted. But we will take your suggestion into consideration.

>Even if you tell to 10 persons that ruote (or anything I make) is
>crap (which may be true), then I could assume safely that those 10 persons
>would be help vampires as well and that I somehow avoided them, happily.

You are wrong again and please don't assume. You are getting personal.
I think it is a little nasty assuming you are dealing with
a narrow-minded moody person. There could be some nasty responses to your accusation as well.
But I don't want to treat an OSS author like that. I assume you have spent a lot of time
on ruote and treat it like your baby and have a big enough heart to let else to use if for free.
I consider those characters as angel side of a person.
On the other hand, please don't assume the one who wants to use ruote is cheap and bad person who
become easily moody and nasty for whatever the reason.

My reply probably is going to make you feel even more tired. Sorry!

[John Mettraux]

Hello,

sorry for getting almost "personal". I like the way you answered.

Please accept my apologies and feel free to ask any question you like, I'll
help you the best I can.

Thanks for the lesson!

John