NetBeans bundled Subversion troubles

This is a small note-to-self.

NetBeans support for Subversion on Windows has an option to use either bundled svn binaries or CollabNet's official installation. The bundled NetBeans svn client works just fine at first - I use it with plink to do ssh tunneling.

Except that eventually it starts failing with a mysterious exception along the lines of:
org.tigris.subversion.javahl.ClientException: The system cannot find the file specified.
Commit failed (details follow):
Can't create tunnel: The system cannot find the file specified.

Long story short, the snafu is likely because in the NetBeans SVN settings, the full path to plink executable has to use forward slashes. Also, it may be prudent to surround whitespace-containing paths with quotation marks.

Anywho, it may still stop working, but we'll see.

UPDATE: nope, still doesn't work, heh.

UPDATE: works now. following NetBeans wiki instructions, it turns out that the bundled svn client doesn't actually listen to tunnel settings given by NetBeans (!). It listens to the .../Application Data/Subversion/config file. Another important caveat that wasted me a lot of time is that any time that file is changed, NetBeans must be restarted for any change to make a difference. And another important caveat is to use the explicit .exe extension on the plink executable file path. I added plink's location to my PATH; I also used Pageant for private-key auth instead of directly specifying the private-key path. Grr, what a stupid NetBeans bug.

Computer Science Approach to OS Design

So I had to tinker with Debian administration a bit... I can't help but philosophize about how some fairly abstract CS theory can apply to pragmatic admin stuff - packages, admin shell-scripts, etc.

Debian's dpkg already allows treating software in a fairly declarative OOP fashion. You have concrete "implementation" packages providing functionality guaranteed by special virtual packages, generic system-wide scripts for things like startup/shutdown sequence management, conf.d approach (one of my favourites) for modular "plug-in" configuration, etc. It is all very much interfaces vs classes and design-by-contract.

So I wonder if there is room to go a step further. Make packages declare their functionality in an abstract IDL/CORBA-like interface language. For example, a /usr/share file is kind of like a read-only property getter. An executable is a method (obviously). A config file is a special variation of user input (where the user is the admin). And so on and so forth.

Then, packages can declare their prerequisites in a much more granular and consistent way - by indicating individual files and utils that they use. There could be even tools that would automate half the work of a package maintainer. For example, compile the program directly from a SourceForge tarball, run it and sniff out its runtime library dependencies, system file access on the fly. In fact, existing debs and rpms could be scanned and adapted appropriately without a recompile.

What does that do? The package manager can be much smarter in detecting broken dependencies and software management issues. There is also room to get closer to a nice unified configuration system (not that everyone really cares too much about that). This would also help a lot to make Linux consumer-friendly (although that is still mostly about desktop app usability). It just seems so much... cleaner.

There is more to this - current Linux kernel allows so much cool admin trickery (such as LUFS) I am surprised core OS maintainers are not using it for more.

So I was thinking about enriching/AJAX-ifying my current JSF UI. The data displayed is very complex; the code is getting big and cumbersome, and the size of each page is reaching 100kb. Actions feel very un-responsive and slow, since it takes 2-3 seconds just to download the HTML itself!

One option is to not even do HTML+JS, and use a Swing-based downloadable client UI. Another is to use partial page replacement and keep existing JSF code. Also, I could just use bare-bones DWR and jQuery.

Common things to think about are:

• I have a good POJO model of what the UI is managing, and I want to re-use it
  
• Wherever the POJO model lives, it has to be able to talk to J2EE service beans

A Swing UI would let the model live on client-side JVM, and would require an RPC channel to the J2EE side directly. Promises to be clunky...

I did some quick Googling on DWR and direct JavaScript <-> server-side session POJO interfacing. Looks very cool because of its simplicity. I am comfortable with using jQuery, and its one-liner minimalism could mesh very well with making simple get/set calls to Java model beans. However, as the UI itself gets complex, one-liners get hairy.

JSF with PPR could be nice and easy to add to existing code. But since it will still generate huge amounts of HTML, I wonder if it will stay just as slow. The only way it wouldn't be the case is if JSF only rendered the affected parts of HTML.

Something to ponder...

Nano HTTP server

A tiny utility that provides a super-minimalist HTTP server, serving up contents of just one file. I mocked it up in Perl a while back, I think it was supposed to provide a WAR file for remote deployment to Tomcat, or some such.

Not really that great, but may be useful for quick-and-dirty file transfer or for testing HTTP stuff. The source code follows:

##
#       listens for HTTP connections and, regardless of request,
#       always returns contents of given file, with given content-type
#       header value
#       useful to serve up some test data as though it was from a real
#       HTTP server
##

use IO::Socket;

my($port, $file, $contentType) = @ARGV;

$port = int($port);

defined $contentType or die "must supply content type";

