Let’s take an example of a particular class, viz. String. The String domain is the set of all possible strings including the empty string “”. And null! Since

String x = null;

is a valid statement. But in my experience, I can’t remember where I really needed or wanted to distinguish between null and empty string.

A similar example applies to List, Set or Map: the empty list, set or map is perfectly fine, and null is not needed.

In (nearly) all cases, I would prefer to know that a null object is not an option. Ever. It would make arguing about possible cases so much easier and a lot of safety code could be removed. In my recent projects we always agreed to never return null list (set,map) but use an empty one instead.

Value objects: should have a defined domain, must include decision whether null is an acceptable member (usually it shouldn’t).

As an interesting side note, Tony Hoare has admitted that the introduction of null was a big mistake. Hopefully I will be able to listen to his talk later this year. Others like C. J. Date have long argued against null values in database tables, partly because it forces three-valued logic upon you (unlike the better defined two-value logic of true or false).

Windows+Cygwin Preliminaries

1. Place the following windows script in the start-up folder, e.g., C:\Documents and Settings\All Users\Start Menu\Programs\Startup:

   @echo off
   C:
   chdir c:\cygwin\bin
   set HOME=/home/%USERNAME%
   bash --login c:\cygwin\sshagentrc
   

2. Edit cygwin.bat file so that it looks like this:

   @echo off
   REM Script to start ssh-agent each time user logs into machine
   C:
   chdir C:\cygwin\bin
   
   set HOME=/home/%USERNAME%
   bash --login -i

3. Place the following code in a file .sshagentrc in the c:\cygwin directory

   #!/bin/bash
   # Creates an ssh-agent,
   # writes ssh agent info to the file '~/.ssh-agent-info-`hostname`'
   # and then prompts user for keys.
   # Then any shell can use the agent by sourcing the contents of ~/.ssh-agent-info-`hostname`:
   #  . ~/ssh-agent-info-`hostname`
   HOME=/home/$USERNAME
   SSH_INFO_FILE=$HOME/.ssh-agent-info-`hostname`
   
   if test -e $HOME/.ssh/identity; then
      /usr/bin/echo "ssh_info:   $SSH_INFO_FILE"
      /usr/bin/ssh-agent > $SSH_INFO_FILE
      /usr/bin/chmod 600 $SSH_INFO_FILE
      . $SSH_INFO_FILE
      /usr/bin/ssh-add $HOME/.ssh/identity
   else
      /usr/bin/echo ""
      /usr/bin/echo "ERROR: No private key defined in $HOME/.ssh"
   fi

Individual User Setups

1. Modify your .bashrc file to include the following lines:

   # Hook into SSH agent session
   SSH_INFO_FILE=~/.ssh-agent-info-`hostname`
   if test -e $SSH_INFO_FILE; then
      . $SSH_INFO_FILE > /dev/null
   fi
   export SVN_SSH=ssh

The SVN_SSH is useful when using subversion with ssh (svn+ssh protocol); you can also create a  Windows environment variable.

1. Goto HOME directory
2. Run

   ssh-keygen [-t rsa]

3. Enter the required passphrase (and remember it!)
4. This should create a file named identity (or similar) in folder ~/.ssh.
5. Email the public key, in files *.pub, to your administrator so that he can add the public key to the required servers.

PuTTY

If you want to run PuTTY (Pageant) as well because you like apps like TortoiseSVN, then

1. Import the OpenSSH key into PuTTYgen and create a PuTTY-compatible key (I store it with the OpenSSH keys in my cygwin home directory: c:\cygwin\home\<userid>\.ssh\identity.ppk)
2. Place the pageant.exe shortcut into your startup directory
3. Modify the short-cut property to “c:\PUTTY_HOME\pageant.exe” “HOME\.ssh\identity.ppk”

This will start up pageant when you log in, asks for your SSH key passphrase and you’re set for the day.

Results

The setup initialises ssh-agent when you log into windows and adds your SSH key to the agent’s session. When starting a cygwin terminal, the .bashrc script ensures that the terminal shares the agent’s session.

