Software As She’s Developed

Writing a multi-timezone clock gadget, I found myself needing to convert timezones in Javascript. This is one unchartered area in Ajax/Javascript - unfortunately, there is no timezone library to my knowledge. Unfortunately, there’s no public JSON service to tell you what time it is right now in Tokyo either. I could create one without too much difficulty, but I’m aiming to build a self-contained gadget, which means I want it all in Javascript.

Back to first principles, ZoneInfo is incredibly thorough, but that makes it difficult to use for a single gadget. There is a wikipedia list too, but not easily parsed. (If web 3.0 is all about the semantic web, then wikipedia will hopefully become a better home for structured data too.) I then found “City Time Zones” which is a user-generated, wiki-style, approach. The problem is it doesn’t handle daylight savings, but it will do for now - the user will simply get a checkbox to say if it’s daylight savings or not. Yeah it’s a really ordinary solution, but the only one I can manage if I’m to build the gadget in a day or so.

I extracted from the ZoneInfo a simple list you might find useful. The first iteration is sorted by timezone and I’ve junked geo and other info, so you just have the timezone names, the offset, and major locations.

Tonga Standard Time,+13:00 Nuku’alofa
Kamchatka Standard Time,+12:00 Kamchatka
Fiji Standard Time,+12:00 Fiji, Marshall Is.
New Zealand Standard Time,+12:00 Auckland, Wellington
Norfolk Island Standard Time,+11:30 Norfolk Island
Central Pacific Standard Time,+11:00 Solomon Is., New Caledonia
Magadan Standard Time,+11:00 Magadan
Vladivostok Standard Time,+10:00 Vladivostok
Tasmania Standard Time,+10:00 Hobart
West Pacific Standard Time,+10:00 Guam, Port Moresby
AUS Eastern Standard Time,+10:00 Canberra, Melbourne, Sydney
E. Australia Standard Time,+10:00 Brisbane
AUS Central Standard Time,+09:30 Darwin
Cen. Australia Standard Time,+09:30 Adelaide
Yakutsk Standard Time,+09:00 Yakutsk
Korea Standard Time,+09:00 Seoul
Tokyo Standard Time,+09:00 Osaka, Sapporo, Tokyo
Ulaanbaatar Standard Time,+08:00 Ulaanbaatar
Taipei Standard Time,+08:00 Taipei
W. Australia Standard Time,+08:00 Perth
Singapore Standard Time,+08:00 Kuala Lumpur, Singapore
North Asia East Standard Time,+08:00 Irkutsk
China Standard Time,+08:00 Beijing, Chongqing, Hong Kong, Urumqi
North Asia Standard Time,+07:00 Krasnoyarsk
SE Asia Standard Time,+07:00 Bangkok, Hanoi, Jakarta
Myanmar Standard Time,+06:30 Rangoon
Sri Lanka Standard Time,+06:00 Sri Jayawardenepura
Central Asia Standard Time,+06:00 Astana, Dhaka
N. Central Asia Standard Time,+06:00 Almaty, Novosibirsk
Nepal Standard Time,+05:45 Kathmandu
India Standard Time,+05:30 Chennai, Kolkata, Mumbai, New Delhi
West Asia Standard Time,+05:00 Islamabad, Karachi, Tashkent
Ekaterinburg Standard Time,+05:00 Ekaterinburg
Afghanistan Standard Time,+04:30 Kabul
Caucasus Standard Time,+04:00 Yerevan
Tbilisi Standard Time,+04:00 Tbilisi
Baku Standard Time,+04:00 Baku
Arabian Standard Time,+04:00 Abu Dhabi, Muscat
Iran Standard Time,+03:30 Tehran
E. Africa Standard Time,+03:00 Nairobi
Russian Standard Time,+03:00 Moscow, St. Petersburg, Volgograd
Arab Standard Time,+03:00 Kuwait, Riyadh
Arabic Standard Time,+03:00 Baghdad
Turkey Standard Time,+02:00 Turkey
Israel Standard Time,+02:00 Tel Aviv, Jerusalem
Syria Standard Time,+02:00 Syria
Jordan Standard Time,+02:00 Jordan
FLE Standard Time,+02:00 Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
South Africa Standard Time,+02:00 Harare, Pretoria
Egypt Standard Time,+02:00 Cairo
E. Europe Standard Time,+02:00 Bucharest
Lebanon Standard Time,+02:00 Beirut
GTB Standard Time,+02:00 Athens, Beirut, Istanbul, Minsk
W. Central Africa Standard Time,+01:00 West Central Africa
Central European Standard Time,+01:00 Sarajevo, Skopje, Warsaw, Zagreb
Namibia Standard Time,+01:00 Namibia
Romance Standard Time,+01:00 Brussels, Copenhagen, Madrid, Paris
Central Europe Standard Time,+01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
W. Europe Standard Time,+01:00 Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
GMT Standard Time,+0:00 Dublin, Edinburgh, Lisbon, London
Greenwich Standard Time,+0:00 Casablanca, Monrovia
Azores Standard Time,-01:00 Azores
Cape Verde Standard Time,-01:00 Cape Verde Is.
Mid-Atlantic Standard Time,-02:00 Mid-Atlantic
Argentina Standard Time,-03:00 Argentina
E. South America Standard Time,-03:00 Brasilia
SA Eastern Standard Time,-03:00 Georgetown, South America Eastern Time
Greenland Standard Time,-03:00 Greenland
St Pierre and Miquelon Standard Time,-03:00 St Pierre and Miquelon
Uruguay Standard Time,-03:00 Uruguay
Newfoundland Standard Time,-03:30 Newfoundland
Atlantic Standard Time,-04:00 Atlantic Time (Canada)
Falkland Islands Standard Time,-04:00 Falkland Islands
SA Western Standard Time,-04:00 La Paz
Paraguay Standard Time,-04:00 Paraguay
Pacific SA Standard Time,-04:00 Santiago
Venezuela Standard Time,-04:30 Venezuela
SA Pacific Standard Time,-05:00 Bogota, Lima, Quito
Cuba Standard Time,-05:00 Cuba Standard Time
Eastern Standard Time,-05:00 Eastern Time (US & Canada)
US Eastern Standard Time,-05:00 Indiana (East)
Central America Standard Time,-06:00 Central America
Central Standard Time,-06:00 Central Time (US & Canada)
Mexico Standard Time,-06:00 Guadalajara, Mexico City, Monterrey
Guatemala Standard Time,-06:00 Guatemala
Honduras Standard Time,-06:00 Honduras
Canada Central Standard Time,-06:00 Saskatchewan
US Mountain Standard Time,-07:00 Arizona
Mexico Standard Time 2,-07:00 Chihuahua, La Paz, Mazatlan
Mountain Standard Time,-07:00 Mountain Time (US & Canada)
Pacific Standard Time,-08:00 Pacific Time (US & Canada); Tijuana
Alaskan Standard Time,-09:00 Alaska
Hawaii-Aleutian Standard Time,-10:00 Adak
Hawaiian Standard Time,-10:00 Hawaii
Samoa Standard Time,-11:00 Midway Island, Samoa
Dateline Standard Time,-12:00 International Date Line West

Yes, Tonga is 13 hours of UTC and 25 hours ahead of those little-known places that are UTC-12. In fact, Kiribati Istland (not shown here) is +14 so a day and 2 hours ahead of the others. This wasn’t meant to be easy.

Anyway, I simplified the list further to:

+13:00 Tonga
+12:00 Auckland, Wellington, Fiji, Marshall Is., Kamchatka
+11:30 Norfolk Island
+11:00 Solomon Is., New Caledonia, Magadan
+10:00 Canberra, Melbourne, Sydney, Brisbane, Hobart, Guam, Port Moresby
+09:30 Darwin, Adelaide
+09:00 Seoul, Yakutsk, Osaka, Sapporo, Tokyo
+08:00 Taipei, Ulaanbaatar, Perth, Kuala Lumpur, Singapore, Irkutsk, Beijing, Chongqing, Hong Kong, Urumqi
+07:00 Bangkok, Hanoi, Jakarta, Krasnoyarsk
+06:30 Rangoon
+06:00 Sri Jayawardenepura, Astana, Dhaka, Almaty, Novosibirsk
+05:45 Kathmandu
+05:30 Chennai, Kolkata, Mumbai, New Delhi
+05:00 Islamabad, Karachi, Tashkent, Ekaterinburg
+04:30 Kabul
+04:00 Tbilisi, Yerevan, Baku, Abu Dhabi, Muscat
+03:30 Tehran
+03:00 Moscow, St. Petersburg, Volgograd, Nairobi, Kuwait, Riyadh, Baghdad
+02:00 Turkey, Tel Aviv, Jerusalem, Syria, Jordan, Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius, Harare, Cairo, Bucharest, Beirut, Athens, Beirut, Istanbul, Minsk

