Sunday, 14 September 2014

Setting up Drools Execution Server

The Drools Execution server (6.2.0-Beta2) has a demo video which looks good, but I needed to know how to set it up on my own machine.

It is not quite obvious how to do this (but this is beta code, so there is a good excuse for that). Still, I thought I'd document how I did it here to save others time.

I'm running Xubuntu 14.04 but the operating system is unlikely to be relevant. Translate as necessary to Windows or OSX path names.

First you need an application server. I'm using Wildfly 8 (used to be called JBoss). Get and unzip it into a directory we will call . You need to add a couple of user names before you start it up. Use the /bin/ script to add two users we'll call user1 and user2. Make user1 an admin user and user2 an application user. Leave the groups field empty for user1 and (confusingly) make the group of user2 'admin'.
For the question after groups enter 'no'.

Now you can start Wildfly using /bin/ and browse to and log in as user1.

Download the two war files you'll need.
Drools Workbench (this is the Wildfly-specific version)
Drools Execution Server

Use the Wildfly Management to load and enable the two war files.
We're nearly done...

Log into this URL using user2

Okay, now you are in the demo. The ones in the video have some different files loaded but the ones you have now
seem to work. You can certainly deploy them and you can certainly call them with a REST client.

Saturday, 6 September 2014

People who say 'Well I think..."

Here I am listening to a radio broadcast of a panel discussion between several
political candidates in our impending general election. It's a well run discussion (thanks to the skills of Wallace Chapman), and unlike some similar events, everyone is behaving well so we all get to learn a lot about who thinks what about what. This is good. Here is the relevant

But what I'm more interested in here is not so much the specifics as the pattern they take. For example there is a question about what the voting age should be. Currently it is 18. I remember (just) when it was 21. Should it be higher? Should it be lower? What do you think?

This seems a good question, certainly worth asking. At 18 we can sign contracts, marry (actually we can do that at 16), vote, buy alcohol and join the army. We don't have any need to conscript soldiers just now, but when we have had such a need it has been tied to the voting age on the understanding that if you're not old enough to vote you're not old enough to be made to risk your life for your country.

So the panel tossed the question back and forth with answers starting with 'well I think...' and speculating that some younger people are old enough to vote and perhaps they should. Then others think it is about right or maybe could be higher, especially with alcohol purchasing.

What no one suggested is actually studying the people involved. Do we have any good data on how well informed 10 year olds actually are? 12 year olds? 14? 16? 18? Surely this is critical to setting the age. We know from other studies that IQ has been shifting upwards for years. This is called the Flynn Effect (Flynn is a New Zealand scientist, but the effect is observed world wide). So it is not unreasonable to suppose that our understanding about how younger people  make decisions is out of date.

Step back a bit, though. This is really not about the specifics. It is about gathering data. It is not enough to base policy on 'well I think...', and it seems we do too much of this. What any of us 'think' about some issue is far less relevant than what the data says.

Another example just to round it out: we have a minimum wage in NZ. Some people think it should be raised, others want to scrap it. The latter tend to say that raising it will cost jobs. This is a 'well I think...' statement. It is very easy to show data that raising the minimum wage does not cost jobs by looking at what has happened when this was done elsewhere. I've yet to see a study referenced that shows it has cost jobs. Maybe there is one, but let's see it instead of having people say 'well I think...'

So watch out for people saying 'well I think...'. If you can, ask them why they think that. Press them for data, some reference to some properly conducted study that demonstrates what they are saying is true (or at least not false, which is subtly different but okay). If you want to pursue this further get hold of Karl Popper's The Open Society and its Enemies which is about some other things as well but he argues better than I can for evidence based policy. Popper wrote this while he was lecturing in Christchurch, NZ during WWII (as an Austrian Jew he needed to leave Europe, but his German heritage made him unwelcome in the armed forces on our side). So there is a local connection there too.

Saturday, 2 August 2014

Do we really want one law for all?

One Law for All. It's a good slogan and, like Motherhood and apple pie, pretty difficult to object to. Some of our politicians have started saying this. We have an election coming up here in New Zealand. The sub text of the slogan is that some people feel that Maori are getting a better-than-fair deal. Specifically two things:

