Evan Summers's Blog

Evan Summers studied mechanical engineering for 8 years, but still didn't know which way to turn a screw driver. So he tinkered with Java, and eventually found "that Swing." Now he lives in a shelter for Swing code junkies, and works on aptframework.dev.java.net.

A short history of Web UI programming

Web 1.0, XUL, Ajax, Laszlo, Flex and Silverlight have a common approach - declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI. JavaFX/Swing is a notable exception - which is exciting and/or risky?! 'Cos Web developers know and love JavaScript and HTML, so XML plus JavaScript is right up their alley.

If you're a Java UI programmer, there's GWT, Wicket and Echo. And with a great new Java plugin in the works, maybe Swing applets will be considered again in some quarters? But all web developers know JavaScript, and not necessarily Java, Groovy, et al, so probably JavaScript/Swing is a better bet than Java/Swing? Imagine having an XML schema for a flashy JavaFX/Swing toolkit, call it JavaFXml, with great JavaScript bindings, so make that JavaScriptFXml ;)

Anyway, let's look at the short history of web programming...

HTML, CGI, Perl
The Web started with HTML. HTML forms could be submitted via a submit button. Apache's Common Gateway Interface (CGI) enabled server-side scripts to process the form data, and generate an HTML result page. Perl, being a popular scripting language at the time eg. with Linux system administrators, suddenly became the popular language for CGI scripts, and many "sysadmins" suddenly became "webmasters."

JavaScript, DHTML
Netscape invents JavaScript for client-side UI scripting in web browsers, "designed to be easier for non-programmers to work with." Microsoft adopts it too for IE, calling it JScript. So it becomes the de facto standard - the lingua franca of web designers everywhere. HTML plus CSS plus DOM plus JavaScript equals "Dynamic HTML" (DHTML). Web designers suddenly become "web developers."

Java Applets
While certainly suitable for experienced programmers, this was not so great for "web designers," despite promising books such as "Teach Yourself Programming, Java, AWT and Swing in 24 hours." Actually this stuff is not "for Dummies." Not to mention some technical issues with the plugin like startup time, browser crashes, download size, etcetera. So web developers stick with JavaScript, which they know and love, to do neat DHTML things on the client-side.

PHP
Web developers know HTML, some JavaScript for client-side scripting, and some Perl for server-side CGI scripts. PHP gives them embedded server-scripting in their HTML pages. Poifect! Web developers become hard-code PHP programmers.

Java JSPs, Servlets
Schools started teaching Java, and enterprises got Java programmers, and we started spreading our Java love across the internets and intranets. But the majority of the web developers are not gonna suddenly jump off the PHP bandwagon and onto the server-side Java supertanker, notwithstanding the availability of the above-mentioned books - because 21 days is quite a long time.

Flash
Woohoo, let's add animations, interactivity and multimedia to spice up web pages!

XUL
Fantastic technology - XML UI markup plus JavaScript logic - way ahead of its time! If IE hadn't taken over the world and crushed Netscape, then maybe XUL would have taken over the Web?!

Ajax
Let's load content asynchronously, without having to submit and reload the whole page, and script the UI using JavaScript as per usual. Poifect!

Laszlo
Great stuff, inspired by Flash and XUL. If it was opensourced earlier, and/or bought by Adobe and renamed to Flex, or bought by Sun and renamed to JavaScriptFX...

Flex
Inspired by Laszlo, and currently taking over the RIA world, athough the Web is still owned by DHTML/Ajax.

Silverlight
Ditto.

JavaFX
Too early to tell. How is it gonna be better than Flex and Silverlight? What JavaFX tools for web designers?

Summary

Everything from HTML, through to XUL, Ajax, Laszlo, Flex and Silverlight, have a common approach, namely let's declare the UI view using markup (HTML or XML), and use JavaScript to handle the UI events and manipulate the UI.

Given the predilection of web developers towards JavaScript and XML, one wonders if the JavaFX initiative shouldn't have embraced JavaScript with an XML thingymajig also, like Microsoft (XAML) and Adobe (MXML) chose to do, rather than introducing a new scripting language? 'Cos in any event, the visual aspects of an UI should be designed by designers, using a GUI builder tool, rather than programmed by a programmer?

With a great new Java plugin in the works, and other JavaFX-induced improvements for client-side Java, maybe Java/Swing applets will be the preferred option for many of the Java programmers out there, rather than moving to one of the available scripting languages on the JVM eg. JavaScript, Groovy, JRuby, JPython, JavaFX Script?