+01:00 Sarajevo, Skopje, Warsaw, Zagreb, Brussels, Copenhagen, Madrid, Paris, Belgrade, Bratislava, Budapest, Ljubljana, Prague, Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna, West Central Africa, Namibia
+0:00 Dublin, Edinburgh, Lisbon, London, Casablanca, Monrovia
-01:00 Azores, Cape Verde Is.
-02:00 Mid-Atlantic
-03:00 Argentina, Brasilia, Georgetown, South America Eastern Time, Greenland, Uruguay
-03:30 Newfoundland
-04:00 Atlantic Time (Canada), Falkland Islands, La Paz, Paraguay, Santiago
-04:30 Venezuela
-05:00 Eastern Time (US & Canada), Bogota, Lima, Quito, Havana
-06:00 Central Time (US & Canada), Central America, Guadalajara, Mexico City, Monterrey, Guatemala, Honduras, Saskatchewan
-07:00 Mountain Time (US & Canada), Arizona, Chihuahua, La Paz, Mazatlan
-08:00 Pacific Time (US & Canada), Tijuana
-09:00 Alaska
-10:00 Hawaii, Adak
-11:00 Midway Island, Samoa
-12:00 International Date Line West

Also available in cut-and-paste form

Just as I was writing this post on ignorance of open source models, there was news of a major publisher making a print edition of Wikipedia. This led to backlash reactions which illustrate exactly the kind of misunderstanding that arises when people don’t get open-source licenses (via ReadWriteWeb.

The whole point of Wikipedia is to provide a voluntary online source of information. That is why people voluntarily gave up some of their time to write the articles for free in the first place. It is a noble project, the writer believed in the project and so they participated in it. Had they known that Wikipedia would then use their work in a commercial printed venture, I’m sure they would have had second thoughts about writing those articles. At the very least they would have demanded a contract and perhaps a guarantee of financial compensation later.

Now the author might well have a point - maybe people don’t know what they’re doing when they’re adding to wikipedia and maybe wikipedia should make it more clear. Still, I find it worrying that they would consider some big ball of wrong has been cast upon them. A great place for them to start researching would be the GNU article on wikipedia, the one article whose authors knew they would be victims right from the start ;).

There are several disturbing things about this:

• First, if this ignorance does exist, that’s unfortunate. If anyone is a major enough contributor to wikipedia to care about this, they really ought to familiarise themselves with the basics of the GNU license they’re operating under. (And for the record, I think it’s a shame wikipedia uses GNU instead of a more permissive license.)
• It’s scarcity mentality. Boo-hoo, the publisher is making money and I’m not, so they must be ripping me off. Yeah right! If you were willing to contribute to wikipedia before, your content remains just as available online as before. What’s changed? Nothing, except someone else is going to make your content more digestible in certain contexts and accessible to more people. And yes, they will make money from it. Maybe they’ll make lots of money. Whatever. That’s what happens in a modern knowledge economy - people like Larry and Sergey make money without denying it from someone else. Far from removing others’ assets, they actually add value to everyone else. Likewise, the existence of a print wikipedia will also add, in its own way, to society’s wealth. (Although not the forests. That’s a separate, more legitimate, argument.)
• There’s an old psychology result that says people care more about their spending power in relative terms than absolute terms. ie you ask them “Would you rather earn $50,000 a year while other people make $25,000, or would you rather earn $100,000 a year while other people get $250,000? Assume price of service and goods would remain the same.” People would rather earn half as much, if it means they are richer rather than poorer than others. That result says a lot for this kind of irrational backlash against anyone who might cash in on their “volunteer” work.
• It’s hardly the first time this has happened. Answers.com and hundreds of fairly useless SEO sites have been profiting from wikipedia content for years. I’m surprised it took this long for someone to do it. I could imagine countless opportunities for books on niche content - bizarre trivia, country almanacs, movie guides, etc etc.

