Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

March, 2012

Change of Address
This blog has moved to
  • Being Cellfish

    Time is hard


    You probably heard about the leap year outage of Azure which is explained here. Essentially it looks like somebody added one to a year (which was probably an integer) rather than using a (proper) date representation. Remember that I do not know, but this is my assumption based on what I've seen over the years. Essentially dealing with time seems to be hard and I think most of the time it is because people don't use a date/time abstraction but take shortcuts based on assumptions that are not correct. Here are some assumptions I've come across in the past:

    • Forgeting leap years.
    • Assuming leap years happen every four years (ex: 1900 was not a leap year).
    • Forgetting daylight savings time.
    • Assuming all countries have daylight savings time on the same date (some countries don't even have daylight savings time).
    • Assuming everybody using your software will be in the same timezone.
    • Assuming all time zones are whole hours from GMT (some countries fraction of hours as offset from GMT)
    • Assuming use of AM/PM rather than 24 hour clock
    • Assuming there are 60 seconds in a minute (ex: leap seconds)

    So there are a lot of things to think about when it comes to dealing with time so you should really use an abstraction for it and preferably use an implementation of that abstraction created by somebody who have tested it well such as something being part of whatever framework you use for development.

  • Being Cellfish

    Configuration in code


    For quite some time I've used a pattern when it comes to configuration to hide it behind some interface. This way I can easily fake it in a unit test but typically there has been an implementation relying on a configuration file. Then when I started working with Azure a few years ago I started to check in a number of different configuration files for different environments and scenarios. But there was always a problem with configurations; while very convenient that they could be changed manually and quickly change the behaviour of my service at the same time those changes are hard to track. The solution was so obvious I didn't think about it until recently in a discussion I had with a co-worker. Configuration should be kept in code. I already started the process by checking configuration files into my source control system, but taking it another step and actually make it part of the code so that you need to recompile is for many reasons a better idea and also possible when working with cloud services.

    Configuration files definitely have it's place but when it comes to cloud services, redeploying your service is fast enough so you can actually recompile and redeploy rather than changing a configuration setting. At the same time you should get a trail of changes (the change is checked in before deployed, right?) and you will run a number of tests before deploying too right? So a simple configuration change is now actually treated as a simple bug fix; it is validated before deployed!

    I realize this is not a new idea, but I find it very appealing the the cloud service scenario and worth mentioning here because somebody like might have overlooked this just as I did.

Page 1 of 1 (2 items)