This is just a quick post documenting my recent forays into Python programming and the kinds of things I managed to (quickly) do with it. You might ask “Why?”, well aside from the fact that learning new languages is fun and can keep you on your development toes, I’m seeing a lot of job adverts asking for skill sets which include scripting languages such as Ruby and Python. Since I’ve done a spot of Ruby in the past, I figured why not spend some time messing around with Python.

Do What?

This is the problem to solve. Given a triangle of numbers, find the shortest path from the top of the triangle to the bottom. So consider the triangle;

      9
    8  5
  5  10  7
13  4  12 11

Moving between rows can only be done by going to the ‘root’ of any particular number. (Here, “root” in relation to trees not Maths). So, if we were are number 10 in the second to last row, our only options of moving to the final row are to select 4 or 12.

For this triangle, the shortest path is “9, 8, 5, 4″ which has a total weight of 26.

Starting from the top of the triangle will lead to a lot of messy backtracking, which, although doable, is a bit more complex than I want it to be. Another top-down solution might be to start lots of threads and start them exploring the triangle[1]. Again, this is a potential solution, but there is a much simpler approach we could take.

Starting at the bottom of the triangle, we can easily work out the cheapest way to get from row-1 to row. With that data, we can move up the triangle, working out the cheapest way to get from the row below, to the current row until we get up to the top, in which case we would have calculated the shortest path.

Because we care about the path and not just it’s weight, I created a class to represent both the path and the weight.

Classes

class Path:
  def __init__(self,v):
    if isinstance(v,int):
      self.path = [v]
      self.weight = v
    else:
      self.path = list(v.path)
      self.weight = v.weight

  def __repr__(self):
    str_list = ['Path:',`self.weight`,'\t',`self.path`]
    return ''.join(str_list)


The only interesting part of the code above, I think, is the use of ‘isinstance’ to provide a form of constructor overloading.

Accepting the input

Accepting command line input from Python was also very easy, as it is in most scripting languages.

def readInput():
  triangle = []

def buildRow(line):
  numRow = []
  strRow = line.rsplit(' ')
  for s in strRow:
    numRow.append(int(s))
  return numRow

This code accepts the input from the command line and returns us our triangle represented as a list of lists. Using the same example as above, we get the list;

[[9], [8, 5], [5, 10, 7], [13, 4, 12, 11]]

Note, that I didn’t bother with any checking or validating that the input formed a correct triangle.

Then I needed a method to be able to convert a [int] to a [Path]. As I was beginning to expect, this was going to be a simple matter.

def convertToPaths(row):
  paths = []
  for n in row:
    paths.append(Path(n))
  return paths

Being able to return tuples is also a very nice feature in Python and one I miss in Java after having spent time writing Haskell. I used this feature when working out the parents of a particular number in the triangle. In Java, I’d be forced to either create a “Parents” class which contained two numbers or return some kind of array or Collection which introduces a lot of places for errors and misuse. Tuples here keep things very plain and simple.

def parents(cIndex, row):
  left = row[cIndex]
  right = row[cIndex+1]
  return (left,right)

I’m now ready for the algorithm proper. Converting the bottom row of the triangle in a [Path] gives me a starting point. Looking at the row above, I can calculate the cheapest way to get to it, knowing the current Path back to the bottom.

Put another way, I take the bottom two rows of the table (one which is a [Path] and the one above which is a [int]) and merge them together to make a new row, of type [Path] but which is of the same length as the [int] row. I repeat this process until there is only one row left, which should have only one element in it; a Path.

Here’s the code.

def calcPaths(base, row):
  newBase = []
  for i in range(0, len(row)):
    (l,r) = parents(i, base)
    if l.weight < r.weight:
      new = Path(l)
    else:
      new = Path(r)
    new.append(row[i])
    newBase.append(new)
  return newBase

triangle = readInput()
shortestPath = calcShortestPath(triangle)
print shortestPath

Then What?

The algorithm I chose, merging one row of the triangle into the row above, looks very much like a fold. (I can’t express who pleased with myself I was when such a functional solution magically popped into my brain when thinking about this problem). I couldn’t find a fold function in Python, luckily, writing my own was very simple.

def foldl(f, a, l):
  if 0 == len(l):
    return a
  else:
    head = l.pop(0)
    a = f(a,head)
    return foldl(f,a,l)

As you can see this is a left fold. This is not intended to be introduction into folds, but basically it works by accepting as arguments a function, an accumulator and a list. It then applies the function to the accumulator and the head of the list. It then recursively calls itself with the same function, the updated accumulator and the rest of the list until the list is empty.

So my main method now a bit more simple, with it’s intention more simply expressed by use of the fold method.

triangle.reverse()

shortestPath = foldl(merge,[],triangle)
print shortestPath[0]


Although finding the shortest path is now expressed a bit more elegantly. We have to reverse the triangle. This is because we received the input in such a way as the ‘base’ of the triangle is the last element of the list, but we need to processes the bottom of the triangle first.

So What?

The thing that surprised me the most about programming Python was how easy it was. And it was really easy. The language syntax is simple and followed the same rules as most of the other languages I’ve picked up.

I particularly likes the way that everything, including functions, are objects and so can be passed around as arguments. I first encountered passing functions as parameters in Haskell, and since picking up that trick have often been frustrated that Java hasn’t offered me a simple way of doing the same thing.

The only thing that put me off was the convoluted way of “overloading” a constructor. Due to the way Python handles it’s types, overloading as we understand it in Java wasn’t possible. I think that’s a pretty small price to pay for the simplicity and power that Python programming provides.