If we want JavaFX/Swing to succeed in the browser, surely we need a GUI tool to design those flashy UIs, generate XML, and be scriptable using JavaScript first, and otherwise Groovy, Java et al, for programmers that prefer those other JVM languages.

Further Reading

Taking a cue from the cutting-edge of EJB3/Seam programming, last week i wrote an article titled "Gooey MVnC" proposing a convention-over-configuration MVC framework for Swing GUIs - to eliminate boilerplate and glue code for beans binding, events and tasks. Everytime i revise that article, i might write a new blog entry, like this one, just so that i can link to it again, which is precisely the reason why i was inspired to write this blog entry!

MVnC architecture for Swing GUIs

Rather than put our "application logic" in a "messy" view class, we create a separate "controller" class, with event handlers.

We wish this controller class to be as neat and tidy as possible eg. with minimal boilerplate or much else besides our application logic.

Let's explore how we might achieve this, using an annotation-driven application framework, with some AOP and convention-over-configuration.

Please submit your comments and suggestions for discussion below. This is an ideas-in-progress, without an implementation (yet). As such this article should be considered to be a first exploratory draft of a design-in-progress...

Next month, i'll whip up some kinda prototype, if it's deemed worth it, and if i'm still unemployed ie. with time on my hands.

Code Snippet

Our controller class includes annotations in order to enable our framework infrastructure to automatically map events from our GUI components to event handler methods, and to support background tasks and EDT-switching via AOP.

public class LoginController extends GBasicController {
   @View LoginView view = new LoginView(); // JPanel with components
   @FormBean User user = new User(); // for form fields auto binding
   ...
   @BackgroundTask void fetchUsers() throws DatabaseException {
      ... // long running task
   }

   @BackgroundTaskDone void fetchUsersDone() {
      ... // update GUI with results from task
   }

   @EventHandler void okActionPerformed() {
      ... // handle OK button pressed
   }
   
   @EventHander void usernameEntered() throw DataException {
      ... // validate username exists in database
      view.password.requestFocusInWindow();
   }
   ...   
}

Annotations in our model beans, eg. User, relate to binding and validation, where we wish to support automatic binding of view components to bean properties, eg. by matching component names to bean property names.

First Class Java: further thoughts on dot notation for class metadata

Who knows why i have a dislike for symbols like ->, => and even := ?! It's pathological, i know that, and i have an obsessive-compulsive (dis)order when it comes to code, and so be it.

So in the previous posting in this series of reports on my pointless coffee shop doodlings, i suggested the likes of username.property to refer to a PropertyDescriptor eg. for the purpose of toolable bindings, where by "toolable" i mean auto-completable, machine-verifiable and safely refactorable, using an IDE. If nothing else, this conforms to the current notation vis-a-vis .class eg. Person.class.

Now i'm thinking @person.username.property or $person.username.property don't look too bad, although many others suggest person#username of course, citing JavaDoc's notations, which i say is like the tail wagging the dog, but so be it.

So what's the big idea? Actually there is no big idea - only a small incremental idea, which is... Let's enable code that is fully toolable, refactorable, et cetera. Which means no references to properties in string literals eg. bind("username", ...). And code that still looks as nice and natural as possible, which to me means using the dot notation as far as possible eg. @company.contactPerson.displayName.

Let's imagine some code...

public class LoginController extends BasicController {
    LoginView view = new LoginView();
    LoginModel model = new LoginModel();

    public LoginController() {
        bind(view.usernameComponent, @model.username.property);
        ...
    }
    ...
}

where alternatively, the above might reference the java.reflection.Field literal as @view.usernameComponent.field.

This notation eg. @person.username.property actually represents a tuple of the instance plus the PropertyDescriptor, whereas @Person.username.property might literally be the PropertyDescriptor, from which we can get the declaring class ie. Person.class eg. via getReadMethod().getDeclaringClass().

Method's are a bit troublesome 'cos of overloading, in which case one might need to refer to their parameter signature to differentiate them eg. @view.load(Weapon, Ammo).method which i don't like the look of, but so be it.

Talking about methods, what about "first class methods", anonymous methods, closures or what-ever. Because people find anonymous classes a bit tedious, and many people are aggrieved that Java hasn't got closures like all other popular languages!?

My feeling at this minute is that if, like generics, closures can't be implemented simply, then they shouldn't be implemented at all, if the code examples look almost as unreadable as line noise!?

Anyway, now i must start working on my next blog entry, possibly to be entitled "Elucidating the MVNC™ Architecture for Gooey Tablets." Where "Gooey" is my codeword for "GUI" and "Tablets" are just tabbed "applets" - in a GUI container frame with a tabbed pane ala the spreadsheet metaphor. And MVNC™? Well that's an acrononym for "Messy View, Neat Controller, Trivial Model" which is just plain ol' MVC with some trivial guidelines and simple rules, as to what is messy and what is neat and what is trivial, so...

Linux desktop market musings

One site i visit every day is LXer.com which is a Linux news site. Today that took me to a blog entry "Five Reasons Red Hat Should Ignore Consumer Linux Desktops" by The Var Guy, who i typically enjoy. I posted a comment in agreement, and when i do that, sometimes i like to repost it as my own blog entry, with some imbellishments, as i've done below, even though this is a Java blogging site and not a Linux one per se. However, my only other blog is decidedly non-techie.

So on the issue of Red Hat Linux desktops, we know that some of Red Hat's enterprise clients are migrating desktops to Linux eg. for call centers et cetera, and so Red Hat have their Enterprise Desktop for them.

Consumers are not going to want to pay for support, and at the same time want a lot of support to get their goodies working, from wifi to cameras, iPods et al - certainly not worth the hassle because let's face it, when you can't specify the hardware, Linux is a royal pain in the arse compared to Windows.

I think Canonical is investing in the consumer desktop primarily for personal passionate reasons of Mark Shuttleworth, and secondarily as a way to get into the market of enterprise desktops and servers with monthly support subscriptions, in order to sell the company because then it'll be getting too corporate and boring for the Benevolent Leader.

So the consumer desktop is Mark Shuttleworth's entry strategy, and the enterprise is his personal exit strategy. Red Hat is in the enterprise already, so no need for them to market consumer desktops as an entry strategy like Canonical.

Having said that, the "consumer desktop" is probably not Ubuntu's demographic, as much as the "technical desktop" ie. the Linux PCs of enthusiasts, system & network engineers, and software developers.

The risk then for Red Hat (and Solaris) and is that these engineers and developers become such passionate Ubuntu advocates, and/or that Ubuntu skills are most readily available and accessible, to encourage management to choose Ubuntu over RedHat in some cases. Probably not for the NYSE, but maybe in some small to medium enterprises that might otherwise have choosen Red Hat.

But anyway what Red Hat looses on the swings, it gains on the roundabouts via Canonical's contribution to Linux desktop development, eg. GNOME et al, testing and what-not to accelerate upstream bug-fixing.

Do you think Red Hat et al are, or should be worried about Ubuntu's meteoric rise, and how they might or should respond?

Hello World Currencies

Since i've hardly being doing anything very useful of late, i decided it's time to return to my potentially generally useful efforts of a year ago vis-a-vis "countries of the world" and publish something for a start, to prod myself into "completing" the task, which i was enjoying immensely before it was interrupted by some months of travel.

So i started preparing Java code which listed the world's countries, currencies, capitals, timezones, internet TLD's, dialing codes, et al, with the help of Wikipedia with its ISO listings. It was helluva interesting, especially the corner cases eg. terrorities which due to current and/or historical political events, are potentially on the borderline of being countries as opposed to um, eg. a defacto self-governing terrority of the secessionist variety, possibly recognised by the UN but not by some country who considers them still part of their territory - you get the picture!

Also interesting are various "quirks" eg. the currency for the British Virgin Islands is the US Dollar. Or an island where the southern part is a territory of France and the northern part is a territory of Holland.

Having compiled these lists, i should reconcile with Locale.getAvailableLocales() via ISO codes, and also the timezones of the capitals eg. reconciled with Java timezones via TimeZone. Also i need to update the country list eg. Kosovo declared independence, and it's status may have changed according to wikipedia?

I'll be publishing code on geo.dev.java.net under Apache License in due course, so you can cut and paste, slice and dice it! If you notice anything not quite right as we proceed, please lemme know, and we'll try to keep this thing correcto mundo, going forward.

Before i get onto the countries, here is teaser sample of the currencies...

