Perfectionist's block

March 4, 2009 at 9:15 PMAndre Loker

So you’re reading all the blog entries and books about patterns & practices, how to design great applications and write great code and what not and you think to yourself: “gosh, with that knowledge I’m going to write the best applications EVER!”. And than you’re firing up your machine and want to start developing that greatest app and… just can’t. You simply lock up, because you are afraid to write something sub-par because you miss one of the techniques to write great applications. And at the end of the day, you’ve created nothing. Instead you hate the code you’ve written before, knowing that there is so much about it to improve.

Does this sound familiar? Even if it does not to you, it does to me – at least for my own pet projects. Sometimes I’m facing this very fear of creating sub-optimal code, an appearance I like to call “perfectionist’s block” (as in “writer’s block). By the way: with projects I’m doing for customers I’m not facing the block because of deadlines etc. that keep me going.

What to do to break through this block? I remind myself that creating nothing at all is certainly worse than something imperfect. Writing semi-perfect code is no problem if you keep in mind that you always improve it later. Backed by a covering set of unit tests (or specs for the BDD people), code can almost always be safely refactored to a better version. I think that getting things done to the best of our knowledge and intentions is the best we can do.

If I feel a perfectionist’s block coming up the next time, maybe reading this post will help me :-)

Posted in: Other

Tags: ,

Simple AOP: introduction to AOP

February 13, 2009 at 12:46 PMAndre Loker

Aspect oriented programming (AOP) allows us to keep implement different concerns in isolation. In this article series I’ll describe ways to make use of AOP without much hassle. This first article serves as an introduction to AOP to those that are not familiar with aspect orientation.


If we analyse the source code software system we will soon realize that the different parts of the code can be grouped according to their responsibilities. For example some parts of the code are responsible for implementing business logic, other parts manage transactions, yet other parts are used to handle exceptions etc. In AOP terms those responsibilities are called concerns. The business logic is considered the core concern of the application, whereas the latter examples represent aspects that somehow interact with the core concerns. Because they interact with the core concerns, aspects are often called cross-cutting concerns. When we look closer at those interactions we can identify two problems:

1. Scattering

Scattering occurs if the same aspect has impact at many different places in the code. For example, logging or transaction management are often used at many different places in the code, but each time almost exactly the same way. This is problematic because it is harder to maintain scattered functionality.

2. Tangle

The second problem that often occurs is that of tangling concerns. At a given place in code – let’s say a single method – different concerns are present and interleaved. To give you an example, here’s a method that has the core responsibility to change the email address of a user identified by some  ID. Three concerns can be identified: the core concern (changing the email address) and two additional aspects (exception handling and transaction management). I highlighted the different concerns using different colours.


Tangling concerns are a problem because they bloat the code and distract from the core concerns. Here’s the same core concern without any extra aspects:

   1: public Result ChangeEmailAddressBusinessOnly(int userID, string newEmailAddress) {
   2:   var user = Users.GetUserByID(userID);
   3:   if (user != null) {
   4:     user.ChangeEmailAddress(newEmailAddress);
   5:     return Result.Success;
   6:   }
   7:   return Result.Error("User not found");
   8: }

Tangling also makes unit testing more difficult, because all the extra non-core concerns have to be considered during the tests as well, at least they have to be stubbed or mocked.

Using AOP to solve scattering and tangle

AOP tries to solve the two problems using the separation of concerns paradigm. With AOP the different aspects are described and implemented in isolation. Because the behaviour is defined once only and than applied automatically at all places of interest in the code, scattering won’t appear. And secondly, because aspects are defined in isolation the core concerns can be implemented without any intermingling aspects which solves the problem of code tangle.


The implementation of the behaviour is called the advice of the concern. Here’s an example of the advice belonging to the exception handling concern in pseudocode:

   1: someAdvice(context) {
   2:   try {
   3:     context.Proceed();
   4:   } catch(Exception e) {
   5:     if(ExceptionHandler.ShouldRethrow(e)) {
   6:       throw;
   7:     }
   8:   }
   9: }

In this example context.Proceed() would execute whatever has to be executed at the point where this concern is present. If that code throws an exception we can handle it.


We must of course somehow define where the concern is present. This is defined by the so-called pointcut. A pointcut is a boolean expression answering the question “should this concern be applied here?” for every possible “here”. Now, what’s a “here”? A “here" in this context is every possible point in the code where a concern can possibly be applied. Those points are called join points. Examples are: “A call to a method named X” or “The assignment of a value to a variable”. What kinds of join points are supported depends on the AOP implementation and is defined in that implementation’s join point model. Adding pointcuts to our pseudocode example could look like this:

   1: pointcut ServiceMethods : call to any method of class Service
   3: someAdvice(context) at ServiceMethods {
   4:   try {
   5:     context.Proceed();
   6:   } catch(Exception e) {
   7:     if(ExceptionHandler.ShouldRethrow(e)) {
   8:       throw;
   9:     }
  10:   }
  11: }

