Java JNaming JConventions

One thing that randomly irks me about Java is the naming conventions. For example: Swing is the newer version of Java’s user interface library. The older version didn’t go away. It’s just not used as much even though it still serves as the basis for much of the newer stuff.

Thus, the applet class in the old version becomes JApplet in the new. Frame becomes JFrame. Panel becomes JPanel. If you’re familiar with the old name you can get the new name just by adding a “J” to it.

While sensible, it irritates me and grows monotonous very quickly.

I keep on wondering how the person who decided to use this particular convention writes in real life.

I imagine him emailing his girlfriend/wife things like “I JLong to JTouch your JBody.”

P.S. If it somehow happens that this blog entry finds the person who came up with that naming convention, well… I have only one thing to say: No, I do not have a better idea.


The state of things on the distributed computing front goes like this:

The project of the team that I’m on will definitely be a file sharing program. I’m going to mostly be in charge of the gui and Casey will primarily be in charge of the actual sharing part of the code. We’re both still talking about the general architecture of the filesharing network.

The goal is to make it work without a centralized server. One way to do this is to use multicasting. Multicasting, at its most basic and least technical, amounts to sending everyone in a group. Basically, the clients would announce themselves via multicasting and continually add to the list of possible clients by saving the IP addresses announced via multicast.

To query, they would send a request using udp to everyone on their list. And then only the people with something that fit the query would respond.

This has obvious scalability problems, but should be workable for the scope of this project.

Linux Usability

In December, I was finally introduced to the wonderful world of desktop Linux.

As someone who does technical support for some 20 users, manages 3 servers (1 Freebsd, 2 Windows 2000), and does a bit of web/database programming, I am used to troubleshooting computer problems. This is a good thing because your average Linux desktop has plenty of problems to troubleshoot.

What is not a good thing is that they are more usability problems than technical problems.

Here’s what I mean. My current laundry list of things to fix goes as follows:
1. Make my thumb drive work with Linux (this looks easy, I just haven’t had time)
2. Make my wacom tablet work with Linux (multi-step process, but at least I’ve bookmarked the necesary pages)
3. Make my sound card work (must learn more about ALSA, will probably have to recompile kernel or something. I dread this)
4. Mess around with the unholy trinity of apache/mysql/php a bit more (all of these work, but I’m still configuring certain details…)

Where is the usability problem in this list? Scattered throughout.

All I it looks like I have to do is load a kernel module and mount the thumb drive for it to work. I will have to mount the thumb drive every time. Just like I do every time I put a cdrom in.

This irks me. The whole point of USB (at least to my mind) is that it’s a transparent technology. You plug it in and it works. Specifically typing “mount” very seldom offers me options that automatically mounting it wouldn’t. Ninety-nine percent of the time I only want to do one thing–access the drive.

Heck, the Amiga back in 1985 automatically detected a floppy placed into it’s drive. OS X, the BSD based Apple operating system does the same today. Why hasn’t someone done the same for Linux?

Kernel Modules
If people really want Linux to be a contender for the desktop market, they will have to either

1. come up with a very usable gui for kernel configuration,
2. enable the most commonly used modules by default, or
3. figure out some way for Linux to automatically add new modules when needed.

Possibly all three–though I’ve got to admit that option 3 makes me nervous. In any case, kernel configuration is not something that your average user needs or wants to know–but if they want to use all too many devices (some sound cards for example) they have no choice.

Man pages suck. Other documentation is not much better. In the process of installing some things related to mysql and php, I was given the option of adding certain lines to the configuration files for apache/mysql/php. I was never told why I should or shouldn’t add those lines. In some cases, I already knew I needed them and happily allowed the installer to add them for me. I’m still tracking down the reason for or against adding certain lines.

The Funny Thing
Despite the annoying problems I’ve just outlined, GNOME/KDE do seem to have moved past the “usable only by geeks” stage. My wife (a social worker) can happily use the Linux box for almost everything she uses a computer for.

At least until she wants to put a cdrom in and listen to music.

Distributed Computing

Had class tonight.

This is, as always, a good thing. This semester I’m taking the last of three classes in the distributed computing series and the first of the classes in the database series. As a result, I’m probably going to be writing a lot more about distributed computing than databases. Advanced topics in distributed computing are likely to be much more interesting than the basics of database design.

At any rate, tonight was the distributed computing class. We’ll be graded for two things in this class: A project (60%) and readings and discussion (40%).

As you might guess, the project is the main point of the class. We’re supposed to create a distributed system. What’s a distributed system? Basically a system that allows multiple computers to access services.

The internet is one example. Napster is another.

The team I’m on is considering creating a file sharing program. We’re trying to figure out how to make it both scalable and decentralized (ala Gnutella). We’d also like to make it impossible for people to figure out exactly what sort of files your sharing–but that’s something we’ll implement only if we have time.

Trying to figure out the basic system will be complicated enough.