One Man Band

...and that is why you fail

2008-01-28T14:46:00.000+11:00

On the weekend I helped my brother setup a new antenna for his house. Now sure we bought a brand new length of co-ax cable, mast-amp, splitter, connectors and only slightly used (my old) antenna. when I had mounted the antenna and run the first length of cable down from it through the roof, instead of wiring it up straight to the splitter, I first took the whole length, put (temporarily) a connector on the other end and tried it out by hooking it up to his tv. Sure enough only 2 of the 5 channels worked! Lucky I thought, not having yet used the splitter, I now only had 1,2,3, 4!! components to test: antenna, cable, amp, connectors. Yep, even though I thought I was being clever by doing some testing - I was already too late! and infact was trying to test which 1 or more of 4 different components had failed.
To cut a longish story sort, I ended up doing a quick bypass of the masthead amp (which in this case happened to be the most complex component in the system) by virtue of sitting on the roof and holding the 2 pieces of coax together and sure enough the tv started getting all the channels. Now as usual, it was a bit of a painful lesson as it meant I wasted hours and ended up having to climbup onto the roof and ceiling space mutliple times, when of course I could easily have done a unit test of the amp while safely on the ground.
So why didn't I test the amp to start with? Well it was made by someelse who should know what they are doing and I just *assumed* that they tested it thoroughly before giving it to us.
After that, what I ended up doing was testing as much as possible each run of co-ax that I put in, because since even though the components (coax, connectors) were quite simple and not likely to fail, my use of them (I dont do cable runs for a living) was prone to error so deserved testing. But what if I had been unlikly with the cable and had got a batch with a break in it? Well I had my multi-meter with me, so I could easily have done a continuity test as well but of course I didn't since as I said I didn't think about testing all the components individually at the start, but rather half way through, by which time it was even too late to be able to test some components like the cable in isolation.

The moral of this story: version 1.6.1 Helma now comes with the jala unit testing framework out of the box and unless you want to spend a lot of times climbing up and down ladders, I suggest we all start using it.

topic of the week

2007-08-28T14:12:00.000+10:00

the need to go cold-turkey for our RDBMS addiction

some think the answer looks a bit like this

I really wish it was as easy as a java lib implementing this.

the downside

2007-07-06T13:56:00.000+10:00

I think this guys biggest problem is he has a crap manager, I have a great one and it sure helps!

"Simplicity" aka Maks's guide to Javascript for Java programmers Part I

2007-07-06T09:06:00.000+10:00