[1] I’ve taken this problem from an tech test for an interview I had recently which I failed. The reason being that I’d spent many weeks prior to this particular interview reading about multi-threading at the new concurrency packages available in Java 5/6. Whilst all that is great and important, because I’d become so immersed in that kind of programming, I forgot to look for the simple solution first. My bad. I guess when you spend a long time studying hammers, new problems instantly present themselves as nails. There’s a lesson I won’t be forgetting in a hurry. Interestingly, my multi-threaded approach just wasn’t per formant enough for large triangles (more than 60 rows) because it found more and more work to do the longer the algorithm ran. With the above approach, the algorithm actually gets less work to do the closer it comes to a solution.

To further help me improve my Haskell skills I’ve started writing an implementation of Conways Game of Live. The rules here are simple;

• The cells are laid out in a grid – my implementation assumes a square
• If any cell is “alive” and it has more than three neighbours, then the cell dies
• If any cell is “alive” and it has fewer than two neighbours, then the cell dies
• If any cell is not alive and it has between two and three neighbours, then it comes to life

I also wanted my cell automata to be nicely visible so I decided to use Glade and Gtk2Hs to make a nice GUI for it.

Getting Everything Installed

I already had GHC installed, so all I need to install was everything else. Firstly, use the package manager to install Glade. This was easy, the rest is easy to but involves using cabal.


cabal install alex
cabal install gtk2hs-buildtools
cabal install gtk
cabal install glade


To use your Glade/GTK stuff with GHC you need to use this incantation;


ghc -package gtk --make MyProgram


Also, when using Glade the project file format needs to be changed from “GtkBuilder” to “Libglade”.

The Code

My code can be found in BitBucket here; Cell Automata

The cell automata algorithm works okay see the “evolve” method. I’m currently stalled on trying to make it work nicely in the GUI.

I got stuck when trying to calculate the square root of an integer (and receive a rounded/truncated integer as the result). I couldn’t make that work so I borrowed/stole some code from http://haskellsolutions.blogspot.com/2009/02/integer-square-root-of-positive-integer.htm to work that bit out for me. I couldn’t make the Haskell sqrt work properly.

Edit: I got this fixed. To get an integer square root of an integer, the following incantation is used

floor (sqrt (fromIntegral (length xs)))

In the above, xs is the list containing my cells world. This is safe to do because in my implementation the size of the world is always a square number. I’ve yet to run hlint over my code to check that it is sensible. Edit ends.

If anyone can offer any insights into how to create a kind of animation thread (for want of a better phrase) to handle the rendering the evolution of the world I’d be very grateful!

Comments always welcome.

Edit: I finally got it all working, including a UI in HOpenGL. The biggest problem I’m facing now is that there GOL algorithm is very ineffecient for large world sizes, I’m guessing this is because it does a lot of list traversals per cell.

I should also mention the following three sites which proved to be invaluable.

1. Michi’s blog which I “borrowed” the majority of the OpenGL code and module layout from
2. Andre W B Furtado tutorial for the IORef help
3. My Awesome Blag – which appears to be the only place on the Internet which shows how to use the timer callback

Except that..

…I can’t avoid all crashes. Sure, more times than not, I’m a perfectly safe driver, regardless of what speed I’m doing or the road conditions or other situations. But there are two very good reasons why I need all those safety features.

1. Sometimes, I’m an idiot
2. Everyone else is also sometimes an idiot

This little rant is in response to a couple of articles that have been bugging me recently. Namely; Patronizing Language Design and Steve Yegge’s Java/Wikileaks article.

Now, I don’t know either of those other authors. The only thing I know about them is that they are both probably way more clever than me. They’ve probably forgotten more great stuff than I’ll ever know. Steve Yegge’s article in particular seems like it’s written as a comedy piece, but like all good comedy there’s a degree of truth hidden inside it. I’ve not had a sense of humor amputation, I laughed and smiled about it as much as the next programmer. However I do take issue the two premises that appear in these articles.

1. Programming languages should allow any programmer to do whatever they want, and it’s the programmers responsibility to be safe
2. Object Orientated design, particularly in Java, forces developers to only use certain software components in known ways and that’s a restrictive and bad thing

Patronizing Programming Languages

Preventing programmers from doing ‘more complicated’ things is just a kind of seat belt. Or maybe a better analogy is that of a speed-limiter as fitted to most trucks and vans these days. (At least, in the UK.) Think back to all the programmers you’ve ever worked with, all the WTF articles you’ve read. Aren’t you kind of glad that some of those developers weren’t driving a lot faster when they crashed? Particularly if it was you they crashed into!

The first article claims that even with more difficult language features available, an increase in program crashes has not been seen. I don’t have access to his data so I can’t verify that claim. My gut tells me though that this just can’t be the case. If you took all the programs written in so-called ‘safe’ languages and rewrote them in ‘un-safe’ ones, I’m convinced that you’d see an increase in the number of nasty crashes.

I’d be interested to visit an alternative reality and see what some of the enormous Java software projects that l’ve worked on look like when written in some less ‘patronizing’ language.

The phrase “enough rope to hang yourself with” comes to mind. Sure, you can hang yourself in ‘safe’ languages such as Java, C# etc. But that’s about it. Introduce language features that give you even more rope and you could probably tie up and hang the entire town. Neither outlook is pretty, but the differences in scale can’t be ignored. Obviously, I’m not saying that this always going to happen, but I would argue that the occurrences of it happening would be greater – and messier.

Doing Whatever You Want To Do

I think that’s it’s fair to say that most of us write programs that are difficult or impossible (at least, according to our individual skill sets) to formally reason about. This means that testing the behaviour of our software is limited to testing it in way we think that it’s going to be used – with some additional edge/exception cases thrown in for good measure.

