« November 2004 | Main | January 2005 »

December 26, 2004

Merry Christmas vs Happy Holidays vs Saturnalia

The history of the Christmas Holidays

5 January Anyone?

Enter Multiculturalism

Secularism

The politically correct thing

Posted by gluck at 06:27 AM | Comments (1)

December 20, 2004

6 Kg of Vegemite

Posted by gluck at 06:14 PM | Comments (4)

December 06, 2004

The BileBlog, without the Bile

• a) he must be based in Europe, or travel to Europe a lot and
• b) would in turn be known to my European contacts.

I read the Bile Blog and find myself in broad agreement with much that is said. So, after discussing it with him first, I am blogging about the last three issues in his BileBlog, without the bile. The purpose is to create some discussion and amplify Hani's points, which I believe have some merit.

So I will do away with the profanity and abuse, and try to distil the issues into a technical discussion that is hopefully more accessible. Where relevant, I'll also mention some positives and helpful suggestions for some of the issues, both of which are considered 'offtopic' on the bileblog.

Issue 1: Developers Vs English - or why documentation is important

For a business application, like I get paid to write by day, it is the business employees. They are generally communicated with via training.

For a web app to be used by the public, your communication needs to be done via Usability. We have a Usability Engineer who conducts usability research. It is so they can use the web app without needing documentation. The interface must be extremely intuitive.

With a Java library, like for example ehcache, the users are other developers. Communication with them can happen in the following ways:

• The code itself, which should be eminently readable. A tool like checkstyle can help with that
• The sample code, or tests, if it comes with these. These demonstrate how to use it.
• The JavaDoc. The quick view CTRL-Q in IntelliJ will explain just what a method is about.
• The documentation.

For these reasons, I take documentation for the open source projects I maintain very seriously. I am still not happy with the quality, so I keep going back and adding stuff.

I also agree with Hani about precision in naming. I find that if something is named counter intuitively, I cannot understand it.

Issue 2: Tending to Mediocrity - or why open source quality is generally low

1. There is a low barrier to entry to create the project in the first place
2. Democratic management of the project leads to a jumble of voices
3. Patches and suggestions get accepted far too readily
4. The result is a low quality mish mash

I think a successful project needs a benevolent dictator. The project should not try to do much and not try to please everyone. I do this with mine. The successful projects out there, like Linux, do this.

The other reason why open source projects can lack quality is the developers are motivated by personal interests, which may not coincide with making a project better. I asked Jon Tirsen why he did Damage Control, rather than just making Cruise Control better. He answered that he was not paid for it, so why would he want to work on someone else's project when he could work on his own? When the famous urge to 'scratch an itch' that fuels open source manifests itself in useless duplication it is symptomatic of a ego-driven 'NIH (not invented here)' disorder. (Though I am using Jon to illustrate my point, in the case of Damage Control I know that it was also done to do something in Ruby and create a build tool that did more than Java).

Issue 3: JUnit bible thumpers - or why the dogma?

Look at my open source projects, and you will see that each comes with a comprehensive JUnit test suite. I think it is a useful approach.

My problem is with the JUnit zealots out there. I think that often they don't understand testing at all. We have a tester at work who has just gone through training. He has a wall chart which defines about 100 different types of test. A Unit, or Component test is just one of these. But most JUnit developers use the term loosely; they really mean a Unit Isolation test.

Any other type of test, such as a Unit Integration Test, is anathema to them. Because it is hard to do Unit Isolation tests in J2EE, they say, let's get rid of J2EE. Don't use any frameworks that get in the way. To me, that is throwing the baby, and the bathtub, out with the water.

I was trained in statistics and auditing. Testers are after a similar thing to auditors or statisticians. Trying to prove assertions based on a sample size less than 100% of the population of phenomena. In the case of testing, it is the lack of flaws, of many different types, in the system. The tester today talked about doing an Installation test. That is where we do a dry run release, including all the database scripts, to see if there are any release problems. Makes sense, right? But it is not a JUnit Isolation test, so to JUnit zealots it is meaningless. I am quite frustrated with the dogmatic responses I get to this type of argument. I am currently refusing to debate testing, including Unit testing, unless those involved have read a testing textbook. I have a great one on hand, Lessons Learned in Software Testing: A Context Driven Approach by Brett Pettichord. Incidentally, I have met Brett. Brett's book, and Brett, are a welcome breath of fresh air.

