Half.com, Oregon, USA

After accidentally searching for “XMLHttpRequest” in Google Maps and discovering no such location exists, I wondered about the fate of half.com, Oregon. This is the town which changed its name from Halfway to half.com during the tulip-mania of the late 90s. Half.com the company continues as an ebay subsite and half.com the town lives on with that name.

Now here’s what made me chuckle. The town website makes very little of the name change:

Halfway (also known as Half.com), population 345, is a picturesque community located 40 miles southwest of Hells Canyon in Eastern Oregon. Consisting of hard-working, self-sufficient folks, the town of Half.com is a tight-knit community, full of tradition and camaraderie.

Now imagine doing some research on Halfway and discovering an incogruous description like that. Your reaction? Mine would be “HUH?” It certainly isn’t aiming to be a Silicon Valley copycat, so why the .com? Weird. (Come to think of it, I’m surprised all the Valley copycats called themselves “X Valley” and no-one created a “X.com” region instead.)

There is actually a page on that website which gives more info on the name change, but it’s not actually linked to. I think someone’s not too happy about the name change.

Personal Domain + Lifetime Email Addresses

Personal Domain and Lifetime Email Addresses … no, I’m not selling them. I just wish people would get an easy-to-remember email, resembling their name somehow. So I wouldn’t have to be told to update my address book, and so I could easily send them mail without having to lookup their address. Unlike a phone number, an email is well-suited to human memory if only people would exploit that opportunity. In fact, email addresses – combined with VOIP – will render phone numbers obsolete in a few years, at least from the end-user perspective.

Objections seem to be as follows:

Technical Inexperience. I think if people realised how easy it was, they’d go for it…so I’ll explain why the remaining objections don’t stack up. Saying that, I’m surprised how many techies still haven’t done it.

Technical Hassle. Again, it’s actually a diddle to set up a domain with email forwarding. You probably don’t want a website or all the other things anyway.

Cost. Well, there must be some kind of mistake here because GoDaddy for instance, charges $8.99 per year. And the prices should go southward if anything, that’s been the trend.

Name availability. Sure, smith.com would have been nice, but it’s gone now, so go for josesmith.cc or something – it’s still permanent and a lot easier than [email protected]

Spam. You like to email-hop so you can avoid the spam when it gets too busy? Have fun, but don’t expect to me to follow you around. Send me a postcard sometime. I understand that spam’s still a big problem, but server-side solutions make it easy for end-users to deal with. For instance, I notice godaddy claims a $10/year email service with spam protection. Or just forward your mail to gmail.

When Honest Communication is Punished

Honest Communiction: The Quote

If your organization punishes honest communications and you start to communicate honestly, you’ll be destroyed.

That’s a quote from Kent Beck I just came across on CoachSpot.

I agree with the sentiment, I disagree with the fervour.

Dishonest communication is frustrating and counter-productive

Many programmers, at least most of the good ones, love what they do, at least in theory, and would write programs if they had all the money in the world, at least some types of programs. It’s naturally frustrating, then, to be dragged into work that is clearly wrong.

Quite often, programmers have to do things that seem illogical. You learned at uni that good design is important, so why are we ignoring those principles now? Well, sometimes that’s the right thing to do for the business. As an extreme example, let’s say it’s June, 2008, and you have to port a poor-quality, legacy application from four years ago in time for the summer olumpics. Chance are, you’re without a paddle anyway you go, and some agile principles will certainly help, but basically you’re not going to be doing it by the book. Companies have absurd deadlines all the time, and there’s often not much the developers in the trenches can do about that. Again, you can go with the action sometimes mentioned in agile literate, and walk away, but that’s hardly practical and a dubious practice anyway.

My point is that unintuitive practices are often necessary. Dishonest communications make things frustrating because programmers are left wondering why those practices are being adopted. Mature software process involves endowing programmers with at least basic business context, so they can make the right trade-offs. Hand-waving about those things leads to paralysis.

Dishonest communication will not destroy you