In my opinion, the gripe about Java programs hiding implementation with final and non-public modifiers is more a gripe about Object Orientated design than about Java specifically. (And goodness knows, I’ve moaned about Java enough!) I just can’t get away from the fact that it is appropriate for some software components to be hidden away; other people may well want to use them in ways that they were not intended.

Ideally, any given class can be extended and have it’s non-private members overridden with predictable results. Hopefully, such things are tested or at least well enough documented to allow other developers to not break anything else. Opening up everything inside every class places an enormous burden of testing on the original developer; how can they possibly verify that if any of the internal code changes (because it has been overwritten) that the rest of the code will behave in the same expected manor.

You just have to ready any “How/Why Do I Do OO?” book or article to see why we encapsulate and hide data/functionality. If you really really need some functionality which is private or final then the correct solution is to petition the vendor and ask for an API change. (Good luck with that!) To me, the Java/Wikileaks article should be more targeted at bad API design and less about abolishing final/private in any particular language.

Programming is not just about design-test-code, whatever language or silver bullet you’re using right now. It’s also about support. Making every possibly software component open to use (and abuse) is just asking for a support nightmare. I would hazard a guess that the response to most support tickets would be closed with phrases like “Your computer caught fire because you overrode this method and you didn’t do something which the original method did” or “You lost £1,000,000 in business because you used that method which is not designed to be used in such a way”.

My car manufacturer says I should only put diesel in my particular car. They’ve left the choice on whether or not I keep that restriction up to me, although it has to be said that they have not documented the repercussions of disobeying them very well in the car handbook. I’m also not holding my breathe for any free support or fix if I do disregard their rules. Now obviously, as a sensible person, I wouldn’t put unleaded, water, Lucozade or anything else in my fuel tank, but there is nothing physically stopping me. But what happens one day when I’m day-dreaming whilst filling up and accidentally pick up the wrong pump? After I’ve paid the expensive bill to get my car fixed, I bet that I wished that there was some physical restriction stopping me from doing the wrong thing. Even though I’d never made that kind of mistake before!

Remind me again why physical restrictions against accidental (or idiotic) mistakes are a bad thing. Remind me again why an API designer hiding certain things from my code is a bad idea.

Summary

You might currently work only with brilliant people, but remember that not everyone does. Every few months (or weeks) a new article is released about how education and training in this country or that is going down the tubes. The bar to entry of the Programming Profession is already pretty low and seems to be getting lower. Keeping ‘difficult’ things away from the majority of those programmers, to me, seems like a good idea.₁ I don’t let my kids play with sharp knives, but as they grow and move onto different meals (i.e. programming projects) different sets of cutlery (i.e. tools, languages, language features) will be introduced and they’ll be taught to use them. But only if I consider their aptitude sufficient enough to wield them safely. Even though some companies have very stringent hiring and interview practices, bad programmers still get jobs!

Programmers should lock their APIs down to a handful of known places which makes sense. Then they can predicate what their users are going to do and help them do that. Some programmers are going to complain that because of those restrictions they can’t do this or that with your API. That complaining is okay. Making everything open is just asking from trouble. Not from you, the reader, obviously. You’re an above-average programmer who doesn’t make mistakes. But restrictive APIs are designed to protect software against programmers like me; you know, the human ones who do make mistakes.

₁ Either that, or raise the bar to entry a bit more!

Given an undirected graph, find all the paths (not just the shortest) between two nodes that are less than some given length.

I decided to attack this problem using Haskell. Simply because I’ve been trying to get to grips with the language and felt that this was a nice “real” problem for me to practice my fledgling skills on. I’ve chosen to model a graph as a list of edges which are described as a simple pair (see the end of the following source code). I have therefore made the following assumptions in the code;

• An entry in the list (‘a’,'b’) explicitly states that an edge exists between the nodes ‘a’ and ‘b’ and further this implies that the edge (‘b’,'a’) exists since the graph is undirected.
• An entry (‘a’,'a’) implies that a node ‘a’ exists that does not have any edges, rather than an edge exists that self-references the node ‘a’. Nodes are not allowed to have edges to themselves.

The following code does work, and returns the correct number of paths given my test data and the requests I make of it. I can’t escape the feeling, though, that my Haskell could be made more simple and efficient. I just don’t know Haskell well enough yet to work out how!

The Solution

Edit 1: code to apply Hlint comments

Edit 2: corrected some cut and paste mistakes


import Data.List

I’ve managed to find some time recently to get playing with my SUN SPOTs again, so I figured I’d start by wiring up one of the servos from my ancient remote control cars to it. Although, there seems to be a lot of information about doing this on the web (mostly the wiring diagrams) I hit a snag with getting the full motion range out of my servo. So I figured I’d put something up here in case anyone else encounters the same.

Scenario

To control my servo I wrote a very quick GUI that allowed me to send float values through the connected base station to the free range SUN SPOT. That SPOT was wired up to a battery pack and servo and the servo moved when I hit the GUIs button. Simple, but a nice first step.

The Setup

I mostly copied the wiring of the servos from “Fantastic Kobe” and this offical SUN blog. There’s not a lot to the wiring, as you can see from this picture.

Shows the wiring from the battery pack and SUNSPOT to the Servo

I not going to go into detail about what connects where, because that information can easily be found on either of the above two links.

Setting the Servo Bounds

One of the things I found was using the setPosition(float p) method on Servo wasn’t giving me the full range of motion. To fix this you need to set the bounds of your particular servo. I didn’t know the ‘correct’ way to do this, so instead I went with a trial-and-error approach.

private int servoPin = EDemoBoard.H1;

private void initServo() {
servo = new Servo(EDemoBoard.getInstance().getOutputPins()[servoPin]);
// for(int i=250; i<2300; i+=10) {
// servo.setValue(i);
// out("value="+i);
// Utils.sleep(100);
// }
servo.setBounds(250, 2300);
}

In the above code, the starting value of “i” was originally zero and the end value was 10000. Then, by using changing these values so that when initServo() was called the servo didn’t groan in protect, I was able to set the bounds as shown. Having done that, servo.setValue(0.5); puts the servo in the middle as expected. With values of 0 and 1.0 taking the servo to its extremes.

I expect that most people’s servos are going to be different. Mine is a Futaba FP-S148. And now I can move a servo around, I can start to do something useful (or at least fun) with it!

The Code (Free Range SPOT)

There is only one class in the application that sits on the free range SPOT.
import java.io.IOException;

}