Javascript (hence forth JS) in its current v1.5 (Ecma262 ) incarnation is a great small, powerful scripting language. A lot of Java developers seem to now be realising this (I'm a convert of about a year now) and given the similarities between the 2 languages might get tripped up.
Also its very easy for new comers to get confuse between what's in the JS language and what is provided by the web browsers that host the JS runtime that most people use JS in (but not all! Actionscript in Flash is a implementation of Ecmascript and you can use JS very nicely on the server-side)
So here is my attempt at slightly damping down the learning curve.

Lets start with the basics:

Almost everything is an Object.
Objects are essentially Maps (i.e. collections of name, value pairs)
The name, value pairs are an objects properties.
There are NO classes.

How can you have objects without classes? Well do your Java Map objects have a class? No they are just simply a Map, whether you stick an Address, CORBA or String objects in a map its all the same, a Map is a Map and in JS a object is an object.

BUT objects do have a prototype. An objects prototype is really just a special key in the object that points to another object, where the JS interpreter will look for a property requested for the current object but not found in the current object. If this sounds a bit a simple form of inheritance - it is, BUT just don't get carried away and start thinking its the same as inheritance in Java.

There are only a few built-in data types: Object, Array, Number, String, Function.

If you are paying attention, you would have noticed that the last data type was "Function". That is because functions (ie executing blocks of code) are an actual data type in JS and are in fact objects (remember almost everything is an object). What this means is that you can have functions as stand-alone entities. In Java of course there is not even the concept of a function - the only code you can have is methods which are inextricably bound to a Class and objects of that class.

Objects have methods

Now we're back to more familiar ground. Because you could have an object property that points to a function object. this gives you a function tied closely to an object, aka a method. Again JS methods are simliar to Java ones (they get an implicit "this" reference) but again don't assume they are exactly the same.

Everything (almost) is an object. Hence there are no "primitives" like Javas int, bool, etc. This means that is if you have a numeric literal, its a literal Number object and you can do stuff like:
(42.1).toFixed(1)

Objects can have a constructor function.

Again this is similar but not ths same as Java.

In fact the truth is that JS is a "new" operator that will create a new "plain" object and then pass it to the function you give it as the argument to "new", calling that function with the newly created object as its context (which just means the newly created object is set to "this" for the function call)
So a line of JS like this:


var me = new Person();

in psuedo code is something like:

make a new object
call a function named "Person" with the "this" reference set to the new object
set the prototype property of the new object to point to the Person function object
assign the new object to the variable "me"

So really there is nothing special about the function Rectangle except that we have written it with a view to using as a constructor but any function object can be called as an argument to the new operator - its just that it only makes sense for those that actually do something useful with their "this" reference - like initialising some properties, eg:


function Rectangle (firstName, lastName) {
this.firstName = firstName;
this.lastName = lastName;
}

Global variable are really just properties of the Global object

This might sound liek a minor point, but it actually matters alot when we get to discussing scope in a minute because the global object is responsible for the global scope.

Functions can have local variables.

This might seem like a no brainer but its interesting because local variables are actually properties of a special object called the "call object" which is passed to every function when its called. In fact function parameters are also properties of this call object. Hmm, elegant but nothing special right, well lets get to the next bit...

Functions have lexical scope.

Lexical scope? what the?
Lexical scope just means scope of where functions are defined, not where they are called. Ok that doesn't help much, so maybe this will:

Remember that call object I just talked about? well its actually the start of a "chain" (ie. ordered list) of objects that gets passed to a function to set its scope. So when you try to reference a variable in a function, JS looks through this chain to find the variable you are referring to. So what other objects are in this chain after the call object? Well its all the previous call objects.
So for a function defined in the global scope, its just the Global object.
And for a function called from with another function its just the Global object! That's right, because as I said at the start, lexical scope is about where the function is defined not where its called from. This means that this magic "scope chain" is set-up when the JS interpreter sees the definition of a function and is not changed when a function is actually called somewhere down the track!
Which brings us to:

Function can be defined within other functions.

Now things can get a bit interesting with lexical scope. Because when you define a function inside another function, the inner function has in it the call object of the containing function. And so now the scop e chain of the inner function has its call object, the containing functions call object and then the global object (and so on if you have mor then 1 level of nesting). And remember this happens at function "definition time" not function execution time.
Well see if this helps:


function a() {
var x = 2;

  function b() {
       var y = 3;
       return y +  2;
  }
return  b;
}

var func = a();

a = null;


alert("The answer is:"+ func());

Whack that in a html page and what do you think you will get? Yep 5! But stop and think about it for a second - b() is defined inside a() but it uses a property belonging to a when its called in the alert box after a() has already returned and after we set a to null, so it not even defined in the global scope any more !
But if you remember that b()'s scope chain is setup at "definition time" it all makes perfect sense! Since at definition time b() got a()'s call object added to its scope chain (which contains the property/value "x = 2") and it keeps that scope chain forever (or at least til we reload the web page :-)
Now to finish off belabouring this point, keep in mind that the objects in the scope chain (for the most part) are just JS objects. So for instance there's no reason why we can't change the values of their properties, say by using var x as a counter...


function a() {
var x = 0;

  function b() {
   return x++;
  }
return  b;
}

var func = a();
a = null;
alert("The first answer is:"+ func());
alert("The second answer is:"+ func());

So essentially var x in the call object of b()'s scope change is a lone "relic" of a()'s existence when the definition of b() was first processed but because all references to a() function object are gone, the x that b() is seeing in its scope chain is its own "private" variable, which brings us to:

Functions are closures

Which as we now now, simply means functions are not only data, but are "self-contained" keeping the scope they had when they were defined not matter what happens afterwards during the execution of the code.

Because functions are actually objects they can themselves have properties.

An important example of this is the "special" prototype property I mentioned earlier that all objects get. When a new object is created, its prototype property is set to the prototype property of the "constructor" function object. And the prototype property of a function is usually initialised by JS to a plain, empty object. However you can then set anything you like on it:


function Person() {
...
}

mrJS = new Person("Brendan", "Eich");

Person.fullName = function() { return (this.firstName+" "+this.lastName);}

alert("JS Creator: "+mrJS.fullName());

Yep you read that right, since JS looks up property names it can't find in the current object, in the object assigned to its prototype property (and then if it can't find it there, in its prototype object, and so on) and at the time the property is used, you can assign properties to a prototype and all the objects which reference that object as their prototype will see the new property.

