Two tales of Customer Service for this day:

The Bad:

I'm signed up to a wireless router as well as hosting from Barak. The idea was that I wouldn't need to bother about setting it up, etc. In practice, I called them yesterday at around 10:00 PM, because I couldn't connect my laptop via wireless (first time I'm trying to do that with this laptop). They kept me waiting for over 30 minutes, listening to stupid voice and a stupid message telling me to reboot the computer and check my name and password (over and over and over again).

The girl on the other side couldn't solve the problem, and promised to escelate the problem to a more senior person, which would call me back. He called me back half an hour ago, meaning over 30 hours of wait. it took another call after that to deal with it.

The (very) Good:

I just tried to ordered some prints of digital photos that I have from Asaf (Hebrew site). I had a problem with the site, and I used the contant us a mail complaining about it. In 30 minutes they called me back and make sure that the problem is fixed.

I like this kind of service.

I'm feeling more and more as if I need to put some common functionality into a project and use it from all my projects. This post is mainly for myself, but I would love to have some comments about the idea. It's not new or anything like this, but using .Net 2.0 features does allow for some intriguing possibilities. I've plenty of ideas that just spring to mind, some of them I blog about, but I don't get to use them, or I need to duplicate the effort. I'm not talking about big things, but about the small stuff that we need to duplicate so many times.

Here is the list of what I think I can put there right now:

• DisposableAction
• Date & Time Utils - It's amazing how often I need to do things with those that aren't supported.
• For Each day / week / month in range.
• Explicit Date Range
• Combing Date's Date and a Date's Time
• Parameter Validation:
• IsNotNull
• IsInRange - For Dates & Numbers.
• IsNotValue
• ValidDateRange
• Collection Utils:
• First
• Last
• SelectAll
• SelectAllNot
• Delegate Iteration
• Actionable Objects - Similar to the way NHibernate Generics works:
• Collections: Action on Add/Remove
• Values: Action on set
• Static Reflection - Because just having all the Func overloads will be great
• Property Indexer

Each of those is a small piece of funtionality, and while I like the thought of putting it all in one project, I don't know if they deserve a seperate project and seperate treatment, since they are actually quite small tidbits. Anyone can think of anything else that they might want to see there?

There has been some discussion recently on the Castle about Aspect Oriented Programming* and their usage in production applications. I thought about using aspects for logging & security in my current project. But I decided against it. The reasons varied from not wanting to add more new stuff to an already complex project, other developers who would use the code, and ease of debugging/testing.

Instead, I used this approach:

The Container class is the central axis of my project, it binds together many services and allows easy access to the functionality of the application. The IRepository<T> interface is a generic interface for accessing and saving data, but with a twist. The nice thing about this approach is that I can specialize for each case independantly, and yet use a common approach where it is needed.

Okay, enough with the buzzwards, what does it mean? It means that I can use this interface for objects that I create I persist using ActiveRecord/NHibernate, for values from a resource files, etc. I'm using it extensively to avoid having to special case my code for each and every object type that I want to use.

An advantage of this approach is that I can now use decorators to provide the usual benefits of AOP. I have decorators that handles security, logging, transaction etc. I find that it is much easier to explain to people what is happening that way, since I can avoid telling them to ignore the man behind the curtain.

Two personal stories, before the end:

• I had a bug in my decorator, where I leaked a transaction. It took me a while to figure out what was happening, (random errors about timeouts because the relevant rows were locked), since I never even looked at the decorator. When I debugged it, it suddenly put me in code that I recently chucked off as complete, and it was a two minute fix to do. I can imagine how hard it would have been if I couldn't debug that, or that it would happen completely transperantly.
• I've a ineresting security problem, I need to check two permissions (and two seperate actions) for a single action. I'm not sure how I would handle that using aspects, but I'm planning to create a specialized decorator for that case, and the rest of my code will remain blissfully unaware of it.

This is not meant as an attack on aspects. If you've been following my blog for a while, you probably figured out that the less I need to do, the happier I am. Aspects certainly provide that, but they come with their own share of problems, which I'm not ready to deal with right now. Decorators are well understood and easy to explain, and it's very easy to generate the skeleton code via ReSharper to delegate to the next item, and add the custom operations that I'm interested in.

* Just to note, Aspect# is a Castle Project.