putCurrency("AED", 2, "United Arab Emirates dirham");
putCurrency("AFN", 2, "Afghani");
putCurrency("ALL", 2, "Lek");
putCurrency("AMD", 2, "Armenian Dram");
putCurrency("ANG", 2, "Netherlands Antillian Guilder");
putCurrency("AOA", 2, "Kwanza");
putCurrency("ARS", 2, "Argentine Peso");
putCurrency("AUD", 2, "Australian Dollar");
putCurrency("AWG", 2, "Aruban Guilder");
putCurrency("AZN", 2, "Azerbaijanian Manat");
putCurrency("BAM", 2, "Convertible Marks");
putCurrency("BBD", 2, "Barbados Dollar");
putCurrency("BDT", 2, "Bangladeshi Taka");
putCurrency("BGN", 2, "Bulgarian Lev");
putCurrency("BHD", 3, "Bahraini Dinar");
putCurrency("BIF", 0, "Burundian Franc");
putCurrency("BMD", 2, "Bermudian Dollar");
putCurrency("BND", 2, "Brunei Dollar");
putCurrency("BOB", 2, "Boliviano");
putCurrency("BOV", 2, "Bolivian Mvdol (Funds code)");
putCurrency("BRL", 2, "Brazilian Real");
putCurrency("BSD", 2, "Bahamian Dollar");
putCurrency("BTN", 2, "Ngultrum");
putCurrency("BWP", 2, "Pula");
putCurrency("BYR", 0, "Belarussian Ruble");
putCurrency("BZD", 2, "Belize Dollar");
putCurrency("CAD", 2, "Canadian Dollar");
putCurrency("CDF", 2, "Franc Congolais");
putCurrency("CHE", 2, "WIR Euro (complementary currency)");
putCurrency("CHF", 2, "Swiss Franc");
putCurrency("CHW", 2, "WIR Franc (complementary currency)");
putCurrency("CLF", 0, "Unidades de formento (Funds code)");
putCurrency("CLP", 0, "Chilean Peso");
putCurrency("CNY", 2, "Yuan Renminbi");
putCurrency("COP", 2, "Colombian Peso");
putCurrency("COU", 2, "Unidad de Valor Real");
putCurrency("CRC", 2, "Costa Rican Colon");
putCurrency("CUP", 2, "Cuban Peso");
putCurrency("CVE", 2, "Cape Verde Escudo");
putCurrency("CYP", 2, "Cyprus Pound");
putCurrency("CZK", 2, "Czech Koruna");
putCurrency("DJF", 0, "Djibouti Franc");
putCurrency("DKK", 2, "Danish Krone");
putCurrency("DOP", 2, "Dominican Peso");
putCurrency("DZD", 2, "Algerian Dinar");
putCurrency("EEK", 2, "Kroon");
putCurrency("EGP", 2, "Egyptian Pound");
putCurrency("ERN", 2, "Nakfa");
putCurrency("ETB", 2, "Ethiopian Birr");
putCurrency("EUR", 2, "Euro");
putCurrency("FJD", 2, "Fiji Dollar");
putCurrency("FKP", 2, "Falkland Islands Pound");
putCurrency("GBP", 2, "Pound Sterling");
putCurrency("GEL", 2, "Lari");
putCurrency("GHC", 2, "Cedi");
putCurrency("GIP", 2, "Gibraltar pound");
putCurrency("GMD", 2, "Dalasi");
putCurrency("GNF", 0, "Guinea Franc");
putCurrency("GTQ", 2, "Quetzal");
putCurrency("GYD", 2, "Guyana Dollar");
putCurrency("HKD", 2, "Hong Kong Dollar");
putCurrency("HNL", 2, "Lempira");
putCurrency("HRK", 2, "Croatian Kuna");
putCurrency("HTG", 2, "Haiti Gourde");
putCurrency("HUF", 2, "Forint");
putCurrency("IDR", 2, "Rupiah");
putCurrency("ILS", 2, "New Israeli Shekel");
putCurrency("INR", 2, "Indian Rupee");
putCurrency("IQD", 3, "Iraqi Dinar");
putCurrency("IRR", 2, "Iranian Rial");
putCurrency("ISK", 0, "Iceland Krona");
putCurrency("JMD", 2, "Jamaican Dollar");
putCurrency("JOD", 3, "Jordanian Dinar");
putCurrency("JPY", 0, "Japanese yen");
putCurrency("KES", 2, "Kenyan Shilling");
putCurrency("KGS", 2, "Som");
putCurrency("KHR", 2, "Riel");
putCurrency("KMF", 0, "Comoro Franc");
putCurrency("KPW", 2, "North Korean Won");
putCurrency("KRW", 0, "South Korean Won");
putCurrency("KWD", 3, "Kuwaiti Dinar");
putCurrency("KYD", 2, "Cayman Islands Dollar");
putCurrency("KZT", 2, "Tenge");
putCurrency("LAK", 2, "Kip");
putCurrency("LBP", 2, "Lebanese Pound");
putCurrency("LKR", 2, "Sri Lanka Rupee");
putCurrency("LRD", 2, "Liberian Dollar");
putCurrency("LSL", 2, "Loti");
putCurrency("LTL", 2, "Lithuanian Litas");
putCurrency("LVL", 2, "Latvian Lats");
putCurrency("LYD", 3, "Libyan Dinar");
putCurrency("MAD", 2, "Moroccan Dirham");
putCurrency("MDL", 2, "Moldovan Leu");
putCurrency("MGA", 0, "Malagasy Ariary");
putCurrency("MKD", 2, "Denar");
putCurrency("MMK", 2, "Kyat");
putCurrency("MNT", 2, "Tugrik");
putCurrency("MOP", 2, "Pataca");
putCurrency("MRO", 2, "Ouguiya");
putCurrency("MTL", 2, "Maltese Lira");
putCurrency("MUR", 2, "Mauritius Rupee");
putCurrency("MVR", 2, "Rufiyaa");
putCurrency("MWK", 2, "Kwacha");
putCurrency("MXN", 2, "Mexican Peso");
putCurrency("MXV", 2, "Mexican Unidad de Inversion (UDI) (Funds code)");
putCurrency("MYR", 2, "Malaysian Ringgit");
putCurrency("MZN", 2, "Metical");
putCurrency("NAD", 2, "Namibian Dollar");
putCurrency("NGN", 2, "Naira");
putCurrency("NIO", 2, "Cordoba Oro");
putCurrency("NOK", 2, "Norwegian Krone");
putCurrency("NPR", 2, "Nepalese Rupee");
putCurrency("NZD", 2, "New Zealand Dollar");
putCurrency("OMR", 3, "Rial Omani");
putCurrency("PAB", 2, "Balboa");
putCurrency("PEN", 2, "Nuevo Sol");
putCurrency("PGK", 2, "Kina");
putCurrency("PHP", 2, "Philippine Peso");
putCurrency("PKR", 2, "Pakistan Rupee");
putCurrency("PLN", 2, "Zloty");
putCurrency("PYG", 0, "Guarani");
putCurrency("QAR", 2, "Qatari Rial");
putCurrency("ROL", 2, "Romanian Leu");
putCurrency("RON", 2, "Romanian New Leu");
putCurrency("RSD", 2, "Serbian Dinar");
putCurrency("RUB", 2, "Russian Ruble");
putCurrency("RWF", 0, "Rwanda Franc");
putCurrency("SAR", 2, "Saudi Riyal");
putCurrency("SBD", 2, "Solomon Islands Dollar");
putCurrency("SCR", 2, "Seychelles Rupee");
putCurrency("SDD", 2, "Sudanese Dinar");
putCurrency("SDG", 2, "Sudanese Pound");
putCurrency("SEK", 2, "Swedish Krona");
putCurrency("SGD", 2, "Singapore Dollar");
putCurrency("SHP", 2, "Saint Helena Pound");
putCurrency("SKK", 2, "Slovak Koruna");
putCurrency("SLL", 2, "Leone");
putCurrency("SOS", 2, "Somali Shilling");
putCurrency("SRD", 2, "Surinam Dollar");
putCurrency("STD", 2, "Dobra");
putCurrency("SYP", 2, "Syrian Pound");
putCurrency("SZL", 2, "Lilangeni");
putCurrency("THB", 2, "Baht");
putCurrency("TJS", 2, "Somoni");
putCurrency("TMM", 2, "Manat");
putCurrency("TND", 3, "Tunisian Dinar");
putCurrency("TOP", 2, "Pa'anga");
putCurrency("TRY", 2, "New Turkish Lira");
putCurrency("TTD", 2, "Trinidad and Tobago Dollar");
putCurrency("TWD", 2, "New Taiwan Dollar");
putCurrency("TZS", 2, "Tanzanian Shilling");
putCurrency("UAH", 2, "Hryvnia");
putCurrency("UGX", 2, "Uganda Shilling");
putCurrency("USD", 2, "US Dollar");
putCurrency("UYU", 2, "Peso Uruguayo");
putCurrency("UZS", 2, "Uzbekistan Som");
putCurrency("VEB", 2, "Venezuelan bolívar");
putCurrency("VND", 2, "Vietnamese đồng");
putCurrency("VUV", 0, "Vatu");
putCurrency("WST", 2, "Samoan Tala");
putCurrency("XAF", 0, "CFA Franc BEAC");
putCurrency("XCD", 2, "East Caribbean Dollar");
putCurrency("XOF", 0, "CFA Franc BCEAO");
putCurrency("XPF", 0, "CFP franc");
putCurrency("YER", 2, "Yemeni Rial");
putCurrency("ZAR", 2, "South African Rand");
putCurrency("ZMK", 2, "Kwacha");
putCurrency("ZWD", 2, "Zimbabwe Dollar");

