Syncing calendars... nothing is ever easy

I have a problem of managing multiple callendars. My wife has access to my Google calendar, my company has access to my Zimbra calendar. I use a Mac, and I like to use iCal if possible. I use Plaxo, TripIt and Dopplr, which provide ical interfaces/synchronisation, just like Google and Zimbra.

All this shouldn't be too original, so I expect that other people have this problem. Granted it is not an easy problem to solve, because synchronisation isn't easy. Let me first explain how I'm managing things now (and how I screw up). Then go over the options and then over what I really want.

Now I manage my calendars through CalDav. This works really well for a single calendar, but it does nothing for you in terms of synchronisation. If my office manager add's an appointment I see it show up in the right calendar, if I get a trip confirmation and send it to TripIt same story if my wife makes an appointment I can see it show up too. Nice overview, clear separation of calendars. Perfect, as long as I do the managing. That is the problem, my wife manages the calender of our private life, my manager manages the calender for the jobs. They have no idea what the other is doing.

So I screw up like this: if my manager plans for me to be abroad he checks with me and puts it in the calendar, then I have to make sure it shows in my private calendar that I'm abroad, otherwise my wife will plan something conflicting in the home calendar.

The underlying problem is that I am just one person, so everybody planning for me to be somewhere needs visibility on where I am. Main options:

• Be more disciplined and copy things over
• Use a single calendar and synchronize

The first option is what I'm doing now. Fine tuning this would mean I create a single calendar that lists my availability and make sure that all planners have read access to that from a single interface that they use for planning. The advantage is that this way the planners do not have to worry about fine grained appointments, just about available time (in a certain location).

The second option would allow me to be very lazy, but it would also result in a privacy issue where my manager can see that I went to a party on thursday evening or something. I don't care that much about privacy. I do care about my manager moving around my dentist appointment from the private calendar, so the solution is not ideal.

An ideal situation would allow me to share availability across calendars, and restrict write access and access to detailed information based on different calendars/sets of appointments.

The annoying thing is that there are no tools that allow this. Requirements are:

• Have to use Zimbra for work
• Have to use Gcal for private
• Want to use iCal as interface
• Want to integrate CalDav calendars
  
• No manual syncing

The only way to get close would be to install different sync utilities for my mac and sync with a local calendar. The proper way to do it is to allow CalDAV calendars to be synced in ical, but there is no support for this in iCal natively. The only workable solution (other than discipline) is to run sync utilities like Spanning Sync and the Zimbra iCal plugin. This is bound to screw up my calendars at some point I'm sure...

Update svn on Leopard to play nice with subclipse

Not so long ago I moved forward to STS 1.1 which is based on Eclipse 3.4 Ganymede. Of course I needed a svn plugin and then I ran into this issue.

Mac OSx packages an old version of collabnet subversion (1.4.x). And that doesn't play nice with subclipse. The fix suggested there is to use an old version because:

For Windows users, it is a simple matter of installing the new Subversion 1.5 client and making sure JavaHL is on the path. For Unix users, this workaround obviously defeats the purpose of having a distro with package management and requires manual installation of the libraries in the correct locations.

If you truly understand that and it is a blocking concern for you (notice the hint of sarcasm), don't read on. There is however a very simple solution to run the right version and just make it work.