I'm very partial to safe code, so I really like the using() statement in C#. The problem with this statement, however, is that I want to do different things at different times, which require different disposing semantics from the same class. Here is an example from Rhino Mocks:

I'm using the using() statement to allow easy scoping of the behavior. I find the code far more readable this way. The problem is that I need to create a class that implements IDisposable, while the action that I want is a single line of code. For this purpose, I created the DisposableAction:

The usage of this class is simple:

And then you can call it like this:

Simple, safe, and it doesn't require of me to write any more than neccecary.

Sometimes a piece of code leaves you with a sense of awe. Sometimes it is because it is so bad, sometimes it is because it is beautiful. Below is a piece of code that Cameron (AKA: ckknight) posted to the Boo mailing list. I think that this is the most succinct, beautiful and clear fib function that I've seen.

When you should make a decision? This is an interesting question that goes beyond software design and into real life as well. I thought that I would share my philosophy about making decisions, and when I make the final cut.

The issue here is not about split second decisions, of course, it's about those decisions you've time to prepare for, but may not have all the data avialable. From development, it may be that you're considering the design of your application, but you are also waiting for the release of some component that you depend on. From real life, you know you are going to get a new team mate in two weeks, but you're not sure what his abilities are.

I had to make many such decisions while I was in the army, and I learned one thing. If I can do it at all, it was best not to decide until I had to decide. Each and every time that I tried to make a decision base on partial information, I was wrong. Most times, even when I did have all the information, by the time that decision was relevant, it wasn't the right decision. Since then, I adopted a philosophy that basically says:

This doesn't mean that you need to wait until you've all the information, often enough you have to make a decision before you've the information. But waiting will usually give your more information that you had before. One thing that this technique require, though, is that you'll consider all the options that you have to make this decision, without trying to find the best one. (I can put the new guy on Marketing, R&D or QA...)

Exploring the options will make sure that when you need to make the decision, at least you'll have a good idea about what are the implications of the decision. I have found this to work in most areas of life, and I attempt to apply it whenever I can.

I'd a problem with how to implement a spesific feature which I couldn't see a clean way to do. It's just something that came up that I don't need to do right now, but will have to do in the future, and this may have some serious ramifications later on. I'm a firm advocate of delaying decisions, so I just let the subject drop, thinking that I'll tackle it when I need to.

When I woke up today, I was still groggy, so I sort of turned over and tried to go back to sleep, and the solution to that problem just sort of came up to me. The feature in question is changing databases per each request when using NHibernate & ActiveRecord. Because of the way ActiveRecord works, I never have to explicitly open/close connections, so that was worrying. I just woke up today knowing exactly which part of ActiveRecord was responsible for the stuff that I needed, and with an easy way to make it work.

I'm not sure if it is a good sign or not. Should I be concerned that I dream of Castle?

Wesner has a post about how to monetize your blog that strike me as interesting.

I started to write this blog in April 2004, and I really cranked the volume of that shortly after that. I usually blog because I have something to say, and that is a good place to put it. Some time ago I put a Google ad on the page, hoping that at least it will generate some cash to pay the bills for the hosting. It didn't really work. So far I didn't even get a payment from Google.

Wesner mentions two ways to make money from a blog:

What do you think of those? If I put a PayPal account that you can donate to (for the content in the blog and/or for the software I produce), will it work? What about the second option? I'm willing to listen to offers to write a (well researched) blog post about a subject. Any takers?

But beyond money value, there is a huge networking effect to having a blog. I recieve several job offers via my blog. I talk with a lot of very smart people, I get to influence some decisions (Microsoft' VS 2005 Service Pack announcement was at least in part because of all the noise in the blogs).

The most important thing, though, that this is fun. I love developing, I love writing (and when I did it, I love presenting and teaching). I'm considerring myself very lucky, to be able to do the things that I love.

Kzu has found a bug in the .Net framework. The issue boils down to the framework saying that: Yes, sure you can convert the string 'Foobar' to int.

Microsoft response is:

Go read the discussion there, and please vote for this. I fail to see a scenario where a working program would break because of this change. Backward compatability is important, but this is way over the top.

I'm using Spam Bayes as my spam filter, and mostly it is doing spectacular job.

The interesting thing is that the single consistent false positives that it has is with mails regarding Boo. I'm not certain how to view this...

Perhpas I should mention that Spam Bayes is written using python? Sibling rivalry? (Okay, maybe distant cousins).