And the winning team is:

… Dennis Pallet and Allard Brand with their Mendix implementation of the “University Enrollment Case”.

Congratulations guys!! Well done! Below is an summary of the jury report:

The University enrollment case is the most complete project for several reasons. First of all, the project was correctly modeled; the project contains several validations, delete behaviour was set and they clearly used the Mendix Modeling conventions. The group was able to make use of webservices to streamline the enrollment process. Further, by calling a Java action, they made it possible to generate passwords given that it requires anonymous access. This realistic approach is supported by both admin interfaces and student interfaces. The group also worked out the idea of sending a welcome email to University’s new applicants. Most important, this University enrollment case reduces lots of manual work, processes are more efficient and the simple sign-up process is user friendly.

Proud-looking Dennis Pallet and Allard Brand

And the winning team is:

… Dennis Pallet and Allard Brand with their Mendix implementation of the “University Enrollment Case”.

Congratulations guys!! Well done! Below is an summary of the jury report:

The University enrollment case is the most complete project for several reasons. First of all, the project was correctly modeled; the project contains several validations, delete behaviour was set and they clearly used the Mendix Modeling conventions. The group was able to make use of webservices to streamline the enrollment process. Further, by calling a Java action, they made it possible to generate passwords given that it requires anonymous access. This realistic approach is supported by both admin interfaces and student interfaces. The group also worked out the idea of sending a welcome email to University’s new applicants. Most important, this University enrollment case reduces lots of manual work, processes are more efficient and the simple sign-up process is user friendly.

Proud-looking Dennis Pallet and Allard Brand

Leading techblog covers Mendix.

Check out the article here.

We are proud! Mendix has just been listed “Cool Vendor” by industry research firm Gartner in the category “Cool Vendors in Application Development, New Tools, 2009″ published on March 30th. We see this as Gartner´s recognition of our vision, innovations and success as a team!

Gartner defines a “Cool Vendor” as a company that offers technologies or solutions that are:

1. Innovative: enable users to do things they couldn’t do before;
2. Impactful: have, or will have, business impact (not just technology for the sake of technology);
3. Intriguing: have caught Gartner’s interest or curiosity within approximately the past six months.

On J-Fall 2008 Mendix and Centric teamed by jointly exhibiting at another successful Java conference organized by the NLJUG. J-Fall proved a great event to get in touch with the Java community and to demonstrate the Mendix platform in front of a live audience.

See you again at J-Spring 2009!

The Mendix & Centric booth

Johan den Haan explains

It seems like a month doesn’t go by without a new whitepaper detailing interesting new ways to maliciously apply JavaScript comes out. And this is fine. The problem I have is not with the papers themselves (I enjoy reading them – a lot of novel code appears there) but rather, how the media picks them up. Sure, ‘AJAX is insecure’ makes for clickable headlines, but it’s bad reporting.

When a security issue is reported the first thing that is relevant is discovering whether this is an implementation bug or an architectural flaw. Implementation bugs are fairly trivial to fix (but might have a lot of short-term impact). Architectural flaws are big time trouble.

Ajax security issues tend to fall into neither category. In fact, they usually are not even Ajax security issues. At all.

These issues generally focus on the interesting things you can accomplish as an attacker once you have already breached security by performing a form on how of malicious code injection.

There is nothing inherently insecure about Ajax applications. Their security (or insecurity) depends entirely on how the service provider manages the content delivered to the client.

So the Ajax security alerts don’t really tell us anything about Ajax security in itself. It is by now a well-established maxim in the security community that once an attacker manages to execute arbitrary code on your computer – it’s not your computer anymore. Why would anyone assume the rules have changed because the web jumped up a number in the media?

As an attacker, if you manage to inject your code into a page you can pretty much go hog-wild with the user session. But this is nothing new. For Ajax security the surface area available for attacks is fairly limited. Once you circumvent that the sky’s the limit, of course. There are any number of ways in which it is possible to get around the single domain policy found in all modern browsers. Some of these have even become a de-facto standard for Ajax developers and have lead to comments stating that such policies are pointless (I respectfully disagree here, but more on that later).

The content provider has a trusted role. A function of that role is to sanitize the content. LISP programmers and security programmers have been comfortable with the idea that code equals data and vice versa for a long time. This is for others a rather novel concept, but it’s high time everybody else caught up.

And shifting blame on end-users (a popular activity in the IT world) is simply not acceptable. As developers we have to shield end-users from technological complexity. This includes security. When people use our applications they implicitly trust us. As technology developers we have to honour that trust.

