The first is that the linux download of eclipse doesnt work very well in the latest version of Ubuntu (Karmic Koala). A work around is described here with further links to Ubuntu’s issuelist. But actually the work around is only a partial fix because Eclipse sometimes starts a copy of itself and, when it does, it ignores the work around. This affects me as I’m currently trying to develop plugins.

One alternative approach that has worked for me so far is to use the version of eclipse that’s in the Ubuntu repositories. However, this version wasn’t taken from the final release of the eclipse codebase and the groovy plugin install, which patches the JDT (Java Development Toolkit) just wont install in this version.

So to use the groovy plugin it looks as though I’ll have to wait for Eclipse 3.5.2 (which is due on February 29th).

If you look at the wikipedia argumentation entry, you’ll see that Dung is mentioned in the Artificial Intelligence (AI) section. The underlying model for Dungine, Dung’s acceptability semantics, is interesting to people who work in AI and are trying to capture how people reason and debate, particularly with inconsistent evidence and automate reasoning in this context. In my lab we use ideas like this to try and improve clinical decision support systems that:

• recommend diagnoses for a patient with a history and a set of symptoms and
• recommend treatments for a diagnosed condition.

Clinicians don’t always agree, and neither does the evidence upon which they base their opinions. If we can adequately represent their arguments, then this software might allow us to automatically reason about which of those arguments we should accept.

In the business world one might use Dungine to:

• accept a recommendation from a source on the web or
• represent a decision about granting a loan,

but there are many alternative approaches to supporting these examples, including Bayesian methods or applying a set of prioritised rules. My intuition is that argumentation is most useful in situations where it feels natural to represent contradicting reasons for doing something (accepting the recommendation or granting the loan) but this is a new area, and there are too few examples of it’s application in the wild. So I’ve built this library to help people give it go, and in doing so gather empirical evidence to help us understand where it’s a practical and useful technique.

Is is very important to ask stupid questions. The amount that a developer is expected to know is huge. They must understand their own field of software development, which is rapidly expanding, the domain of their client and be able to think about both at the tiniest level of detail and the highest abstraction. It is inevitable that things fall through the gaps along the way, and often the only way to pick those things up is to ask stupid questions. If you are afraid to ask stupid questions you’re going to proceed much more slowly then you could otherwise. Of course, most people don’t like asking questions that they suspect might be stupid, but developers should consider this as part of their role.

One consequence of this attitude is that a software team, when it takes on a new member, must expect a whole series of questions from that newcomer about their domain, design decisions and working practice. They must allow for this in their planning and encourage this from that person. However, everyone has limits about being pestered about things that seem stupid, and my stated limit is that if someone asks me to show or explain to them the same thing three times I will be cross. Twice is ok (expected sometimes), three is not. I hope this encourages people to actively examine their level of understanding at whatever level of abstraction and document the processes they encounter (or, even better, review the documentation that exists).

Oh, and why did the first question suggest a lack of experience? Well, because we’re not actually paid by an organisation to write software (although generally of course, this is what we get a kick out of the most) – we’re paid to solve their technical problems in a sustainable manner. And generally this involves prioritising partial solutions. Thus if an organisation doesn’t understand why you wish to pursue a particular line of work, and you cannot justify that line of work in terms of a problem they have, then it’s legitimate for them to prioritise another piece of work for you. Sorry, but that’s just the way it is. You have the option to continue rich seams of development in your own time (I would say this was one of the primary motivations for open source software), or find an organisation that is more aligned with your own personal enthusiasms – this may mean starting your own.

A friend of mine in a compiler writing class produced a compiler with one error message ‘you lied to me when you told me this was a program’

see plasmasturm.org/code.

* Maybe I did notice it before and didnt get it. Since I first looked at that site I’ve done some work with the RACC, JACC and JavaCC compiler compilers (of the two Java compiler compilers, I prefer JavaCC).

This was almost my first encounter with PHP and definately my first encounter with the WordPress codebase but the task turned out to be fairly straightforward. The files in the WordPress themes were intuitively named and the code was easy to read. The only problem I had was tracing the location of some of the core functions that are used in the theme, but this is quite normal for this sort of application I feel.

There is no standard swing control (container) to do this so you must roll your own. Searching for “java status bar” didnt get me very far. Initially I just used a JLabel, but this is too simple. I really wanted something with multiple recessed panels (as in the skype example). I considered using an unfloatable JToolBar but I dropped this idea because a toolbar’s default background doesnt look like a status bar and because its not easy to make the recessed panels this way. Finally I realised that the best way to build my status bar is to nest JPanels. In the next screenshot you can see an example Java status bar which consists of the one JPanel with two JPanel containers nested within it.

Now it’s a little tricky to get the status bar behaving correctly on resize, but if you use a GridBagLayout for your top level JPanel then it’s doable. However, a GridBagLayout is pretty horrible to use so I constructed two helper classes, StatusBar and StatusBarPanel to make things eaiser. A StatusBarPanel is simply a JPanel extended with two extra attributes: an integer panelWidth and a boolean fixedWidth. Thus you can define the width that you wish for your panel and whether or not it can stretch on resize. The StatusBar class also extends JPanel and has an array of StatusBarPanel objects. A StatusBar object configures the GridBagConstraints for you when you give it the array of panels.