Dennis Forbes on Pragmatic Software Development
Subscribe to RSS
 
Thursday, October 20 2005

[Note: Some have noted that it should be Daylight Saving Time, without the pluralization of Saving. I, like many, use it more as a general-use title rather than a literal statement - given that it isn't actually saving daylight - and I generally hear it referred to as Daylight Savings Time. Just thought I should mention that.

If one wants to be a pedant, I believe it should actually be Daylight-Saving Time]

The Ontario government caved today, rashly deciding to follow the lead of a ludicrous U.S. energy bill rider, extending Daylight-Saving Time by three weeks in the spring, and a week in the fall (switching into DST on the second Sunday of March, rather than the first Sunday of April as it currently is, and switching back to Standard time on the first Sunday of November rather than the last Sunday in October).

Given that many don't entirely understand DST, I thought I'd share a graph I made some time back (I originally planned on turning the source algorithm into a web service to allow one to punch in the inputs such as location and generate their own graph, but could never justify spending the time on it).

Toronto Sunrise/Sunset DST

All values are calculated for Toronto, Ontario, for 2005. The red line represents EST sunrise, the yellow EST solar noon, while the cyan line represents EST sunset. The purple lines represent the 9-5 workday, adjusted in the summer months to account for DST (where 9-5 is really 8-4). The blue lines represent the extensions brought about by this change (3-weeks earlier in the spring, one week later in the fall). To recap - only the workday period on the graph above calculates in DST (e.g. the 8pm sunset during the summer is 9pm on the clock during DST, and the 4:20am sunrise is actually 5:20am on the clock).

As much as I dislike the incredibly costly confusion and complexity of DST (my two and a half year old still hasn't adjusted), there is a small amount of logic behind it - Presuming that human beings don't naturally adapt to the sun coming up earlier during the summer, DST moves an hour of this presumably unused time into the traditional post-work hours, "lengthening" the evening (not really lengthening the evening, but artificially doing so by moving the traditional 1950s work hours earlier in the day).

Many people would argue against this, saying that the summer hours give them an opportunity to jog, garden, go to the gym, and otherwise take advantage of the extended pre-work hours. Nonetheless, DST is geared towards those who do nothing until their pre-work preparation (e.g. the alarm clock goes off an hour and 30 minutes before the work day starts). For those people DST is entirely beneficial.

Extrapolate that logic out, though, and there should be a second layer of DST that moves the clock yet another hour forward during May to September. Maybe an hour more during June. Perhaps we should have a dynamic clock, such that 9am is an hour after sunrise year round.

Humor aside, there is a tremendous risk of this DST extension, especially coming into force so quickly. Having worked with a number of daylight-saving time related software problems (please use UTC people, or at the very least disregard DST), I would wager that there will be significant ramifications of this. Millions of dollars will need to be spent preparing for, and then cleaning up after, what many seem to think is a simple date change.

Anyone interested in the source data that I generated for this can find it here (it's a Microsoft Excel worksheet).

http://www.yafla.com/

Thursday, October 20 2005

One of the big marketing pushes to help hype the release of SQL Server 2000 was a huge onslaught of the benchmarks - before SQL Server 2000 was even available to buy, its results were dominating the TPC results, primarily via clustering. Shortly thereafter, it is purported, Oracle demanded that the TPC separate clustered and non-clustered results. Not long after SQL Server was doing very well in the non-clustered category as well (on very, very, very expensive machines - Big Iron).

SQL Server had joined the big leagues. Any questions about its scalability dissolved.

Remarkably we're on the cusp of the real release of SQL Server 2005 (Nov. 7th I believe), yet there has been barely any noise at all in the TPC results. It has taken more of a lead in the price/performance TPC-C results, and it has pushed a little higher in the pure performance results - though that has more to do with beefier hardware - but all-in-all it has been very sedated in contrast with 2000's release. I wonder if the TPC results simply aren't considered important anymore (probable, giving how old most of the leader results are. 50% of the top 10 are from 2003)

Is the TPC no longer relevant? Does SQL Server 2005 simply offer marginal scalability/performance advantages for the TPC suites?

On the topic of scalability, SQL Server's clustering capabilities could use some improvements. As it is, scaling your database out across two or more servers is most certainly a non-trivial task. It's something you really have to design around (distributed partitioned views don't partition themselves, and it's a leaky abstraction). In an ideal world you could add a new server, install SQL Server and choose "add to the cluster" and it'll automatically propagate some data over and start sharing the load transparently. If it were so easy and elegant Microsoft would see a tonne of license sales as people scaled out.

I'm not an Oracle expert, but I believe that's how their clustering solution has been built.

Of course that sort of clustering is really focusing on the computation end, which really isn't a problem for most scenarios. Instead most are limited by I/O, and we already have methods (via SANs) of tremendously and transparently scaling-out our storage subsystem. Take a look at the full disclosure of the price/performance leader: A single (albeit dual-core) 2.8Ghz processor - a relatively low-end head-end system - backed by a SAN hosting 56 "clustered" hard drives. The TPC-C benchmark is artificial, so this doesn't necessarily mirror the real world, but it is telling. Keep your data efficient through good design and delay the day that you need a 56-disk SAN. 

Thursday, October 20 2005

It's been around for a while, but a lot of people still haven't experienced it - The Quiet American's One-Minute Vacations Site. It's an expanding collection of user submitted 60-second audio samples from around the world. Absolutely fascinating to listen to, and many of them really do take you there. Take a minute break and go on a vacation.

While people often use the term "Audio Blogging" to refer to the spoken word (which, when fed through RSS, becomes podcasting), I see these sort of audio samples to be more analogous - though in the audio realm - to photo blogging. As much as I appreciate the Quiet American, it would be interesting to have a site like Flickr-for-audio-samples, with thousands or millions of samples from around the world. Heck, maybe just the Flickr we know and love, but with the addition of audio. It would be interesting to see photos of an Indian market, coupled with some audio samples, and be able to search and browse by keywords.

Of course naturally one would think "Duh...that's video with audio...That's Google Video", however video remains too unwieldy, and in the hands of a less-than-expert it very seldom captures the essence of a scene like a carefully taken photo does, nor does it facilitate quick and easy consumption.

Earlier EntriesLater Entries

Dennis Forbes - Dennis Forbes is a Toronto-based software architect and technology writer