I promised Sushrut Bidwai to write about my experience. Did I like it? Lets’ see.

What I liked:

• We (I paired with Marc Evers) completed a number of quite usable features in the span of a morning (thankfully we did not have to write much back-end database code, with java verbosity / xml-osity  or anotation-osity seems unavoidable).
• Writing javascript in java feels a bit odd (as a language, I am taken more with javascript’s flexibility than java’s mid-level-language ‘you must spell everything out n times’, but being able to apply merciless refactoring tools on the client side was quite nice.
• Realizing whether the piece we were working on was on the server or client side was a bit confusing at first.
• Having programmed with Wicket quite a bit lately, and writing a GTK desktop application in C#, the programming model was quite familiar. Having all the behaviour that is (part of) a screen in one place feels convenient (as opposed to e.g. ruby on rails where behaviour tends to get spread out over controller code, view code and javascript files here and there).
• The client side code provided by GWT for formatting currency and dates was elegant and easy to use (take that Java API! )

Puzzles:

• Marc felt the AsyncCallbacks instances that are needed to glue front to back – end were at the wrong level of abstraction. I feel that may be, but it is already a step up from having half of the mechanism in javascript and the other half in the server side language.
• When working on a user interface, I like to be able to see changes instantly, so that I can play around and see what works best (and yes, tests will be written at some point, before, after or during). Some changes we could try instantly, in the special GWT toy browser, others needed a lengthy compile.

Things I liked less

• Even for the sample application, the compile times (when we changed some parts of the code, otherwise we could reload in the special browser) were already quite long. I am used to instant modifications (ruby, perl etc.) or very fast compiles (java with wicket) and have no desire to go back to the days of program-compile-coffee-run . Apparently it can be reduced by generating client javascript for just one browser (and generate everything in the build for instance)
• Unit Testing the client side code is ’special’ – can not use JUnit apparently. (this is me being a customer – I want more! testing javascript code is special otherwise as well).
• The ide (intellij idea)seemed necessary to magically tie bits of client and server code together that belonged together.

Verdict: I am a bit conflicted. For AJAX-heavy (more likely: AJAX-only, GWT does not seem to be meant for unobtrusive javascript) web applications it seems quite productive. However I would worry about the long compile times (maybe less if I knew how to rapidly testdrive the whole thing – this may be a beginners’ perspective. However I also heard some of my tweeps complain about compiles that take a couple of minutes).

If you are curious and want to go out and play for yourself, the example code is accessible through the Spa Conference wiki.

I stumbled across links to kryogenix. Kryogenix has some very unobtrusive ways to do sortable tables, search keyword highlighting and explorer like tree views and more. Each of them requiring only that you include a javascript file, add a few lines of CSS stylesheet code, and (for the tree view and the table), add a “class” to one table or list. They are unobtrusive, in that your site will still work if javascript is disabled, or your browser does not support everything.

A simple explanation for adding and removing elements on a web page (using document object model (DOM) and javascript): javascript tutorial – dom nodes and tree .

The reason I’m brushing up on javascript, is that I want to write integration tests with FireWatir for pages that have a TinyMCE editor in them. I did an experiment and had it working before, I threw it away accidentally and have to re-create it. Throwing something away is a good way to really learn something (although it takes more time…). So the second time, I’m taking the time to understand more about modifying pages with javascript, documenting my trail for the next time, and save the results in subversion…

We completed a minimal implementation – only for taurus (could easily be parameterized in the next bit). It consists of a shell script that downloads a horoscope from yahoo, and downloads one from astrology online. It’s two scripts, since we extracted the extraction code for astrology online to a script called …extract.pl.

rm -f taurus*
rm -f daily.htm*
wget http://www.astrology-online.com/daily.htm 2> wget1.out
./extract.pl daily.htm > first.txt

wget http://astrology.yahoo.com/astrology/general/dailyoverview/taurus 2> wget2.out
cat taurus | grep Quickie  | sed 's/<.*b>(.*).*>/1/' > second.txt

cat *.txt

extract.pl :

#!/usr/bin/perl -w

while ( <> )
{
if (/CHANGE TAURUS/)
{
$printing = 1;
next;
}
if (/END TAURUS/)
{
$printing = 0;
}
if ($printing)
{ print ;}

}

Vise enables a programmer to inspect values inside methods, and then test (with unit tests) and inspect these values, so at least when refactoring the programmer can be sure nothing has changed, and can get some confidence that all branches have been covered.

Vise should lower the barrier for testing and refactoring legacy code – when old complex code is not refactored, new more complex code is ‘wrapped around’ it, and no-one dares touch the old code anymore.

It’s been a while since I last programmed in smalltalk, and its nice to see there’s ongoing development. Especially if the vendor presenting does so in an open way, going into questions and openly giving answers – I wish more vendors presented like this.

Even though I haven’t programmed in smalltalk for a while, most of it still makes sense – I guess that is what stable technology looks like.