my recent reads..

Longitude


Longitude by Dava Sobel is the very readable tale of John Harrison's astonishing, life-long quest to build timepieces that were suitable for maritime use in the determination of longitude.

Self-educated and living far from the madding crowd in Barrow, his first clocks were largely wooden. Harrison's earliest surviving clock movement, dated 1713, can be found at the The Worshipful Company of Clockmakers of London.

He first set his mind to the challenge of maritime timekeeping in 1727. The Board of Longitude had been established in Britain by Act of Parliament and offered a prize of ₤20,000 for a method that could determine longitude within 30 nautical miles (56 km).

The problem of longitude had long plagued sailors, sending many crashing to their deaths on unexpected landfall, or dying from thirst and scurvy lost at sea. It was the subject of much public discourse, as global warming is for example today. It even makes a cameo in William Hogarth's engravings of A Rake's Progress (note a man scribbling a dim-witted solution to the longitude problem on the wall, centre).
In the centre, a lunatic scribbling a dim-witted solution to the longitude problem
The method for determining longitude by comparing local time with the time at a known origin relies on very accurate time keeping. Beyond the capabilities of clocks of the age, even on land. At sea, the combined effects of motion, temperature and gravity made the approach seemingly impossible.
Let's say that the sun is directly overhead and your chronometer, which was set to noon when you were at 0 degrees, says it's 3 o'clock. This means that three hours ago the sun was overhead at this latitude at 0 degrees longitude. In those three hours, the sun moved 15 degrees 3 times, or 45 degrees. So you're at 45 degrees West.
Despite support from the Royal Society, the Board of Longitude was well stacked with those who favoured an astronomical approach, relying on measurements of the passage of the moon. Nevil Maskelyne proved to be Harrison's arch-nemesis and main proponent of the lunar distance method. Although the chronometer eventually won over seafarers (and King George III) through its simplicity and reliability, Nevil's Nautical Almanac became his enduring legacy and is still published today (minus the lunar distance tables).

After producing five timepieces (H-1 through H5), John Harrison was finally recognised in 1773 by Parliament to have proven his claim, although he was never to officially be awarded the full prize by the recalcitrant Board of Longitude. The National Maritime Museum of Britain has a comprehensive time Gallery which features H-1 to H-4. H-5 is at The Worshipful Company of Clockmakers of London.

It was Harrison's successors, like Thomas Earnshaw, to fully commercialise the maritime chronometer. Yet they all owe their successs to the many innovations that Harrison pioneered.
The machine used for measuring time at sea is here named a chronometer, [as] so valuable a machine deserves to be known by a name instead of a definition.
-ALEXANDER DALRYMPLE in his pamphlet 'Some Notes useful to those who have Chronometers at Sea'

Harrison's Chronometer H1
Harrison's Chronometer H5
read more and comment..

Desktop Keyboards Stuck in Design Limbo

Keyboards are terrific examples of how bad design can get stuck in a rut, unable to overcome inertia. Everyone says qwerty is a bad idea, yet I couldn't imagine using anything else now since it's use is so ingrained.

But another aspect of keyboard design that has me really grumpy is the whole numeric keypad appendage on desktop keyboards. It is a holdover from the days when users were "data entry clerks". But we are stuck with it (Microsoft only have two keyboard models without it, while ALL Logitech models are saddled with this cancer Postscript: Dean Chu corrected me here; Logitech's diNovo models don't have the numeric keyboard).

This started to really annoy me of late, because I've been switching between a laptop during the day, and a desktop at night.

Working with a desktop keyboard again was feeling really strange and difficult, but after some reflection I realised the problem. My right-hand is used to shifting all the time between jkl; and the mouse. On the laptop, this is a subtle and effortless gesture. On the desktop, its like playing table tennis.

The fact that virtually all laptop designs eschew the separate numeric keypad should be proof that it is evolutionary dead wood.

