Well the time has come for me (Michael) to say goodbye – to Red Hat. I must turn into the force, just as yoda did. I will of course remain a community member – using and developing drools. It has been a blast working on this stuff fulltime for the last few years – andRead more →
Well the time has come for me (Michael) to say goodbye – to Red Hat. I must turn into the force, just as yoda did. I will of course remain a community member – using and developing drools.
It has been a blast working on this stuff fulltime for the last few years – and to see the community grow so much. There is now so much going on no one person can really keep up in detail – didn’t used to be like that (not really that long ago either !) – things are in brilliant shape.
So thanks everyone for your support and advice over the years. Hopefully I will have more to blog about here soon !
For those interested, my personal blog (which I will put more details up on when I can) is here.
So long, and thanks for all the fish ! And see you around the mailing lists etc !
Tohu is the project which ads Q&A and “smart form” intelligence on top of drools (and provides a very nice CSS stylable and embeddable jquery based ajax front end as well). (see project page here). Some interesting demo videos made by solnet here explaining how it works: Example 2 (spreadsheet to define Q&A) Example 1Read more →
Tohu is the project which ads Q&A and “smart form” intelligence on top of drools (and provides a very nice CSS stylable and embeddable jquery based ajax front end as well). (see project page here).
Some interesting demo videos made by solnet here explaining how it works:
(In case you are wondering, the accent you can here is New Zealand – or Middle Earth as I prefer to refer to it – perhaps only NZ and Australian citizens can tell the difference between !).
Red Hat Japan recently ran a successful training event/workshop on BRMS. Yusuke has been also working on the localization of BRMS’s web UI. slides: http://www.slideshare.net/yusukey/jboss-brms-quick-start: JBoss BRMS クイックスタート View more documents from yusukey. lab-htmls: http://yusuke.homeip.net/diary/files/brms-quickstart/lab1-install/index.html Check out the screenshots of BRMS running in Japanese: lab-projects in github: http://github.com/yusuke/brms-quickstart/ Nice work !
Red Hat Japan recently ran a successful training event/workshop on BRMS.
Yusuke has been also working on the localization of BRMS’s web UI.
A recent feature committed into Guvnor trunk is the ability to track what you have opened, or edited – this shows up under an “Inbox” item in the main navigator. Recently Opened Clicking on the recently opened item will open a listing of all items you have “recently” opened (it tracks a few hundred itemsRead more →
A recent feature committed into Guvnor trunk is the ability to track what you have opened, or edited – this shows up under an “Inbox” item in the main navigator.
Recently Opened
Clicking on the recently opened item will open a listing of all items you have “recently” opened (it tracks a few hundred items that you were last to look at). Pretty simple
Recently Edited Any items that you save changes to, or comment on will show up here, once again, pretty simple
Incoming changes This tracks changes made by other people to items that are in your “Recently Edited” list. When you open these items they then are removed from this list (but remain in your Recently Edited list).
All pretty simple (one of those things that are simple to grasp and use, and painful to implement ! as are all the good things in life).
Some people have asked about a tool mentioned some time back for creating smart forms made (which was being done by Solnet). This is being prepared to be open sourced, and will have a section on jboss.org where you can find it/download it. Status update from Derek: Just a brief update: There is a proposedRead more →
Some people have asked about a tool mentioned some time back for creating smart forms made (which was being done by Solnet). This is being prepared to be open sourced, and will have a section on jboss.org where you can find it/download it.
Status update from Derek:
Just a brief update: There is a proposed name: Tohu (which is a Maori word whose meanings include to advise, guide or instruct). We are basically happy with the state of the code. What we are working on is the documentation and various other supporting artifacts prior to releasing this to a wider audience, which should be within a matter of weeks (hopefully sooner rather than later).
And now for something completely different… A recent feature request was for a discussion/comment feature for files in Guvnor: The comments are below the “documentation” section (and of course optional) (and there is an Atom feed to them). An interesting addition was using a “backchannel” type connection that is kept open from the browser toRead more →
And now for something completely different…
A recent feature request was for a discussion/comment feature for files in Guvnor:
The comments are below the “documentation” section (and of course optional) (and there is an Atom feed to them).
An interesting addition was using a “backchannel” type connection that is kept open from the browser to allow messages to push back – this means (when enabled) that messages show up in real time (and other handy things like if something is added to a list – the list is updated).
There are a few ways of doing this in a browser – but it all boils down to the same idea: opening a connection which “waits” on the server – the server can then “push” response messages back down this pipe (whence the client reconnects, waiting more). This type of thing is becoming more and more popular in “real time” features of websites, interestingly (but it is quite an old idea).
Here is a video which shows at the end 2 browsers, and the second one being updated in “real time” ** by the first one.
Enjoy !
** Yes this is not really “real time” but the term seems to have caught on due to things like Facebook, Google Wave etc…
A common problem with writing systems in rules, is when you are mutating data (modifying working memory in any way) it is possible to have rules activate themselves over and over, and cause a non terminating loop (also known as an Infinite Loop ;). Now we all know we can’t know for sure (yet) thatRead more →
A common problem with writing systems in rules, is when you are mutating data (modifying working memory in any way) it is possible to have rules activate themselves over and over, and cause a non terminating loop (also known as an Infinite Loop ;).
Now we all know we can’t know for sure (yet) that ANY program will terminate – but still, its troubling to have run away processes etc…
So to stop the simple case of a rule directly activating itself, we of course have the “no-loop” attribute: this instructs the engine to not let that same rule be activated as a result of its consequence. Of course this only works for simple cases: its possible for ruleA to triggle ruleB, and then back to ruleA and so on (or even more complex patterns).
In unit tests – its usually easy to spot non terminating cases, and its not that troubling as they are obvious. Buried in an app this is more troubling however.
In many cases the results of this looping is mostly harmless – you would rather it just get over itself and return something right ?!
There are a few ways to help with this issue:
1. Set a max fires value when executing – this pretty much ensures it will finish (this also assumes that you know what a reasonable upper limit is for the number of rule firings – not always the case).
2. Avoid modifying an existing fact (well – not always helpful to say this – its a bit like a doctor saying “don’t go and get the flu !”).
3. Cycle detection:
Well if you were to note down all the names of the rules firing, you would notice that a cycle forms (a repeating pattern) which may or may not be obvious to the eye. You could perhaps decide after a certain amount of time that you will just stop and say “enough is enough ! I think you are going in circles”).
There are a few algorithms for detecting these cycles, such as the Tortoise and Hare:
(which I like because it has a cute diagram):
The basic idea is that the main phase of the algorithm is where the hare moves twice as fast as the tortoise, once they both sit on the same value, they have the potential start of a cycle/loop (and if they move in sync after, they can find out the length of a potential cycle – you can read more on the Wikipedia link above).
Now all this isn’t really necessary for what we want. If we were to look the names of the rules executing in sequence, at a given point in time we can take a look at that list, and see if it ends in in a cycle/loop. Unlike the above, we aren’t concerned with finding any cycle – but only one that starts at the end. If the cycle is repeated enough, then we could say it *might* be stuck in a loop (the cycle might be 1 rule firing over and over, or a sequence of rules that fire over and over…).
So a rough algorithm might be to flip the list of firings around, and anchor the “tortoise” to the start, and then look for a potential repetition, check if it is a repetition, if it is, check its length. We can then decide if the repetition carries on for long enough, to terminate (this can be done by Listener implementations).
To try this out, I wrote the following (Scala) code, and applied it as a Listener. Every 1000 or so firings I would check the log, and see if a cycle had formed. If it was, and it was a certain number of iterations (but could be variable in size) I would return:
/** * Take a list, return a list of the pattern that is repeated, and the total number of items that are * detected to be in a repeated pattern. Loosely based on the tortoise and hare algorithm, only in this case * I break the tortoise legs as I don't want him to leave the start line. */ def locateLoop(list: java.util.List[String]) : (Array[String], Int) = { var i = 1;
val endVal = inv(list,0) var pattern = Array(endVal) var cycleSuspected = false var confirmed = false var cycleY = 0 var cycleX = 0 while (i < list.size - 1 && !confirmed) { val v = inv(list, i) if (v == endVal) { cycleSuspected = true cycleX = 0 cycleY = i var repeatingItems = Array(endVal) while (cycleSuspected) { cycleX = cycleX + 1 cycleY = cycleY + 1 if (cycleY < list.size) { if (inv(list,cycleX) != inv(list,cycleY)) { if (cycleX >= i) { pattern = repeatingItems // println("Terminated With Loop Found") } cycleSuspected = false } else { // println(list(cycleX - 1)) if (cycleX == i) { confirmed = true // println("Found !") } if (!confirmed) { repeatingItems = repeatingItems ++ Array(inv(list,cycleX)) } } } else { pattern = repeatingItems cycleSuspected = false } } } i = i + 1 }
(pattern.reverse, cycleY) //this is the return value - the pattern plus size !
Certainly seemed to work well. There are many cases where a deep recursion does occur, where this might detect false positives – so its not a general solution, BUT, for many business rules scenarios (for example executing on a web server as the result of a request) it can work as a safeguard quite nicely (in other words, another optional tool).
Some other suggestions I have had were to look at the cached hashcodes of the tuples causing the activations – the idea being that if there is looping AND no data mutation – then the looping is clearly useless and should be stopped. I also tried this, but it can’t really work with the hashcodes as hashcodes do NOT have to change as a result of data mutation. (Sadly, this means that deep-ish copies would need to be made of the data to watch for mutation – a cumbersome and expensive option and still not fool proof).
A feature recently checked in to trunk: an optional attribute to tell the editor to “freeze” parts of a rule. This is useful if you want to give some users access to some rules – but not change the structure (remove bits, add bits, general mayhem). Users with sufficient permissions can edit options, and canRead more →
A feature recently checked in to trunk: an optional attribute to tell the editor to “freeze” parts of a rule. This is useful if you want to give some users access to some rules – but not change the structure (remove bits, add bits, general mayhem). Users with sufficient permissions can edit options, and can choose to freeze sections:
..after which the editing stuff will be hidden away, and only field values can be edited: … of course, users with sufficient permissions then can remove the lock as needed:
… allowing them to continue with Project Mayhem if that is what their goal is.
Now to turn this into templates, a few more moving parts are needed (TBD), but basically it involved crafing the templates, locking them (and giving them sensible names) and then allowing people to create rules based on these templates….
These are my notes and pictures – I am sure others will have notes and pictures to post (if you do have pictures, feel free to email them to me and I will share them here, or links to Flickr or whatever…). First day, “state of the union”: We had a few kind-of presentations eachRead more →
These are my notes and pictures – I am sure others will have notes and pictures to post (if you do have pictures, feel free to email them to me and I will share them here, or links to Flickr or whatever…).
First day, “state of the union”:
We had a few kind-of presentations each day, but mostly unstructured. I think it worked pretty well for the most part.
Also had JavaOne duties: Just a few of the interesting things I worked on with others:
Franklin American crew:
a Guvnor plugin to persist rule data to a RDBMS in a reasonably normalised format (that they could mine, use for other things)
a design for “smart views” – searches that are persistent based on category, status etc, which can be used to build/run tests and “deploy” (so you are only deploying certain rules in a certain status) – selectors on steroids.
NHIM: Talked with Emory Fry about a standard rule based “platform” for the National Health Information Network – the idea being a common model, execution server and environment so that rules can be sent as messages, and processed close to where the data lives (rather then having to pull all the data around).
Michael Finger worked on making Jackrabbit clusterable for failover (I expect a blog from him sometime !).
A general point I took away was the different ways people will want to integrate and re-use your code, often in unexpected ways. I need to be more vigilant in leaving clear interfaces, with documentation for others to use, and think more about plug in architectures that allow people to extend things in an safe and upgrade friendly way.
For some R&R some of us went on an epic ride across the Golden Gate Bridge:
Kris Verlaenen tried to kill us a few times, taking us down dead end hills only to ride back up. Kris is quite fit and this meant nothing to him 😉 Another fact about Kris: please address him as “Dr Kris” as he actually has a doctorate.
