Symphonious

Kathy Sierra writes about being a loner and how it makes pair programming very frustrating. I can see her point - some people enjoy being alone and don’t like feeling crowded by others. That is different to not being a team player - loners can be very good in a team, but they do run into trouble when the team happens to be using pair programming or is just a very “in each others back-pocket” type of team.

I’m not sure what the answer is. As a manager (and I was always a really bad one), I’d probably be tempted to say sacrifice the one for the many. But does that really, in the long run, serve the company and the team best? Is there really no other way to get the benefits of XP Pair Programming than by this particular (sit side-by-side, etc.) implementation? Because True Loners aren’t against team work and being with people

There is a way. Move to the other side of the world and communicate electronically. I’m serious (though moving to the other side of the world is optional, a different cubicle would do). I work in a company that has people working from the two different offices in the US, two or three different places in Australia and one guy in India. We communicate electronically with a lot of success. The combination of instant messaging, voice chat (if your in the next cubicle that would be equivalent of poking your head around the corner) and email is extremely powerful for collaboration. If you wanted to take it a step further and do full on pair programming, add in something like SubEthaEdit so you can both see and edit the same document. The combination of either voice chat or instant messaging and SubEthaEdit would probably be perfect for a loner doing pair programming.

Personally, I think I’m a half-loner. I love being alone, I tend to dislike family gatherings and I often come across as anti-social. Despite that, if I’m alone too long I do get lonely. Then again, I’d say that anyone who says they don’t get lonely has either never truly been alone or is lying. Sure there are hermits that spend their lives hidden away from everyone but I doubt they never feel lonely at least a little.

Okay, I have to ask - why the sudden massive interest in JXTA? It seems to have taken over all the weblogs on java.net and most other places I look around. Maybe if I actually had a clue what it was really about I might be excited about it too, but I just haven’t had time to look into it.

Sigh.

I can’t resist picking apart this comment to my earlier post.

It’s easy to look at the code and modify it, but it’s not as easy to actually test that code. You need to mess with bootclasspaths and things like that.

How is this different to an opensource version of Java? You would still have to set up all the correct bootclasspaths and make sure you had things in the right place for it to work. That’s the design of Java, it has nothing to do with whether or not it’s opensource. Additionally, it’s not that difficult, just replace rt.jar (on Sun based JREs, classes.jar on Mac) with your new modified version and viola, you have a modified JRE.

And even if you do submit patches, you can’t include patched versions of JDK classes in your application, nor can you distribute your patches. No one could create a “development version” of the JDK that included other people’s patches, and that could be distributed for use with other applications.

This is considered a good thing by pretty much everyone I’ve head from on the issue. The greatest problem with opensourcing Java is that it could become fractured with multiple different non-compatible versions floating around causing trouble for Java developers. By not allowing you to distribute a modified JRE that problem is avoided.

I think Scott’s response to IBM was silly, since (1) IBM offered to release the source to their JVM, and (2) Sun doesn’t make money off of the JDK like IBM does from DB2.

1. If IBMs JVM is all IBMs intellectual property, they could opensource it without Suns help. There is nothing against having an open source JVM implementation, IBM wanted Sun to release control of Java certification.

2. Sun makes a lot of money off of Java through licensing their implementation, certification, developer training and a whole bunch of other ways. Think of the JRE as Sun’s “free reader” like Adobe provides a free reader for PDF documents.

I noticed this on Java.net. In it, Eitan Suez suggests that having open source J2SE libraries would rapidly increase their quality because of all the developers contributing patches.

The major problem with this argument is that the source for the Java standard libraries is already available and in fact is included in pretty much every J2SDK. It’s right there, in a format that can be used to create patches against and submit them to the publicly available bug parade for java. How many people do you see actually doing this though? Some, but very few.

Sure people are going to be more inclined to submit patches if Java becomes buzz word compliant and gets a mickey mouse badge from the FSF, but there will still be far more people demanding improvements than there will be fixing them. Open source isn’t this magical bullet that suddenly makes life easy and gives perfect quality - there are plenty of extremely buggy opensource programs with too few developers and there always will be.

Maybe I’m just more careful in choosing which commercial software I use, but on average I’ve found opensource software to be lower quality than commercial software, however opensource is more towards the extremes - it’s either really great or really bad. I’m sure that’s going to start a massive flame war but so be it. Opensource isn’t always better quality because generalisations are always false.

Finally I’d like to draw attention to what I consider the best rebuttal I’ve heard in a long time:

Go open source with DB2 and then you can tell me what to do with my assets

From Scott McNeally obviously. Check and mate.

Jim Winstead has posted a couple of entries on character encodings (1, 2). Some good info in there.

My three big tips for dealing with character encodings is this:

1. Know your character encoding and make sure you’re using that encoding everywhere. No look again because you probably missed a place where you didn’t think about encoding. Particularly don’t forget that printing something to System.err or System.out in Java uses the platform default encoding and so characters that can’t be represented in that encoding become question marks.

2. When practical, use US-ASCII and escaped characters for anything outside of it’s range. Most formats which support different encodings also provide a way to represent a character which isn’t in the current encoding through something like HTML’s entities or java’s escape codes (\u8222 etc). Most encodings are compatible with US-ASCII (EBDIC being a notable exception) so even if people forget to use the right encoding they can generally get away with it.

3. Remember that character encodings, despite their name do not apply to characters - they apply to byte sequences which represent characters. If you have a char variable in Java it has no character encoding as far as you are concerned, it’s just that character. The JVM can choose any representation it likes for that character in physical memory and you shouldn’t care (it actually happens to choose UTF-16 I think but you still shouldn’t care). You *do* however have to worry about character encodings when you convert from characters (or Strings which are really just a fancy array of chars) to byte streams. This happens when you use String.getBytes(), or print the characters to any kind of output stream. You also have to worry about the reverse process, new String(byte[]) and reading from an input stream.

The first two items should be pretty clear to you if you’ve done any work with character encodings, the third may seem unimportant, but it will help stop you from expecting code like the following to work:


String str = new String("my string");
byte[] utf8Bytes = str.getBytes(”UTF-8″);
String strISO88591 = new String(utf8Bytes, “ISO-8859-1″);


Naturally this won’t work because of rules 1 and 3. Rule 1 is broken in that you used a different encoding when working with the same data and 3 is broken because you expected strISO88591 to be a String using ISO-8859-1 character encoding, but it doesn’t because String objects don’t have a character encoding (as far as you should be concerned).

The big exception to rule 3 is when you’re using a language which doesn’t guarantee it will support whatever characters you throw at it, in which case you basically either have to work only with byte arrays and never let the language string functions near them. In general though I’d suggest you find a better language or a better library.

If I were to add fourth suggestion, it would be: remember that just because your character is valid, doesn’t mean the font you’re using can display it. Most fonts can’t display anything more than the characters in ISO-8859-1 and a few select others so if you’re working with mathematical symbols or characters from other languages you’ll need to find a special font that supports them.

BTW, yes I have spent far too much time working with character encodings and tracking down where people stuffed up with character encodings.