The Code (Base Station)

The code on the base station is simple enough, in fact too simple to warrent posting and spending the time formatting it here. The only interesting bit is the following line which is one of the first lines in the public static void main(String[] args) method;

OTACommandServer.getInstance().start();

The rest of the code is either UI/Swing code or normal Java/SUN SPOT code. In fact, the initComms, sendMessage, startListenerThread and listenForMessage methods are identical to those that run on the free range SPOT. The only difference is the SPOT address that the DatagramConnection is opened with. Obviously, on the free range SPOT it is opened with the address of the base station, and the reverse for the code on the base station.

Aside

Disclaimer: Obviously, soldering is dangerous to yourself and the components you’re working on/with. Any damage or injury you sustain following this advice is entirely at your own risk and I accept no responsibilty for it.

…that being said; if you don’t have a decent breakout board for your SUN SPOTs (and you’re in the UK) then Maplin do some PCB socket connector things* that you can buy and solder into your SUN SPOT. This gives you the ability to use bread board connector cables to easily connect up different sockets from the SUN SPOT without having to do any resoldering. The soldering its self is a bit fiddly, so I recommend getting a decent magnifying glass and a soldering iron with a fine tip. I’m definitely not the worlds best solder-er but I managed it okay.

* – I forget the actual name or catalogue reference, they’re pretty cheap (less than a pound I think) and are sold in rows of about 20 or so. You just snap off two rows of 10 each and get on with it.

Useful Links

• SUN SPOT API Doc

So what I figured the first thing to do would be to create a simple way to do this. Basically, each SPOT you want to talk to another instantiates a Buddy object and asks it to look for another buddy (myBuddy.lookForPair()) this will then start the buddy broadcasting and looking for a fellow.

It’s probably important to note at this point that I have not tested this code with more than two SPOTs, I certainly haven’t tested any edge cases where multiple SPOTs start up and all start looking for buddies on different ports. This is code is for my own use, I’m very happy for anyone to download, modify and use it (it is GPL’d) as long as you remember that it only works for the nicest of use cases.

Once two buddies (on different SPOTs) have connected you can send a message from one to the other by typing;

myBuddy.sendMessage("my message");

Recieved messages are handled by a BuddyListener which your SPOT application should have given to it’s Buddy instance. Recieved messages come in from the following method on that interface;

void messageRecieved(String message);

There’s lots of ways this code could be improved, for example the initial broadcast port is hardcoded into the Buddy code itself, this should really be parameterised. Also, the sleeps and waits that the Buddy endures while trying to connect to another one and so on. These should probably be pulled out to fields so that they can be tweaked more easily.

The good thing about this code is that it makes paired communication very simple (although you do have to be careful with the threads that are listening to incoming messages). You can also use your own language/protocol that the SPOTs will interpret on top of this Buddy mechanism very easily.

radio.Buddy – This is the meat of the project. To easily connect two SPOTs each must have an instance of one of these. Once connected to each other sending and recieving messages between the two is very easy.

/* 
 * This program is free software; you can redistribute it and/or modify 
 * it under the terms of the GNU General Public License as published by 
 * the Free Software Foundation; either version 2 of the License, or 
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful, but 
 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 
 * for more details.
 * 
 * You should have received a copy of the GNU General Public License along 
 * with this program; if not, write to the Free Software Foundation, Inc., 
 * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */
package radio;

import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.IOException;

import javax.microedition.io.Connector;
import javax.microedition.io.Datagram;
import javax.microedition.io.DatagramConnection;

import com.sun.spot.io.j2me.radiogram.RadiogramConnection;
import com.sun.spot.io.j2me.radiostream.RadiostreamConnection;
import com.sun.spot.peripheral.radio.RadioFactory;
import com.sun.spot.util.IEEEAddress;
import com.sun.spot.util.Utils;
import com.sun.squawk.util.StringTokenizer;

public class Buddy {

	private static final String NEED_BUDDY = "BUDDY_REQ";
	private static final String I_WILL_BE_YOUR_BUDDY = "BUDDY_ACK";

	private long thisAddressAsNumber = RadioFactory.getRadioPolicyManager().getIEEEAddress();
	private String addyStr;

	private RadiostreamConnection listenOn;
	private RadiostreamConnection sendOn;

	private DataInputStream listenOnInputStream;
	private DataOutputStream sendOnOutputStream;

	private int portOut;
	private int portIn;

	private BuddyListener buddyListener = new NullBuddyListener();

	private int initialBroadCastPort;

	private boolean foundBuddy = false;

	private RadiogramConnection broadcastConnectionIn;
	private DatagramConnection broadcastConnectionOut;

	private int MAX_BROADCAST_SIZE;

	public Buddy(int broadcastPort) throws IOException {
		this.initialBroadCastPort = broadcastPort;
	}