Now everytime we call a method of class  Service the advice will be executed. The call to Proceed() will in this case execute the method that is being called.

Advice types

Now that we have defined what is advised and where we can add the minor detail of when it is applied, because we have different kinds of advices. The example above uses a so called around advice. That is, the advice is wrapped around the joinpoint. It controls the moment when the joinpoint is executed explicitly by calling Proceed(). Other examples of advice types are:

  • before and after advices, which are executed before or after the execution of the joinpoint respectively. Those advices can’t explicitly define when the joinpoint is executed.
  • throwing advices, which are only executed if the execution of the joinpoint raised an exception
  • returning advices, which are only executed if the execution of the joinpoint did not raise an exception

Finally, here’s a fine-tuned version of our pseudo code example:

   1: pointcut ServiceMethods : call( Service.* )
   3: around(context) : ServiceMethods {
   4:   try {
   5:     context.Proceed();
   6:   } catch(Exception e) {
   7:     if(ExceptionHandler.ShouldRethrow(e)) {
   8:       throw;
   9:     }
  10:   }
  11: }

By the way, I didn’t come up with this notation all by myself. It resembles the syntax used with AspectJ, which is more or less the most prominent (Java) AOP framework available. It has grown quite mature and if you’re interested in AOP I highly recommend to have a look at it. Yes - even it uses Java :-) 


So, we have defined a bunch of aspects with their pointcuts and advices. The missing link is obvious: how do those advices get applied to the base code (the code containing core concerns)?  For this process – called weaving - several approaches exist, all with different pros and cons.

Compile time weaving

This approach is taken by AspectJ for example. An additional step is taken during compilation that inserts the advices into the source code or an existing binary assembly. This results in binaries that don’t look any different from conventional binaries.


  • the join point model can be very detailed (e.g. the assignment of a value to a variable)
  • performance wise there’s little overhead


  • weaving is static only, we can’t change aspects at runtime

Runtime weaving

With runtime weaving the aspects are woven into the base code – well – at runtime. There are different approaches to achieve this. Some implementations for example modify the runtime environment to support injection of code. A simpler approach is the creation of runtime proxies for advised objects.


  • no need for an extra compiler
  • aspects can be added or removed dynamically


  • depending on the implementation, the join point model can be rather limited

For this article series we’ll use proxy based runtime weaving: it is simple and in many cases sufficient.

Critical view

In principle AOP sounds promising: separation of concerns helps to concentrate on core concerns and keeps our code free of tangle and scattering. Where there’s light, there’s also shadow they say and this counts for AOP. If you look at the base code you can’t see at a glimpse which aspects are applied (except if you have tool support). Because the aspects are injected “invisibly” you might encounter unexpected runtime behaviour, especially if the aspects affect each other. Likewise, you have to be careful where the different aspects are advised to avoid some unintended application of concerns. Keep an eye on your pointcuts!

Also, AOP is generally not a first class citizen but an “artificial” extension to existing software environments the woven code comes with an overhead, especially with runtime weavers. Most business applications are I/O bounded, so whether a method call takes 1 microsecond or 1 millisecond does not matter much if the method itself takes 50 milliseconds to run. Just be aware that advising a join point in a performance critical loop might be something to reconsider.

Therefore – as with any tool – use AOP wisely. Use it when it makes sense, just don’t go crazy with your new toy.

Wrapping it up

This concludes my introduction to AOP. I haven’t covered all details of the topic (like inter type declarations or advice precedence). Still I’ve hopefully shown the need for and benefits of AOP well enough to have awaken your interest in the next parts of this series. Feel free to leave a comment for questions and suggestions.

In the next part of the series I’ll how we can use Castle DynamicProxy as a starting point for a AOP-esque separatio of concerns.

Other articles in this series:

Posted in: Tools | Other

Tags: ,

Firefox 2 and 3 side by side

June 19, 2008 at 11:08 AMAndre Loker

So, Firefox 3 is out. The curious part in me wants to upgrade, the reasonable part wants to stay with version 2 ("will my add-ins work with v3, yadda yadda"). Even worse, the developer in me wants to install both versions, to see how my projects work on either one. Side by side installation is not really intended by Mozilla. But luckily it's still possible.

This article will show you how you can run both FF 2 and FF 3 on the same machine. We will not change the FF 2 installation. We'll only add a non-installation version of Firefox 3 that can be launched on demand without changing the FF 2 profile. The article is based on this article and this article (German).