That a company can do something like this without having to formally negotiate with the wikipedia foundation and a million contributors…I call that a cause for celebration, not outrage. Personally, I’ve contributed various boring tidbits to wikipedia and I hereby invite any publisher to print what they want from my contributions, even if there’s only limited demand for hard copy about snowclones.

Controversy arose in several open source projects last week: Ext JS, SpringSource App Platform, and the SWF/FLV specs. Dion has a good summary and concludes with a reminder that most people could care less:

Finally, I know that 99% of the developers out there may not even care, let alone users. There are open source wonks who like to argue about licensing and methodologies. As I watched the John Adams HBO series, I felt a little like those fine chaps arguing over the finer details of things. Many of the people didn’t know what was going on there, or why a particular Article was written the way it was. But, they had drastic implications for the people. I think that the same can hold here for some of the projects.

Now this ignorance of open source models in my experience and an interesting phenomenon. It took open source until around the middle of this decade for even the basic definition of open source to be understood, and to some extent, accepted, by mainstream IT and business communities. That’s about five decades after the practice began, two decades after Stallman’s GNU Manifest, and almost a decade after Raymond et al declared “Open Source” teh nu k00lness.

The basic definition of open source is understood, but as Dion notes, most people have no idea how the models vary, or what the implications are. Which is unfortunate, because the commercial implications are indeed vast.

I consider myself an expert on this topic ;P because I once picked up a copy of an O’Reilly book on open source models at a heavily reduced price and flicked through it intensely for at least two hours. Okay, so not quite an expert (!), more an armchair ignoramus, but certainly a stakeholder as both a consumer and publisher of open-source. And I’m hardly the Richard Stallman of the Ajax world either, but whenever I publish software that could potentially be used or adapted by someone, I make the tiny effort of including a license notice. Sometimes it almost seems arrogant to do so when the software is so trivial, but I’d rather do that than leave the license unstated, in which case it would come under the silly default, i.e. standard restrictive copyright. (Even if you agree with standard copyright, doesn’t it seem silly that rights to anything anyone creates belongs to them by default, and for the greater part of a century?)

Well, since I include a notice, I’ve had to think about which license to use.

In my dim-witted view of models, there are three key categories. All allow people to use it free of charge and generally remove any liability from the provider. They vary in what happens when people change it:

• Copyleft/Viral (e.g. GPL, Creative Commons Share-Alike) - Anyone who modifies it must release the modified version.
• Permissive (e.g. MIT, BSD, Apache) - You don’t have to release your modifications, though you still have some restrictions such as retaining the original license and author details.
• Public Domain - Anything goes.

There are other distinctions too, e.g. around charging and attribution to the original creation; but the above distinction is the most important in most cases. And this is the sad thing: most IT and business people simply don’t understand these distinctions and the implications they have.

You can argue about ethics until you’re blue in the face, but the reality is, there’s no absolutely “right” or “wrong” model. It’s just horses for courses and being aware of the implications. Personally, I do have a hard time justifying copyleft-style licenses and I sometimes wonder how many people release stuff as GNU just because they associate it with open-source, without realising the full implications. I’ve worked in many commercial situations where GPL is unacceptable and I hate the idea that developers will be in the same situation as me, i.e. gleefully eyeing something that would scratch their itch, but not being able to use it. Incidentally, Ajax Patterns was initially released with the more permissive Creative Commons license, but following the book deal, O’Reilly asked me to change it to share-alike as it discourages other publishers from publishing their own version of the same book, which has apparently happened in the past. This is similar to the reason some companies release dual licenses - GPL and standard copyright. It means anyone can use it for free under GPL, but other companies can’t update and re-distribute for a fee. I can see that. It creates an incentive to release as open-source.

It’s convenient for me to have a default license choice, so I don’t have to think too hard whenever I release something. I have chosen The MIT License because it is extremely concise, and is basically the smallest (in words) mainstream license that satisfies my main aims: To allow people to work with it freely and free of the restrictive burden GNU creates; to receive credit for my work; to be free of liability. The three paragraph license can easily be embedded in any source file, which is great for releasing one-file libraries without having to include a separate README or LICENSE file. Best of all, it’s easy to grok. If developers should be able to consume open source as easily as pulling out books from a shelf, you really don’t want to release software under a license that only a lawyer could love. Don’t let MIT’s concise nature fool you into thinking it’s only used for toy projects: MIT is used in Rails, Mono, and the system for which it was originally written: X-Windows.

The MIT License looks like this:

Copyright (c)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

I discovered at last minute a developer event on Yahoo! FireEagle at Covent Garden tonight and decided to rush down there. FireEagle is pretty intriguing as the first serious attempt at an OAuth API (though Google Contacts now qualifies too). For me, that was the main draw; but the actual service it offers is also compelling.

What’s FireEagle?

Location based services have been hyped for years. By now, you should be walking around and receiving reviews of local restaurants on your phone, browsing nearby tourist attractions, and seeing which of your friends is in your vicinity. However, it hasn’t caught on. The main reason is stovepipes and walled gardens. Your mobile provider might have an API available, but probably restricted access to a very limited set of developers. A mix of privacy and commercial concerns have rendered this whole area practically useless.

Enter the eagle. FireEagle completely opens up this area, by offering a model that is flexible and open, but without compromising user privacy. It’s an API that essentially tracks one thing: Where in the world are all FireEagle users?

In other words, the FireEagle API allows any client to update a user’s location and any client to retrieve a user’s location. Of course, the user must consent to all this activity, and that’s where OAuth comes in - as a way for users to say, for example, “I trust app abc to update my location and app xyz to read my location”. So FireEagle detaches location providers from location consumers, opening up an entire ecosystem.

What kind of clients act as location updaters? You might think it’s all automated stuff, like mobile devices and IP numbers, but actually many updaters are manual. Here’s a sample:

• Mobile phone app. Anyone with the right access details could write a mobile phone app to use cell tower information, built-in GPS, or any other cues, to update location as the user moves around. This is the no-brainer example of an automatic mobile updater.
• Twitter. When you tweet with “L: london”, a twitter monitor app could notice that and notify FireEagle. (As with all cases below, you must have authorised the monitor app to do that.) This example illustrates that users aren’t always passive lemmings walking around with a mobile updater app in their pocket. It may be that location data is only ever updated when a user proactively tweets their location.
• A client that watches you adding geotagged photos to Flickr, and assumes you are in the last location you uploaded.
• Specialised tracker device. Devices based on GPS (e.g. SPOT) could easily be made to update FireEagle with their location.
• Car app. Based on GPS, a car’s location could be tracked using FireEagle. (The car, not the driver.)
• Travel card. (My example.) Theoretically, your travel card could update FireEagle location as you move around. Same for transponder devices in cars.
• Many, many, more examples.

What kind of clients act as location consumers?

• Find nearby friends, tourist attractions, pubs, etc.
• Find currency rate (since you know what country they’re in)
• Phrases in the local lingo or an online dictionary
• Location based games
• Many, many, more examples

Some clients may act as both updater and consumer.

Privacy

The other thing FireEagle gets right is great concern for privacy - users can give out as much or as little data as they like, and they can stop the service at any time. The first way this happens is with OAuth, which lets you manage which services can perform what actions. You can start and stop this at any time. In the future, there will be a simple client to let you log in from your mobile and control all this. In particular, you will probably be able to suspend all tracking at any time.

Additionally, you can apparently set granularity, so you could expose just a general area, e.g. whiiich city or country you’re in, instead of a particular co-ordinate.

In the future, you will probably be able to authorise a client just for a certain time, e.g. during a conference, after which it can no longer access your data.

At some point, historical data may become available. The team said if this happens, they will allow users to delete and edit their past data.

In summary, the team has been very careful to ensure users have complete control over their own data,

Very Raw Notes from Presentation

Tom Coates is talking about FireEagle.

FireEagle is the old CS classic: a layer of intermediation - between location identification systems and location consumer systems. As a user, I can tell FireEagle where I am and any permissioned app can make use of that data.

London is about the most frequent location for fireeagle

What would your existing/past apps look like if they had location services available?

e.g. Navizon

e.g. ZoneTag

e.g. Firebot - Make it your twitter friend and direct message your location to it.

e.g. BrightKite - cf dodgeball

e.g. Rummble

e.g. Plazes - determines your location via wifi. Then shows where you are on map, people around you, etc etc. And updates FireEagle

WikiNear - ~1M geo-tagged articles in wikipedia. Wikinear exploits that data - as you’re walking around, shows you the closest POIs that are in wikipedia.

Lightpole

Outside.In

Fireball - where your friends are

Fire Widgets - weather where you are, nearby Flickr photos

Moveable Type

Facebook “friends on fire” app - shows where your friends are and updates your Facebook status

Could be great…

Spot - specialised comms/phone device for backpackers, aid workers, etc. ~100pound for device, 100pound a year and keeps updating your location every� ten minutes. Doesn’t integrate yet but great example if it did

Ambient Orb - e.g. changes colour as you move away

Nabaztag

Geotagging all user generated content - cinema listings, local traffic, local TV stations, nearby friends, weather forecast, local exchange rates, public holidays, windspeed. A lot of this is on wikipedia thanks to geotagging.

Friends and family widgets. e.g. where they are in the world, what time it is, weather, etc. (A gadget for each person.)

Last.FM - On cracked iphone, can get mobile scrobbler on iphone. What if it recorded where you were, then you could see which songs people play in particular areas. Cool!

Pacmanhattan - Lots and lots of game ideas (idea: scavenger hunt! reminds me of geocaching)

(later mention: geocoding animals, e.g. track migration)

Later on, expecting it to track historical data. (and since it will be user-modifiable which means you could back-track your entire life! (or someone elses eg fake shaekspeare))

http://tinyurl.com/5gtj92

http://tinyurl.com/3uklhl

Building an APP