There are some handy predefined objects, with handy methods: eg. Date, Math

You don't get anything like Java's rich class library in JS, but there are quite a few handy methods in these objects which are defined by default in the global scope.
And since JS is intended to be used as an embedded scripting language its assumed that the host environment (eg, web-browser, web-server) will provide the required objects with lots of useful methods defined.

Well that's about it for quick run through, of course there's lots more and the best place to find it is the JS book, with the big rhino on the front.

(Helma + H2) == "to easy"

2007-05-11T11:27:00.000+10:00

So I'd come across H2, the pure java sql rdbms engine written by Thomas Mueller (the original author of hsqldb) and had been menaing to give it a go, but never got past just firing it up and having a few quick clicks in the webbrowser based admin (which was pretty impressive all by itself!)
But then the other day I was working on the windows partition of my laptop and needed a db for a Helma app and couldn't be bothered downloading and installing the current win32 mysql package so decided to see if I could quickly get up and running with H2 instead. I was also thinking it would be good to have a quick and easy DB for a rapid prototyping and in memory db for testing of my helma webapps, so it was all worth spending a little time on and if it didn't work out I could always go through installing mysql.

But boy did it work out. H2 is a fantastic app, with alot of thought put into it. Not only is it easy to get up and running, but its very well documented and has a a lot of nice features such as a batch file that not only starts the dbserver running with web-console enabled, but also puts a little icon in your system tray and opens up a new browser window all ready for you to login!
The experience gets even better once you login with a nice ui that includes sql syntax auto-completion, history AND unbelievably editable tables of results! This puts to shame many of the dedicated java/native sql clients I've used in the past.

And what about using it with helma? (the whole point of the exercise), well that was a piece of cake, just drop the h2.jar into helmas lib/ext folder, restart helma, pop the connection details into my applications db.properties and hey presto!

But you want more? well for just $0 more, you get the full DB *embedded* inside your helma server.
Yep that's right, since H2 has an "embedded" as well as client/server mode, all you need to do is shutdown the H2 server (right click on the systray icon), change the connection URL in your helma apps db.properties from say:

jdbc:h2:tcp://localhost/col

TO:

jdbc:h2:/data/h2/col

and bam! your H2 db is now running in the same JVM process as helma (very handy on a cheap, strapped for RAM webserver for example).

But wait there's more! Yes how would you like to still have that nice web interface into the embedded DB? not possible you say, since now H2 is not running in a separate JVM - but in fact the H2 docs tell you exactly what to do[1], you just need to fire up H2's webserver when your app starts, so in your apps Global folder:
functions.js:

function onStart() {
 writeln("H2 web server started by"+app.name);
 app.data.h2WebServer = Packages.org.h2.tools.Server.createWebServer(null);
 app.data.h2WebServer.start();
}

function onStop() {
 writeln("H2 web server stopped by"+app.name);
 app.data.h2WebServer.stop();
}

Then in your browser, goto http://localhost:8082/ and there's H2's web console waiting for you admin-ing pleasure!

If you've got more then 1 app in your helma server, you won't want to start a new h2 webserver for each one, so in that case just make a new empty helma app, call it maybe h2admin, pop the above code in there and your done[2].

Now that's what I call RAD!
I wonder if the rails crowd will even believe me without a funky screencast demo...

[1] Well actually the H2 docs tell you about how to fire up a DB in a servlet to be accessed by multiple webapps in the same tomcat container, but with a bit of lateral thinking and a quick look at h2.bat I got the idea.

[2] Of course this way H2 is running its own webserver alongside helma's one and I a nice future project would be to 'port' the admin web ui to be a helma app :-)

Update: I'm now confident (crazy?) enough to use this on the test server, but by default the H2 web console won't accept connections for machines other than localhost, so to get this to work you need to use this code instead:

function onStart() {
   writeln("H2 web server started by "+app.name);
   var args = java.lang.reflect.Array.newInstance(java.lang.String, 2);
   args[0] = "-webAllowOthers";
   args[1] = "true";
   app.data.h2WebServer = Packages.org.h2.tools.Server.createWebServer(args);
   app.data.h2WebServer.start();
}