Overall, you only have to type in your SSH key’s passphrase once and the rest is easy sailing

I like to start Eclipse with the option -showlocation; it helps to identify which workspace I am working on, especially when I need to work on two version (trunk and branch).

Workspaces

Just upgraded to Eclipse 3.4 (Ganymede) and had to get rid of a wrongly created workspace. While it is easy to move between workspaces many have commented that is difficult to get rid of workspaces.

In Eclipse 3.4, go to file <Eclipse_HOME>/configuration/.settings/org.eclipse.ui.ide.prefs and remove any workspace in the key-value RECENT_WORKSPACES. Voila. Done. Thanks.

Working Sets

I sometimes like to group projects into working sets, especially in workspaces with many Eclipse projects; but in Eclipse these sets are somewhat second class objects:

• many menu options don’t work on sets
• can’t export/import sets

I would like to export sets because when I branch my code it would be nice to carry things over to the branch.

Bookmarks

Similarly, you cannot export/import bookmarks. What a shame/hazzle/waste-of-time. My current workaround is to take a snapshot with Faststone Capture (version 4.8, great little helper app!) and keep the picture.

Comments

Looking at the changes and the surrounding code, there is just no hint, viz. comment, there that tells you what is happening and why the line of code is important.

Now, I don’t like to comment the obvious; many style guidelines ask for far too much commenting when the code is quite obvious. But in this case, several good practices were not employed:

• Using an obvious self-documenting procedure name
• Add a warning to crucial code lines or code ordering
• Commenting in detail (or providing a URL)

If you’re implementing a complex algorithm, you need documentation somewhere. The lessons of Literate Programming, as exemplified in Donald Knuth’s TeX programme, seem to have fallen on deaf ears. But Knuth at least put a challenge down that he would pay out money for each verified TeX bug. (It didn’t bankrupt him.  Firstly, the error rate per kLOC was very, very low and, secondly, people treasured a cheque signed by him so much that they preferred to frame rather than cash it!).

Testing

The cause of mistake is also touching other areas, among them testing. The problem with testing algorithms like the OpenSSL one is that you sometimes need to test a lot of combinations. And I mean A Lot! In his recent talk at the Cambridge BCS meeting (see my review), Peyton-Jones showed an example where the error only revealed itself after running several hundred different data inputs for the same test-case! We usually don’t go anywhere near that length to test our code. But sometimes you need to do it, usually by generating random data in order to cover as many possibilities as possible in order to avoid any bias of excluding certain cases (we humans are often good at rationalising away potential sources of error a la That can never happen).

(Disclaimer: Apologies if parts seem like ramblings but I haven’t been able yet to make more consistent connections between all concepts.)

Responsibility and Authority

When you are charged with managing a project, you are typically charged with achieving some objective with a budget (time, money). But are you always given the right parameters to achieve that objective? One important aspect is the right balance of responsibility and authority. If you feel to have a lot of the former but not enough of the latter then please read on!

Johanna Rothman, author of [1], writes on Responsibility is Authority (see also here):

As a project manager, you have the responsibility to take authority, rather than wait for someone to give you the authority.
No manager ever has enough real authority to do what he or she wants to do. There’s always someone with a bigger title. Even if you’re a CEO, you report to a board. Even though titular authority is useful, it’s not enough. If the project is strategically important to the organization, act first (doing whatever the project needs) and ask forgiveness later. You’ll know whether the project is strategically important by how many people ask about the status and what levels of people ask. The more people ask at the higher levels, the more strategic the project is. If the project is not strategically important, don’t waste your time trying to accomplish it. In reality, if the project is important enough to the organization, you have the authority to do just about anything you need to do. (You need the self-esteem to do what you need to do.) But if the project is not important enough to the organization, you can never get enough authority to do what you need to do.

A good definition of authority and responsibility:

Authority: The legitimate power given to a person to use resources and exercise discipline to reach an objective

Responsibility: The duties, assignments and accountability for results associated with a function or position

(Definitions on related concepts can also be found there). The author also quips that sometimes you just have to grab it [authority] and run with it and a person should be granted at least as much authority as she can handle, which seems in agreement with Rothman.

Leadership

How should you use it? You should mainly use to enable your team to perform well, i.e., it’s not a license to tightly control your team but rather to remove obstacles that hinder your team. In other words don’t lead by command but rather by mission, be an enabler. This is at least my understanding of leadership as espoused by SCRUM and DSDM Atern.

Key principles of leading-by-task (or mission) were developed in the 19th century Prussian Army and state that the leader [2]:

• informs what his intention is,
• sets clear achievable objectives,
• provides the required [...] resources,
• will only order details regarding execution if measures which serve the same objective have to be harmonized, [...],
• gives latitude to subordinate leaders in the execution of their task [mission].

This approach certainly takes a very dim view of micromanagement [2]:

It is, therefore, out of the question that a colonel or even a general appoint himself squad leader to direct traffic at a road intersection or to instruct a patrol leader about his mission.

Rupert Smith, as a former general in Bosnia, demonstrates in [3] how a lack of clear intentions and goals and a lack of understanding of the capabilities of his resources (viz. armed forces) from his political leaders did leave him in difficult situations and often rendered him unable to use his resources with their full utility. True leadership is not easy.

The Team: Collective Wisdom

Current agile approaches place great importance on the project team, especially one that self-organises and is not managed by an old-style project manager. Important issues and results from social experiments relating to small teams are reported and discussed in [4], especially in Committees, Juries and Teams: The Columbia Disaster and How Small Groups Can Be Made to Work (Ch. 9). We tend to rely on a single person to make a decision rather than trust a (small) group of people to make a better and more consistent decision, sometimes with disastrous results. [4] concludes that:

[...] that there is no point in making small groups part of the leadership structure if you do not give the group a method of aggregating the opinions of its members. If small groups are included in the decision-making process, then they should be allowed to make decisions. If an organisation sets up teams and then uses them for purely advisory purposes, it loses the true advantage that a team has: namely, collective wisdom.

(Some people even seem to be able to overturn the image of the genius inventor by using teamwork.)

Quotes

These are all from wikiquote on leadership and too fitting not to mention them:

Don’t tell people how to do things, tell them what to do and let them surprise you with their results. (George S. Patton)

If it’s a good idea, go ahead and do it. It is much easier to apologize than it is to get permission. (Admiral Grace Hopper)

A clear vision is usually assumed and rarely communicated. (Unknown)

References

1. Johanna Rothman: Manage It! ( ISBN: 978-0-9787392-4-9, 2007)
2. Werner Widder: Auftragstaktik und Innere Fuehrung (eng, PDF)
   
3. Sir Ruper Smith: The Utility of Force: The Art of War in the Modern World (ISBN 0-713-99836-9, 2005)
4. James Surowiecki: The Wisdom of Crowds (ISBN 0-349-11605-9, 2004)

Some important points:

• Future of programming will be about “Control of (Side) Effects”
• Programming languages will become more functional than imperative
• Purity is good for understanding, verification, maintenance,
• Purity pays back in performance, parallelism, testing
• Functional/value-oriented is easier to test than object-oriented stateful
• Functional is good for generating tests (domain-specific language)

After a short intro into Haskell (10 min Haskell 101:)) SPJ moved onto testing in Haskell. In his demo, he tested a programme that would pack 7-bit words into 8-bits, so that eight ASCII characters would take up only 7 byte instead of 8. This sort of space saving is done in SMS where bandwith is precious.

One fundamental test tried to assert that unpack(pack(x))==x. After testing some hand-written cases, which succeeded, the test started to use randomly generated words and started to fail after after a few hundred attempts. Due to its random nature, it took a randomly varying number of cases, but typically it failed after less than a 1000 cases. (It turned out that words of 8-byte length ending in a particular bit sequence were not correctly packed.)

The beauty of the underlying Haskell testing framework was that it took very few lines of code to express a generic testing framework.

