Category Archives: nerd

X Windows

Recently, I have heard several references to the term “X Windows”. For all of you uninformed fools out there, here’s the official word straight from the horse’s mouth (see man X):

The X.Org Foundation requests that the following names be used when referring to this software:

X
X Window System
X Version 11
X Window System, Version 11
X11

So, as you can see, there is no reference to “X Windows”. It has nothing to do with “Windows”, so don’t call it that.

Advertisements

Sometimes I feel like constructors should be removed from Java

Sometimes constructors in Java are convenient. You can instantiate your class with all the data you need with a simple one-liner:

Car car = new Car(numberOfWheels, color, engine, doors);

That code is fairly readable and concise, but things can quickly spiral out of control. Unless you use really descriptive variable names like those above, it’s pretty easy to get lost. Eventually you end up with code like this (partially obfuscated to protect the innocent):


foo = new Bar(rs.getString(1),
rs.getString(2),
rs.getString(3),
rs.getString(4),
rs.getString(5),
rs.getString(6),
rs.getString(7),
rs.getString(8),
rs.getString(9),
rs.getString(10),
rs.getDate(11),
rs.getDate(12),
(“Y”.equals(rs.getString(13)) ? true : false),
(“Y”.equals(rs.getString(14)) ? true : false),
(“Y”.equals(rs.getString(15)) ? true : false),
(“Y”.equals(rs.getString(16)) ? true : false),
(“Y”.equals(rs.getString(17)) ? true : false),
(“Y”.equals(rs.getString(18)) ? true : false),
(“Y”.equals(rs.getString(19)) ? true : false),
rs.getTimestamp(20),
rs.getTimestamp(21),
rs.getString(22),
rs.getString(23),
rs.getString(24));

This is the point where I say you gotta just use a blank constructor and setter methods. Much more readable. And on a side note, when you are typing rs.getString(24), you should probably start thinking about how it might be more readable if you refer to your result set columns by name. That is all.

Ditch MySQL now


MySQL was “bought” by Sun last year, as you may know. The fact that this is significant sort of illustrates one of the reasons I didn’t like MySQL from the moment I met it in 1997 or so. It’s only like half in the game as far as being free and open source. It is tied way too much to MySQL AB, the company, and the way it is licensed is totally shady. Anyway, now Sun is dying and Larry Ellison is about to scoop it up. Monty, the MySQL guy is whining to the Internet, trying to get the European Commission to block the deal. It’s a sad story, but if Oracle doesn’t buy Sun, they will just need to get bought by someone else or go out of business. The real sad part of the story is the death of Sun, one of the original great Internet companies (my other favorite being SGI which met its fate years ago). In any case, MySQL’s future is dark and cloudy.

That is why I’m just going to go ahead and plug my favorite database, PostgreSQL. You should check it out, it’s awesome. It is way more powerful than MySQL and the licensing is better. It was built from the ground up to be a real database, not some tinkering project like MySQL. If you are running a project, especially an open source one, that is dependent on a database, you should take a serious look at PostgreSQL and consider making it your database of choice.

A recipe for trouble

Dear the Internet,

Please never write this code:

if (value == null || value.equals(“”)) {
d = new Date(0);
} else {

This is what I like to call “bug hiding”. Rarely does a person really mean 12/31/1969 when they pass you a null or blank value. That is all.

JSP is still really bad

I had to do some maintenance work recently on a JSP app. Normally, I avoid JSP like the plague because my (dated) experience with it has been mostly bad. The app I had to maintain was a stone age thing full of scriptlets, but I did a little research and used JSTL to do some of the work on the updates. I was pretty impressed with how cleanly you can do some flow control stuff now. So, I started some new development on a new project with JSP as a proof of concept to see if it is a tolerable programming environment now. It isn’t. For the real basics, there has been a lot of improvement, but some of the mechanisms for taglibs, dealing with variable between servlet/JSP, etc. are still very clunky. And today I encountered this. If you forget to put the return type when defining a function within your app, you get a super mysterious error.


I guess you could blame the implementation (Jasper), but what does anyone else use? Also, you can sort of tell from the screen shot of the editor, but the JSP editor in the current version of Eclipse is pretty awful. It displays some of your double quotes as single quotes, which is really awkward.

Tapestry 5 pain points

I have been doing Tapestry 5 work for about a year now, and I’m definitely still learning, but I think I know my way around fairly well. I really (mostly) like it, and I think it is way easier to use than Tapestry 4, as well as many other frameworks. It also results in a nice clean code base which isn’t too difficult to approach. There are, however, a couple of areas that I really just find confusing. Some of them aren’t too bad once you get to know them, but they are hard to learn. I think it is important for most aspects of the framework to be easy to learn/use, because if people encounter pain during their initial impression stage, they will abandon the framework and use something else.

The first issue I have is with the way that the Select component works when you want to have a dynamic model for the list. I think this is a common requirement for applications, so it is something people will most likely encounter fairly quickly. For complex models, it is usually necessary to implement two interfaces: SelectModel and ValueEncoder. The interfaces make sense once you get to know them, but I think the learning curve is quite steep for such a common task. I’m not sure how this could be solved, but it seems like Tapestry 4 may have had a more simple system (though I’m sure it had some problems which led to it being redone).

The second issue I have is with page context. Often times in standalone web applications, I have created pages which take query string parameters. These can be referenced by external apps or pages, and used to link between pages of an app. Tapestry’s equivalent is the page context, which can be used to pass contextual data between pages. There are two problems that I’ve encountered with page context. First, it is limited in what data it can represent. It is generally just a list of nameless parameters. This makes it difficult to pass only certain parameters or parameters with names. Second, the format for the URL is not a part of the spec (correct me if I’m wrong), so it can only reliably be used via other Tapestry pages. This makes it difficult to pass data in to a Tapestry page from an external place.

So to sum it up, I’d like to reiterate that I really do like Tapestry 5 and hope for its widespread adoption, but it has a few points that are difficult to deal with. If these issues were addressed in a future version, I think it would help ease a new developer’s adoption of the framework.

Image submit in Tapestry 5.1

This just took me a really long time to figure out, so I’m writing it down. Tapestry 5.1 adds support for submit buttons with an image (I think it was added in 5.1). In any case, you just use the normal tag, but you add an image attribute which is an “asset”. I added an Asset property to my page class and used @Inject and @Path to inject the asset. I used that property name in the image attribute, and it didn’t work. It turns out, you don’t need to declare the asset as a property in your page class. You just specify the path in the image attribute just like you would in the @Path annotation. So, it looks something like this:

<t:submit image=”context:images/submit.gif”/>

Much simpler than I was thinking. Sometimes I get really frustrated with these little Tapestry issues…