We have a separate Maori electoral role which elects its own MPs. Sounds very apartheid at first glance, but the first difference is that Maori themselves decide if they vote on the General role with the rest of us, or on the Maori role. And when I say 'decide' I mean each individual makes that choice, it isn't delegated to some representative body that is out of their control. If Maori don't want the role they can just (individually) stop using it. The other difference is that the MPs are real MPs, with as much status as any other. So not apartheid.

The second thing is that there is consultation about various issues such as how land gets used, where motorways get built and so on. One of the objections to this is that such consultation takes up time and time is money.
These two privileges get some people fired up and using the word 'unfair' and so on. I guess I'm in the demographic that gets fired up: white, middle class, middle aged, male. So why aren't I?

The answer is, quite simply, history.

If you were on the first boat load of people to arrive in this country and you were setting up a society for the first time, from scratch, 'One Law for All' is just obvious. But we aren't. Not by a long shot.

When the English took over New Zealand they did not do it by conquest. They signed a treaty with Maori. There are arguments over what that treaty says, not uncommon with legal documents, but it is pretty clear that there was a promise that Maori would be able to keep the rights they already had over the land. This is more complex than it might sound. In the UK the land is owned by 'the crown' and people actually own a 'title' to the land, which is a licence to use it rather than ownership. I've heard there are strange exceptions to that but it is generally the case. It is the same here in New Zealand. So the New Zealand land effectively became owned by Queen Victoria in 1940, with Maori now having a title.

This allows the state to exercise compulsory purchase when, say, they want to build a motorway through your house, dig for oil under and fly planes over it. We don't have a simple ownership right to our land, we have a title.

Okay, almost before the ink on the treaty was dry boatloads of settlers began arriving from England and they wanted land. The history is a bit complicated but dirty deals were done, fighting broke out, troops from the UK were brought in to quell the rebellious natives and land was confiscated. It wasn't only confiscated, there were other ways of prising Maori apart from their land which were more subtle. Remember the compulsory purchase? It was decided that Maori land did not need to be 'purchased' as such, it could be just taken if the state needed it. Since it was simpler to take Maori land rather than pay money for other land you can guess that was the preference. While the fighting was over fairly quickly, the compulsory 'purchase' arrangements continued well into last century.

Less formal was the casual prejudice that sidelined Maori economically. I grew up on a farm that was confiscated land and we had a Maori farm hand. I'm not sure my father and the farm hand gave much thought to the history, or even if they knew it. But the farm hand wanted to buy a car and he needed a loan. My father knew the bank manager well so he talked to my father about it who approached the bank manager on his behalf. My father told me he explained to the manager that this farm hand was in steady work, was a reliable character and that he himself was prepared to guarantee the loan. The bank manager explained that this, then state owned, bank did not lend to Maori. So there was no loan. My father had a loan, but he was white.

The result was that all the best land got into the hands of white settlers who cleared it and farmed it and built our economy on it.

But the unfairness of this came back to haunt us eventually and late last century we started doing something about it. The first major compensation settlement was for Tainui, the people who used to own the rich Waikato area. They got some land back and cash. I remember at the time people pointing out that Tainui were magnanimous. The value of the compensation was nothing like what they had lost. Everyone understood that the only land that could be returned was land that had not passed into private hands, and there was no way the cash could make up for it. This has been the pattern for subsequent settlements. No one, at that point, suggested there ought to be one law for all. One law for all would see farmers turned off their lands and any government trying to make that happen would never survive another election.

Since then there have been moves to respond to this magnanimity. The Maori electorate seats were already there, they've been in place since 1867, shortly after the fighting and they were brought in to ensure Maori could vote. In recent years the number has been expanded from 4 to 7, to more fairly reflect the number of people on the Maori electoral roll. Consultation with the local iwi (tribe) over various issues is commonplace, though not always comprehensive or even popular, but it is a move in the right direction.

We now get situations like this where a taniwha, or water monster, held up a highway construction for, it was claimed, 3 weeks while local Maori were consulted. Now, some people got very, very annoyed about this and talked up the cost of the project, the amount of time wasted and the 'ridiculous belief' in taniwha. I saw it as real progress. We often accomodate various 'ridiculous beliefs' such as the value of heritage and religious sites and surely Maori, to whom we owe so much, ought to get similar accomodation.

