Quest for improvement - teaching

How to get a servlet to answer

quest — Thu, 27 Dec 2012 11:06:05 +0000

The basic problem, as illustrated by this somewhat aged Jetty pathSpec documentation, is that "/" is treated as "/*" when giving a servlet path spec. Thus, if you want to have a servlet as "front page" in an embedded scenario:

ServletContextHandler servlets = 
    new ServletContextHandler(ServletContextHandler.SESSIONS);
servlets.addServlet(MyServlet.class, "/");

... that servlet will get requests for the entire URL space and no other servlet in the context will get any requests. In particular, if you want to add a DefaultServlet to serve static web pages, images and CSS, that will be tricky.

The solution is to stick each servlet in its own context handler. If you do this, you can control in what order they are asked to handle the HTTP request. Thus, you can make sure it asks all other servlets before asking the greedy "/" servlet. Something like this:

ServletContextHandler html, servlets;
servlets = new ServletContextHandler(ServletContextHandler.SESSIONS);
servlets.addServlet(MyServlet.class, "/");

html = new ServletContextHandler(ServletContextHandler.SESSIONS);
ServletHolder holder = html.addServlet(DefaultServlet.class, "/html/*");
holder.setInitParameter("resourceBase", "./");

ContextHandlerCollection collection = new ContextHandlerCollection();
// First, try the static stuff
collection.addHandler(html);
// Then ask the greedy servlet
collection.addHandler(servlets);

Server server = new Server(8080);
server.setHandler(collection);
server.start();
server.join();

The reason this works is that a context will simply "pass" if it does not match a certain URL.

While on the subject, it is fairly annoying when developing that the context won't print tracebacks. When developing, we would prefer the error web page to contain the stack trace. This can be achieved fairly easily:

ErrorHandler errorHandler = new ErrorHandler();
errorHandler.setShowStacks(true);
server.addBean(errorHandler);

Tags:

quest-blog

java-programming

teaching

What makes a good unit test?

quest — Thu, 12 Jul 2012 07:06:28 +0000

Motivating rant

There are numerous articles out there talking about how to write unit tests. Still, I find that they mostly assume that the reader is an accomplished developer trying to learn to write unit tests.

In particular, many articles, such as this one from the force.com people, may have the right idea, but atrocious examples. In the linked article, the getFraction() example doesn't test the behaviour of a unit, it tests the division operation of the processor! Not only is this a fairly unlikely failure, it is also highly specific to the processor the unit test is run on, and doesn't say whether it is going to work on any other processor the code is need to work on.

For those who are trying to learn programming, a somewhat different approach is needed. This article tries to find an approach that work in a situation where you are trying to learn programming with a test-driven approach.

What is a "test"?

Technically, a test is a small program that tries to make certain that some part of the production software performs as expected.

Simply put, each test should tell a story. This story contains

a protagonist: it may be a procedure, method, class or an object,
(usually) supporting characters: these are typically mocked objects or methods, and
an interesting story: this is usually a use case for a part (the so-called "unit") of the system.

So what is a "unit"?

Most people ask this question when they try to make sense of test-driven development. The traditional answer is that the unit is, in Wikipedia's terms "the smallest testable part of an application." The problem is that when we write the test before the implementation, the choice of a unit is a side-effect of the narrative of the test and so does not require particular consideration.

So what about this story?

Without further ado:

public void testWolfCanWasteHousesButNotThatOfPracticalPiglet() {
    Wolf wolf = new Wolf();
    Piglet fifer = Hamlet.lookupPiglet("Fifer");
    assert !fifer.isMason(); // sanity check
    House house = fifer.getHouse();
    wolf.huffAndPuff(house);
    assert house.isRuined();
    assert house.getDoor().isOpen();

    Piglet practical = Hamlet.lookupPiglet("Practical");
    assert practical.isMason();
    house = practical.getHouse();
    wolf.huffAndPuff(house);
    assert !house.isRuined();
    assert !house.getDoor().isOpen();
}

This test documents the contract between a Wolf and various piglets. Basicly, it says that a Wolf can huff and puff and blow the house down, unless the house is built by a mason.

Depending on programming language and development environment, exactly how to execute a test varies. There are numerous articles detailing this for various programming language and environment. Search engines are your friends.

Tests should be named for what they test. The ultimate goal of the test name is so that a developer immediately understands contract has been broken.

Finally

Finally, there are some fine articles about unit testing out there.

Tags:

teaching

test-driven

quest-blog

Metaphors for computers: the slave

quest — Wed, 23 May 2012 11:34:41 +0000

In the previous article, I proposed the toolshop as a metaphor for a computer. Thinking of computers as toolshops assign them to a passive role. This was true twenty years ago, but with the advent of global networking and - particularly - with mobile computing, computers can no longer be called passive; they are becoming symbiotic. Indeed, we increasingly depend on them to remind us of what we should do, to make movie recommendations, to do a thousand boring chores we can no longer be bothered to do ourselves. So, there is need for a metaphor with a more active connotation to explain how computers colonize our reality.