Maks' guide to LDAP for Busy Java developers

2007-01-05T09:26:00.000+11:00

So maybe like me, you're a busy java webapp developer (isn't everybody these days?) who just got told/decided for yourself that instead of creating yet another app for which users need to remember a username/password pair, that you will instead do the Right Thing and connect up to your company/organisations central LDAP (or ActiveDirectory) .
And (again like me) you might even need to have cause to setup your own LDAP server either for testing or some other reasons you can't use the existing AD setup in your org.
So instead of replicating the tedious hours of frustration that I've spent - let me give you a quick run down of the pertinent facts you need to get up and running.

First the obligatory intro to LDAP:
its basically a tree of objects. Each object belongs to 1 or more "classes". Classes are just sets of compulsory and optional attributes. Attributes a just name-value pairs (think java properties files).

So getting a bit more specific, if you have a person class that has the compulsory attributes "firstname" and "lastname" and then another class called orgPerson that has a compulsory attribute "email" then you can have an object that has "belongs" to both classes and so will always have a firstname, lastname and email.
eg.

firstname: homer
lastname: simpson
email: hsimpson@springfield.com

Of course the above classes (and attributes) are made up, but are pretty close to the real thing, as in LDAP you can have any class you like, all you need to do is define a schema for it (just like with relational DBs really). Handily, most LDAP server implementations seem to come with a whole bunch of predefined classes (not sure if they are actually a standard or just convention) for users, groups, etc.

Now the whole tree bit is just as easy, its basically just made up of objects (usually belonging to specific 'container' style classes) forming, well, a tree. Now 'container' style classes are ones such as "o" (organisation), "ou" (organizational unit), etc. There is also "dc" which is normally used when creating a tree based on DNS names (eg. www.springfield.com)

Now the only slightly wierd thing about LDAP is the way the naming syntax works, its all about commas. So to say the homer belongs to the staff group at the springfield site of the bruns power company you would write:
uid=homer, ou=users, ou=springfield, o=burnspower

this is assuming that the homer object has am attribute called "uid" that identifies it (its "Relative Distinguished Name" in LDAP speak) and that you've already defined the "users", "springfield" and "burnspower" org units and org respectively. And how would you do that, well you could use a LDAP GUI tool to connect to your LDAP server or write ldif files (which are basically serialised text versions of parts of the LDAP directory tree) to define them,
eg.

dn: o=burnspower
objectClass: top
objectClass: organization
o: burnspower

dn: ou=springfield,o=burnspower
objectClass: top
objectClass: organizationalUnit
ou: springfield

dn: ou=users, ou=springfield,o=burnspower
objectClass: top
objectClass: organizationalUnit
ou: users

As you can see, you just define each object one after the other, and with the "dn" (Distinguished Name") you set the "path" of the object in the tree, just like you would if you were creating a series of nested folders on your PCs filesystem.

Now this brings us nicely to doing some real work, like actually setting up the LDAP server. Basically while there are a few different commercial and open source LDAP servers out there, basically ignore all the rest and use OpenLDAP. Even though it might me slow and chunky, it is the lest painful way to go if you've just got a linux box and not much time or patience.
Often OpenLDAP will be part of the default OS install or just a few clicks/commands away using your package manager of choice.
Once you do have it installed and configured (for OpenLDAP usually just means setting a couple of options in the /etc/openldap/slapd.conf), use something like the above ldif files to set up your basic directory structure and then you can just go start plonking your users in there (again using wither ldif files or via GUI) . The main thing you need to decide is what class(es) you want to use for your user objects - for myself I've found inetOrgPerson had all the attributes I needed.
eg.

dn: uid=homer ou=users, ou=springfield, o=burnspower
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Homer Simpson
displayName: HomerSimpson
givenName: Homer
mail: homer.simpson@burnspower.com
mobile: 122 333 4567
sn: Simpson
uid: homer
userPassword:: adlr0912384nq4o358ndfadasl

Note1: the user has both the inetOrgPerson and organizationalPerson classes in a kinda inheritance way to pickup all the attributes we want to use.

Note2: the above userPassword attribute is how my gui ldap browser exported the ldif file, but I suspect that the correct way to specify them (for OpenLDAP) at least is:
{CRYPT}AF387HED3SDA

Note3: all the above password binaries are just random typing on my part and so dont match :-)

Setting up groups is also pretty straight forward, the 2 handy classes you want are groupOfNames and groupOfUniqueNames. Note that both have attributes which let you specify the members of the group by having multiple instances of that attribute,
eg.

dn: cn= Managers,ou=groups,ou=springfield,o=burnspower
objectClass: groupOfUniqueNames
objectClass: top
cn: Managers
description: the bosses
uniqueMember: uid=monty, ou=users, ou=springfield, o=burnspower
uniqueMember: uid=smithers, ou=users, ou=springfield, o=burnspower

And that about covers it from the LDAP side of things.

Now we can actually get to the java side and setup a single authentication service.
Basically LDAP has lots of different ways to do authentication, most of which seem very complicated and are definitely overkill my mine and most small installs, so I'll just stick to the simple ones:

Method 1.
First of you need to know that in LDAP-speak logging into to an LDAP server is called 'binding'. When you "bind" to the server, you can do it as a particular user as long as you specify the users "DN" as the login.
You also give the password and the LDAP server goes looking for the password attribute for the object given you specified in the DN (eg. uid=homer ou=users, ou=springfield, o=burnspower) and if the bind is successful you know the user is authenticated and hooray, you're done! Once you have bound to the server, you can then also grab all the users details (email, lastname, whatever) using the supplied DN to lookup the user object for yourself.

Method 2.
Another way to do it is to use an "admin" users login to bind to the LDAP server, fetch the user object for the given DN and then compare the password attribute in your app code. You might want to do this for instance if you need to check which groups a user belongs to but the user themselves dont have permission to access the groups part of the directory tree (I forget to mention that you can set permissions for users to read/write (or not) any part of the tree - again just like you do with a filesystem). So you bind to the LDAP server as an 'admin' user which does have permission to go looking up the groups (or whatever) part of the directory tree.

Security Side Note:
One thing should point at this stage is that while the LDAP protocol itself is binary (bit wierd to find that out in this age of internet text protocols - at least its defined in some RFCs) its still all sent in the clear, so the usual modius operandi is to do all the LDAP connections over SSL so that people don't go snooping on your passwords in the net traffic.

Anyway, now that we've covered the connecting to server and authenticating theory, the actual java code (for method 1) is a walk in the park:

 
     public boolean authenticate(String username, String password) {

     String userSuffix = ",ou=users,ou=springfield ,o=burnspower";
     String userRDNPrefix = "uid=";
 
     String hostname = "ldap.burnspower.com";
      String port = "389";

     String userRDN = userRDNPrefix+username;
 

     Hashtable env = new Hashtable();
     env.put(Context.INITIAL_CONTEXT_FACTORY,
         "com.sun.jndi.ldap.LdapCtxFactory");
     env.put(Context.PROVIDER_URL, "ldap://"+hostname+":"+port+"/");

     env.put(Context.SECURITY_AUTHENTICATION, "simple");
     env.put(Context.SECURITY_PRINCIPAL, userRDN+userSuffix);
     env.put(Context.SECURITY_CREDENTIALS, password);

     // Create the initial context
     try {
         DirContext ctx = new InitialDirContext(env);
     } catch (AuthenticationException ae) {
         System.out.println("Invalid Login");
         return false;
     } catch (NamingException e) {
         e.printStackTrace();
         return false;
     }
     return true;
 }

And voila! one less set of passswords for your users to remember.

top 10 reasons I dont use rails

2006-12-01T11:19:00.000+11:00