open(FILE, $file) or die "cannot open file";
local $/ = undef;
my $data = <FILE>;
close(FILE);

my $socket = new IO::Socket::INET('LocalPort' => $port, 'Proto' => 'tcp', 'Listen' => 1, 'Reuse' => 1);
$socket or die "cannot create listener socket";

while(1)
{
        my $clientSocket = $socket->accept();

        # read a token amount of data, just for appearance's sake
        my $buf;
        $clientSocket->recv($buf, 5);

        # print our response
        print $clientSocket "HTTP/1.0 200 OK\r\n";
        print $clientSocket "Content-Type: ", $contentType, "\r\n";
        print $clientSocket "Content-Length: ", length($data), "\r\n";
        print $clientSocket "\r\n";
        print $clientSocket $data;

        $clientSocket->close();
}

Unicode Sparklines

The concept of Sparklines (http://sparkline.org for examples) has been around for a while. I was reminded of it when browsing the Unicode character map the other day, and coming across the "block shapes" characters. There is a set of 8 characters that are essentially vertical bars with heights ranging from 1/8th to full character height. That allows to create crude but image-less quick spark-lines directly in text.

I mocked up a quick script that pulls stock data from Yahoo! Finance and converts it into a bar-graph using those Unicode characters. My Debian machine's fonts display those codes, so I assume most browsers out there will, too. Here is an example: ▇█▆▄▄▃▂▁. Link: http://sigmaxis.com/misc/quote-unicode.php

By the way, it was pleasantly surprising to see Unicode support for a lot of other "pragmatic" characters, such as ASCII box-drawing, etc. Heh, reminds me of good old DOS pseudo-GUIs and spreadsheets.

Script source:

<?php

$ticker = 'JAVA';

$handle = fopen("http://ichart.finance.yahoo.com/table.csv?s=$ticker&g=m", "r");
$csvdata = fread($handle, 4000);
$lines = explode("\n", $csvdata);
fclose($handle);

$prices = array();
$max = 0;
$min = 1000000;
$skipped = 0;
foreach($lines as $line) {
        if(!$skipped) { $skipped = 1; continue; }

        $values = explode(",", $line);
        $price = $values[4];

        if($price > $max) { $max = $price; }
        if($price < $min) { $min = $price; }
        $prices[] = $price;
        if(sizeof($prices) >= 8) { break; }
}

$prices = array_reverse($prices);

header("Content-Type: text/html");

echo "Monthly closing price for $ticker: ";
echo '<span style="background: #cdb">';

foreach($prices as $price) {
        $adj = intval(1 + 7 * ($price - $min) / ($max - $min));
        echo "&#960$adj;";
}

echo '</span>';

?>

JSF MyFaces tree2 Practice

I have tried using the MyFaces Tomahawk custom tree2 component in a UI project of mine. I had to show a hierarchy of beans; in addition, each bean had several list properties which also had to be editable and shown as part of one big heterogeneous tree structure.

Here are my observations:

• not nearly as simple and quick to get going as JSF sets the standard for
• does not seem to work inside the h:dataTable element!
• out-of-the-box, client-side node expand/collapse state does not react cleanly to tree modifications

Bean model implementation took a couple of tries to get decent, since node objects must implement the TreeNode interface. The cleanest result was to just roll a usual bean model, implement a TreeNodeBase subclass with a generic Object "data" field and then have a "getTreeRoot" method on the top-level element that would walk the model and build a corresponding tree of nodes. That way, I could have JSF tags get directly at the original model bean via the "data" field with no extra fuss.

The alternative included making model beans directly subclass TreeNodeBase, but that got messy fast.

I don't know if someone implemented that already, but I was aching to have a JSF tree component that would not impose a custom tree node interface model. The cleanest implementation would just take an arbitrary root node bean value and then recursively invoke a special "get child nodes" EL expression on it and its children. For example, assume that you have an "Account" model bean class, and it has a "getChildAccounts" method that returns an array or list. Here is what I'd expect the tag to look like:

<x:myAwesomeTree nodeVar="acct" value="#{blahblah.rootAccount}" children="#{acct.childAccounts}">
... usual JSF tags referencing the acct variable ...
</x:myAwesomeTree>


I should mention that I ended up ditching the tree2 tag after all. I just made a special tree-walker method that returns a list of all nodes in my tree structure in traversal order. That list is shown directly as a bunch of divs via t:dataList tag. Then, each node tells how many ancestors it has, which sets the CSS left-margin attribute. Yep, that's right. Cheap and dirty won the day.

In fact, even after that I ran into performance and usability issues... I think that I should have made a Swing-based UI delivered via Java WebStart. For my need - a complex, rarely-accessed administrative interface - it fits the bill best. But oh well, that is a task for another day.