But let's not get carried away about having one law for all. If we insist on that it will cost us dearly.

Tuesday, 29 July 2014


I live in the woods, so getting the internet here is not as obvious as it is to most of you. I few months back when I realised my neighbour had wired broadband I tried getting it to my house too. The technician came out in a van and a hi-viz vest, poked a the phone line connection to the house, made that ticking sound with his tongue and drove off. Soon after I got a letter saying I was too far from the exchange to support wired broadband, oh and please send back the modem they had couriered me.

So, excitement over, I continued using my phone as a wifi hotspot, sharing its 3G connection. That works quite well but my plan is capped at 3GB. When I say capped that means no more data after that. Some plans allow you to pay something and put a bit more data on. Not this one. Capped means capped. It is actually an old plan and, based on the odd letter and phone call I get from Vodafone they would like me to switch, but the only things they have to switch to have less data and more voice time. Since I almost always hit the end of my data and never run out of voice this is not attractive.

You may imagine I look at the wired broadband plans that offer 80GB caps (they're pretty well always capped in NZ) with envy. I can add to my 3GB by going to the library where I get 200MB a day, but I feel kind of 3rd world doing that. My favourite cafes offer unlimited but if I camp there all day I end up drinking too much coffee, though I tend to get all my updates done by making sure I breakfast out most weeks.

But when I get doing something like installing new software, or developing new software (which inevitably needs me to pull down some new libraries) I can easily find my quota is blown. Checking G+ gobbles up about 50MB so I don't do that every day.

Mrs has a T-stick, a little USB 3G modem she plugs into her laptop. It will actually plug into a wireless modem we have so it would be a lot like everyone else has, ie wifi all over the house connected to broadband. Her plan has a cap as well, an extendable cap. That's because it is with Telecom instead of Vodafone. So I got thinking: if I got another T-stick I'd get another 3GB. Extending Mrs for another 3G is more expensive than a separate one, besides she doesn't quite trust me not to chew through all her quota (and she is right not to).

These T-sticks come trumpeting their support for Windows and Mac machines... but not Linux. So I expected to have to scratch around on the web and find out what to do. Mrs' T-stick doesn't work OOTB, I tried it. I believe it is possible and when I convince her to switch to Linux I'll need to figure that out. But my new T-stick (pictured... it's not a tampon) just worked. No config, nothing at all. It shows up as a wired connection. For anyone else trying this it is the E3531 T-stick and I have it running on Ubuntu 13.10. It has a little web server in it you can browse to if you need to change the config or send/receive TXT, or you can ignore it. Just browse to

I'm not actually in the woods right now, I'm down in the city (Auckland) so I have it on my laptop, but when I get home I will plug it into the modem and use the house wifi. I probably need about 4GB/month so I can either top it up when I need to or I can use my phone, though I expect I will change the plan on the phone now, quite possibly I'll switch it over to Telecom since they seem to do a better job.

There's a second reason to switch the phone to Telecom. We don't have a land line connected. That's our choice, we used to have one, but we never used it because we have the mobiles. So when we had a big storm a while back the Vodafone network went down. The Telecom one stayed up. It meant Mrs could get online but with both phones on Vodafone we could not voice-call (and I had no internet). We didn't need to call anyone, but it might have been handy if we had an emergency. So it seems prudent to spread it around, especially since it is no longer vital to keep that 3GB plan.

With the house wifi providing internet I can use it like the rest of you do, ie multiple devices connecting to it, hang a USB drive off the modem for simple file exchange and backup and make better use of our wifi printer. My phone needs to be plugged into power to hotspot because that chews through the battery, so doing that less will be nice.

Monday, 9 June 2014

Winging it and the Peter Principle

This story from the Guardian came at me from multiple people who +1's it or tweeted it or whatever. It's good, feels true etc. Read it now, I'll wait.

Like I said, it feels so true and at one level it certainly is. I was sitting at my laptop struggling with writing some tricky code, trying to figure out why whatever ought to work wasn't and thinking 'yeah, I am totally winging it here' which was true except for the 'totally'.

We work on the edge of our expertise a lot of the time. For many of us that's where the fun is, the challenge. It makes us grow, or it tells us our limits or something. We don't even think about the things we do that are second nature.

This is related to the 'Peter Principle', the notion that we are all promoted to one level beyond our expertise, which is just another way of saying we work on the edge. The Peter Principle is about people being promoted until we find they are in a position they cannot perform in. They've been good up until now, but the latest rise up the corporate ladder was one too many. They stay there because the people who put them there are too gutless (or incompetent) to push them back down again.

Mostly this is rubbish. It assumes there is just one point where people switch from competence to incompetence and that that this cannot be changed. I suggest that every new promotion has its challenges and each one takes time to work through, but what is really true is that we work on the edge of our expertise all the time. And it is true even for those of us who don't work in a corporate environment where 'promotion' is a foreign concept. We take on challenges because they are fun.

But are we totally winging it? Of course not.

Take some basics. I code using a laptop, mouse, second monitor etc. Do I have the slightest difficultly operating the mouse, getting it to point where I want and so on? No. It's not a trivial skill. Try teaching it to someone over 80 who hasn't used a mouse before. The development environment I prefer is Eclipse and I use it to write Java and C++ code. Navigating the file structures in that environment is something I do without hardly a thought. And, of course, those two languages have syntax which is as natural to me as speaking English. This isn't blowing a trumpet. Anyone who programs in this environment works this way.

A little while ago I reorganised my projects to build with maven instead of ant/ivy. I didn't know maven and I hate reading manuals. I generally read a little and try it, fall over, do a little more reading (just enough, I'm lazy) and get past that problem and so on. I was winging it the whole time. Now I use maven every day, and I don't think about it.

So it is true that we wing it all the time, but that is because we like working on the edge, but we're only on that edge because we have a rump of expertise to be on the edge of. So winging it, sure, but not totally winging it.

Sunday, 1 June 2014

Madura Demos

I've re-deployed my demos. This is more interesting than it sounds, well I hope it is anyway. I've already posted about each of them. This is about the pain of getting them up there and running in the cloud.

Long ago I had them running on CloudFoundry and they worked fine, then the CloudFoundry business model changed and their free option went away. Since I make no money from this stuff the demo site has to be free, so I went to AppFrog who were running the same CloudFoundry software and they lived there for a while...until the same thing happened.

Recently, after completing the Workflow project, I had some free time so I thought I'd try and get them going on Google Application Engine. But I gave up on that yesterday (yes, it was only yesterday) and loaded them onto OpenShift (Red Hat's cloud offering). They worked first time. It was so easy. I was surprised.

The reason I was surprised was that it was so very hard to do Google Application Engine. There were two main issues.

First, GAE doesn't like Logback, which is a commonly used logging mechanism and I use it everywhere (because commonly used means it should work everywhere, right?) GAE only likes JUL and no one I know uses JUL. JUL is the native Java logging mechanism and it is the reason for products like Logback, ie people hate JUL and want something else.

But switching to JUL was not a big deal. I wouldn't want to have to work with it, but these demos are already debugged so that's mostly okay.

Next GAE needs lots of classes to be serializable so it can flick sessions between servers. I see the sense of this and I went off and made all my classes serializable. It didn't take very long, actually. Of course I tried it out using GAE's Eclipse plugin to make sure it was working and it was.

But when I deployed it for real it complained of more classes that needed to be serializable. However these aren't my classes, they're libraries from other people. Spring etc. I can't change them (well, not unless I want to maintain them ever after, and I don't). I suspect there is a solution to that particular problem but I'd noticed that the only way to find out any of this stuff is with the remote deploy. The local test told me nothing. This was true of the Logback issue too. So I realised this might go on forever and I bailed.

Openshift, in contrast, was quite happy with Logback and didn't care about Serialization. That may cost them something in efficiency, but it sure got up and running fast.

There seem to be two general approaches with Openshift: using Git and using scp. The Git option assumes you store your project source on their Git repository and they build and deploy from there when you tell them. Sounds fine, but I already have a public Git repository at GitHub, and my maven build works just fine. I don't feel a pressing need to learn their build syntax etc, though it is likely easy enough.