The talk also showed that sometimes testing with large random test data is necessary to find bugs; something we rarely do!?

Overall, I found the speaker very engaging and the talk enjoyable even if I won’t claim of having understood or remembered everything.

Luckily, regular expressions make that an easy task. Here is the query:

SELECT *
  FROM myTable x
 WHERE REGEXP_LIKE( x.myColumn, '(^[[:space:]]*$)' );

A short explanation:

• ^...$ says that pattern applies to the string from start to finish, i.e., it’s not just a sub-string pattern,
• [...]* says that pattern occurs 0 or more times (could also have been [...]+ in this case),
• [:space:] defines a pattern of all white-space characters, including blank, \t, \r and \n.

Sometimes, regular expression just make tasks like these very easy.

Some basic facts as they are available today (March 2008) in the table below. I chose a Dell since it is widely available and a very common and representative competitor.

The Dell version has been customised slightly by choosing a faster matching processor.

This is the best match in terms of hardware components I could find. They are quite close: the Dell scores better in the memory and hard-drive specs, the Apple in the resolution.

Hence, we are down to Max OS vs Windows Vista, the various bits of pre-installed software, the quality of the components (hard to judge from the outside) and the very personal matter of taste.

Currently, I personally just can’t get myself to pay a 40% premium for the Apple. One problem for me is that Apple seems to update its hardware specs only infrequently while others constantly upgrade or adjust prices (downwards). And so the Apple laptop starts to look more and more expensive over time. I will keep looking and comparing …

Let me tell you what we did in our current project; I learned a lot during it, mainly since I had to manage the releases most of the time. In the end, the whole process is less scary than I thought; I’ve become even quite relaxed about it, and merging code is no longer scary (but a bit boring).

I must stress that you must adopt your own release process and fit it to your circumstances.

A few words on our software and its installation as it has some bearing on our choice of branching model. The code is a Java webstart application, written using Swing, connecting to enterprise beans on a server. This implies that whenever a user starts the application he will be forced to worked with the most recently installed version; i.e., there is ever only one release in production.

Here is our process to release (assuming we are currently at production version 2.2.1 and use the Linux convention for numbering):

1. A set of features is defined for the next release.
2. When the features are implemented a release branch is created and named (e.g., release-2.4).
3. Part of the team, the release team, completes the new release code, incl. final configuration, acceptance testing, release notes, etc.
4. The release team releases a candicate for acceptance testing on a test server (tagged 2.4.0rc1).
5. Bugs in acceptance testing are fixed and a new candidate (tagged 2.4.0rc2) is released. This continues until the code is accepted.
6. The code is released (tagged 2.4.0).
7. Any upcoming bugs of the released code will be fixed on the branch line, repeating steps 4-6, and releasing the fixed version (tagged 2.4.1, 2.4.2, …)
8. After each release (candidate), the code changes are merged back into the development line (merges are tagged appropriately).
9. The development team starts to work on the next set of features on the development line, repeating steps 1-9 for the next release (2.6 or 3.0).

(If I have time I may add a picture of this process.)

What are the advantages that we obtained from this process?

• We have a clear, easily understandable and reproducible release process.
• There is no significant code freeze period when preparing a release.
• The process allows the team to allocate time efficiently and in parallel.
• The process is quite agile and flexible; there is minimal burden on developers as many can continue working as if unaware of the release process.
• The code can be placed under coninuous integration at all stages.
• We can reproduce production releases at any time quickly.
• Even during the testing process for a new release (e.g., 2.4.0rc2), we can release an emergency fix for the current production version (e.g., 2.2.1 to 2.2.2) without major upheaval.

It is also obvious that our installation allows us to choose this branching model since we never have more than three versions out there: the current production (e.g., 2.2.1), the current release candidate (e.g., 2.4.0rc2) and the development line (named 2.5).

If your circumstances are different (e.g, customers paid for different feature sets), you will have to come up with a different branching model to make it fit for your needs.

Some recommendations:

• Think early about the branching model and release process suitable for your project; at least no later than when the first feature set is complete
• Learn and use some of the branching patterns (see references)
• Merge early and often (before the deltas become too large and are hard too merge)

Don’t be afraid of branching and merging; once you understand the process, its limitations and benefits, everything beomes much easier.

References:

• M Shuttleworth: Merging is the key to software developer collaboration
• B Appleton, S Berczuk, R Cabrera, R Orenstein:Streamed Lines: Branching Patterns for Parallel Software Development
• C Walrad, D Strom: The Importance of Branching Models in SCM, IEEE Software 2002, September, p31-38. See also comments in Letter to Editor, IEEE Software 2003, January, p11.

PS

Eric Raymonds has started a page on version control systems. Worth keeping an eye on it.

Let me come out with my point-of-view right now: Avoid checked exceptions, stay away from them. They are not worth it. OK so that’s out. But some clarifications are in order:

• I do not argue against declaring exceptions in a method’s signature:
  • In Java you can list both, checked and unchecked, exceptions in the method signature.
  • You should document the most important contract violations that the method will reject.
  • Better still, document the contract in the spirit of B Meyer’s Object-oriented Software Design.
• I don’t ask that rather obvious requirements, like arguments not being null, are documented in detail.
• I argue against the rule that checked exceptions have to be declared in each method of the calling stack unless they catch the exception.

What is the main purpose of an exception? It’s to indicate a contract violation (I think Bertrand Meyer’s language is the most appropriate to use).

Does the method raising the exception care about the context in which it is called? No, the method provides its own context: its contract. The rules of ERH about internal and external exceptions make no sense whatsoever in this model. Whether I can write to a file (object) or not, whether the provided argument is of the wrong type or not, whether the object’s state is within the method’s control or not, is irrelevant and is not the question that is being asked.

The method asks a much simpler and more general question: Do you obey my pre-conditions? It does not care what the intent of the caller is, what the calling context or the semantics are. Only the programmer may know that. No, the method just promises to fulfil its side of the contract (post-conditions) if the pre-conditions are fulfilled.

If a file instance is passed as an argument, the file is always outside the control of the called method. If it cannot write to the file because the file doesn’t exist or is write-protected, the method doesn’t care. It just says: You’re not fulfilling the pre-conditions of my contract; here is my exceptional response.

The whole distinction between external and internal exceptions makes no longer any sense (and you could always argue ERH’s examples in different ways depending on context). So we established that any distinction between checked and unchecked exceptions is based on some arbitrary classification of the caller that cannot be maintained inside the method throwing the exception. (You can easily do this for any other model, the checked-unchecked cases are always based on such classifications.)

So we are left with the question whether the compiler-enforced rule on checked exception provides any benefits, and we have to ask the questions:

• Is it beneficial that every calling method repeats the exception in its signature?
• In a proper object-oriented design, who carries the information about the problem?
• Where is the exception being handled and resolved?

The first question should remind you immediately of DRY: don’t repeat yourself. The answer to the second is obviously the exception itself, not the method signature. And the final one is more based on the experience that, at least in applications with a user-interface, it is standard practice to throw the exception back to the user rather than to resolve the problem programmatically. There are some exceptions (no pun intended) like in message-based applications where the queue may try to re-send the message a few times and finally succeed, adding some robustness, but ultimately the problem is thrown back to the user (or left on the dead-letter queue!).

Developers of embedded systems could tell you how hard it can be to resolve exceptions adequately to prevent the system from crashing. Sometimes they just reset the system and log the fault; sometimes they just skip the faulty data and continue (and interpolate, for example, when taking sensor readings). (You may want to read more on this issue and exception design & patterns in the recent series of IEEE Software articles by R Wirfs-Brock.)

In the end we are left with the conclusion that Java’s checked exception were an experiment of good intentions but one that ultimately failed and didn’t provide any significant benefits but rather gave rise to a new anti-pattern: the silently caught exception a la catch(Exception e){ /* do nothing */ }.