Tuesday, December 30, 2008

Man Guilty Of Killing Moose Just Inside National Park Boundary

Newsminer.com in Alaska has a story about a hunter that was convicted of shooting a moose just inside the boundary of Denali National Park. The location of the park boundary and how well it was marked on the ground were important elements of the case.

I know from personal experience that United States National Forest Boundaries, Wilderness Boundaries, and National Park boundaries are not always well marked. I'm not making any determination of the hunter's guilt, I'm just pointing out my own personal experience with one issue in this case.

Goes to show that location matters.

Here is a link to the article:

Posted on 4:20 PM | Categories:

"Java Platform Performance" and OpenJUMP (Scalability)

I recently purchased the book “Java Platform Performance: Strategies and Tactics” and I have been reading it here and there. In Chapter 1 the author identifies four areas of a program’s performance:

  • Computational Performance
  • RAM Footprint
  • Start-Up Time
  • Scalability

We all know OpenJUMP has some issues with RAM Footprint, especially on older computers. The architecture of Eclipse was especially designed to have good performance when it comes to Start-Up Time. However, one aspect of performance that I never really thought of was scalability. Here is a snippet from Chapter 1 where the author provides a nice description of scalability:

“Scalability, the study of how systems perform under heavy loads, is an often-neglected aspect of performance. A server might perform well with 50 concurrent users, but how does it perform with 1,000? Does the performance of the server drop off gradually, or does it degrade quickly when a certain threshold is reached?”

You might not think that scalability would be a big issue for OpenJUMP. After all, OpenJUMP is a desktop application designed for a single user, not a client-server application designed for hundred or thousands of users. Still, scalability might creep into the performance equation for OpenJUMP in unexpected areas. One example might be the number of layers in a Task. Your plug-in might work great if the current task only has two (2) layers, or five (5). But how does it perform when there are 50 layers, or 500? If I remember correctly we’ve had bugs in OpenJUMP that only show up when there are a large number of layers present. I’m sure there are other examples of scalability issues in OpenJUMP.

I look forward to learning a lot more from the Java Platform Performance book and to applying this new knowledge to OpenJUMP.

The Sunburned Surveyor

Posted on 12:56 PM | Categories: