I updated the site to Subtext 2.0. So far, it looks good.

Reason for upgrade? I wanted to get the ability to future post. That should give me a way to throttle my blogging bandwidth.

This post, for that matter, is posted with 4 minutes delay.

Broken: I manage to forget that this blog also has a lot of links built from the old old blog, using dasBlog. It run for the last year and a half with no issues, so I just didn't notice that. Trying to fix it now, but it may be delayed for tomorrow.

When I was in the army, I used to have a notebook (that is a physical one, made of paper) and I wrote just about everything there. I stopped doing it when I realized that I never read it. I don't do to do lists. I can barely manage to handle task tracking with a bug tracking system, and that is because even I recognize this as mandatory.

This is about how I manage to do things. It is likely not applicable for anyone else.

Currently, I use my inbox as the master todo list. And I am using read/unread for managing that. If it is unread, I need to take care of that. It works, except when I have to checkup on things in some time period. That is, let us say that I mail someone something, and I need to get back to them about that in a week. My current option is to mark this as unread and leave it that way for a week.

This approach drive me crazy.

Oh, I tried using things like outlook's reminders and stuff. They don't work for me, too much of an association with meeting reminders and annoyances.

What I wanted was a way to have a mail sent to me in the future. That is, if I want to follow up on that in a week, I will get an email next week reminding me that. Since I am using Gmail, I'll also get the entire conversation, which is the context for what I want to read.

Eventually, I decided that I am going to build this. TimeBox is a simple future email forwarder. It supports natural date syntax, courtesy of DateTimeEnglishParser. Now, if I want to be reminded of something, all I do is forward it to the mailbox, where the service will read it, parse the date and email that to me in the appropriate time.

From the UX perspective, it is:

• hit 'f' for foward
• enter timebox email
• tab twice (subject and then to the actual text)
• enter time, such as 'in one week'
• tab to send, enter
• Done.

I started using this already, and I am liking this quite a bit.

I just finished setting up a build server for Rhino Tools. Ideally, I want it to be publicly accessible, and have people download the build artifacts after each build. However, CC.Net is not something that you want to just expose to the web. It has no security model (any random Joe can just start a build, hence DOS).

Any suggestions?

I should note that anything that involves significant amount of time is going to be answered with: "Great, when can you help me do that".

And I mean that in the kindest way possible. I am currently working with these wizards, and they (and the possibility WPF opens) keep surprising me.

I am well aware that this piece of code is par the course for WPF devs, but I have only dabbled in WPF, and seeing what it can do from visual perspective doesn't mean much until I have seen how clean the UI code looks like. I mean, just take a look at this:

All the information that I need to have about how to handle a piece of the UI is right there, and the infrastructure supports working in the way that I think is appropriate. The reason for this post is seeing how context menus works. I was extremely pleased to see how it all comes together in a single cohesive unit.

It is so much fun to see things that I worked on coming alive. The official announcement is here, with all the boring details. You can skip all of that and go read the code directly using SVN by hitting: https://svnbridge.svn.codeplex.com/svn

Switch svnbridge for your project, and you are done. Note that this is https. And yes, it should work with git-svn as well.

Way cool!

I had hard time deciding what examples I should give about what is impressive to me and what is not. I didn't want to use the real world scenarios, but I did want to give concrete examples. Fortunately, I did manage to think of a couple of good examples.

Distributed Grid and Distributed Caching. Both of those are considered hard. In the sense that it takes a lot of expertise to build them. They are also one of those pure technical issues that developers love, no need to deal with pesky tax laws or understand why delinquent customers are given more credit, just pure programming bliss.

The problem is that those are just aren't impressive on their own. Building a distributed cache is easy and fun. There is nothing complicated going on there. Distributed Grid sounds complex, at first, but it is a very simple technical challenge. It is slightly more complex if you want to implement it with automatic binary distribution (that is, you don't need to manually deploy dlls to the machines in the grid, it happens for you), but even then, it is firmly in the realm of the easy to do.

What is impressive in such a scenario is how you solve the management problem. How do you gracefully recover from a failed worker node on the grid? How do you handle another node adding itself to the cache? What happen if a server crash?

Handling those problem is an interesting, challenging and impressive. Because it require a bit of thinking beyond just technical expertise.

Damn, this is annoying:

And then I find out why:

Stupid of me, really stupid of me.

Linq for NHibernate is not part of the 2.0 release. Linq support is planned for the 2.1 release. That said, we have been getting a lot of questions about that.

The technical reasons are not really interesting, but suffice to say that to provide good Linq support we also need to modify NHibernate slightly. Those changes happens on the trunk, which is what Linq for NHibernate is following.

However, due to all the questions that we got, I wanted to point out that Daniel Guenter has back ported the current version of Linq to NHibernate to Nhibernate 2.0 and made it available here.

Now, the disclaimer. We are not supporting this. This is an unofficial (but welcome) contribution from the community. It is likely to have bugs (in fact, we know it contains bug in the more complex Linq queries, that is why it is still under active development), and the NHibernate team response is most likely going to be, use the latest, which requires the NHibernate trunk, not the NHibernate 2.0 version.

Use at your own risk, etc.

A while ago I talked about persistent DSL caching. I was asked why my solution was not a builtin part of Rhino DSL.

The reason for that is that this is actually a not so simple problem. Let me point out a few of the issues that are non obvious.

• Need to handle removal of scripts
• Need to handle updating scripts
• Need to handle new scripts

Those are easy, sort of, but what about this one?

• Need to handle DSL updates

When you are in development mode, you really need to know that changing the way the DSL behaves would also invalidate any cache.

I like to keep a very high bar of quality on the software I make, and there is a fine distinction between one off attempts and reusable ones. One off attempts can be hackish and stupid. Reusable implementations should be written properly.

And no, there isn't anything overly complex here. Just time to test all bases.

Anyone feels like sumbiting a patch?

It doesn't take a lot to impress me. All you have to do is show me something that I didn't think about, or do something that I consider difficult and valuable. If it is just difficult, it is not really interesting, and if it is valuable but obvious, it is not really impressive. If it is not valuable, there is no point in spending any time on it.

It seems like common sense, to me. But I had four different occasions recently where I was shown things where I got the strong impression that I was supposed to be impressed. I wasn't. I really wasn't, in a few cases.

In two cases, it was doing things in the really hard way, and I was able to point out easier ways to approach the problem. One was just not interesting to me and in the case of the last two, I kept asking, "and... ?", trying to figure out exactly why I was supposed to be impressed. Both were a duplication of existing work, and I couldn't figure out what new there.

Oh, there were new things, but none of them was something that couldn't be built in less than a day or two. So they didn't pass the difficult bar.

If you want people to be impressed, you have better do something impressive. Sorry, but I have hard time of getting excited of Yet Another Xyz or Overcomplicated Solution Abc.