All Posts

Last week, prior to a weekly meeting, one of my team members had the idea to take a few minutes before the meeting to review some code. We already do code reviews prior to deployments, but we've been wanting to improve the quality of the code reviews... we wanted to really have good dialog about code quality and be able to share that discussion with the whole team.

Now that the year of the Mayans is upon us, I wanted to take some time to look back over 2011. And don't worry, I'll do my best to not mention the Mayans and 2012 anymore this year. I won't guarantee it won't come up again because I think it is funny, but I'll try.

So, a few weeks ago I was able to attend the BUILD Windows conference in Anaheim. I'm guessing you heard something about it. The last time Microsoft held a conference at the convention center in Anaheim was when it announced Windows 95 \- this conference was an attempt to show that Windows was going to revolutionize things again. I've got a lot of thoughts that I want to talk about, so I'll probably have to break this into multiple posts.

Ah, timeouts. At my previous job, I wrote quite a bit of code that dealt with threading. When dealing with threads, asynchronous operations, and performant UIs, you can't always rely on callbacks to get you the results of some asynchronous operation. Sometimes you also have to throw in some waits, particularly if the UI gets to a point before the callback has happened. Whenever I did have to write any code to wait for something (usually off an AutoResetEvent or a ManualResetEvent), I never wanted to actually specify a timeout. What would my application do if it timed out? Would I retry again? Would I just show the user an error? Instead of dealing with that question, I just made the wait last for the default... which in most cases is INFINITE.

The Mohundro family has some big news... our first child was just born a couple of weeks ago! Both mother and daughter are doing great!