Currently there is:
- nqueens (the "hello world" example)
- traveling tournament (trying to break the record) (trick spec)
The serious examples:
- curriculum course (ITC2007 spec)
- examination (ITC2007 spec)
- patient admission scheduling (kahosl spec)
I wouldn't cut any of those examples.
It's not that much work keeping them up to date
and it's a good way to test the framework.
The only one I might cut too is:
- miss manners 2009 (james owen spec)
Actually, in time I 'd like to add these serious examples if I find
decent a specification in a research paper or a competition and I have
lots of time:
- bin packaging
- employee shift rostering
- vehicle routing
Most business implementations are a variation on one of these serious
With kind regards,
Geoffrey De Smet
Michael Neale schreef:
Good point (in fact that is what I do !) - so yes, perhaps just a
couple of canonical examples are ideal... once features stabilise, let
the examples branch out.
In fact almost 2 examples is probably enough - easier for users and for you !
On Sat, Dec 26, 2009 at 9:57 AM, Geoffrey De Smet
> API changes aren't a problem, they are refactored along.
> The problem is keeping the examples up-to-date with the newest
> improvements, such as relativeSelection, StartingSolutionInitializer, ...
> Users copy-paste from an example and it's a pity if they don't use the
> best techniques because they started from an older example.
> With kind regards,
> Geoffrey De Smet
> Michael Neale schreef:
>> ok with me - what aspects of maintaining examples are hard? api
>> changes? (just want to know for my own purposes)
>> On Sat, Dec 26, 2009 at 1:35 AM, Geoffrey De Smet
>> <ge0ffrey.spam(a)gmail.com> wrote:
>>> I am thinking about removing the lesson schedule example from Drools
>>> Planner in order to cut down maintenance on the examples.
>>> The curriculum course example is a more advanced form of that example.
>>> Does anyone object to this change?
>>> With kind regards,
>>> Geoffrey De Smet
>>> rules-dev mailing list
> rules-dev mailing list