| 2013-02-04 22:42:41 utc | jmettraux | ypz: hello, here is a simplified version of your gists: https://gist.github.com/4710343 |
| 2013-02-04 22:42:59 utc | jmettraux | no forking involved, so no need to connect to the database after the fork, etc |
| 2013-02-04 22:44:09 utc | ypz | thanks, I was distracted from this project for past week or so |
| 2013-02-04 22:44:20 utc | jmettraux | no worries |
| 2013-02-04 22:44:22 utc | ypz | I'll take a look |
| 2013-02-04 22:45:09 utc | ypz | btw, is there a road map for Ruote project? what other features are in the planning ? |
| 2013-02-04 22:45:59 utc | jmettraux | I have a todo I follow vaguely https://github.com/jmettraux/ruote/blob/master/TODO.txt |
| 2013-02-04 22:46:31 utc | jmettraux | but most of my efforts go into the new ruote-asw library https://github.com/jmettraux/ruote-asw |
| 2013-02-04 22:48:59 utc | ypz | what's meaning of [o] and [x] and [ ] ? |
| 2013-02-04 22:49:34 utc | jmettraux | [ ] means todo, [o] means done, [x] means not done (for whatever reason) |
| 2013-02-04 22:58:06 utc | ypz | are there any examples to export a process definition as xml ? |
| 2013-02-04 23:01:09 utc | ypz | a major concern in our group is that we want to have other people/teams to create process definitions, who are not ruby programmers, or not developers at all, so process definition must be very easy and intuitive. |
| 2013-02-04 23:01:38 utc | jmettraux | xml is not intuitive... |
| 2013-02-04 23:02:56 utc | jmettraux | here is an example that turns a process definition to xml |
| 2013-02-04 23:03:16 utc | ypz | at least more people have already been *forced* to learn xml , and there are xml authoring tools out there (never used such tools before myself) :) |
| 2013-02-04 23:04:02 utc | jmettraux | from what I've seen in the industry, people are selling BPMN tools and telling "you don't need to program, you just need to draw" |
| 2013-02-04 23:04:17 utc | jmettraux | and people end up programming and having programmer problems |
| 2013-02-04 23:05:11 utc | jmettraux | one technique you could use is have a simple DSL, and a translator than turns input in that DSL to ruote's language |
| 2013-02-04 23:05:13 utc | ypz | management has been pushing commercial apps with fancy GUI based bpm definition tools |
| 2013-02-04 23:05:26 utc | jmettraux | (or any other tool) |
| 2013-02-04 23:06:37 utc | jmettraux | btw, this blog is great, http://mainthing.ru/ it's mainly about BPMN and well, "programming" processes |
| 2013-02-04 23:07:02 utc | jmettraux | the "basic BPMN assumption" series there is wonderful |
| 2013-02-04 23:08:28 utc | jmettraux | if you want something fancy but still open source, you could look at the latest jbpm or at activiti, they are both Java, but with Jruby you can easily play with them |
| 2013-02-04 23:08:33 utc | jmettraux | they both support BPMN 2.0 |
| 2013-02-04 23:09:31 utc | jmettraux | http://www.jboss.org/jbpm/ and http://www.activiti.org/ |
| 2013-02-04 23:10:13 utc | jmettraux | my preference would be for jbpm, its latest version is tied with drools, a rule engine, so you can play either on the process or on the rules field (or both) |
| 2013-02-04 23:11:18 utc | jmettraux | but with any tool, user-proofing the process definition/modelling is hard |
| 2013-02-04 23:13:11 utc | ypz | personally, I would rather just have a tool to create process definitions, and feed results (with necessary transformation) into a ruby app based on ruote |
| 2013-02-04 23:14:07 utc | ypz | we were a php shop, collectively made the decision to go ruby for all future tools, don't really want to add java into the mix |
| 2013-02-04 23:37:00 utc | jmettraux | ok |