Feel Love for the Google Web Toolkit

The Google Web Toolkit (GWT for short) is unlike any other AJAX Api you’ve seen to date. GWT is nothing new to the world, it was introduced ages ago, and yet I’m supprised by the seemingly slow uptake of this amazing toolkit. Unlike DOJO, jMaki and co, GWT doesn’t even need you to code HTML! Thats right, no JavaScript, no HTML. So how does GWT work?

GWT is actually a Java compiler. Normally your Java compiler takes you Java source-code and spits out Java byte-code, GWT’s compiler however takes you Java source-code and spits out JavaScript. So you code your application using the lovely (really really nice) GWT Api’s, and run it through their compiler, and you’ve got a 100% cross-browser web-application. They include classes for all the standard HTML forum components; AJAX calls back to the server; and some extra Widgets like a Tree, Tab panel, Dialog or Popup DIV; and even an XML parser.

I’m working on a system that uses XML and XSLT heavily, the fact that I can have the browser construct the entire XML document and send it to me when the user is done with it makes a huge difference. All my servlet has to do with the XML is run it through a parser with validation enabled.

Code at runtime in Java 5/6

One of the great features added in Java 5 was annotations. The meta data carried by annotations can be processed by the Annotation Processing Tool (apt), to generate new classes, more code or even data files (like Hibernate mapping files and such). However, annotations can also be stored in the byte codes and reflected at runtime. This becomes a truly amazing feature when you combine it with the Proxy class that was added in Java 1.2. How so? Imagine you create an interface with a bunch of methods, annotate them with what you want them to do, and then an API can generate an implementation for you, at runtime! The really awesome part of this thing? You won’t be generating any byte codes, it’s all done for you!

This is in fact, exactly how EoD SQL works. You annotate a method with your database queries (SELECT, INSERT, UPDATE, DELETE, etc), and it generates an implementation for you with it’s QueryTool class. So, how do you do it? Its actually really really easy.

EoD SQL 0.8-beta Released

After quite a long wait, EoD SQL 0.8-beta has been released. Why is 0.8-beta so special, because EoD SQL has grown up. 0.8-beta sees an API freeze in preparation for the big 1.0 release. The key features of the new release are:

• Full Transaction Support through the new TransactionQuery interface
  • Commit
  • Rollbacks
  • Savepoints
• Better support for SELECT COUNT/MAX/MIN/AVG queries using the new @SelectPrimitive annotation

EoD SQL 0.8-beta also includes some important bug fixes and workarounds for Commons-Pooling and databases that don’t play nicely with JDBC.

Making AJAX faster, smaller, more compatible

Two major problems I’ve faced when writing AJAX web-applications are (1) data size, and (2) browser compatibility. The fact is that it’s a hell of a lot easier to have a page fragment come over the connection to you, rather than a DOM which you then have to convert to HTML. However, this approach pushes a lot more data across the connection than is necessary. I know, why should I be worried about a few extra K online; most browsers can handle a GZIP stream, etc. etc. etc. Well the fact is most sites don’t use the fact that their clients can handle compressed data, they just send large lumps of bits back to the browsers, over, and over, and over again. Sure bandwidth is mostly cheap, but the fact is, pushing to much data is just a waste.

Where am I heading with this? I still haven’t touched on browser compatibility. It’s not JavaScript compatibility I’m talking about either, it’s HTML compatibility. Anyone developing a web-site faces this problem. Well, I’ve found a (sort of) solution to both problems. It’s a Google Code project called ajaxslt, and it’s an implementation of XSLT in JavaScript. So you specify some XSLT sheets to transform the XML that you send of the network. Much neater!

Breaking the spam chain

Chain letters are a form of spam. It’s really as simple as that. I know so many people who forward these emails on, and all they’re doing is helping spread spam. We jail spammers, fine them, and yet people continue to send these emails. Most people think that spam is just some sort of by-product of the internet, just like viruses are. Let me tell you that neither viruses, nor spam just come out of no-where. They are created and send by human beings (or in most cases software written by human beings). These are not “glitches” in code, they are systems designed specifically for one purpose: take your money away from you. It’s robbery, plain and simple, and by forwarding chain letters, you are contributing to this mess.

One of the most popular phrases I read in these things is, “Microsoft is tracking this email and will donate….” (Microsoft is sometimes AOL, or some other Big Computer Company^tm). The fact is: email is untraceable. No one will donate the money. It’s spam, or worse. In some (growing number) of cases, the images, and/or hidden code within the email caries a computer virus. So by forwarding this email to 10 of your closest friends, you’re sending them a virus for their computers as well.

