Quest for improvement - quest-blog

asynchrmi 1.2 released

quest — Thu, 02 Jul 2015 13:33:43 +0000

asynchrmi goes to version 1.2. This is the first production-ready release. Its core features seems to serve us well.

For those who used earlier snapshots, note that there is an interface change in the ChainBuilder. It now uses a common object called a ChainResult. In traditional Promise programming, each group of tasks typically feed the next step. When using asynchrmi we foung that we needed to gradually build up a data by successive layers of relation lookups. Only at the end do we have enough data to produce the actual result (i.e. a web page).

Maven dependency looks thus:

   <dependency>
     <groupId>net.windwards</groupId>
     <artifactId>asynchrmi</artifactId>
     <version>1.3-SNAPSHOT</version>
   </dependency>

Tags:

quest-blog

java-programming

jboss

asynchrmi

asynchrmi helps writing JBoss RMI clients

quest — Fri, 15 Aug 2014 09:33:01 +0000

I have started a new project called asynchrmi. The purpose of this lib is to make it simpler to write serious applications that calls a JBoss application server.

We were in the process of writing a modern web frontend to our car-sharing system when we concluded that: 1) making many parallel calls to JBoss as different users didn't work, and 2) that because of the heavily relational datamodel (a typical Hibernate model) you needed to make several calls to get all the data you wanted - calls that could be parallelized.

In order to encourage the building of a vocabulary, I wrote a simple library called asynchrmi that enables threadpool-mediated, Future- and/or callback-driven client JNP operations that will be safely threaded.

The project is still in early stages, but has proved useful and robust.

The big missing piece is the ability to inject RMI endpoints on RMITask objects so that all the tedious lookups can be compressed (and ideally performed in parallel).

Please note that this is a large hammer. You can easily sink your application server, either via lock-death or through load-death. Proceed with caution.

Tags:

IPv4 addresses must really be running out

quest — Thu, 26 Jun 2014 09:09:56 +0000

The IPv4 address space really must be running out. Today I received the following spam:

We are currently seeking to enter into direct lease with respect to any of your unused IPv4 netblocks. We pay Competitive lease rates via wire transfer and close transactions quickly. Our lease/rental of your IP space will always be governed by best practices. If interested, please respond to this email and we can work out the details.

Someone is getting desperate - or spotting a business opportunity.

Tags:

quest-blog

The case against dependency injection (in its common form)

quest — Tue, 11 Jun 2013 21:51:27 +0000

Dependency injection as it seems to be commonly used in Javaverse, is at the center of what I consider problematic (read sucks) with the philosophy behind JEE.

To be clear: annotation-driven dependency injection is a reasonable software pattern. For example, it allows defining partial standards such as JAX-RS. However, dependency injection as the default mechanism (i.e. with one global namespace) for interconnecting beans makes sense only for small projects.

Dependency injection is often sold with the argument that it solves the problem of constructors with long argument lists. The problem with this sales pitch is that having ten arguments to your constructor or having ten injections on your class both amount to an unsurveillable mess. Put differently, ten constructor arguments or ten injections make no difference to a unit test.

Both JAX-RS and stateless beans are (more or less) instantiated per request. Given the low cost of instantiation this makes sense as an isolation mechanism, but since classes are just used to group responders that are related (operate on similar data, use shared helpers, et cetera) each responder method is likely to require a slightly different set of injections. The grouping class ends up with the union of all injections. The result is a chaotic network that is hard to create a mental map of. Where dependency injection has created such networks, isolating functional units for testing becomes much harder. Massive mocking ensues.My position is that in order to be comprehensible and unit testable, any large software project needs to be divided into subsystems. Each subsystem should be a namespace unto itself. Its interaction should be isolated properly, e.g. using a message passing pattern (a message queue in JMS terminology). A system thus subdivided will not suffer from unwieldy constructors. It could still use dependency injection internally for e.g. plugins.

Expressed differently, dependency injection should be a tool in the hands of a systems architect to apply where relevant, rather than the default mechanism of a framework for interconnecting individual classes. Square Dagger is designed for this purpose and allows creating mini-frameworks focused on sensible injection.

Tags:

quest-blog

java-programming

Evolution of the lib-framework dichotomy

quest — Tue, 09 Apr 2013 23:15:16 +0000

The debate about the relative merits of frameworks versus libraries will likely remain a fixture in software development theory for a long time to come. Nevertheless, there are trends afoot, that suggest that this dichotomy is not so rigid as the OO theorists of the 90s would have us think.

