Kåre Kjelstrøm’s online tracks on software architecture and development
Okay, so given that we have a Paris in Denmark as well, I guess I should have expected there to be a Copenhagen in the USA also. Turns out my AccuWeather widget defaults “Copenhagen” to “Copenhagen, USA” … obviously. When you enter “Copenhagen, Denmark” you get a more accurate picture of the weather situation:
Sorry about the noise AccuWeather - maybe you should consider adding a country code to the city name as well to avoid similar situations in the future?
… especially of the future! This fact of life has to be a daily nuisance to meteorologists all over the planet as they struggle to interpret satellite images of the Earth’s atmosphere painted in all colors of the spectrum. Meteorology is a science of probabilities, a trade whose precision diminishes rapidly the farther into the future predictions are made. Tomorrow’s weather can almost always be predicted with certainty, but what about today’s?
InAccuWeather
The OS X Dashboard sports an “Accuweather Widget”, which, although extremely slick in its look and feel, fails miserably at displaying even the current weather situation. At least in Denmark. Today on July 22nd 2007 AD the Danish Meteorological Institute (DMI) informs anyone who shows an interest that it is raining. In fact it will rain so much here that the institute has issued a warning for “extreme weather conditions” with 17°C and yet AccuWeather thinks that we have a cloudless sunshine here and 27°C!!
Did anyone say “useless”??
What to do? I decided to ditch AccuWeather and write a widget that grabs the current 5 day forecast image from DMI. The result can be seen in the picture below with AccuWeather gleaming sunshine on a rainy Sunday:
The image caching nightmare
Writing a widget is not rocket science, and requires little more than HTML and Javascript skills in its most basic form. The Dashboard is basically a specialized web browser. Brilliant! Unfortunately this also means that widgets inherit any problems that browser applications suffer. One of these problems relate to the caching of images. In this case, the forecast, which DMI has decided to publish on the same image URL. The current 5 day forecast for Eastern Jutland, for instance, is always published on http://www.dmi.dk/dmi/200611090030_cms6dognostjylland.jpg”. Once the Dashboard has downloaded this image, it will be cached for the lifetime of the widget i.e. until it is eventually removed, and so the forecast slowly but surely becomes irrelevant.
I spent the better part of an afternoon scouring the web for solutions to this annoying problem and ran in to numerous frustrated Javascript developers. After pondering the problem some more I came up with the following possible solutions:
Caveat: While my solution works, it will fill /tmp/ with images: one per day per region you choose to display. I could have implemented a cleanup facility in the shell script as well, but I am not a big fan of scripts that perform “rm” on my local folders. I leave that as an exercise for those with strong stomachs.
The widget can be downloaded from this link. Quote Apple: “Mac OS X v.10.4 Tiger is required. If you’re using Safari, click the download link. When the widget download is complete, the widget installer appears. Click Install if you want the widget installed on your Mac. If you’re using a browser other than Safari, click the download link. When the widget download is complete, unarchive and open it to show the widget installer.”
Enjoy! And have a sunny summer …
The Danish Government has launched a large scale initiative to modernize and digitize the Danish Public Sector and is channeling information about the details via the website modernisering.dk. One important goal of this exercise is to increase the level of service provided to citizens, while at the same time reducing the cost of delivering it.
Government Agencies, Ministries, Counties, and Regions, all flock (some more than others) to the Internet to provide self-service to it-literate citizens. Such a flurry of service provider activity is bound to become slightly chaotic lest something be done, so enter the portals: Sundhed.dk for health care services, Borger.dk for citizen services, Virk.dk for company services, and The Danish Nature and Environment Portal for … well you guessed it.
Virk.dk and borger.dk are currently having makeover and will be launching new versions within the not-so-distant future. The remake will focus on bringing new services to citizens and companies thru leverage of the enabling infrastructure that we are so fortunate to have here, including (but not limited to) a national address register of all citizens (CPR), and a national digital certificate initiative (OCES). The vision is to provide two very thin portals whose primary functions are to expose (web based) services from other public entities. In other words, the portals will not implement any business logic, but delegate actual service implementations to other servers, elsewhere.
Many service providers will be exposing services on more than portal. Thus, in order to reduce the cost of implementation and the time to market, it becomes imperative that the portals agree on integration mechanisms …
For the past months I have been working intensely for the Digital Task Force with a few colleagues to provide a common service provider integration model (OIM) for borger.dk and virk.dk. Our efforts were initially restricted by the vision of thin portals, and by a Gartner report, which pointed to 4 different integration technologies: simple linking, embedded frames, web services remote portlets (WSRP), and the Java Portlet Specification (JSR-168). As we dug into it, however, JSR-168 disappeared from the radar because portlets written with this technology will have to be installed into the portal server, hence violating the “thinness†principle (and introducing loads of other issues).
The Digital Taskforce has bravely decided to expose the OIM to the public on a project WIKI - while it is constructed. At the time of writing, however, you will find only the main document for which we’re not responsible, and not the 3 appendices for which we, are as they are currently thru an internal hearing.
On the horizon there will be a public conference on September 5th 2007 where 1.0 of the OIM will be presented. By then, if not sooner, everything should be publicly available.
View Kåre Kjelstrøm's profile