(http://fireeagle.yahoo.net/developer/documentation/getting_started)

1 - Get API key 2 - User authorises your app 3 - Make API calls to Fire Eagle Outside.In -�

Who’s within an area

Each consumer key and secret identifies an application using Fire Eagle.

User Authorises ….

There are three models and the difference is purely to do with differences in (app triggering web page) and (web page triggering app). Web: Can trigger in both directions Mobile: Can’t trigger in either direction (maybe, but can’t assume it) Desktop: App can trigger web page, web page can’t trigger app

Web App model: Request token

I asked which model was used for widgets. Answer: Desktop. (Makes sense, with current technology. Web model would cause redirection from container. Later on, Opensocial will have oauth built in.)

Core Concepts

Note: social graph (user and friends) is beyond scope

location - point or bounding box location hierarchy - set of locations

Exposed RESTfully:

• user() - duh
• lookup() - provide location string and choose from list of resolutions (which “london”??)
• update() - duh. call it and it “moves you”
• within() - ?
• recent() - “map of soho and everyone in there” OR “last 100 updates from my users”

walking through http://github.com/mojodna/fireeagle-tutorial/tree/master/ruby

Will probably support xmpp/Jabber too - more appropriate than HTTP for this

Aptana Cloud has now been announced. This is exciting news and a step closer to server-side Javascript world domination. You don’t have to use Javascript, as the platform offers several engines, but from my perspective, the most exciting thing is the inclusion of Jaxer. So it should be easy to deploy server-side Javascript to a completely scaleable platform.

As for the more headline feature, it is a general cloud play. It will target the existing Amazon/Google/Joyent/others clouds (a “designed to go meta” as Dion puts it) rather than being a YAC (yet another cloud). My personal experience with the much-hyped Amazon EC2 has been nothing but pain, pain, pain. It might be fine for your run-of-the-mill Web 2.0 startup, but casual use? Forget it. Give me bog-standard ssh any day. If Aptana can solve that problem, and I have no idea if they can, but if they can, I’m sold. Key to the strategy will be integration with the Aptana IDE. That said, I find the Heroku idea of Cloudies (cloud IDEs) fascinating, so it would be nice if a product like this also offered some rudimentary cloud editing support in the future. (Enough to at least fix a critical bug from the comfort of an internet cafe.)

Kevin Hakman got in contact with me after the Javascript Grid article and kindly offered to let me review the beta, which is still on the cards, so I’ll let you know how it goes once I get access. I’ll also be interested to see how much more expensive it is to hit a Jaxer script versus a PHP script.

Dion is to blame for the trivia that follows…

The new rage seems to be piping this to your blog:

history | awk ‘{a[$2]++}END{for(i in a){print a[i] ” ” i}}’ | sort -rn | head

It reminds me of history class at school. Always painfully boring, which is such a crying shame, as history itself is fascinating. How school managed to take the subject that could be so enjoyable, and such a tie in to all other subjects, and instead make it incredibly boring is a crying shame.

Drum roll …

150 ls
115 cd
60 vi
29 fortune -ooo
21 ssh
10 maven
10 cd..
9 svn
9 ping
9 find
7 rm

There, I dunnit. Offensive meme, but easiest post. Ever.

At present, the OpenSocial containers are new and the whole process is still quite difficult from a developer’s perspective. These are unfortunate barriers to adoption which the containers could overcome with some redesign.

The challenges at present are:

• Manual signup and approval process required. Even to get onto the sandbox area, you have to go through a manual signup and approval process, which usually takes a day or two. A human is in the loop verifying your details. At that time, the developer may have lost interest, or the mail may never get to them.
• Lack of test accounts. The sandbox accounts usually can’t interact with non-sandbox accounts - that’s what makes them “sandboxes” and this is a wise policy. However, what do you do, as a developer, when you want to test with a large group of friends? You could friend other developers, but testing is going to get a little tired if you have to keep asking them what happened. The problem is the manual signup process - you have to add new users with fake details for approval by the container - weird! On Orkut at least, you can also invite friends from your test account, so it’s possible. And, oh yeah, I hope you get a kick out of CAPTCHA. You’ll be filling in a *lot* of CAPTCHA forms as you build up your social network of imaginary friends! One to create the account, one to verify email, one for good luck here, one more just because why not. And that’s for each user on each container! If I was running these containers, I would make it even simpler and just create an initial block of 10 fake friends (some friends with each other…pick your favourite soap opera) and let the user seamlessly add new ones too.
• Older versions and Missing Features. Ning and Plaxo are hosting OpenSocial 0.5, whereas 0.7 has been out for a while and 0.8 is about to come out. I can’t blame them for not upgrading all the time, but it still makes development more difficult. As for missing features, I noticed this with Hi5. It’s a good implementation, but still missing a critical feature - UserPrefs. This is just the multi-container nature of OpenSocial.
• Slow code-test cycle. When testing with a container, you have to change the gadget on the server and the container will then reload it and render it. This reloading process will always take some time, but the container can do as much as possible to eliminate any other delays. Unfortunately, they don’t make it easy at present. I refer specifically to caching. You obviously don’t want your gadget to be cached during code-test cycles. Caching is usually enabled by default, even in the sandbox. That’s kind of dubious - you would think a sandbox should load the gadget each time. But okay, I can accept that decision as it’s useful when you’re testing the gadget 100 times not to be re-downloading it all the time. However, it’s usually not clear or documented how to suppress caching when you want to. Again, the containers should be making it dead simple if they want to encourage development…how about a caching on/off checkbox somewhere in the gadget chrome or settings menu?

There is a lot the containers can learn from Facebook, and they will need to for OpenSocial to really take off and compete against it. For comparison, here is how Facebook deals with the issues above:

• Manual signup and approval process required. Facebook makes this completely automated. You create a normal Facebook account and simply visit a special URL to make it a developer account.
• Lack of test accounts. It’s easy to create test accounts in Facebook - you just keep creating normal accounts and flipping them to become developer accounts by visiting that special URL.
• Older versions and Missing features. With Facebook, there is only one implementation, so only one definitive version of the API. There’s nothing OpenSocial can do about this directly. It’s simply a consequence of the “Write Once, Run Many” aspiration and the only way for the community to deal with it is to be better in other ways, and to at least be very explicit about what each container does and does not support.
• Slow code-test cycle. This doesn’t arise in the same way because the model is either based on an iframe directly to your site, or FBML you enter into a form. The OpenSocial gadget model - an XML sitting on a server somewhere - is neater as there’s no form involved; everything’s encapsulated in the XML file. However, it does introduce the whole question of caching and the containers should be doing all they can to simplify the development process to that end.

I’m a great believer in the OpenSocial vision; hence, I hope the containers will be working to minimise these obstacles. Right now, it’s okay for professionals, but there are enough hurdles there to hold back an army of potential hobbyist developers from uneashing their creativity on this platform.

I made a little music mashup you might enjoy using.

A Little Music

As I was playing around with the new layout of this blog, I added a Last.FM widget to the sidebar. It looks like this:

(May not render if you're reading this from a feed reader.)

Great. Now I can listen to trance from the blog. Trance is good for coding. So that's ace. But I couldn't stop there, could I?

Widgets, Widgets, Everywhere!

I made this page with 30+ gadgets in all sorts of genres. This is good for those times when I'm not coding and want to listen to something else. Being in the cloud, it means I can easily listen to whatever I feel like when I'm in an internet cafe or the such like. So even more ace.

Make Your Own Jukebox

In the spirit of sharing, you can easily make a page containing your own favourite music. The URL for the default music page resolves to something with a ridiculously long list of genres:

For example, you might be a more passionate fan of contemporary Japanese music than myself, in which case you would concoct the following URL and save it to your delicious bookmark manager to enjoy many years of musical gratification:

http://softwareas.com/music?tags=j-ska,j-pop,j-punk,j-hop,j-rap,anime

Add A Player on the Fly

One other feature is that you can add a new player on the fly. This again is great for travelling around as it will let me easily listen to any genre I care for without even having to edit the URL.

(Unamusing trivia: I actually caused a bug at first by using "gray" as the colour name here. I'm used to working with American spelling for programming of course, but then last.fm is a UK company and the name you want is actually British spelling, i.e. "grey".)

Obligatory Wishlist I'll Not Really Get Around to Implementing But it's Cathartic to Braindump it Anyway

If I was going to do more work on this, I would:

• Make it into a widget-like portal which lets you add/remove/layout etc and save settings within a hackable URL (using Unique URL. You could argue the whole thing is useless as you could achieve the same thing in iGoogle/Shindig, but sometimes a specialised interface, tucked neatly inside a separate tab, works best.
• Provide more flexibility on layout
• Add support for bands, not just tags
• Run it on a separate page without the blog layout
• Keep the loldog

From the dubiously-related-to-the-topic-of-this-blog department, I finally devoted a lazy few hours to getting this blog sorted! It was previously crawling, with pages loading at around 40 seconds. (According to WebWait, the premium website benchmarking tool, of course ;)).

• Upgraded to WP 2.5.
• Removed WP-Cache. Installed Super WP-Cache and set up htaccess correctly. At this point, caching starts working whereas it previously did not. Still, uncached pages remain dog-slow.
• Changed to default WP theme and pages load fast. This test tells me that my theme is wonky.
• Try to fix theme. Nothing works.
• Instead of going back to default theme, I switch to the pretty cutline theme. Fortunately, it works.
• Re-incorporate the old stuff.
• Remove a ton of sidebar links from 2004. While WP 2.5 admin interface is pretty and more usable, editing links still sucks as much as it did 4 years ago. I wish I could find a plugin that just gives me a data grid of links to maintain.
• The blog has a cleaner look, pages are generated faster, and caching is serving them faster. Plus it's easier to maintain and admin. Happiness and world peace reign supreme in the land of plentiful chocolate.

Google App Engine launched this week and one controversial aspect was that it only works for Python. It wasn't a big deal to me. Firstly, it's a good way for Google to limit the initial market. Secondly, Google specialises in Python and not Ruby - quoth Yegge: "One of the fences in this big playground is your choice of programming language. You have to play inside the fence defined by C++, Java, Python, and JavaScript." After all, Google has Guido but not Matz or DHH. (I wonder how many times someone has asked that guy if he'd consider a position at Google!) Thirdly, who cares? Do you really think it will stay Python-only for long? Heavens to Murgatroyd!!!

Dion's take (read his post for the full detail):

Anyway, I have a dream and surprisingly it doesn't involve Ruby and unsurprisingly it does involve the magic bullet that is server-side Javascript.

How cool would it be if Google bought Aptana or AppJet - or did their own work with Jaxer or Rhino - and made a robust, elastic, server-side Javascript platform? Then roll in Rhino and Rails, hopefully reworked from Rails considerably to take into account the synergies delivered by dual-side Javascript. Backed by BigTable of course!

That's the tipping point right there!