The scp option is basically 'I have this war file, upload it and deploy it'. Great! That's what I did. Worked first time. I suspect the running applications are not as fast as they might be but for a free service I can live with that. I'll even listen to arguments that GAE's serialization requirements really help Google deliver a faster application. But working trumps speed and I have it working.

Madura Pizza Order Demo

I'd meant to post an entry about putting my demos on line so people can play with them and not have to build the software. Not everyone, it seems, is actually a software engineer :-). Then I realised I had never actually posted anything about the basic pizza order demo. So here it is.

The purpose is to show off the Madura software I've been working on some time now. All of it can be found on my Github repositories, all open source and, with one exception, all of it free. The idea with Madura is that it makes use of rich business objects (Orders, Pizzas, Employees etc) to remove code from the application. These objects are very rich, in that they can include business rules that monitor what is going on. Most people do this with application logic and UI logic which is harder to write and maintain than what we have here.

The demo needs to be run from Firefox. It works on IE6 (I don't run Windows normally but I had an old version lying around). Don't use Chrome because that will show you the mobile UI, which is a different demo. I guess I should add don't run it on your mobile device either. It works, but it isn't the demo I'm about to describe.

We are supposedly ordering a pizza (but don't worry, no pizza will be delivered). There are several pizza related products but the most interesting is the Configured Pizza, which dynamically adjusts the choices to be compatible with what has already been picked. The premise is that only some combinations of topping, base and size of pizza are allowed and the Madura-driven UI only ever
presents valid choices, dynamically altering the fields as necessary.

Click on the URL and log in as admin/admin. You should see something like this:
We'll configure a pizza in a moment, but first click on the Customer button.

Notice the four buttons at the bottom and that one of them, Dynamic,
is disabled. Enter the name 'fred' (without the quotes) in the Name field and tab off it. The Dynamic button is now active. Change 'fred' to something else. The button is disabled again.

What is going on here? Do we have some custom javascript or custom java driving this? Actually no. That's what other people do.

There is a rule defined using Madura Rules which controls whether the button is disabled or not. This is the rule:

rule: Customer "dynamic" {
    if (name == "fred") {
        dynamic = true;


 Normally this kind of thing gets done in something like Java, and you'd write code to test if the name field was 'fred', and you'd also write code to test if it was not 'fred' and then set dynamic to false. One of the nice things about rules is that their converse is implied without having to write it, so this is all we need.

The next demo step is to enter something into the email, eg 'abc'. Now you see an orange '!' beside email. This is the usual way Vaadin indicates an error. Roll over it with the mouse and you will see

Failed email: label=email not a valid email address, attempted=abc 

which is the default error message for this kind of error. The email field
requires an '@' sign so this is a simple validation error. There actually isn't a proper rule for this because it is too simple. We just add an Email annotation on the field and the rest happens. Naturally you can customise that error message and you can add I18n alternatives (which means it can show up in French etc if you need it to).

Also notice that the Save button is now disabled. This happens automatically because there is an error. You don't even have to write a rule. When the error is cleared the Save button will enable.

Change the email field to something valid and click the Save button to get back to the home page. You have a list of products on the left hand side. Expand the Sides heading and click on Boneless Chicken.
There isn't any configuration for this product, just a price. But note
that the message about the shopping cart now says it contains one item. This message is controlled by the following rules:

rule: Order "shoppingcartsize" {
    if (count(orderItems) > 0) {
        shoppingCartStatus = format("shopping.cart.status",count(orderItems));

rule: Order "shoppingcartsize" {
    if (count(orderItems) == 0) {
        shoppingCartStatus = format("shopping.cart.status.empty",0);

We could make this simpler if we were happy with saying 'Shopping cart contains 0 items', then we would only need one rule. But 'Shopping cart is Empty' looks nicer. The 'shopping.cart.status...' references are to a properties file that holds the actual messages we need, including the error messages mentioned above. The French messages are in a similar file, so if your user was French it would say "Le panier est vide" when the shopping cart is empty. To be clear, the language thing is just ordinary Java stuff, though it is rarely applied this well.

Now press the Save to Order button to keep the product in the shopping cart. The Cancel button would remove it so don't press that. The next step is to expand Pizzas and pick Configured Pizza.
This is a more complex form. There is a date field, which like all the other fields, is a standard Vaadin widget. The amount at the bottom is zero, until we pick enough options for the rules to work out a price.

But the first thing to note, which you cannot see very well on the form, is that this form is generated using exactly the same Java as the Boneless Chicken one. The only difference is that object it maps to is different. This is part of the 'rich objects' thing. The objects themselves have enough information in them for the Java code to build us a form. So defining a new product doesn't involve writing more Java (necessarily). It just needs the right object and the right rules.

Now we start configuring our pizza. Change the default Base to 'Puff' and pick Size='Medium'.
There is a new field called testing now and it has a red asterisk beside it, which is standard Vaadin for indicating a required field. The Save to Order button is disabled because we now have a required field that is not filled in. Finally you have an amount calculated. This is the relevant rule:

rule: Pizza "p3" {
    if (size == "Medium") {


amount = 15;

activate(testing) makes the field visible and require(testing) makes it required. There are no rules to disable the Save to Order, that is handled in the same way as the error in the Email field, ie automatically.

But there is more. Check the options for Topping. They should be Italian and Spanish. Now clear the Size (and notice the testing field vanishes and the button re-enables). Check the options for Topping again. There are three others. The lists of valid values are being dynamically constrained depending on what else is picked. This is independent of the order they are picked, so if you pick Topping first then Size will be constrained and if you pick Size first then Topping will be constrained.

The rules behind this aren't convenient to express in the if/then format we've seen so far, and they are awful in an ordinary language like Java. Instead we use decision tables. The format of the table in this case is XML but it could be a database table or, if you're prepared to write some code, something else. I won't bore you with the XML here. Conceptually the table looks like this:

topping          size
Seafood            Small
Italian               Medium
Spanish             Medium
Hawaiian          Large
Greek                Large

Pick some valid combination, press Save to Order then press Checkout.
This just lists the resulting order items and their prices with a total. The total is
calculated using a rule:

formula: Order "sum" {
    amount = sum(orderItems.amount);

This is fired whenever we add or remove an item from the orderItems list, or if we change the amount of something already in there.

Part of the richness of the objects is that they include permissions on the fields. For example the admin user you are logged in as has all permissions. Another user operator/operator has slightly less capability. For example he doesn't have access to the address field of the customer so when he goes to that form it doesn't show up. There is no code to write to handle that, it is just part of the object definition. Similarly if you type 'fred' into the name field the Dynamic button doesn't enable. Operator doesn't have permission to use the Dynamic button, so regardless of the value of the name it won't enable even if the rule tries to enable it. Declared permissions trump rule permissions.

All of this, apart from making the application a whole lot simpler is taking us to an interesting question. Since the business objects contain all the logic how come the UI can know what is going on?

It does it by knowing only that the objects are rich, that it can query them for labels and currently valid picks (the pizza sizes and toppings) and if they are required or not etc. It does not ever know anything about the rules, including the simple validation things like the Email validation. And this actually makes it brilliant when we want to implement another user interface.

Usually when a business decides to implement a new interface, such as something that runs on a mobile platform, people discover they've implemented a lot of business logic in their UI and they have to rewrite it for the new system. Then they have to keep the two in sync, doubling the maintenance effort. But we don't have to do any of that. We just write the new UI and leave the business rules where they are.

To prove the concept I went ahead and wrote another Vaadin UI for the pizza order. If you browse to the same URL with your iPad or Android phone or a Chrome browser you'll see it. The login is a bit fiddly, you may need to press the user and password fields to activate them, depending on your device. They are over on the right.

This mobile demo is a bit simpler, it just does the configured pizza so there's no need for a blow-by-blow walk through. You know enough now to try picking different options and see what happens. It ought to be much the same as before.

We said it before but it is worth saying again. Although the UI is different all the rules and objects are the same. The only thing we had to change was the UI code. But we do mean the bare UI. We did not have to write code to restrict the choices based on earlier selections, nor did we have to write any code to track the total order or make the submit button (actually the Log Out button here) disabled until all the required fields are complete. All of those things are managed behind the UI with the same code as before. This shows the power of keeping the business logic clearly separated from the UI, and Madura is clearly an effective way to do that.