where we specify the number of decimals.

Now to countries, with their currencies, languages, dialing codes, TLDs, and their capitals, with their coordinates, timezones and what-not, all cross-referenced via ISO codes! Baby steps... :)

First Class Java: Thoughts on a dot notation

So last week i started rambling about "First Class Java." Lemme continue while i wait for my clothes to dry on the line outside, whilst i prepare myself for a wedding this afternoon, which i love, especially the eating and drinking and chatting and laughing and dancing part of it.

So i was wondering what notation would be neat for first-class references to properties, methods and fields, for this so-called "First Class Java" exercise.

Since we have .class notation for Class eg. Person.class, my first thought was to have something similar eg. .property, .field, .method - waddayathink?!

For example, let's say our Person.class has a property username. Then we could refer to its PropertyDescriptor as Person.username.property. We might also refer to it's Field and accessor Method as Person.username.field and Person.getUsername.method.

Comrades here have been touting using a hash (which is quite neat) eg. Person#getUsername (for first-class method referencing), and we see things like Person->username for properties. The question is then what non-conflicting notation for fields!?

(As an amusing side bar on hash notation, many years ago i was hosting two decidedly non-techie friends from London, and roped them into a geeky Linux User Group year-end dinner party. They got thoroughly bored, their heads down with all this technobabble going around and over their heads. The only time i saw them whip their heads up was when they heard the word "hash." Disappointingly for them, not the type they could converse about, but rather further technospeak related to unix scripts, which caused a further shoulder-drop. Heh heh.)