We should be trying to produce quality software for a reasonable cost. So that the client gets maximum Net Present Value. (Yes, NPV is a Business Finance term, but it models very well how business's think and what they value).

So, in testing, Unit Isolation White Box testing, is one of about 100 tools in our arsenal. Treating it as the only tool is wrong. As the saying goes: "When all you have is a hammer, every problem looks like a nail".

A comment in defense of JUnit. A suite of automatic regression tests, with high coverage, support safe refactoring of the code base. This benefit is less about testing in the sense of producing a high quality output, than in enabling developers to make changes without fear. In this sense tools like JUnit are very valuable.

I am also likewise concerned about the state of JUnit. JUnit has been inactive for 2 years. A few months ago I got together a coalition of about ten developers willing to work through the reported bugs and patch list to bring JUnit up to date. I volunteered to take over maintenance of the project, along with the team. Eric Gamma, Kent Beck and Eric Meade considered this, but in the end decided they could continue to commit energy to the project. A look at JUnit CVS shows that they have been busy working on release 3.8.2 for the last few months. Great news!

Update:Some people asked where the estimate of 100 testing types came from. Have a look at these two testing glossaries. Looking through one of them I counted 68 different types of testing, one of which was Unit Isolation Testing.

• http://www.testingstandards.co.uk/living_glossary.htm
• http://www.aptest.com/glossary.html

In Summary

1. Documentation is vital and should be treated seriously
2. Most Open Source projects are of low quality.
3. JUnit is a tool for Unit Isolation White Box testing, one of many testing techniques which can all produce quality software. It does have a special role supporting refactoring though.

Posted by gluck at 08:33 PM | Comments (3)

December 05, 2004

The metric system: a case study in technical standard setting

As of 2004, the only countries in the world whose official system of measures is not the metric system are Myanmar (formerly Burma), Liberia and the USA. It is a fantastically successful international standard. In the US, Congress passed the Metric Conversion Act of 1975, calling for voluntary conversion. Amendments to the Act in 1988 designated the metric system as the "preferred system of weights and measures for United States trade and commerce." In the US it is legal to use but not mandatory.

Before France's revolution, its' academy, very much an analogue of England's Royal Society gained prominence. It was the age of rationalism and the scientists were pushing for measures which simplified scientific calculation. Think of them as the geeks. At the same time the King was worried about unrest due to lack of grain. Think of him as the suit. France had a babylon of local measures. Each city had measures morticed into the town hall walls. There would be one for a barrel, one for measuring grain, one for measuring cloth and so on. There were hundreds of measures for each item, totalling thousands of measures across France. It was very difficult to create contracts or conduct trade. As each market had its own measures, it made it difficult to compare prices between markets. The local aristocracy charged a fee to use the local measures. As a result each market was a monopoly.

The King was interested in a uniform standard. Nothing more. The idea of a completely arbitrary standard was anathema to the Academy, who thought that it should be based on an invariant, like 1/10000000 the length of the meridian from the North Pole to the Equator. Why this? They already knew this would give a measure very close to a length measure already used in Paris. The King reluctantly agreed and a surveying mission to measure the meridian from Dunkerque to Barcelona. The idea was to measure part of the meridian and then extrapolate the result, based on the idea of the Earth as a regular ovoid.

The two chief surveyors were Delambre and Mechain. In the seven years it took to complete the survey, revolution and counter revolution took place. At the end Napoleon was in charge. Though there were changes of government, each government wanted to advance trade. The new idea of nation engendered by the French Revolution needed means of defining the nation. Indeed the metric system has often been adopted when countries have become independent (e.g. India and Chine).

Ultimately it was found that:

1. The Earth is not a regular ovoid, so the extrapolation was impossible
2. That plus Mechain's fudging of his data, caused the metre to not be 1/10000000 of the quarter meridian.
3. The metre turns out to be an arbitrary standard afterall.

Nevertheless the initial geekiness around the metre, and Napoleon's successful conquest of much of Europe was enough to get the metre rolling. The rest of the metric system rolled along with it.

Though scientists quibbled over the measurement of the metre, economics was driving its adoption. With standards in place it was possible to trade between markets in a country and then markets between countries.

Once there was a critical mass the network effect took over. Countries started adopting the metric system because other countries had, and the standard would enable trade.

The scientists of Britain, USA and the colonies were not invited to the first metric convention. The hostility to the metric system caused by that fateful act ensured the metric system would not be used in Britain, the Commonwealth or the United States for almost 200 years. Finally with the creation of the European Common Market in 1970, Britain was concerned enough to act. It adopted the metric system and the remaining non metric countries such as Canada and Australia followed suit. The latter happened in my memory. I remember having inch rulers in Grade 1 and centimetre rulers in Grade 2.

The United States had standardised on imperial measures early in its history. Because it already had a standard it also had all the benefits that come from one. It is only now, in the age of globalisation, which is really a word for pervasive international trade, does the United States suffer. Trading partners insist on metric measures. Industries such as Car manufacturing, which rely on parts made all over the world, are already completely metric. Now almost 80% of Americans know of metric units. It is expected that the metric system will continue its creeping takeover of the USA.

A repeating theme in adoption of the metric system is its rejection by adults. In the Benelux countries who were the first to permanently adopt the metric system , it was found the only way to achieve adoption was to teach it in schools and wait two generations until the majority of the population understood it. The old measures were anthropomorphic. The foot was originally the King's foot. Some human measures, like your weight and height feel more natural in the old measures. Everyone knows that a male over 6 feet is considered tall. I am 5'11".

So, what are the lessons learned for introducing a new technical standard?

1. The standard should appear to have technical merit and appeal to geeks, even if it secretly doesn't
2. The standard will need an economic rationale for adoption
3. The standard should appear to be neutral and not favour any one party
4. A meeting representing all should be held to agree on. Those not represented will inevitably resist it.
5. The standard needs an exact specification. The metre has been revised three times and its specification tightened.
6. The standard needs a standards body.
7. The standard needs easy availability of implementations. (The French produced millions of metre rulers each year)
8. Compliance needs to be audited and enforced.
9. Once the network effect kicks in the standard becomes viral and achieves dominance
10. The old standards, though rarer, will persist for a long time
11. A standard that works well enough is very hard to replace. E.g. the US imperial system

A great example of a well executed standards process is J2EE. A great example of a bad one is Web Services, where almost every one of the above rules was broken.

A final characteristic of successful standards is there permanence. It was discovered only a few years after the introduction of the metric system that the metre was flawed in terms of what it was supposed to be. A platinum bar was created which became the first metre. Then when the Germans complained that the ends were scratched, another one, created by International committe over years was fashioned. The current definition is 1/299,792,458 of the distance travelled by light in a vacuum in one second. Each refinement has simply been a better specification of that original flawed platinum bar. The length of that bar will likely live on for Millennia.

Doubtful? The 60 based time and angle system (60 seconds in a minute, 60 minutes in an hour, 60*6 = 360 degrees in a circle) originated in Babylon 4000 years ago. When the French tried to reform time into a decimal day they failed. I wonder how long TCP/IP will be around?

Posted by gluck at 06:45 PM | Comments (4)

December 04, 2004

SimonSays: A stretch reminder program to cure those stiff necks

I finished the first Java version of a program recently which reminds programmers and other continuous computer users to stop and stretch. Versions are available for Mac OS X, Linux and Windows. It is the Java reincarnation of a commercial program I wrote years ago and sold quite a few copies of.

It took me three years of part-time effort to complete the new Java version. It was started on JDK 1.1 and finished on JDK 1.4.2. Over that time Java has matured enormously, and made it a lot easier to create a smooth desktop application. Simon has been developed primarily on Mac OS X and Linux. Mac OS X has also matured as a Java platform and I finished the application on IntelliJ.

If you supervise people there is a problem getting them to stretch regularly. On our project we now have four people who have their own chairs and regularly see physiotherapists. Yet a better approach is to develop healthy habits. These include posture, particularly seating position, and regular stretching.

Simon Says pops up at predetermined time intervals. Simon, our cartoon character then guides you through an animated series of stretching exercises . It logs your exercises, so when you get that stiff neck you can go back and check whether you have been streching, or not. When the exercise program is completed it sleeps for a set time after which it will pop up again with another program to run.

There are more than 100 exercises which exercise most parts of the body organised into programs. For example, stretches can be selected for cervical spine, arms and wrists, thoracic spine, lumbar spine etc.

All exercises were designed by a sports physiotherapist. They comply with modern ideas on stretching taken from phsiotherapy and pilates. If you have a phsiotherapist no doubt they have already recommended regular exercises. You can find these in SimonSays and get it to run them for you.

The configurability extends to running speed, frequency of pop-up, whether to get audible beeps and the times you want it to run.

There are four program types:

• Preventative Stretching - for general prevention
• Parts of the Body - for stretching a specific part of the body
• Custom - any combination and frequency of the more than 100 exercises in SimonSays

New in the Java version is:

• Preventative Stretching- injury prevention exercises for the workplace
• Create custom exercises
• Allow multiple users to each run Simon Says on the same computer
• Creates a log of exercises for future reference
• Now includes more than a hundred exercises
• Comprehensive Guide to Common Conditions and injuries
• Added the following platforms: Mac OS X, Linux and XP

SimonSays is commercial software. It took me thousands of hours and I would like some return for that effort. The price is USD40 or AUD60 with volume discounts.

You can get a 30 day demo here.

For more on SimonSays see simonsayssoftware.com.au.

Posted by gluck at 03:33 PM | Comments (1)

December 01, 2004

Threads as a metric of the scalability of Java Virtual Machines - by Operating System

Enables a thread-local allocation buffer. Using the buffer allows for more scalable allocation for heavily threaded applications, greatly increasing allocation performance. It is on by default on multiprocessor computers and in Mac OS X Server.