It makes for some interesting food for thought.

The bottom line is that security is hard and we can’t expect end-users to ever comprehend the complexities involved. So dumping security resonsibility on end-users is fairly stupid.

It’s up to us to write decent systems.

Let’s take a shot at controlling the order of execution of synchronous and asynchronous functions in JavaScript.

If you want to play along instead of just reading passively, fire up a JavaScript Shell and copy/paste all code directly into it.

We’ll start off with everyone’s favorite annoyance. Popup alerts.

var sayA = function() {
  alert("a");
}
var sayB = function() {
   alert("b");
}

So, let’s say we want to run those in order. First sayA, then sayB and then sayA again.

var funcArray = [sayA, sayB, sayA];
for (var i=0;i<funcArray.length;i++) {
  funcArray[i]();
}

Nice and cuddly. But that is, of course, no fun at all. Time to start making this a little more interesting.

Let’s pretend we want to grab a random number from an asynchronous request.

var asyncGetNumber = function(request) {
  window.setTimeout(
    function() { request.handler(Math.floor(Math.random()*16)); }
    , 500);
}

And let’s have a say function that alerts the returned value..

sayRandom = function() {
  var request = {
     handler: function(n) {
       alert(n);
     }
  };
  asyncGetNumber(request);
}

And before we start repeating ourselves, let’s have a function that runs functions for us.

var sequence = function(funcArray) {
  for (var i=0;i<funcArray.length;i++) {
    funcArray[i]();
  }
}

Now, let’s rock!

sequence([sayRandom,sayA,sayB]);

Oops. Notice what happened? Our alerts in order were “a”, “b” and here in my case “5″. Not the order we wanted.

As the handler function in asyncGetNumber falls outside of the execution sequence, we can’t control the execution order. Time to change that. Enter action sequences(tm) (get yours free with an extra large order of fries).

Now we’re going to use a few features of JavaScript that are generally speaking less well understood than, say, alert.

We’re going to create and pass around functions on the fly. First we re-write sayA, sayB and sayRandom to accept a handler parameter. This is basically a function that it’ll call when it’s done doing whatever it does. (How’s that for non-specific?)

For sayA and sayB this is pretty trivial.

var sayA = function(handler) {
  alert("a");
  handler && handler();
};
 var sayB = function(handler) {
    alert("b");
   handler && handler();
};

Not very spectacular, right? Don’t worry – we’re not there yet.

A detail to note is the use of,

   handler && handler();

The && works as a guard operator, giving these functions the new handler functionality if a parameter is passed (by executing it), but otherwise operating exactly as they did before.

sayRandom = function(handler) {
  var request = {
     handler: function(n) {
       alert(n);
       handler && handler();
    }
  };
  asyncGetNumber(request);
}

The handler parameter is available in the local scope, which includes the scope of the function found at the handler key of the request object. So when request.handler is executed, the handler parameter passed to sayRandom is available to it.And now we re-write sequence as follows,

var sequence = function(funcArray) {
    // runFunctions is a function that takes the first element of the funcArray
    // and executes it with *itself* as the parameter
    var runFunctions = function() {
      // If there is anything left in the Array
      if (funcArray.length != 0) {
       // Take it out and assign it to a local variable
       var latestFunction = funcArray.shift();
       // Execute it and call with ourself
      latestFunction(runFunctions);
    }
  }
   // Now run it.
  runFunctions();
};
sequence([sayRandom,sayA,sayB]);

Voila. Sequenced actions.
It still looks a little crufty, though.
Let’s clean that up a little. For this we’ll use two aspects of functions in JavaScript. The first being that we can anonymously define and evaluate a function on the fly. The second being that a function in JavaScript can refer to itself, using the local variable arguments.callee.

We’ll use these to create a new local scope that can be referred to with arguments.callee, but which has access to the funcArray parameter passed to sequence.

A direct evaluation looks like this,

(function(){
  alert("How you doin'?");
})();

And combining this with arguments.callee allows you to quickly and efficiently shoot yourself in the foot by blowing up your stack ..

(function(){ arguments.callee(); })(); // Keep calling ourselves

Now, applying this to a re-write of sequence..

var sequence = function(funcArray) {
   (function() {
     (funcArray.length != 0) &&
       funcArray.shift()(arguments.callee);
  })();
};

Much more elegant. Now, let’s use that to get 10 random numbers.

var actions = [];
for (var i=0; i<10; i++) {
  actions.push(sayRandom);
}
sequence(actions);

10 random numbers in 5 seconds, if you click really fast.