Back to the beef. Besides the hash and -> notations, for closures we see a => notation being bandied about willy-nilly. Urrrrgh!

The problem is that firstly, i personally dislike with a revulsion that is impossible to put into words adequately, such double-dastardly punctuation symbols like C/C++'s hideous ->, and => is even worse! Having said that, i don't mind C/C++'s &, and of course we all love it's dot notation for referencing.

Given that we have too many first-class thingymajigs like properties, methods, fields, and given that Java's preference in general is words rather than punctuation, eg. extends rather than C++'s doubly-distastful colons, i say using words like .method is better, and inline with Java's existing "dot-word notation" for meta-majiggies ie. .class.

In general, less char's is not better. (Where by "char's" i mean "characters," as a case in point.) Java takes the approach of readability over brevity, eg. lastKnownWhereabouts over lstKnwnWhabs, and extends rather than colons. (Lemme not launch into a whole tirade about unixen /usr and /tmp, and the elitist-obscuritism to which i am philosophically and psychotically indisposed.)

Given the above, a related point on the subject of closures is, sure, introduce closures if it's gonna simplify and robustify our libraries, API's and programs. But let's continue Java's legacy of beautiful readability rather than introducing the dastardliness of C++'s duplicitious punctiliousness.

Enough semantic monkeying around from me - please restore some sense and sensibility to this posting with your affably obliging comments - thank you very much! :)

July 2008

Search this blog:

Categories

Archives

June 2008
May 2008
April 2008
March 2008
January 2008
November 2007
October 2007
September 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006

Recent Entries

A short history of Web UI programming

MVnC architecture for Swing GUIs

First Class Java: further thoughts on dot notation for class metadata

This work is licensed under a Creative Commons License.