So after a very nice dinner catching up with an old friend, I got asked why don't I use rails for my next webapp project. I replied about how I keep meaning to learn rails (and even bought a book to read) but that I'm more comfortable sticking to helma (the javascript-based app server framework I'm using).
But this got me thinking, apart from my inherent laziness, why aren't I using rails?
Well heres my top 10 reasons after a bit more thinking about it:

helma is implemented on top of a standard java servlet container (Jetty) so I get to reuse all my existing j2ee knowledge/experience and techniques (eg. mod_jk connector to apache)
it uses standard java technologies (eg. JDBC) so again same as above
it can directly and very easily use any java library and at this point, its arguable java has surpassed even C as the library lingua-franca, especially for things you do for webdev
Using Java libraries means if something goes wrong I get a java exception trace which is helpful (since I mainly use oss java libs which come with source) unlike the less helpful: "Segmentation Fault" that you would get with using C libs with rails
Another thing about being able to use Java libs is that its really easy to write my own, wrap up/modify existing ones, etc. which I definitely can't do with C libs (my C coding days are a long way behind me)
I only need learn 1 new language for both the client and server side programming tasks. Its arguable the Ruby is a nicer/better lang then JS but JSs simplicity really appeals to me (warts & all)
While they are hardly alike (except for having a common first name) I find javascript syntax at least close enough to javas' to feel quite comfortable and not get a mental 'jarring' that happens every time I try to read ruby code
JS is also becoming a very popular language and while ruby isn't exactly hard to learn for java programmers, JS is certainly better for me at my current work where the only other tech people are web designers with only JS or AS (actionscript) knowledge
performance with helma is excellent, especially with jetty and the rhino JS engine that uses "under the hood" and the memory footprint is excellant too. Now I've only heard here say about rails (rubys) poor performance but thats enough to put me off, especially since with helma I know I can always fall back on using standard java profiling tools and optimising the frameworks underlying code (got know chance to do that with rails ruby interpreter written in C)
Even though its not the "out of the box" templating system, I can use Velocity templates with helma in a fairly nice way (and its such a simple integration that I've taken over maintaining it from the original author and have stated adding some small enhancments of my own). As far as I understand, rails goes down the whole nasty "code in pages" road (ala JSP) and that leads to no place I want to be.

well they aren't really in any particular order of importance but for me they are pretty compelling reasons to stick with helma and only read a rails book in my (very limited) spare time.
now there are downside compared wit what I already know about rails:

no scaffolding
no builtin unit testing
no builtin support for db migrations

but so far none of these are deal breakser for me and in fact I'm slowly working on adding those features to helma myself.
And another one of the down sides to using helma vs rails is the huge community (comprised of a fair few j2ee refugees) that has sprung up around rails. I certainly don't feel the need for that with helma but I think it would be nice not to be off on my own little island - so I'm finally going to set aside a bit of time and write up a short series of helma "intro" articles here - which if they work out ok, might even form the basis of a nice little book: 'server side js: web development with helma" :-)

Better fonts in Ubuntu - full stop

2006-10-05T22:42:00.000+10:00

Now I'm the first to admit I dont have the best eye sight in the world, but ever since i started using ubuntu and even going back to the days I was using fedora even I've noticed that the fonts in Gnome have always been "fuzzier" and looked worse then similiar sized fonts in windows XP. This has been very clear on my laptop where LCD subpixel rendering makes a difference.

Today I finally got really sick of them and despite all the posts on various blogs and forums going on about how its just peoples imaginations and fonts on Ubuntu/linux/gnoe really do look better then winXP or that its just a matter of twiddling with the Gnome font settings I just went ahead and installed 3 packages based on some recent pathces to the releavant libaries. I found the deb packages here
and thanks to this very nice person my fonts finally look decent in ubuntu (gnome). At last!

Now I just need to figure out how to make patched debs based on ubuntu's latest sources since the update manager now keeps trying to replace the versions I just installed with "newer" packages which of course don't have the patches and rtunr my destop to it former ugliness.

sad, sad world

2006-10-02T22:23:00.000+10:00

So I just finished reading a very interesting article about the building of squeak - an implementation of the smalltalk language. One of the key points of the article I thought was that the authors got a big productivity boost by actually writing the squesk vm in smalltalk (or actually a subset of it). And then they converted into C for compiling to get good performance. Which is fair enough, I reckon C seems to be a more popular byte-code the JVM or CLR byte codes :-)
No lets have a look at the Java world, as far as I know, out of all the JVM out there, there's a grand total of 1 that is actually written in Java. But even then, JikesVM is a nightmare to build with wierd dependencies and some kind of code-generation in the build too. Can anyone even tell me why they ned code generation for a VM? Ok it is meant as a research VM rather then a production one, but I havn't heard of any of the C-based JVMs doing this.
So anyways, obviously all the Java community believes in Java being a superior language that they all went and wrote their VMs in...C!
Now Im not sure how the mono crowd do with their VM, but at least their new VB compiler is self hosting as is their C# compiler.
Of course their is some hope, may OSS projects are now switching to using Eclipses Java compiler which is written in Java.
But no decent small JVM in Java along the lines of JamVM.
And then theres the lovely monolithic gnu classpath. Which must be credited with doing well to implement the now enormous "standard" java class library but is about as modular as a obelisk and weighing in at around 8MB!! is hardly light-weight let alone suitable for use in embedded or small device applications. Even worse it is absolutely riddled with native code dependancies, which while good for quickly implementing the huge Sun-created APIs does not exactly make it easy to port.
Now you might be expecting me to say that I've had enough and am just going to write my own - well I would if I had a bit more time, but for now I'm just going to put up with it all and see if I can just get JamVM up and running nicely on my 770 but if I get really adventerous I might even try cutting classpath down to a proper (J2ME CLDC 1.1) size.
On the other han, my love affair with javascript script continues and I note there are no self-hosting implementations of it either...

a dapper world

2006-06-14T22:38:00.000+10:00

well now that dapper has gone final (aka Ubuntu version 6.06 has been released) I've installed it on my laptop. Unfortunately I've been too busy to test the beta's or 'flight' versions hat have been released during it development cycle so I have only myself to blame that I need to use the following work around to get suspend working (found on this blog entry):

One thing about sleep: vbetool needs to save and restore your video state in order to have working video on resume. Currently, on Macbooks this is broken. This is caused by a mistake: the vbesave init script comes before the acpi init script. This means that laptop-detect will report to vbesave that you are not on a laptop and vbesave will not save your vbestate. Matthew Garrett is working on a fix, but in the mean time a workaround is to edit /usr/sbin/laptop-detect and insert a line 'exit 0' right after the #!/bin/sh (always report that we're a laptop).

Not pretty, but since I'm pretty sure my laptop should infact be running inlaptop mode, I think its ok for now.

also to get my funky special acer keys to work (especially the little flashing "you've got mail" light) I needed to do the following:
$ sudo -s
# echo "acerhk" >> /etc/modules
# exit

Well, at least its supposed too. My keys work, but no flashing light yet...

[Update] Bah, dont know whta happened at first, but a reboot later and my you-have-mail blinken light is going strong once more.
Now I just need to figure out how to get my new rt2500 wifi card working with NetworkManager, but thats a story for another day...

fight the future

2006-06-02T11:16:00.000+10:00

According Javascripts creator (Brendan Eich) blog this is the future of JS:
http://developer.mozilla.org/presentations/xtech2006/javascript/

Well if thats the future JS, I'm buying a tardis and staying in the past.
I'm definitely in the camp that would like to have the current bugs fixed but have the core language left well alone.
To explain why I think this way, I should give some background:
I've been a Java programmer (mainly J2EE) for the last 6 odd years and its only recently (triggered by all the ajax hype and being sick of the huge bloated ediface that J2EE has become) that I've taken the time to learn Javascript and discovered what a wonderful little language it is. And I use "little" in a very positive sense, its one of the things that really attracted me to it, unlike much more complex languages like Java or even complex scripting languages (perl, python).
Infact I'm now so firmly on the JS bandwagon using it not only for browser client-side work, but also server side via the brillant Helma Webapp framework/server.
Having now done close to 5 months of solid JS server side development, including almost work on over a dozen small apps (2 already in production use) I really am appreciating the power of using a scripting language to do web development "in the small" as well as the simpliticity and yes, elegance of JS.
Now of course there is no reason why I can't just stick with the current javascript "1" for my server-side coding even if Mozilla and others push ahead with JS2, but one of the other big reasons I like using JS is that I now only need to use 1 language for both server and client side coding (with only the occasional drop into Java for a bugfix or using a 3rd party lib, since Helma is written in Java).
Now the above are all just personal reasons for leaving JS as is, but here is a more pragmatic one:
for good or bad, I belive a lot of JS's popularity comes from its small size and simplicity, its an easy language to learn and use, yet is still powerful and flexible enough to handle a amazing variety of tasks.
But its still a scripting language and as such it should not be used where its not the best solution - "programming in the large" is one such place scripting languages do not belong. For that is why we have Java and with Rhino we can have the best of both worlds, using each language for the tasks that suit it best. Making JS2 a 'a Java/Python lite" and trying to get it to work for programming in the large is just not going to work, what you will get is a new language which will no longer be suitable for the quick, simple programming "in the small" tasks that its used for now.
Of course I doubt this little rant and others like it will have any effect on stopping JS2, since it seems that its being strongly pushed by Brendan and alot of the big powers in the web browser world, but you never acheive anything without trying...

the little things

2006-06-01T09:15:00.000+10:00

here's something I learnt the hard way a couple days ago and thought I'd better put it here so I don't forget it next time:
Javascript event handlers (eg. onclick) execute a whole block of javascript, not just necessarily 1 statement. This is easy to forget if all you are doing is calling a function (eg. verifyDelete()) and want to use the return value of the functions as return value of the event handler ( because if you give a event handler a return value of 'false' it won't execute the action it was called on - ie. a lcik on a link won't actually cause the browser to load that link).

Thus, this doesn't work:

<a href="delete" onclick="verifyDelete();"> Delete Me </a>

while this does:

<a href="delete" onclick="return verifyDelete();"> Delete Me </a>

Yes the return statement is important, since even though I'm doing just one function call in the onlcik handler definition, I could quite as easily have written 100 statements (seperated by semicolons) so without the return thres no way for the onlcik handler to know what the return value from my block of code is.

email the hard way

2006-04-30T14:28:00.000+10:00

So I needed email server (MTA) capability for a feature on the personal project I'm working on.
I figured that I had a few choices:
- use sendmail (default on linux) or one of its alternatives (postfix, exim, etc)
- use a different thirdparty MTA, preferably a Java-based one
- use a "managed service" like fastmail, who I already use very happily for my inbox/IMAP

Fastmail would probably have been the easiest path, but I decided I might want to have more control and my VPS service gives me a much bigger bandwith allocation then fastmail would. Having decided o do it myself, I was very hesitant to use the notorious sendmail (its just scary to be able to write a book of hundreds pages long about an app that does a relatively simple job) or even its supposed 'simplier' alternatives like postfix, so I hunted around for a simple Java based one and found James (from apache) ZeroToaster, a cheap commercial java app and JES, pretty much the same thing, but open source.

So I of course went with JES and the initial out-of-the-box experience was excellant, 30 min & I was up and running send/receiving emails, and that included changing my DNS MX records.

Unfortunately after running it for a few hours it got into a nasty loop of repeatedly throwing an exception trying to deliver a malformed email it received (yes I had spam start coming in within minutes! of starting it up).
But this is where the power of oss does shine, being a nice simple app (the reason I avoided James like the plague) I grabbed the src-code zip, found the offeneding code and added some code to put aside malformed emails and fixed a null pointer bug in the shutdown code for good measure!

So probably for less tha a couple of hours of work I now have a working light MTA, with just enough features that I need and a resoanble confidence that I can fix other problems that might turn up. The only downside is that the sourceforge project for JES seems to have been abandoned for over a year, so for now I've just imported the code into my own subversion repo.

Still need to come up with a little wrapper to start it via rc script.
And I've found on JES's maillist that someones had success with compiling it with GCJ, with excellant results in terms of memory footprint and performance, so theres something else to look into.

[Update] Doh! Just found a patch on the sroucforge project page that fixes the problem I found with malformed emails (actually bounce mails with an empty address).

D.I.Y.

2006-04-25T17:13:00.000+10:00

So, I finally admitted that I don't have time to whip up even a quick personal blogging app, especially since I wanted to document it as I went, along the lines of the 15min blog app screencast that the rails crowd has on their website.

So I decided that if I was going to use a ready made blog app, rather than doing it myself, I'd at least try to go the whole web app route and rather than installing an app on my laptop or on my server, I'd use a web service style app and decided to try Google's Blogger, since I remembered it has the option of publishing to your web server and not just using their website.
Well so far, (its only my first post) so far, so good: all I had to do was create a directory in my public html directory on my server, plugged-in my sftp login and all done. I did have one hiccup when I changed the ftp path but didn't realise I also needed to change the 'archive' path, but apart from that its a nice looking, clean, easy to use interface.

I still plan to make my own blog app when I get a bit more spare time, but for now Blogger looks good and I can keep working on my current project (more details on that soon) and have somewhere to write my thoughts on it.

PS. Oh and just found it has a very nice spell checke, but one which ironically doesn't recognise words like 'Blogger' and 'blog' and no well to choose British over US spelling, but oh well no one can be perfect - I'm still very happy with it, well done Blogger & Google.