Computers as slaves

Computers, though active, are unproblematically subservient to our will. However, they are not (yet) generally trusted to act on our behalf; they require detailed instruction and we do not treat them as equals. This makes them slaves. (If they were trusted or our equals, they would be assistants.)

Let us disregard for the moment the melodramatic revolt; in practice, most slaves accepted their role in their respective societies.

A typical slave-based society has an abundant supply of slaves (or your society will not stay slave-based for long). Similarily, with the advent of cloud services, IaaS, PaaS and the rest, there is essentially an unlimited supply of computing available. The critical limitation of slave-based structures are how many slaves you can instruct and coordinate.

There are two axes along which utility grows: attention and trust. In the extreme case, if a slave would require your full attention at all times, it would be meaningful only when the work was dangerous. Similarly, a computer program that requires your full attention at all times is useful only in special circumstances. The real utility of slaves come when they are sufficiently autonomous for you to oversee several of them, effectively multiplying your capacity.

The second axis is trust. In order for slaves to be useful to you, you must trust them to act in your stead. You must trust them to continue to perform according to your instructions when your attention is directed elsewhere, and you must be able to trust them to notify you when they encounter some condition that they are not equipped to handle.

Similarily, the relevant limit for a human's use of computers is in instructing them to do your bidding and to get a predictable and faithful execution.

This gives us some important design principles for software:

Try to require as little of the user's attention as possible, but never guess.
Make sure to keep state so the user don't have to repeat instructions unnecessarily.
Try not to make assumptions about the number of computers available to work on a problem; good software can be empowered by adding computing power.

Computers, however, are not human

Computers do not share many properties with humans. They can concentrate indefinitely, they are (mostly) immobile, they are not prone to cognitive cross-connection and they are not self-centered. When we instruct computers (whether we are writing software or trying to use software) we should remember these strengths and make use of them.

Tags:

quest-blog

teaching

Metaphors for computers: the toolshop

quest — Mon, 27 Feb 2012 00:32:32 +0000

In order for there to be meaningful learning about computing, we need metaphors for computers. In order to learn, humans build whole networks of information pieces at once and so need some simplifications to bootstrap these networks. The most powerful such simplifications are metaphors.

Thus, in order to learn about computers, we need some way of thinking about them. In this article, I propose the first such metaphor.

Computers as toolshops

Out of habit, we often claim that computers are tools. While superficially true, this classification is unhelpful. From calling them tools, it does not follow that they will fundamentally transform society and elevate humanity. The hammer, while tremendously useful, has not changed the world. The computer has. Also, thinking of computers as tools needlessly limits our creativity by making us think of them as finished products.

I propose that we think of computers as toolshops. A toolshop is a place, an environment you might say. There are numerous tools there, but the tools themselves are not the point. Rather, the creativity - the potential - embodied in the toolshop is the point. It is the same with computers. They are a large collection of tools; with Internet access, the collection is near infinite. If we learn mastery of that environment, we can change the world, or as big a piece of it as we can drag into our toolshop.

A good toolshop:

has numerous tools, both to examine the world and to manipulate it
is well organised
is general in purpose - you never know what you will need to fix or make tomorrow

As software developers, we will intuitively embrace this metaphor. Much as the traditional toolshop grew from the needs of a mechanic, we will shape our work environment to make us productive. But the point is this: we must take care to preserve the toolshop for the end user. The beauty of the general purpose computer is that the full toolshop is on every worker's desk and in every person's home. Just as the software developer requires a set of modular tools, the tools we develop for others should be similarly adaptable and inspiring; they should be repurposable.

Using this metaphor, several things become clear: software tools should ...

... insinuate their purpose
... create easily recognizable and inspectable artifacts
... not be overly specific in its purpose
... inspire, stimulate creativity
(all metaphors have their limits) ... should always strive to make their effects reversible

You may object that your users are afraid to touch a computer, never mind taking a sledgehammer to their economic data. When placed in a toolshop, the user may be unwilling to use a hammer for fear of hitting herself on the thumb. The answer to this cannot be to pad the head of the hammer. Rather, let us hang a set of pliers by the hammer (or even fit them together with a clasp to make the hint really obvious). Generally speaking, humans react well to such empowerment.

Of course, there are situations where software must be highly specialized, perhaps because the user is never interested in changing its purpose. For example, a concert ticket machine is just an obstacle on the user's way to seing a movie. Being fundamentally contrarian in purpose, it is highly unlikely to inspire the user's creativity. But even here we must ask hard questions on designing it; do not lightly assume that you know which use case will be the most common one. Users may want to browse what conserts will be on next week, or they may want to book a ticket for tonight. The ticket machine can be viewed as a trvel kit, a pocket toolshop.

Tags:

quest-blog

teaching