	public void lookForPair() throws IOException {
		IEEEAddress addy = new IEEEAddress(RadioFactory.getRadioPolicyManager().getIEEEAddress());
		addyStr = addy.asDottedHex();

		System.out.println("I am " + addyStr);

		broadcastConnectionIn = (RadiogramConnection) Connector.open("radiogram://:" + initialBroadCastPort);
		MAX_BROADCAST_SIZE = broadcastConnectionIn.getMaximumLength();
		broadcastConnectionOut = (DatagramConnection) Connector.open("radiogram://broadcast:" + initialBroadCastPort);
		startListenForPartnerResponseThread();
		startLookForBuddyThread();
	}

	public void setBuddyListener(BuddyListener bl) {
		
		if(null != bl) {
			buddyListener = bl;
		} else {
			buddyListener = new NullBuddyListener(); //allows us to reset the currently loaded BuddyListener
		}
		
	}

	public void sendMessage(String message) {
		if (null != sendOn) {
			try {
				if (null == sendOnOutputStream) {
					sendOnOutputStream = sendOn.openDataOutputStream();
				}
				sendOnOutputStream.writeUTF(message);
			} catch (IOException ioe) {
				System.out.println("IOException sending message on partner stream");
				ioe.printStackTrace();
			}
		} else {
			throw new IllegalStateException(
					"Cannot send message.  No buddy found yet.");
		}
	}

	private void startLookForBuddyThread() {
		Thread t = new Thread(new Runnable() {
			public void run() {
				lookForBuddy();
			}
		});
		t.start();
	}

	private void lookForBuddy() {
		try {
			while (!foundBuddy) {
				Datagram dg = broadcastConnectionOut.newDatagram(broadcastConnectionOut.getMaximumLength());
				dg.writeUTF(Buddy.NEED_BUDDY + " " + initialBroadCastPort);
				broadcastConnectionOut.send(dg);

				Utils.sleep(1000);
			}
		} catch (IOException ioe) {
			ioe.printStackTrace();
		}
	}

	private void startListenForPartnerResponseThread() {
		Thread t = new Thread(new Runnable() {
			public void run() {
				try {
					while (true) {
						Datagram dg = broadcastConnectionIn.newDatagram(MAX_BROADCAST_SIZE);
						broadcastConnectionIn.receive(dg); // blocking call

						String message = dg.readUTF();

						String otherAddress = dg.getAddress();
						long otherAddressAsNumber = IEEEAddress.toLong(otherAddress);

						if (thisAddressAsNumber != otherAddressAsNumber) {
							handleIncomingBroadcastMessage(dg, message,	otherAddress);
						}
						if (sendOn != null && listenOn != null) {

							System.out.println("Buddy status achieved, no longer going to listen to broadcasts");
							System.out.println("Partner port to send on: " + sendOn.getLocalPort());
							System.out.println("Partner port to listen on: " + listenOn.getLocalPort());

							startListenOnPartnerStreamThread();
							break;
						}
					}

				} catch (IOException ioe) {
					System.out.println("Exception when listening for buddy response");
					ioe.printStackTrace();
				}
			}
		});
		t.start();

	}

	private void handleIncomingBroadcastMessage(Datagram dg, String message, String otherAddress) throws IOException {
		if (message.startsWith(Buddy.NEED_BUDDY)) {
			if (null == sendOn) {
				int otherPort = Integer.valueOf(separateStrings(message)[1]).intValue();
				Datagram response = offerToBeBuddy(otherPort, otherAddress);

				response.setAddress(dg);
				broadcastConnectionIn.send(response);
			}
		} else if (message.startsWith(Buddy.I_WILL_BE_YOUR_BUDDY)) {
			buddyInviteAccepted(message, otherAddress);
		}
	}

	private void buddyInviteAccepted(String message, String otherAddress)	throws IOException {
		foundBuddy = true;

		portOut = Integer.valueOf(separateStrings(message)[1]).intValue();
		sendOn = (RadiostreamConnection) Connector.open("radiostream://" + otherAddress + ":" + portOut);

		portIn = portOut - 1;
		listenOn = (RadiostreamConnection) Connector.open("radiostream://" + otherAddress + ":" + portIn);
	}

	private Datagram offerToBeBuddy(int otherPort, String otherAddress) throws IOException {
		foundBuddy = true;

		portOut = otherPort;
		portIn = portOut + 1;

		System.out.println("Offering to be a buddy to " + otherAddress + "\nSending on " + portOut + "\nListening on " + portIn);

		sendOn = (RadiostreamConnection) Connector.open("radiostream://" + otherAddress + ":" + portOut);
		Datagram response = broadcastConnectionIn.newDatagram(MAX_BROADCAST_SIZE);

		response.writeUTF(Buddy.I_WILL_BE_YOUR_BUDDY + " " + portIn);
		listenOn = (RadiostreamConnection) Connector.open("radiostream://" + otherAddress + ":" + portIn);
		return response;
	}

	private void startListenOnPartnerStreamThread() {
		Thread t = new Thread(new Runnable() {
			public void run() {
				while (true) {
					listenForIncomingMessage();
				}
			}
		});
		t.start();
	}

	private void listenForIncomingMessage() {
		if (null != listenOn) {

			try {
				if (null == listenOnInputStream) {
					listenOnInputStream = listenOn.openDataInputStream();
				}

				String message = listenOnInputStream.readUTF();
				buddyListener.messageRecieved(message);

			} catch (IOException ioe) {
				System.out.println("IOException recieving message on partner stream");
				ioe.printStackTrace();
			}
		} else {
			// Maybe we haven't found a partner yet, so don't spin the processor
			Utils.sleep(100);
		}
	}

	private String[] separateStrings(String msg) {
		StringTokenizer stk = new StringTokenizer(msg, " ");
		String[] result = new String[stk.countTokens()];
		for (int i = 0; stk.hasMoreTokens(); i++) {
			result[i] = stk.nextToken();
		}
		return result;
	}
}

radio.BuddyListener – Classes wishing to have a buddy must have (or be) one of these and give it to the buddy instance

/* 
 * This program is free software; you can redistribute it and/or modify 
 * it under the terms of the GNU General Public License as published by 
 * the Free Software Foundation; either version 2 of the License, or 
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful, but 
 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 
 * for more details.
 * 
 * You should have received a copy of the GNU General Public License along 
 * with this program; if not, write to the Free Software Foundation, Inc., 
 * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */
package radio;

public interface BuddyListener {
	void messageRecieved(String message);
}

radio.NullBuddyListener – It might be that two buddies are connected and one could be chatting to the other which doesn’t have a BuddyListener attached, in which case this is used instead.

/* 
 * This program is free software; you can redistribute it and/or modify 
 * it under the terms of the GNU General Public License as published by 
 * the Free Software Foundation; either version 2 of the License, or 
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful, but 
 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 
 * for more details.
 * 
 * You should have received a copy of the GNU General Public License along 
 * with this program; if not, write to the Free Software Foundation, Inc., 
 * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */
package radio;

public class NullBuddyListener implements BuddyListener {

	public void messageRecieved(String message) {
		System.out.println("Warning!  NullBuddyListener being used and messages are getting recieved");
	}
}

radio.RadioFun – This is included for completeness. It’s the app that got run when I was testing the Buddy connections. I don’t think it makes a lot of sense for any one else to use this class except to see how to talk/listen to the buddy.

/* 
 * This program is free software; you can redistribute it and/or modify 
 * it under the terms of the GNU General Public License as published by 
 * the Free Software Foundation; either version 2 of the License, or 
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful, but 
 * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 
 * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 
 * for more details.
 * 
 * You should have received a copy of the GNU General Public License along 
 * with this program; if not, write to the Free Software Foundation, Inc., 
 * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */
package radio;

import java.io.IOException;

import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

import com.sun.spot.peripheral.radio.RadioFactory;
import com.sun.spot.util.IEEEAddress;
import com.sun.spot.util.Utils;

public class RadioFun extends MIDlet {

	private Buddy buddy;
	
	public RadioFun() {
	}

	void start() {
		try {
			buddy = new Buddy(60);		
			buddy.setBuddyListener(new BuddyListener() {
				public void messageRecieved(String message) {
					System.out.println("recieved=["+message+"]");
				}
			});
			buddy.lookForPair();
		} catch (IOException ioe) {
			ioe.printStackTrace();
		}

		IEEEAddress addy = new IEEEAddress(RadioFactory.getRadioPolicyManager().getIEEEAddress());
		String addyStr = addy.asDottedHex();
		
		while (true) {
			try {
				buddy.sendMessage("Hello from "+addyStr);
			} catch (IllegalStateException ise) {
				System.out.println("Failed to send message ["+ise.getMessage()+"]");
			}
				
			Utils.sleep(500);
		}
	}

	protected void destroyApp(boolean arg0) throws MIDletStateChangeException {
	}

	protected void pauseApp() {
	}

	protected void startApp() throws MIDletStateChangeException {
		RadioFun rf = new RadioFun();
		rf.start();
	}
}

Looking back at code I wrote ages ago often leaves me wondering “What idiot wrote this junk?” Looking back through articles I’ve written gives me an uncomfortably similar feeling. Today I’m thinking specifically about multiple return points, which I announced to be the root of much evil in this post. What this post reminds me about most, though, is the Do What Makes Sense principle, something that I’ve often claimed to subscribe to.

How do you plead?

I have to confess my guilt before I can continue. I’ve recently started writing some methods which have more than one return point (and I’m not just talking about exceptions here). But as a kind of mitigation I only use them in very small methods and only sometimes.

Actually that’s not true either.

There is a certain kind of method where multiple return points are acceptable, like these;


public Object myMethod() {
    if(comeCondition) {
        return someObject;
    } else {
        return someOtherObject;
    }
}


Or this one;


public Object myOtherMethod() {
    switch (something) {
        case 1:
            return something1;
        case 2:
            return something2;
        case 3:
            return something3;
        case 4:
            return something4;
        case 5:
            return something5;
    }
}


But in these examples the methods are doing very specific things, most plainly, they return something. No other processing is done. I would still say returns dotted around throughout a method is still a Bad Thing. But that’s not what got me thinking. Whilst trying to justify this use of MRP to myself I started running through the reasons why this code is acceptable, when previously I had said it wasn’t. The switch method above reminds me of some refactoring work I did on my company’s product a while back, and it’s the fallout from that refactoring that I ended thinking about the most.

The Situation

Here’s some background. I work for a company which produces (and uses) it’s own software product, this product allows the buying and selling of Widgets. There are many different places that we can buy and sell Widgets from using our software, there is also a piece of third party software which we must tell who has purchased what Widgets, from whom and how many. The problem comes from the fact that each the objects which represent a user’s Widget-trading position is different for each Widget Gateway. Further, the position objects which we must send to the third party software is fixed. What’s even worse, is that each Widget Gateway can be further subdivided into more specific kinds of Widget Position Objects. Again, it’s even worse than that.

The AcmeWidgetPositionSubA class and the AcmeWidgetPositionSubB class both have the same attributes, but because one is …SubA and one is …SubB, when translating this to a ThirdPartyWidgetPosition the attributes with the same name in the …SubA/B classes will be mapped to different attributes in the ThirdPartyWidgetPosition class.

For example; AcmeWidgetPositionSubA.getSpecialCode() needs to be mapped to ThirdPartyWidgetPosition.getCode(). But AcmeWidgetPositionSubB.getSpecialCode() needs to be mapped to ThirdPartyWidgetPosition.getSystemCode().

This is the scope of the problem and the existing code to do this was lots of lines of if…then…elses to get the right things into the write place before the ThirdPartyWidgetPosition is sent to the third party software for processing. Further, there each subtype of Widget Gateway had it’s own chunk of if…then…else code of varying complexity to get the job done specific to itself. To refactor this code I got rid of all the if…then…else functionality and put all the logic into the type system. By introducing some extra classes that had only overloaded constructors I could remove every occurance of if…then…else, create a AcmeWidgetPositionSubX object, cast it to a ThirdPartyWidgetPosition and have everything in the right place, as if by magic.

So far so good, lots of complex nested branches get removed, all the unit tests pass, everything works, we all go home happy. Now fast forward a couple of months. Someone else is looking at the code and they are struggling to see what goes where and how the branched code has been removed in favour of a clever type hierarchy. Now, let me first explain that it’s my opinion that having the logic inside the type system is a better, actually less complex and cleaner implementation approach than if…then…else. It just feels “more OO”; even if I can’t quantify that phrase particularly well. But to a team member who is more used to seeing and reading if…then…else structures it is not cleaner and more obvious. It’s something that they need to wrestle with and really read in order to understand it.

So if I have slowed down the work of a team member, if I have caused them extra effort to do their own tasks, is my approach still the better one? Even if the code I wrote was the “more correct” implementation; was it the right code to write because of the affect it had on someone else?

Style Over Substance

A few more of my little foibles are using Boolean.TRUE rather than the primative true, and putting the literal I am comparing as the first operand of equals – even though I know that the protection this offers me is irrelevant given I spend most of my time writing Java₁. I know, because I have been told, that some people find these things more difficult to read than their more usual alternatives. Personally I don’t understand why they are more confusing to read. But given that I can read the code quite happily either way and given that the compiler will change my code to whatever it feels like; should I be tailoring my professional coding style so as the most number of team members are happiest reading it?

Drawing The Line

The answer, as everything when discussing ‘programming best practise’, is; “it depends”. In the first example with the types vs if…then…else, that change should definitely be made. I can sit down with you and discuss why it is better, what benefits it has, show you how it is easier to extend etc. And as a consequence of that discussion, the team members who will be reading that code will hopefully start to learn from that example and we’ll be seeing fewer and fewer nested-branched code. Designs will become cleaner and gradually the overall quality of the code across the project will get better.

But what of more style based differences, or indeed, anything else which you can’t prove is a tangible benefit? If they cause pain for other team members or get in the way, then I suggest always defaulting to the lowest common denominator₂. That might be structuring code for the least experienced developer – as long as such structuring does not compromise quality in any way. Or at least, structuring your code so that it is consistent with the rest of the code base. It means shoe-horning your coding style into the style used in the rest of the code base to make it easier to read for the whole team – this is especially true in large legacy codebases.

Doing these kinds of silly superficial things in difference to the rest of the code base is something that I am guilty of, and on reflection, something that I should be trying much harder to put a stop to. Make my code blend more seamlessly into the rest of the code is going to make reading it easier for everyone. But beware, when there is a real change that should be made, for a real reason with benefits that can be quantified I will still argue for that change – even if it’s out of the comfort zone of those around me. And I fully expect, nay demand, that those around make those same kinds of changes to pull me out of my comfort zone – because that’s the only way I’m going to become a better programmer.

There is a lot of talk in various technical blogs about how superstar programmers should be allowed to express themselves in any way, structure their code the way they think it should be done, and basically do whatever they want because (you know) they’re superstars. Most of us are probably not superstars and most of the teams we work in are probably not 100% made up of superstars, so I really don’t find those arguments compelling. What I do find compelling is trying to increase the average code quality and the skill levels of the average (or lowest) team member, and these things are not measured by where they put their curly brackets or whether they use Boolean.FALSE or false. These things are superficial and any non-superficial programmer should be able to get over them.

And let’s not forget; everyone of us is the average-est or the lowest skilled level programmer in the team at something. And even if your team is made up of Superstars, chances are they are not all going to be the same kind of Superstar. Think of your favourite classical music composer, rock performer, rap artist, solo violinist, jazz pianist and so on. Now imagine putting them all in the same band; left to their own devices I really don’t think any music they produce is going to be bearable, let alone enjoyable – and this assumes that they’ll manage to produce anything! Not unless they all agree to do certain things in the same or similar way and all pull in the same direction₃. And I guarantee that each one of them will feel restricted in some way by that. But what they produce will be well worth the Superstar fees they’ll be charging!

Conclusion

It is true that a bit of sand inside an oyster will make a pearl, but a bit of sand inside your shoe is just going to make blisters on your feet. Removing code complexity and builder and more defined cleaner design is a worthy goal and one worth fighting for. But doing what is essentially meaningless things for no tangible benefit is not. As with anything where more than one individual is concerns the rule of give and take must be applied. Forcing your team members to adopt a distorted concept of Hungarian Notation is pointless. Similarly, when such a notation has been adopted and is prevelant in a large percentage of the code base, fighting that notation is probably a hiding to nothing.

Team cohesion is important. Every team will be working better if each member is considerate to the others. By all means bring up the uncomfortable truths and fight to make the design and code better. But if the benefits of what you’re fighting for are not worth the battles to win it, then it’s likely your efforts would be better spent putting for head down and servicing user requests and bug fixes.

1 – Unless I’m comparing booleans, of course.
2 – This is not meant to be a derogatory phrase.
2 – Singing from the same song-sheet even.

Rachael gave birth to Esmé Faith this morning (26th July 2008 ) at 4:20 AM BST. She weighed 7lb 2oz, for those looking for metric measurements please go to Brussels where you will (unlike here) be welcomed.

