Traditional unit tests in test-driven development compare a few concrete example executions against the developer’s definition of correct behavior. However, a developer knows more about how a program should behave than can be expressed through concrete examples. These general insights can be captured as theories, which precisely express software properties over potentially infinite sets of values. Combining tests with theories allows developers to say what they mean, and guarantee that their code is intuitively correct, with less effort. The consistent format of theories enables automatic tools to generate or discover values that violate these properties, discovering bugs that developers didn’t think to test for.

@Theory public void multiplyIsInverseOfDivideWithInlineDataPoints(
    @Between(first=-100, last=100) int amount,
    @Between(first=-100, last=100) int m
  ) {
    assumeThat(m, not(0));
    assertThat(new Dollar(amount).times(m).divideBy(m).getAmount(),
        is(amount));
  }

GapMinder is an interesting presentation of life expectancy data by country and region over time....  What will the people at Google think of next.

• this is very easy
• this is very powerful

The average number of customers in a stable system (over some time interval) is equal to their average arrival rate, multiplied by their average time in the system.   [from Wikipedia: http://en.wikipedia.org/wiki/Little's_law]

 

So in non-computer terms, if 10 people entered a store each hour and each person stayed in the store for .5 hour, then the number of people you could expect to find in the store is 5.  10 * .5 = 5.  OK, simple enough.  It all just seems like the commutative principal of multiplication.  What's the big deal?  Well, the big deal is when you start flipping the equation and making practical applications to understanding your performance tests and your application server configuration.

One application of Little's Law is validation of your performance tests, as described in the article Software Infrastructure Bottlenecks in J2EE, written by Deepak Goel.  Little's Law is used here to validate the test ensuring that there was not an unknown limitation of the testing tool. 

Another potential application is sizing the JDBC Connection Pool.   I have heard the question asked, "How big should my JDBC Connection Pool be?"...and the common answer is something like "Big enough so that you never run out of connection."  While that is true, Little's Law could be easily applied here.  Say under a particular load there are 10 SQL statements issued each minute.  And the average time of these SQL statements is 30 seconds (.5 minutes).  Then according to Little's Law the JDBC Connection pool should be 5.  In reality you may want to make it a little bigger....but it is better than wild guesses like "I set the JDBC Connection Pool to 50, and it hasn't maxed out yet so I will just leave it there."  

Similarly, one could size JMS queues, the number of HTTP Connections, etc... could they not?  Other uses perhaps in optimizing Oracle? 

Something to think about the next time you do something related to queues, pools, or performance.  And with J2EE technology, that might be sooner than you think.

 This is Steve Ballmer, Microsoft CEO, pitching Windows in a 1986 TV advertisement.  I think he has drank the proverbial Kool-Aid.

Courtesy of IFILM

CTRL-ALT-DEL
David Bradely, inventor of the Windows CTRL-ALT-DEL function, describes the origins of the shortcut and makes a joke at the expense of Bill Gates. All of you nerds are going to laugh it up at this one.


Courtesy of IFILM