Tuesday, May 31, 2011

The trouble with tabs (in Firefox 4)

I use my web browser a lot. And I mean, a lot. (It's not that I necessarily want to, but the browser seems to have killed off a lot of proper applications, and the world is a poorer place for that.)

I've actually switched to Firefox 4. (OK, on Solaris you don't actually have all that much choice.) But normally it takes me very much longer to update to a newly released version of Firefox. Why the move this time? Primarily performance - I've found that some sites (and I suspect Twitter here) can make the whole browser feel sluggish. Certainly since I switched to version 4 the annoying lags I used to have are gone.

There are a few changes in Firefox 4 that really can't be described as anything but negative. That's my opinion, of course, but I'm a heavy user and it has really irked me that for the last couple of decades we've matched advances in computing with compensating steps backward.

The first thing that didn't actually bother me initially but soon got spectacularly irritating was the new "Tabs on Top" feature. (Ahem, misfeature.) What this really means is that the tabs for a page are separated from the page they apply to by a couple of tool bars (in my case, the Bookmarks toolbar and the Navigation toolbar). This makes the user suffer thrice: the interface appears to put the toolbars into the tabs, causing confusion; separation on screen causes a mental disconnect between the page and its tab; and you have to move the mouse further to get to the tabs, making them harder to use. Fortunately you can turn this off pretty easily by right-clicking (on the home button for example) and unchecking the option.

Far worse (because it can't just be turned off) is the switch to tab feature. So you want to open a site, you start typing its address and it appears in the dropdown list. Only if you've already got it open, you don't get to open it, you get to switch to tab - so the browser just goes to the already existing tab. Now, listen people: if I wanted to go to the tab I had already had open, guess what? I would have clicked on the tab! The fact that I'm entering it again means that I absolutely want a new copy. This behaviour is especially annoying when the tab is in another window on another virtual desktop, because it then brings that up (moving the Firefox window to a different virtual desktop in the process). Fortunately there's an add-on to disable this particular misfeature.

Browsing in tabs was a spectacularly useful advance, adding extra scalability to the browsing experience. Firefox 4 attempts to make them less usable; fortunately I've been able to sidestep that (for now).

Saturday, May 28, 2011

JKstat and KAR - JSON migration

There are a couple of new updates for JKstat and KAR.

For JKstat, version 0.45 brings in JSON support, and 0.50 solidifies it.

For KAR, version 0.6.5 likewise introduces JSON support, and 0.7 makes JSON the only supported data format, superseding KAR's private data format.

The only point of 0.6.5 is that it can both read and write in both the old KAR format and the new JSON format. So I needed that in order to be able to convert old KAR archives.

I've covered some of the advantages of JSON previously. While those were just early thoughts, subsequent tests confirm the advantages of using JSON for both the client-server communication and the KAR archive format. So these releases represent both a transition and a clean break (which is why there are two new versions of each).

Now I've got JSON format data available, I'm learning javascript so as to write a browser-based client. Stay tuned.

Sunday, May 15, 2011

About time to modernize Java

It's about time to modernize Java.

I'm not talking fancy things like closures or functional programming. I'm talking some of the basic interfaces in commonly used classes.

Exhibit A are the constructors for JTree and JList. These take a Hashtable and a Vector. How long have we had Collections built into Java? So why don't JTree and JList use Map and List?

Exhibit B are classes that still return Enumeration. For example, to get the contents of a ZipFile you get an Enumeration and have to work your way through it by hand. Now Java has the enhanced for-loop, there ought to be methods for returning a Collection directly.

I could go on, but I think you get the point - many of Java's own classes simply haven't been modernized to bring them in line with improvements elsewhere. And I get really irritated having to continue to write crufty old-fashioned code to deal with those deficiencies.

Saturday, May 14, 2011

JSON meets JKstat and KAR

I've been looking at JSON for a long time, wondering whether and how to best make use of it. After considerable experimentation, I'm convinced, and it's going to be an integral part of both JKstat and KAR.

So, the first thing I was looking at was the client-server code in JKstat. One of the things that's always irritated me about XML-RPC is it's obvious lack of a long data type. It doesn't seem to be bothered that the world is more than 32-bits. Sure, there are various vendor extensions (and I have to turn them on in the Apache XML-RPC implementation that I use) but the result is something that's horribly non-portable.

The other thing I've been looking at is the archive format used in KAR. I started out with simple kstat -p but that proved inadequate in that important data (metadata) was missing, so I developed a private format. This was better, but was a horrid hack.

So, enter JSON. It turns out that it makes an excellent serialization format for kstats.
  • Reusing a standard means there's less work for me to do.
  • I can use the same code for KAR and the JKstat client-server mode.
  • There are JSON bindings in almost all languages, so interoperability is easy to achieve.
  • The format is a string, so no messing about with extensions to pass longs.
  • For KAR, it's almost twice as quick to parse as my own hacked format.

As a result, the next versions of JKstat and KAR will support JSON as their archive and interchange format.

As an aside, this opens the door to wicked cool stuff.

Tuesday, May 03, 2011

SolView 0.56

Hot on the heels of an updated JKstat comes a new release of SolView.

Like with JKstat, there's a lot of tidying up and quite a bit of extra polish. Little things, like changing some of the label text to make it more meaningful, or telling you if a disk or partition is part of a ZFS pool.

There's one fairly visible change, to the start of the explorer view, which now looks very different:



This is getting closer to what I envisioned early on for this view, a much more graphically rich presentation. It's not finished, and what's shown (and how) will certainly change, but it shows the direction I would like to head in.

Monday, May 02, 2011

JKstat 0.44

It's been one day off work after another here in the UK recently. In between going to a beer festival and Newmarket races, I've found a little time to work on JKstat.

The result is a new version of JKstat available for download.

There's nothing earth shattering here, but a process of steady improvement. I've gone through the demos, removing some of the cruftier ones, enhancing some of the others, and moving some of those from SolView back to JKstat. So, the original iostat demo has gone, leaving just the table-based version; the load subcommand has been replaced by an uptime subcommand. The cpustate demo has been merged with the cpuchart demo, and has also had a vertical mode added.


OK, so it's not that impressive on my little desktop machine, but it works much better than the old layout as a display arrangement on something like a T5140 that has 128 cpus in it.

There's additional polish elsewhere. Apart from fewer typos, I've filtered out kstats from the chartbuilder that you'll never want to chart, so there are fewer kstats to munge through. The charts work a little better too: they now display the statistics in the requested order, and you can set the colors.

Another thing I've been playing with is an 'interesting' subcommand that tries to identify kstats with interesting behaviour - as in doing something out of the ordinary. This worked out a whole lot worse than I hoped. The problem, of course, is defining what constitutes normal (let alone anomalous) behaviour. The behaviour of any kstat certainly isn't normally distributed, and in fact many are very spiky as a matter of course. I may revisit this with KAR, which has historical data from which I can construct a baseline of the expected range of behaviour.

Something else I've been looking at is sparklines. I added a simple line graph to JStripChart to support this. At the moment they're not really sparklines, just little graphs, but it's a start, and expect to see more of that in SolView.

There's also a stunningly boneheaded bug fixed in KstatFilter. Filtering out things you don't want was matching far too much (it would match any of a module:instance:name specifier rather than the correct behaviour of matching all of them, so unix:0:kstat_types would throw away all unix kstats and all of instance 0, which wasn't what you wanted).