Monday, 28 February 2011

The Human and Computer OR

There is often some confusion between normal humans (i.e. not software designers) and computers regarding the use of "or".

The human way:

  • are you going to the movies this evening or tomorrow evening?

To most humans this is an exclusive or indicating that only one of the options is possible.

The computer way:

  • are you going to the movies this evening or tomorrow evening?
To a computer, the answer to a boolean condition is either yes (true/1) or false (false/0).
  • The computer will answer yes if you're going to the movies this evening.
  • The computer will answer yes if you're going to the movies tomorrow evening.
  • The computer will answer yes if you're going to the movies this evening AND tomorrow evening

Short-circuit evaluation

Most computer languages will not evaluate conditions that have no (longer any) influence on the total result.

So, an if statement containing one more AND operators will stop evaluation if one condition evaluates to false, because the total will always be false.

So, an if statement containing one more OR operators will stop evaluation if one condition evaluates to true, because the total will always be true.

If you wish to explicitly evaluate all operators in Java, try the | (OR) and & (AND) operators instead.

Good luck!

Wednesday, 23 February 2011

Pre- and Post Conditions

< not here yet >
  • assertions in private methods, indicate programming errors
  • checks in public methods using if->throw new Exceptions, indicate wrong use of public API (IllegalArgumentException might be a good one)
  • Contracts (just had a look at Contracts for Java) - use annotations to put down pre- and post conditions.

Thursday, 17 February 2011

"HTTP Redirects considered harmful"

To those of you not "in the know", the title above refers to that most famous of computer science literary pieces, written by dutch IT professor Edsger W. Dijkstra.

"Go-to statement considered harmful"

Most software designers in general agree with the premise written above. And so, a great number of applications have been designed very carefully without anything approaching "goto statements".

However, software designers would not be software designers if they couldn't find a way around this.

I am talking about the ability to create "redirect" http requests and "forward" requests. Once more the difference:

  • "redirect" requests tell your browser to go someplace else
  • "forward" requests are done at server level, and your browser is ignorant of this fact
  • javascript: window.location = "something else"; (this particular one is a clue that someone somewhere is having to hack his way through problems)

I've seen some examples of the problems that can arise, when used too much or wrongly, to wit the following:

  • redirecting an http error to an error page. The error page can be found, returns HTTP code 200 ("Ok") and the browser loses any knowledge that anything went wrong. (A rather severe problem when dealing with REST services.)
  • forwarding to a different url, or a different webserver for that matter, causing the original request to be lost. (for example, you may lose the ip address of the browser that sent the original request. this causes the problem of no longer accurately validating requests based on ip.)
  • the dreaded "The site is redirecting the request in a way that will never complete.", meaning that it's possible that our redirects are stuck in a nice little loop.

A lot of these redirects and forwards grouped together can cause an application to become a truly dizzying maze that's impossible to analyse and might just provide a severe performance hit.

Some examples that make use of it:

  • apache mod_proxy
  • javascript: window.location = "http://new.website"
  • javascript: top.location = "http://new.website"
  • response.sendRedirect(url);
  • request.getRequestDispatcher(new_url).include(request, response);
  • getRequestDispatcher(new_url).forward(request,response);
Please try and limit these to as few as possible. It will make your life easier. I promise.