Friday, March 07, 2008
Google has released Google Calendar Sync, which will automatically sync your Google Calendar to and from Microsoft Outlook. As an avid user of both calendars, I rushed to download and install the tool. It installed quickly, accepted my Google Apps email, and was ready to go. However, after the first sync, I was puzzled as to why the items from Google Calendar hadn't shown up in Outlook yet. I tried a few manual syncs, but still nothing happened.

I have to admit that I rarely read instructions before installing software, so I had missed the following important information on the Google Calendar Sync: Getting Started page, which reads:

"Keep in mind that it's not possible to sync events on secondary calendars at this time. Google Calendar Sync will only sync events from your primary Google Calendar and your default Microsoft Outlook calendar."

Ugh. I didn't notice my events coming into Outlook because I don't have much in my primary Google Calendar. I was expecting to see everything come into Outlook, but the tool doesn't actually support that.

Are they serious about this? So, I can't use multiple color-coded calendars in Google Calendar? That's right. Any events not on the primary calendar will simply not be synced. And of course, the problem exists on both sides. If you happen to use multiple calendars in Outlook, you're out of luck.

calendar

To make matters worse, the tool doesn't handle event collisions very well. So, if the same event exists in each calendar before the first sync, you'll wind up with two items in both calendars. Yup. If you have "St. Patrick's Day" in your Google Calendar and Outlook, you'll find two "St. Patrick's Day" events in each after syncing for the first time.

C'mon Google, you can do better than this! Supporting only the most basic use case isn't enough. I need a tool that does it all with the ease-of-use that I've come to expect from Google's tools. I don't need a tool that 1) requires babysitting, or 2) limits the number of features that I can use.

Somebody please let know when this really works. Until then, it's uninstalled.

posted on Friday, March 07, 2008 10:36:40 AM (Pacific Standard Time, UTC-08:00)  #    Comments [4]

kick it on DotNetKicks.com
 Monday, September 24, 2007
Recently, I've been using Lutz Roeder's indispensible .NET Reflector to explore how C# 3.0 LINQ query expressions are compiled. To make this easy, the .NET Reflector supports a useful "optimization" setting that specifies which version of the .NET Framework the disassembler should draw features from for code generation. Changing the setting is pretty easy. Just select "Options..." from the "View" menu to display the Options dialog. Then, modify the "Optimization" value on the "Disassembler" page.

Reflector options for optimizing disassembled code to a specific .NET Framework

With the disassembly optimization set to .NET Framework 3.5, here's how a simple query expression looks:

LINQ code disassembled with Reflector and optimized for .NET 3.5

That's pretty cool, but it doesn't really give any insight into the compiler magic happening under the hood. To get a better picture of this, the optimization setting should be changed to ".NET 2.0." Once this is done, the disassembler no longer generates query syntax, and it uses anonymous methods. This makes it plain to see which extension methods are compiled for the different clauses of a query expression. In addition, the method calls are hyperlinked, making it easy to dig deeper.

LINQ code disassembled with Reflector and optimized for .NET 2.0

While this is all very helpful, I do have a few complaints:

  1. I should be able to change the disassembler options on the fly. It'd be great if the Disassembler window sported a toolbar for modifying its options. The current user experience requires me to open the options dialog, make the change, click OK and wait while the .NET Reflector unloads and reloads all of the assemblies that are open. In fact, if I open the options dialog, make no changes and click OK, Reflector will still unload and reload everything. At the risk of inviting comment abuse from Reflector devotees1, I have to say that this strikes me as a pretty lame UI cop out.
  2. The .NET 2.0 optimization isn't accurate because it generates syntax for extension methods. I'm a bit torn by this because this inaccuracy actually makes it easier to understand the code. If this is changed/fixed, there should be an additional option that hides query syntax and shows the underlying method calls with lambda expressions instead of anonymous methods. That way, Reflector could display this LINQ expression:
var query = from m in typeof(String).GetMethods()
            orderby m.Name
            select m.Name;

Like this:

var query = typeof(String).GetMethods().OrderBy(m => m.Name).Select(m => m.Name);

Regardless of these issues, which I hope are addressed (are you reading this, Roeder?!?), the .NET Reflector is a life-changing tool. If it isn't already a part of your developer's toolbox, you should go download it right now.

1I'm one of them.

posted on Monday, September 24, 2007 9:46:09 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

kick it on DotNetKicks.com
 Wednesday, March 28, 2007
While giving a talk at the Dayton-Cincinnati Code Camp, my computer started dragging to a crawl—PowerPoint was hung, Visual Studio 2005 wouldn't respond—very bad. I'm comfortable with multi-tasking so I fired up Process Explorer while I continued to introduce the session topic. When Process Explorer was up, the culprit was revealed. Both cores of my CPU were pegged by the Adobe Updater software. Discovering this, I couldn't help pointing out the problem to the audience (with some choice comments) and logged a todo item in the back of my mind to get rid of the Adobe PDF Reader ASAP.

Today, I am Adobe Free. I removed the PDF Reader and the diabolical Adobe Updater. Today I'm running Foxit and I couldn't be happier. It's much faster than Adobe's reader. My machine actually responds as if chains have been removed from it. Thanks Foxit!

posted on Wednesday, March 28, 2007 7:13:41 AM (Pacific Standard Time, UTC-08:00)  #    Comments [5]

kick it on DotNetKicks.com
 Monday, March 19, 2007
Delegates rock. But there's a dark side to them that can cause non-obvious bugs. Read on if you dare!
posted on Monday, March 19, 2007 12:00:13 PM (Pacific Standard Time, UTC-08:00)  #    Comments [1]

kick it on DotNetKicks.com
 Wednesday, August 30, 2006
To me, enums in the .NET Framework 2.0 don’t feel like a polished feature. Writing serious code with them is a descent into typecasting madness filled with the maniacal laughter of bitwise ands and ors. Maybe the problem is that they are considered "good enough" or simply "not interesting enough" to improve. I mean, what’s more exciting to a compiler writer: enumerations or generics and lambda expressions? It’s possible that enums haven’t been improved simply because of time constraints or resources. But, in my humble opinion, it’s high time they deserved some love. In this article, I offer up my list of potential improvements for .NET enums. When possible, I present workarounds to implement the improvements with the current or next version of the .NET framework.
posted on Wednesday, August 30, 2006 10:49:47 AM (Pacific Standard Time, UTC-08:00)  #    Comments [1]

kick it on DotNetKicks.com
Responding to a user's comments about a warning raised by Microsoft's Code Analysis tool in Visual Studio Team System.
posted on Wednesday, August 30, 2006 4:17:27 AM (Pacific Standard Time, UTC-08:00)  #    Comments [5]

kick it on DotNetKicks.com