The increasingly asynchronous nature of programming is one such trend. Many modern libraries, from Akka to backbone.js prescribe event-driven (callback-/message-driven) models that means a certain inversion of control is present. They thus acquires framework-like properties. The starkest example is probably the rapid adoption of MapReduce as the prevalent query paradigm in newer NoSQL databases.

We have also seen the rise of several platforms lately. Docker is perhaps the most interesting example, though npm also deserves to be named. These are clearly frameworks, but with very narrow contracts: if you follow a narrow set of rules, tons of magic will ensue.

Thirdly, most serious frameworks are acts of curation. As can be seen from e.g. Maven, the nature of this curation is changing, as are developers' expectations. JBoss AS now exposes all its internal dependencies as "modules" allowing easy (or at least clear) replacement. A stark contrast to older versions' repackaged jars.

The dichotomy is also affected by the steadily improving quality, particularly of open source projects. This is partly because a lot of open source is in fact produced commercially, but improving methodology and fierce competition also helps. This reduces the need for discovery and quality aspects of curation.

I think all these trends points roughly in the same direction: it pushes both libs and frameworks towards the middle ground, with narrow concepts (e.g. Akka's "there is only message-passing"), usually following established, well understood models (e.g. MapReduce). These will be successful because they can easily be combined into new constructs, lib style (e.g. a Maven-Docker plugin). I think we would do well to remember this when choosing software components for our projects.

Tags:

quest-blog

software-development

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

In defence of keyboards

quest — Sat, 17 Nov 2012 17:00:08 +0000

Tablet computers worry me.

I strongly beleive that the tools we use shape both our behaviour and our opinions. There may be large individual variation in our reaction and some delay, but gradually and collectively opinions will shift to adapt to what is feasible with the set of tools we wield.

So, for example, mobile and smart phones have shifted everyday behaviour away from planning. Railroads transformed our perception of distance. Penicillin totally changed both our behaviour when infected and our view of illness in general. It seems that tablet sales is increasing partly at the expense of laptops. This means we exchange our fast-typing physical keyboards for cumbersome onscren ones. The keyboard being the primere tool for expressing complex opinions, this is - theoretically - cause for some concern.

I would not worry so much about disappearing keyboards if it was not for the signs that most computer users seem not to appreciate the importance of keyboards. I am continually amazed at how many users of stationary computers put up with horrible keyboards that are shipped with your typical desktop computer. This worries me because it seems probable that without good keyboards, will mean less talkback, less dialog and a more passive consumption of content. Gradually, as keyboards become less frequent, users will favour sites and services with more linking and less unrestrained navigation, leaving more room for middlemen to control what is and is not read.

One probable consequence is that photos and video recording becomes more frequent since most tablets have cameras. Video is much more difficult than text for computers to comprehend, which means that search engines will have a harder time providing useful answers.

I doubt that searching will lose its hegemony because of the shift to crappy onboard keyboards, but even its weakening may have large consequences for the shape of the Internet. This is not a claim that the apocalypse is coming. It may well be that most tablets mutate into Asus Transformers or that people decide that they don't want to live without keyboards and buy separate physical keyboards. In theory, speech transcription could rise to the challenge. Rather my purpose with this post is to raise awareness of the good keyboard and add an admonishment that you should be aware of how the tools you are wielding empower you as well as limit you.

This post was written on a tablet.

Tags:

quest-blog

What does it mean to develop software?

quest — Thu, 04 Oct 2012 12:14:48 +0000

Consider the following:

In principle, in the general purpose computing world, once you check in to your version control system a solution to a certain problem, you will solve that problem for everyone everywhere for all eternity.

You may counter that if that were true, there would be only one Get Things Done app for Android, rather than 100. However, this springs more from disagreement on what the problem is.

If we take that basic premise to be true, we need to gradually increase our capacity to solve problems. If we do not, logically we must sooner or later run out of problems that we can actually solve.

Or, bluntly put, writing software is the craft of producing unemployment.

Now, Joseph Stigliz may say that this has a lot to do with cheap capital favouring capital investment (such as massive compute farms and powerful software systems) over investment in manpower. This may be so, but this has been the norm for the last decade and a bit, and is likely to remain true for a decade to come while banks and states deleverage. Thus the principle will stand for the forseeable future (several aeons by ICT yardsticks).

Tags:

quest-blog

software-development

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

June 6 is World IPv6 day

quest — Thu, 31 May 2012 11:48:16 +0000

June 6 is not only Sweden's national holiday. It is also World IPv6 day:

Major ISPs, home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by 6 June 2012.

My pledge for this year is to try to make this website visible via IPv6. Since it is hosted on EC2, this will mean using 6to4 tunneling, which seems to be allowed. Stay tuned for updates.

Tags:

quest-blog