Don’t forward chain email, emails warning you about gangs, hijackings, or computer viruses. Not from your closest friends, and certainly not to them.
You are not helping them!

EoD SQL – Getting Ready for 1.0

Wow… I never thought I’d actually say it, but thanks to a lot of prompting from a few people: EoD SQL will be moving to 1.0 in a month or two. I know it’s early to say that now, but I’ve now got a roadmap and plan for where it’s going to go. To explain in further detail:

• A 0.8-beta release will be made with some bug fixes, and important new features
  •  The internal workaround against a bug in commons-dbpool will be included
  • QueryTool.createQueryImplementation is deprecated and will be replaced by “getQuery”
  • Full transaction support will be added (commits, rollbacks and savepoints) through a new TransactionQuery interface
  • Support for “SELECT COUNT” style queries will be added through a new @SelectPrimitive annotation
• An API freeze will take effect directly after the release of 0.8-beta, the only code changes will be bug fixes
• Once I am confident that the API is as bug free as I can make it, 1.0 will be released
• The 1.0 release will include:
  • A new tutorial (more quick-start like), it probably won’t be written by me
  • A new ant script (do away with the Netbeans ant script dependency)
  • Unit tests will work on an embedded (in-memory) database
  • Some examples of how EoD SQL can be used

I was thinking in the night, and I realized that EoD SQL’s massive advantage is not it’s size or tiny overhead. It’s the simplicity, it helps you do the really horrible drudge-work of mapping your ResultSet’s to POJO’s. It’ll never be a Hibernate or JDO or TopLink, and thats exactly the way I want it. Those tools are great, but they’re far to heavy for my liking.

If I were to choose my favorite feature of EoD SQL, it would be the rubber-stamping DataIterators, they are so fast and lightweight, you just have to love them 😛

Linux is ready for mainstream use, get over it!

Instead of hearing it less and less, I seem to be hearing it more: “Linux is to hard”, “Linux is not desktop friendly”. It’s probably all the talk of Vista, and all those trying it out and comparing their 10+ years of windows use to a week with Linux (sometimes no more than a half-baked attempt at installing a distro). Quite frankly guys, Linux is desktop ready. Not only my parents, but my parents-in-law and grand-parents run Linux. I know schools that have installed Linux, and their kids find Windows more difficult to work with. It’s a question of what you’re used to. If you don’t know that distro’s like Suse and Mandriva have wonderful hardware config tools, and you wind up re-compiling your kernel to install some weird wireless card that is supported through NdisWrapper, then shame on you.

I’m not of the opinion that Linux will one day be on every desktop on the planet. Nor am I the type that starts frothing at the mouth when they hear the word “Microsoft” (though I do know a few like that :P), what I’m saying here is simply: don’t dismiss Linux because you tried to install Ubuntu. Ubuntu is a heavily purest version of Linux (very VERY GPL based). Rather try something like Suse of Mandriva that includes things like you NVidia drivers and Flash.

flightwish.com update… again

This is gonna sound like real marketing rubbish, but: due to unforeseen circumstances, flightwish.com will not be launched early February as hoped.

Now for the explanation: we had a short review meeting of what had have done so far for flightwish.com, and realized that what we were working towards was not what we have now 😦 . So the short review meeting became two days of brainstorming how we should go about getting the site back on track. We’ve begun the rather large task of reworking the system, but at the same time as I am working on another project, so things are taking a bit longer than we thought.

I personally hope to launch the site later this month, or very early March at the latest. Sorry for the delay folks.

Rollback your app?

I was driving to the doc earlier today, and a thought struck me while thinking about programming languages and medical systems. I have several friends and relatives that work “in medicine” (a doctor; an anesthetist; a dietitian; and even an ambulance driver). I was thinking about the way the language you program in has a direct link to how stable and “safe” your code is. If I code something in Java and C++, I know that the C++ code will be faster (most of the time), but I will always be less sure of it, C++ doesn’t deal with failure nearly as well as Java does (mostly because Java has a nice big VM underneath it).

So the thought was this: transactions in you language. So I can set a save-point, open and close transactions, commit and rollback bits of memory and disk, as a language feature. It would make dealing with failure a lot easier, since you could say “attempt this transaction 3 times, delay 500ms between each attempt, if they all fail, do xyz”, instead of simply “try { … } catch(…) { … } finally { … }”.

Java’s try, catch, (and most importantly) finally, is really really awesome and all, but transactions mean that if the code fails, you don’t have to worry about where it failed, so theres less or no cleanup. Anyways… just an idea 😉