So this is my grumpy call for all keyboard manufacturers to wake up their snoozing product managers/designers and actually innovate for once. Fix this ergonomic nightmare! At least give us some choice ... integrate it with function keys like laptops; use separate USB numeric keypads; even consider sticking it on the left-hand side of the keyboard.

And for all those poor souls who really are still data entry clerks, I'm sure there will be no-brand outfits from China knocking out standard 102-key designs for years to come.

Is it just me? Did I get up on the wrong side of the bed today, or do others feel this way too?

Postscript 9-Feb-2009 ... hat tip to mqt for linking Trevor Blackwell's solution: just chop it off! If you gotta take a bandsaw to a product to make it fit-for-use, then something's wrong, right?!!

read more and comment..

Appcelerator - bringing down the wall between RIA and SOA?

I wonder if the Appcelerator guys have finally cracked the RIA and SOA dichotomy? I first came across them on Coté's RIA Weekly #008 RedMonk Radio podcast.

I've presented my views before on what I see as the three megatrends in IT:

  • Web 2.0 - or more generally, RIA
  • SOA
  • Grid - although today I'd probably update this to be "Cloud Computing"


But the distinction between RIA and SOA has always felt forced; unrelated working metaphors, owing more to the historical segregation of the communities addressing each than strict architectural principles.

While industry lines have been drawn very clearly around these two domains (take OpenSOA v. OpenAJAX for example), there have been many attempts to nibble away at the distinction. AJAX toolkits like SAJAX and SWATO strive to make calling back-end resources more convenient. And frameworks like ADF approach the problem from the other end, by "hiding" AJAX rendering in their server-side, SOA-aware paradigm.

So what has Appcelerator got to do with this?

From what I understand so far, the key is that they have unified the event/messaging model both within the browser and the "SOA-sphere", and done so in a very elegant way. There are three parts to their solution:
  • Web Expression Language
  • RIA Widget Framework
  • RIA Message Broker

All components in an Appcelerator application communicate via simple lightweight messages using the RIA Message Broker. On the server-side, Appcelerator provides a set of SOA Integration Points that enable service creation in Java, PHP, Ruby, .NET, Python and Perl.

On the client, the Web Expression Language message-enables HTML elements. The RIA Widget Framework is a Javascript-based API that enables you to create new widgets and wraps existing third-party widgets like scriptaculous.

The end result is a very clean, lightweight and seemless development approach. HTML attributes define behaviour: what messages to send, and what to do when a message is received. And the real magic: when you send a message, you do not know or care if it handled by another HTML element on the same page, or a SOAP Web Service somewhere out on the net.

Here's how straight-forward it gets. An example of an input button messaging a calendar widget to show itself..
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:app="http://www.appcelerator.org">
...
<app:calendar title="Pick a Date" on="l:show.calendar then execute" inputId="mydate">
</app:calendar>
<input type="text" id="mydate" value="click me" on="focus then l:show.calendar"/>
...

Or an input button sending a message...
<input type="button" value="submit" on="click then r:login.request"/>

.. that is handled by a Java service:
import org.appcelerator.annotation.Service;
import org.appcelerator.messaging.Message;

public class LoginService
{
@Service(request = "login.request", response = "login.response")
protected void processLogin (Message request, Message response)
{
// get request data
String username = request.getData().getString("username");
String password = request.getData().getString("password");

User user = userDAO.login(username,password);

// format response
if (user != null)
{
response.getData().put("success",true);
response.getData().put("user",user);
return;
}
response.getData().put("success",false);
}
}

Appcelerator looks like one to definitely watch closely and investigate further..
read more and comment..

Beginning Rails


Beginning Rails: From Novice to Professional by Jeffrey Hardy and Cloves Carneiro is one of the most approachable "learning rails" books I have found to date.

The writing is clear, and concepts are presented in a very readable way. I really appreciate the organisation of the book - they've done a great job of presenting key topic areas in a logical sequence that guides you up the learning curve without losing sight of the big picture.

Working through the examples right now...

read more and comment..