1. Download and install http://www.collab.net/downloads/apple/download.html
2. sudo rm /usr/bin/svn* (you might want to check if you haven't got any other programs named svn* before you do this)

The second step is needed because the collabnet package installs simlinks into /usr/local/bin and the programs in /user/bin take precedence.

Once this is done you're good to go, and with the latest versions.

Update: I've moved on to do this with MacPorts, lately their svn versions are fine, and the installation is much simpler.

Correct Simple Singletons

This is going to be a very short blog. It's not about concurrency. It's about avoiding to think about concurrency. As was the original intent of this blog it is about being lazy, but still not being wrong.

Yesterday I read a very old blog while digging through the web for reasons to be scared of the volatile keyword. I found plenty, but this one is a gem: http://blogs.msdn.com/brada/archive/2004/05/12/volatile-and-memorybarrier.aspx. It's about .Net code, but the basic problems also apply in Java. The link to http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html is worth a read too.

If you can think about concurrency but you don't want to do it every day like me adhere to these rules when writing singletons:

When you plan on using the singleton write:

public class Singleton {
  private static final instance = new Singleton();
  private Singleton() {}
  public static Singleton get() {
    return instance;
  }
}

When you don't plan on using the singleton, but you still feel the urge to implement it write:

public class Singleton {
   private static instance;
   private Singleton() {}
  public static synchronized Singleton get() {
    return instance;
  }
 }

When you're not going to use the singleton a lot, it is probably more memory efficient to just use a disposable instance, hence removing the need for the singleton at all. So the recipe goes like this:

1. Don't use a singleton if you don't need to
2. Use the simple (static final) variant if you do need a singleton
3. Use the synchronized variant if you are intent on going on the downward slope
4. Of course you are special, so go on and do it the hard way.
   

Don't repeat yourself, just quote yourself.

I just read an article by Dan North about how the DRY principle doesn't work with Test code. Obviously I agree with him, because it is almost trivial once you've figured it out on your own. I already met many people that did and were quite happy with themselves for it, actually that could have been me after I had about 1 year of experience with TDD.

When I read the linked blog I mused over the main counter argument against dropping DRY, it is actually the argument to adopt it: what about the maintenance hell of all that repeated code. Arguably if you use proper mocking or stubbing (especially mocking) you shouldn't have too much trouble with this, but wouldn't it be nice if there was a solution for this?

So what are the requirements:

1. We want to get readable code (not requiring you to constantly switch source files or scroll)
2. We want little writing effort (not repeating the same code snippet over and over)

Requirement 2. is covered by OO, AOP and friends, but they completely ruin 1. in certain scenarios (e.g. test code). To get 1. you will have to drop 2... NOT good enough!

I am a fan of wikis and as you might know many have a feature called templates that specifically targets these two requirements. How about template in code. Just add a template construct and let the IDE optionally show the actual code inline.

I like it.

My first mobile internet

I've just replaced my well over 4y old battle scarred Nokia 6100. It's not that it was really broken, but just that my definition of 'the basic necessities' has changed. Let me give an overview of the definition over the years:

In 1998 when I bought my first mobile phone:

1. Be able to make a call

In 2004 when I got my third phone:

1. Be able to make a call
2. Be able to use sms
3. Battery life at least 1 week/4h calling

In 2008:

1. Be able to make a call
2. Be able to use sms
3. Be able to connect my laptop to internet
4. Battery life 1 week

Now in 2008 I have a job that requires me to travel and I "need" to have internet at all times. I decided to do what operators have been blabbing about for 6 years now and combine my phone needs with my internet needs. We do have UMTS now so it should be OK, right? Right...

To put things into perspective I will just give some hints to how my 'basic' internet needs are pretty far advanced compared to my phone needs. I for example:

• expect ANY website to render in under 0.5 seconds
• routinely download files over 300M and don't expect to wait longer than it takes for me to get coffee.
• store my complete life (contacts, documents, ...) online and don't expect to notice the difference.

So I got myself a unlimited data subscription and a UMTS capable phone (SE W660i if anyone cares). And I started connecting it to the internet.

Many geeks will look pitiful at my incompetence, but it took me 4 hours to get things working. Kudo's to http://www.taniwha.org.uk/ and the guys from SE for doing my providers and Apple's work for them. Funny that the guys that get the most money from me (Apple) are the least helpful in getting things to work properly. Ah well, I should have gotten an iphone, but that doesn't have umts... anyway, that's a whole different rant.

Now that everything works I am just curious at the speed I can get out of my new toys (http://text.dslreports.com):

40 kbit/sec
1.978s latency

Erm.. Those guys from telfort are really missing the point here I think. WTF!

When I made webpages last millennium the general rule was to keep images under 100k so that with this speed it would take me, say 20 seconds PER IMAGE to load the page.

I looked at http://www.umtsworld.com/technology/dataspeed.htm and the theoretical maximum is still pretty disappointing...

It's 2008 dammit, where is my flying car!