Mother and baby are doing fine. Kate (2 years, 2 months old) is running around saying “You must go to sleep! Don’t wake the baby.” Followed by bellows of “SILENCE!” I don’t know where she got that from.

On a technical aspect, I was impressed with the midwifery team, as soon as the baby was built they ran all the unit tests (developed before the baby was, naturally) and could easily indicate a successful build.

A small subset of pictures is below.

About 15 minutes old

A few hours old

All together at home

Don’t expect this post to be breaking any barriers. I’ve been struggling with to solve an exercise from my Haskell Road book for the past week or so and I finally cracked it.

I’d be interested to know if anyone has a better way to solve it. I’m still very much a Haskell beginner and haven’t gotten much past pattern matching, guards and the where clause; so try not to confuse me.

The Problem

Create a function

splitList :: [a] -> [([a],[a])]

Which takes a list

[1..5]

and returns a list;

[([1], [2,3,4,5]), ([1,2], [3,4,5]), ([1,2,3], [4,5]), ([1,2,3,4], [5])]

My Solution

moveHeadToTail :: [a] -> [a] -> [a]
moveHeadToTail (xs) (y:ys) = xs ++ [y]

splitList :: [a] -> [([a],[a])]
splitList (x:xs) = splitListAux (x:xs) []

Without these changes I will spend each day being a little bit more gumpy than is necessary. This is bad because I vocalise my grumpiness. (I like to think of it as contributing to the team.) So if I’m grumpy, I’ll make those around me grumpy. And in turn, they’ll make the ones around them grumpy. So without these changes and with a few more hops like that Kevin Bacon will be grumpy.* So I think that it’s safe to say that even Kevin Bacon want’s these changes. Sun is actually making Keving Bacon grumpy. And that’s not fair.

So here’s a very quick, off-the-top-of-my-head, list of things that I’d like to see in Java. I don’t care if they’re adopted as fundamental language changes or whether they’re just syntactic sugar that the compiler removes and replaces. As long as the changes are made, I’ll be a happy bunny.

Validate Method Parameters

Like a good boy I always check my method parameters before I can use them. Most of my checks are boring and repetative, they clutter up my super-important-and-complicated business method. Why can’t they be moved out to annotations?

Code Like This…

public String complexMethod(Object someObj, String someStr, int number) {
  if(null == someObj) {
    throw new IllegalArgumentException("someObj cannot be null");
  }
  if(null == someStr || 0 == someStr.trim().length()) {
    throw new IllegalArgumentException("someStr cannot be null or empty");
  }
  if(MIN > number || MAX < number) {
    throw new IllegalArgumentException("number out of range");
  }

  // Complex code goes here
}

Is Replaced With…

@Check(NOT_NULL, IllegalArgumentException, someObj, "someObj cannot be null")
@Check(NOT_EMPTY, IllegalArgumentException, someStr, "someStr cannot be null or whitespace only")
@Check(IN_RANGE, com.mycompany.BadNumberRangeException, number, MIN, MAX)
public String complexMethod(Object someObj, String someStr, int number) {
  // Complex code goes here
}

Wrap Methods in Try-Catch

Many times a day I see code where the entire method is wrapped in a try-catch statement. Often times the stuff in the catch statement is repeated though the class (or classes). Another annotation could remove this noise and make the business code look much more plain.

Code Like This…

public void doDatabaseThing() throws SQLException {
  try {
    // some database thing
  } catch (SQLException sqle) {
    methodToRun();
  }
}

Is Replaced With…

@IfThrown(java.sql.SQLException, methodToRun)
public void doDatabaseThing() throws SQLException {
  // some database thing
}

Maybe a better approach is to abolish all checked exceptions, but that’s another post.

What was the index, please?

Java’s for-each loop is just syntactic sugar for a normal for loop, complete with counter. Why couldn’t they introduce a Perl-esque special variable that had the current iterations index in it? For example;

for(String name : names) {
  System.out.println(name + " is at index " + $_);
}

Controvertial: Easily implement the decorator pattern

Sometimes you need to wrap objects in other objects. Fine. Sometimes you can’t use a simple “extends” and just override the methods you’re interested. Annoying. But what happens when the object you want to wrap has an enormous public interface? You can argue that this is implying you have a bad object model, and I probably won’t disagree, but sometimes you just have to play the cards dealt you and that means wrapping something with a big public interface.

Code Like This…

public class Wrapper {
  private Wrapped wrapped = new Wrapped();
  public void method1() {
    wrapped.method1();
  }
  public void method2() {
    wrapped.method2();
  }
  public void method3() {
    //do something different first...
    wrapped.method3();
  }
}

Is Replaced With…

@Decorates(wrapped)
public class WrapperClass {
  private Wrapped wrapped = new Wrapped();
  public void method3() {
    //do something different first...
    wrapped.method3();
  }
}

…and have the compiler fill in all the boring pass-through methods for me.

Pattern Matching

I really like the pattern matching of methods you get in Haskell and I’m left wondering if Java might benefit from them to.

Code Like This…

public void doSomething(boolean flag, Object otherArg) {
  if (flag) {
    // some code here
  } else {
    // other code here
  }
}

Is Replaced With…

public void doSomething(Boolean.TRUE, Object otherArg) {
    // some code here
}
public void doSomething(Boolean.FALSE, Object otherArg) {
    // other code here
}

But I really don’t know if this makes things more simple.

In Closing…

I haven’t actually done much (read: any) research into how to write my own annotations in Java. I really don’t know how to write an annotation that will make the compiler behave differently and inject code into the source. I’d be interested to hear if anyone knows where I can do some reading on this.

* Okay, so it’s not a perfect application of 6-degrees, so what?