Before we start: I am not responsible for any trouble that this guide causes on your computer. It works fine on my machine, but don't blame me if your Firefox profile get messed up, your keyboard catches fire or your girlfriend leaves you etc.

  1. Make a backup of your current Firefox installation. I mean seriously, make a backup. I recommend MozBackup, it's easy yet powerful and gets its job done.
  2. Create a new Firefox profile for our future Firefox 3. We don't want FF 3 and FF 2 to use the same profile, so this step is important.
    1. Launch the profile manager with: firefox -profilemanager -no-remote
    2. Select "Create Profile..." to create a new profile. You can name it whatever you like (here I named it ff3test), just remember the name for later!
  3. Download Firefox 3 from You should have 'Firefox Setup 3.0.exe' by now. Do NOT install it!
  4. Extract the content of 'Firefox Setup 3.0.exe' to a folder on your drive. I use 7-zip for this, but other tools may work as well. With 7-zip, right click on 'Firefox Setup 3.0.exe' and select 7-zip -> Extract to "Firefox Setup 3.0\". The folder with the extracted content should look like this:
  5. Remove unnecessary files: remove the following files/folders:
    1. optional
    2. removed-files.log
    3. setup.exe
  6. Move the content of localized to nonlocalized. Confirm to overwrite all files when asked. You can delete the "localized" folder safely.
  7. The "nonlocalized" folder now contains all required FF 3 binaries. You may rename it (to let's say "Mozilla Firefox 3") and move it (to "Program Files (x86)") if you like.
  8. Create a shortcut to FF 3. In this example I create a shortcut on my desktop.
    1. Locate firefox.exe in the (former) "nonlocalized" folder, right click on it, choose 'Send to' -> 'Desktop'
    2. Locate the shortcut on your desktop, rename it if you like, right click it and choose 'Properties'
    3. Append "-P ff3_profile -no-remote" to the "Target" text field, where ff3_profile is the name of the designated Firefox 3 profile you created in step 2. In my case it was called "ff3test", so my text field looks like:

That's it! You can now continue to use FF2 as usual. If you feel like FF3'ing, just use the shortcut we created to run the shiny new Firefox 3. Of course, there is no uninstall option for FF 3 (we did not install it in the first place). To get rid of FF3 just delete the respective folder, the shurtcut and if necessary the profile.


NB: the first time you start FF2 after this procedure the profile manager may appear. Just select the default profile and check "Dont's ask at startup".

Posted in: Other


Older versions of Firefox

June 19, 2008 at 10:32 AMAndre Loker

Need an older release of Firefox? Here you go:

Posted in: Other


.NET 3.5 setup woes

June 5, 2008 at 1:32 AMAndre Loker

Today I tried to install .NET 3.5 on one of my web servers. It's a virtual server running Windows Server 2003 Standard x64 under Virtuozzo. I downloaded the complete redistributable (197 MB). The setup, however, failed with an error message that was not too comprehensible:

[06/05/08,00:51:10] XPSEPSC x64 Installer: [2] Error code 1603 for this component means "Fatal error during installation."
[06/05/08,00:51:10] XPSEPSC x64 Installer: [2] Setup Failed on component XPSEPSC x64 Installer

So there was something wrong with the XPSEPSC component (until know I never even heard of it). After digging through heaps of installation logs I found a file called dd_XPS_x64.txt in %USER%\Local Settings\Temp\28. That file appeared to be the installation log file for the XPSEPSC component. At least it was a bit more chatty:

3.078: XpsEPSC Setup encountered an error:  Setup could not verify the integrity of the file Update.inf.  Make sure the Cryptographic service is running on this computer.

Nice clue, I thought, expect that the cryptographic service was already running in automatic mode. At least I somehow managed to find this knowledge base article that referred to the error message. Already the first method that was described in there helped a lot:

Method 1: Rename the Edb.log file

Rename the Edb.log file, and then try to install the program again. To rename the Edb.log file, follow these steps:

1. Click Start, click Run, type cmd in the Open box, and then OK.
Note On a Windows Vista-based computer, click Start, type cmd in the Start Search text box, right-click cmd.exe, and then click Run as administrator.

2.At the command prompt, type the following command, and then press ENTER:

ren %systemroot%\system32\catroot2\Edb.log *.tst

After renaming Edb.log I ran the setup again. During installation a different error message popped up complaining about the VC++ runtime:

The application has requested the Runtime to terminate it in an unusual way.

I already thought setup was to fail again, but interestingly it completed successfully and told me that .NET 3.5 was installed correctly. Really, I had never come up with this myself, so I'm really glad I found the KB article.

By the way: the reason why the VC++ runtime error occurred was likely that the printer spooler service was disabled (and it is on my web server). Right, the printer spooler. Who on earth should predict that? At least there are blog posts about it, e.g. here and here. Just out of curiosity I started the printer spooler, re-ran the .NET 3.5 installer and chose the repair function (go get some coffee, it takes aeons to complete). At least during the repair no error occurred, so I assume everything's fine now.

Posted in: Other | Tools

Tags: , ,