Placing head firmly in sand – on some issues at least – is standard behaviour in many parts of many corporations, including many multinationals that have survived for decades – centuries even – and remain profitable to this day. A colleague told me he was once on a finance project which was burning what sounds like a million dollars or more per month, and was obviously doomed. There was a rare opportunity to get an explanation from upper management as to why the sinking ship was continuing to be held afloat. The answer: “It would be impolitic to let it go”. Aahh, so that’s why all those employees, contractors, and consultants are still out there charging you and your shareholders.

Even individual projects survive this type of self-mutlation. Especially when there are enough talented (and probably well-compensated) people around to act as heroes.

The universe is more than IT …

I think sometimes software professionals are prone to use superlatives, driven by frustration at the strong degree of ignorance about IT that is so prevalent. So we can say things like “this will ruin our chance to compete” or “how on earth will we ever deal with the increase in sales”. ** But somehow, many companies have a way of being resilient to these things and just muddling through them with a combination of manual workarounds, extra staffing, and last-minute duct-taping**. That’s rarely optimal, but it’s usually enough to avert a disaster.

Treo On/Off Slider

The Treo has a physical slider to quickly let you switch calls on and off. Hardly earth-shattering. but consider this: apparently no other smartphone has that same feature! Now, I haven’t investigated and I’m not enough a gadget freak to do so, but at least it’s what the Treo Director of Product Marketing claims:

During one design meeting, “Jeff Hawkins, [inventor of the Palm Pilot, Palm and Handspring co-founder], said he wanted a way to turn off the ringer and other sounds quickly, and a slider switch just seemed like the obvious idea … What really surprised us, I think, was realizing later that other cell phones didn’t have this feature, and moreover, I continue to be surprised, given how useful that little switch is, that no company I know of has copied it!

It does seem kind of obvious and it certainly beats holding down some random key for some random period of time. (“Sir, the manual makes it very clear that you hold down the ’8′ button for 4 seconds”).

Following the principle of encapsulation, there’s work being done to let the phone manage the ring-tone for you. I think some products actually try to do this now, but I couldn’t find them. A few cues I’ve heard about: * Diary: Your smart-phone theoretically knows when you have an appointment. * Microphone: At the very least, your smart-phone knows how loud it is, so can set the ringer volume. In a more AI scenario, it might also try to work out what’s going on and whether it should be off altogether. * Usage logs: If you’ve used the phone recently, it’s more likely the ringer should be on. If you’ve taken calls at the same time for the past four weeks, it should probably be on.

So, ultimately, there needs to be a third slider setting: on, off, and you-tell-me.

Clear Instructions on Mozilla Site

It’s nice to see an example of clear, personalised, instructions. I just upgraded to Ubuntu (I’ll post about it later), and visited the Firefox site to pick up extensions. It gives me the following message:


Firefox on Ubuntu

You appear to be using the Firefox package provided by Ubuntu Linux. Ubuntu distributed a new version of Firefox which contains the security fixes from Firefox 1.0.4, however, they did not update the version number, so we have no way to tell whether your copy of Firefox contains the security fixes or not. A request to Ubuntu to update the version number has been filed at Ubuntu Bug 10681. A workaround you can use to get access to addons.mozilla.org is given in comment 3 on that bug. Please ensure you have updated to the latest Firefox package using apt-get, Synaptic, or the Ubuntu Update Manager before trying the workaround.

It’s nice that not only is the message specific to this browser version and platform, but it’s lucid about the problem that’s occurred and what I can do about it. Perhaps it would be nicer if the presentation was a bit more structured – e.g. as bullet points – but the information is all there.

Naming of Interfaces and Impl’s

Cedric on Interface naming convention:

Some argued that using ‘I’ adds noise. Usage of ‘Impl’ suffix takes care of this problem too.

I wonder if the author of this remark noticed the irony of this comment :-)

Neeraj Kumar left a good comment on this, which is similar to what I was thinking: Both “I” and “Impl” add noise – the question is which one is less evil.

Here’s why I prefer “*Impl”.

  • The interface is part of the core code. Using a container like Spring, implementations are hidden away in config. So “Impl” is less invasive than “I“.
  • Both sound clumsy, but “I” sound clumsier to me, mainly because the “I” dominates the start – rather than the end of the word. I can think of “CoffeeMakerImpl” as “CoffeeMarkerBlahBlah”, but it’s harder to think of “ICoffeeMaker” as “BlahCoffeeMaker” – the initial “I” is too invasive.
  • Furthermore, it’s easier to search for “Impl” than “I” in an IDE, especially when some code will use the “I” convention and other code won’t (ie most external/legacy code).

    Actually, I usually prefer Impl’s to tell me what kind of Impl. Even if there’s only one Impl, it’s sometimes useful to provide a hint about what other Impl’s might be possible. To use the canonical example, I’d rather see BubbleSortImpl than SortImpl. Also worth noting that if you’re doing TDD, you probably have mock implementations as well; with JMock, they’re not defined classes because they’re instantiated using dynamic proxy. However, they are present, so I like to keep in the back of my mind that the class name “XImpl” is really shorthand for XProdImpl.

  • Scrollback Gripe

    Why is the default scrollback setting always so small? This applies to DOS, XTerms, terminal emulators like putty (which could really do with a way to save the scrollback setting too).

    How much memory does a 10,000 line scrollback cost? Let’s knock ourselves out and assume it’s full unicode – four bytes per character. On 80 wide, that’s 320 bytes per line. So the entire scrollback is 3.2MB. Being even more hedonistic, let’s have ten such terminals, for a total of 32MB. Modern computers come with 1GB or more, so the cost is negligible, and any installer should make use of the computer’s capabilities. Benefit of not losing vital information: priceless.

    Missing Javascript Business Logic Support

    Marcus Baker recently wrote about Ajax applications not being responsive enough, so the argument goes you should do just about everything in the browser, and mainly use the server-side for periodic persistence. I don’t think that’s always the right thing to do, but there’s definitely going to be more apps developed that way, and there’s definitely a performance driver to keep at least some business logic in the browser.

    So, after looking at the various frameworks, what’s missing among the Javascript offerings is a portable, non-UI, utility library to support business logic. Such a library wouldn’t do any DHTML or DOM manipulation. Instead, it would offer the sort of functionality you’d get from java.util or the STL or various Jakarta classes. A cohesive library of features such as:

    • Collections and related algorithms.
    • Logging
    • Number-crunching algorithms.
    • Basic variable manipulation (like Jakarta Commons Lang – simple, oft-repeated code like isWhitespace()).

    Some of this stuff exists already, but it’s scattered across the net, with various licenses and inconsistent styles. A worthwhile API would offer this functionality and package it all together, with self-referencing whenever possible e.g. if it provided a logging framework, all of the packages would take advantage of it. It would also need to avoid excessive downloading. XMLHttpRequest can actually help here – Alex Russell recently mentioned that DOJO actually pulls in Javascript on the fly. Also, caching of Javascript files clearly helps a lot. And on intranets, it’s usually a non-issue.

    It might also be worthwhile allowing server-side integration via XMLHttpRequest, with sajax-like functionality mapping Javascript functions into server-side calls. For example, a library might work like the dependency injection containers, allowing the caller to configure how particular functions are deployed. You could then switch an implementation over to the server if desired. It’s fairly transparent, though with an asynchronous call, the callback function would impose some interference.

    I realise there are plenty of problems with Javascript business logic, and it’s certainly not always applicable. Those problems include:

    • Security – Exposes business logic algorithms and enables them to be changed.
    • Complexity – Javascript is more powerful than many people assume, but suffers in comparison to standard language like Java or Ruby, where there is also better library support, development tools, and more established design patterns.
    • Footprint – There’s the potential to download excessive library code, so careful management is required to avoid that situation.
    • Scaleability – While client-side processing can actually out-perform server-side processing when the server is heavily loaded, there’s a scaleability problem – you can only run as fast as the client platform.

    But having said that, there are places where it makes sense, and we’ll be seeing a lot more business logic in the browser. It therefore makes sense to ease the development pain when that happens.

    Ajax and Awareness of Other Users

    A few Ajax UI idioms are emerging, e.g. progress icon while waiting for server response. But I haven’t yet seen anything for awareness of other users. I was just playing with the magnetic poetry demo (via Ajaxian. The pieces started moving on their own volition, which I assumed was, uh, due to magnetism. It turns out it was someone else, but there was no way to know that. I’m not knocking the demo here, which after all is very cool and in fact every ajax wiki/chat app I’ve seen does the same. I’m suggesting that it would be nice if these multi-user apps had a way to express information about others, respecting privacy of course.

    Some of these things are already done on websites like messaging boards, which I assume use the last time of request to see if the user is “online”. With Ajax, you can be a lot more certain if the user is “online”:

    • You can use a heartbeat mechanism to keep checking the application is alive and well in the browser.
    • You can monitor user activity to detect when a user has gone idle.

    Short of strapping on eye-trackers and performing a PET scan, that’s about as good as it gets, even on the desktop.

    So, armed with this kind of information, you could do the sort of things you see on desktop applications or collaborative websites:

    • Show how many users, and possibly a list of those logged on, if their profile wants it. “last seen” time, etc.
    • Use different cursors for different users
    • Use a modified “yellow fading technique” to show when someone else has changed something. Maybe it should be a reverse-fade to pretend that it’s being squeezed out of the server, as opposed to being sucked in (which is how I see the fading technique work).
    • When all’s said and done, it all comes down to one thing: Avatars. Well, not really. I just thought “avatars” would be cool to mention here.

    I’m sure there’s lots more of these waiting to be discovered.

    As I’ve mentioned before, intranets are the killer app for Ajax, and there are scores of opportunities for collaborative Ajax systems in the enterprise.

    AJAX Frameworks round-Up

    I’ve been fortunate enough to have received various updates on Ajax projects from some of the developers. Right now, there are so many new Ajax frameworks coming out, and so much Ajaxification of existing frameworks, that it’s getting hard to keep track of what does what. So here’s a round-up of Ajax (and related) frameworks, copied from a new page I created on ajaxpatterns.org. I wasn’t actually expecting any patterns of frameworks to emerge, but they did … when you look at all the Ajax-related frameworks out there, you’ll tend to notice four distinct styles, as descibed in the background section. I haven’t yet looked into the revisited Ajax support on Struts/Tapestry/etc.; those might be quite different.

    Please visit the ajaxpatterns.org frameworks page for the latest summary of Ajax frameworks. What follows is a current snapshot which won’t be updated.


    Thanks to everyone who’s let me know about the frameworks as they emerge. Please mail Michael Maheomff (mailto:[email protected]) about any frameworks not yet here, or any corrections. (This is, for now, just a content management system rather than a true wiki.)

    As a summary, the pure Javascript frameworks can be divided into two groups:

    • Infrastructural frameworks: provide basic piping and portable browser abstractions, leaving the content for the developer to create. Typical functionality:
      • Wrapper around XMLHttpRequest to encapsulate browser-server interaction. (All frameworks offer this).
      • XML manipulation and interrogation.
      • Performing DOM manipulation according to responses from XMLHttpRequest.
    • Application frameworks: may offer the above functionality, but are notable for including widget abstractions and other components which are more along the lines of desktop GUI frameworks.

    And the server-side frameworks usually work in one of the following two ways (although they are classified according to language):

    • HTML/JS Generation: Server provides complete HTML/Javascript code generation and browser-server co-ordination, so that only browser-side coding is only for customisation.
    • Remote Invocation: Javascript calls routed directly to server-side functions (e.g. Java methods) and returned back to Javascript callback handlers. Or Javascript calls to server to extract information, e.g. session details, database queries.

    Pure Javascript: Application Frameworks

    DOJO (Under development; from September, 2004)

    DOJO (http://dojotoolkit.org/) offers comprehensive widget and browser-server messaging support.

    • Framework for creation of custom Javascript widgets.
    • Library of pre-built widgets.
    • Browser-server messaging support – XMLHttpRequest and other mechanisms.
    • Support for manipulating URLs in the browser.
    • Open-source license (Academic Free License 2.1 (http://opensource.org/licenses/afl-2.1.php)). Led by Alex Russell (http://alex.dojotoolkit.org/) of JotSpot (http://www.jot.com/).

    Open Rico (Under development; from May, 2005; based on earlier proprietary framework)

    Open Rico (http://openrico.org/demos.page) is a multi-purpose framework with support for Ajax infrastructure and user interaction.

    • An XMLHttpRequest response can be routed to one or more callback operation, DOM object, or Javascript object.
    • Easy drag-and-drop.
    • Ajax animation such as scaling and transitions (and presumably the increasingly common idioms such as progress indicators and fading technique?)
    • “Behaviors” – Essentially a widget library.
    • Open-source. From Sabre Airline Solutions. By Bill Scott (http://looksgoodworkswell.blogspot.com), Darren James, and others.

    Pure Javascript: Infrastructure-Focused

    AjaxJS (Raw alpha; from May 2005)

    AjaxJS (http://ajaxpatterns.org/demo/liveSearch) is a basic threadsafe wrapper around XMLHttpRequest mainly for Ajax newcomers, still raw alpha and under development, only packaged with the AjaxPatterns live search demo for now.

    • RESTful calls to the server (GET/POST/PUT/DELETE) with plain-text or XML routed to a callback operation.
    • Destruction of used XMLHttpRequest objects.
    • Response caching (planned).
    • Aimed at Ajax newcomers – instead of optimising on performance or footprint, the library will aim to be a readable code base and will provide debugging support.
    • Open-source license. By Michael Mahemoff (http://softwareas.com) (with some ideas from John Wehr and Richard Schwartz).

    HTMLHttpRequest (Beta; from 2001)

    HtmlHttpRequest (http://www.twinhelix.com/javascript/htmlhttprequest/) is an alternative to XMLHttpRequest which uses IFrames for superior compatibility.

    • Tested and Works: IE6/Win, IE5.5/Win, IE5/Win, IE4/Win, Mozilla/Win, Opera7/Win, Safari/Mac, IE5/Mac.
    • Untested, Probably Works: IE4/Mac, Mozilla/Mac, Opera/Other, Konqueror/Linux. Are you using one of these? The author is requesting compatibility info.
    • Open source license (LGPL). By Angus Turnbull of Twin Helix Designs (http://www.twinhelix.com/).

    Interactive Website Framework (Under development; from May 2005)

    Interactive Website Framework (http://sourceforge.net/projects/iwf/) is a project aiming to support the various aspects of Ajax infrastructure in the browser. Describes itself as a “framework for creating highly interactive websites using javascript, css, xml, and html. Includes a custom xml parser for highly readable javascript. Essentially, all the plumbing for making AJAX-based websites, as well as other common scripts.”.

    • Thread-safe XMLHttpRequest implementation
    • Wrapper around XML document, so you can make more readable code:

       var node = doc.groceries.frozen[0].pizza[0].size;</pre>
    

    instead of manual navigation:

       var node = doc.documentElement.firstChild.firstChild.getAttribute("size");</pre>
    

    • Open-source license. By Weaver (http://circaware.com|Brock).

    LibXMLHttpRequest (Released; June 2003)

    libXmlRequest (http://www.whitefrost.com/servlet/connector?file=reference/2003/06/17/libXmlRequest.html) is a thin wrapper around XMLHttpRequest.

    • getXML() and postXML() methods.
    • Pooling of XMLHttpRequest objects.
    • Response caching.
    • Source available (obviously), but protected by standard copyright. By Stephen W. Coate (http://www.whitefrost.com/index.jsp).

    Sack (In development; from May 2005)

    Sack (http://twilightuniverse.com/2005/05/sack-of-ajax/) pushes the server response directly into a DOM element.

    • Caller specifies the server URL, the data to be sent there, and a DOM element. The DOM element’s HTML/content will be replaced with the response.

    Sarissa (Released; from February, 2003)

    Sarissa (http://sarissa.sf.net) is a Javascript API which encapsulates XML functionality in browser-independent calls.

    • Portable XMLHttpRequest creation.
    • Portable XPath queries.
    • Portable DOM manipulation.
    • Portable XSLT.
    • Portable serialisation to XML.
    • Open-source (GPL 2.0 and LGPL 2.1. IANAL and wouldn’t have a clue how it can be both at the same time.). From various contributors.

    XHConn (Released; from April, 2005)

    XHConn (http://xkr.us/code/javascript/XHConn/) is a thin wrapper around XMLHttpRequest.

    • Example:

    new XHConn().connect("mypage.php", "POST", "foo=bar&baz=qux", fnWhenDone);
    

    • Open-source (Creative Commons Attribution-ShareAlike License). By Brad Fults.

    Server-Side: Multi-Language

    SAJAX (Workable but not 1.0; from early 2005?)

    SAJAX (http://www.modernmethod.com/sajax/) routes calls directly from Javascript into your server-side language and back out again. So, for example, calling a javascript method “x_calculateBudget()” will go the server and call a Java calculateBudget() method, then return the value in javascript to x_calculateBudget_cb().

    • Faciliates mapping from Javascript stub function to back-end operation.
    • Capable of stubbing calls to numerous server-side platforms: ASP/ColdFusion/Io/Lua/Perl/PHP/Python/Ruby.
    • Open-source license. From various contributors.

    JSON and JSON-RPC

    JSON (http://www.crockford.com/JSON/index.html) is a “fat-free XML alternative” and JSON-RPC (http://www.json-rpc.org/) is a remote procedure protocol, akin to XML-RPC, with strong support for Javascript clients.

    Server-Side: .NET (Under development; from March 2005)

    Ajax.Net (http://ajax.schwarz-interactive.de/csharpsample/default.aspx) is a library enabling various kinds of access from Javascript to server-side .NET.

    • Like SAJAX, can pass calls from Javascript into .Net methods and back out to Javascript callbacks.
    • Can access session data from Javascript.
    • Caches results.
    • Free to use, source available, unspecified license. By Michael Schwartz (http://weblogs.asp.net/mschwarz/).

    Server-Side: Java

    Note: Many existing frameworks have recently been adding Java support (e.g. struts), and I will link to those later on.

    Echo 2 (from March 2005)

    Echo 2 (http://www.nextapp.com/products/echo2/) allows you to code Ajax apps in pure Java (Demo (http://demo.nextapp.com/InteractiveTest/ia)).

    • Automatically generates HTML and Javascript.
    • Co-ordinates messages between browser and server. Messaging in XML.
    • Can hand-write custom Javascript components if desired.
    • Open-source license (Mozilla Public License or GNU LGPL). From Next App, Inc. (http://www.nextapp.com/).

    Direct Web Remoting (DWR; 2005)

    Direct Web Remoting (http://www.getahead.ltd.uk/dwr/) is a framework for calling Java methods directly from Javascript code.

    • Like SAJAX, can pass calls from Javascript into Java methods and back out to Javascript callbacks.
    • Can be used with any web framework – Struts, Tapestry, etc.
    • Follows Spring-like KISS/POJO/orthogonality philosophy.
    • Open-source license (Apache (http://www.apache.org/LICENSE.txt)). By Joe Walker (http://www.getahead.ltd.uk/sg/space/joe/). Being incorporated into next WebWork (http://www.opensymphony.com/webwork/) release.

    Server-Side: PHP

    AjaxAC (From April, 2005)

    AjaxAC (http://ajax.zervaas.com.au/) encapsulates the entire application in a single PHP class. From the website:

    • All application code is self-contained in a single class (plus any additional JavaScript libraries)
    • Calling PHP file / HTML page is very clean. All that is required is creating of the application class, then referencing the application JavaScript and attaching any required HTML elements to the application.
    • Built in functionality for easily handling JavaScript events
    • Built in functionality for creating subrequests and handling them
    • Allows for custom configuration values, so certain elements can be set at run time
    • No messy JavaScript code clogging up the calling HTML code – all events are dynamically attached
    • Easy to integrate with templating engine due two above 2 reasons
    • Easy to hook in to existing PHP classes or MySQL database for returning data from subrequests
    • Extensible widget structure to be able to easily create further JavaScript objects (this needs a bit of work though)

    Background: