Subscribe: Jimmy Nilsson's weblog
Added By: Feedage Forager Feedage Grade B rated
Language: English
architecture  code  data  domain model  domain  good  great  microsoft  might  model  net  new  object  part  patterns  time 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Jimmy Nilsson's weblog

Jimmy Nilsson's weblog

Published: Sat, 17 Jul 2004 22:50 +0100

Copyright: Copyright 2004 by Jimmy Nilsson

Discussions that are must reads right now

Mon, 15 Dec 2003 22:10:00 +0100

It has been a crazy autumn/early winter workload wise, so I've been behind with my blogging. With luck that will change a bit now when hopefully things get back to normal again.

I'd like to start by recommending some very interesting discussions about ObjectSpaces (and OR Mapping in a more general sense). For example, at the newsgroup microsoft.public.objectspaces you will find the following threads which I think are very interesting:

  • Objectspaces versus JDO
  • SOA impact on design of O/R
  • Anemic Domain Model Anti-Pattern
Also make sure you read this blog post by Andrew Conrad.

Ahh, at last... MBF

Thu, 06 Nov 2003 21:30:00 +0100

There has been a lot of hype before, during and after PDC regarding Indigo, Avalon, WinFS and so on. Something else that I also think is very interesting is MBF (Microsoft Business Framework), but as I see it, it hasn't been given the attention it deserves! You'll find some slides here.

I've been banging on to many different Microsofties for a long time that the Domain Model pattern is often a very good solution. Until recently, I've felt as though I've been nagging, whining and being awfully stupid. Perhaps I wasn't being after all... at least not all that much.

Are architects working with software architecture?

Fri, 10 Oct 2003 16:44:00 +0100

I have realized that I should be more careful in using the word "architect" when describing roles in software development projects. Martin Fowler and Allan Cooper state here and here that the role has been misunderstood in the software community. I guess some people will be getting new business cards and some products will be getting new names.

SOA doesn't mean anti-OO

Fri, 10 Oct 2003 16:43:00 +0100

Sometimes I hear the comment that object orientation is utterly out of fashion and that SOA is what should be used nowadays. Let's not start a discussion just yet about when I think SOA is usable... I'd like to say here and now that I believe there is no conflict between object orientation and SOA. In my opinion, OO is a great tool for building the services.

At first I thought Clemens was disagreeing with me here. He says (among other things):
"In a service world, there are no objects, there is just data".

But after reading the comments here, we are in agreement. Among other things he says this:
"OOP is great for the inner implementation of a service..."

In the same way that Clemens feels it necessary to explain that object orientation isn't important at the interface level in SOA, I think it's necessary to stress that object orientation is great to use for building the services themselves.

ToBeSaved(), part 2

Wed, 01 Oct 2003 21:40:00 +0100

As you might remember, several weeks ago I blogged here about how I might need something like ToBeSaved() to mark an object as ready to be persisted, so that the user could be in full control of what should happen.

I received lots of good feedback from Frans Bouma, Thomas Tomiczek, Mats Helander, Dave Brookes and Martin Fowler. (Thanks a lot, all of you!) After having thought some more about this together with Christoffer Skjoldborg and inspired by all the good feedback, we decided to skip the ToBeSaved() and instead create something called the Business Transaction Layer at the consumer side. Each use case will have a class in that layer and each use case will have a Unit of Work and an Identity Map. By doing it like this, everything a user now does within one use case so to say, can always be persisted together. Furthermore, when/if we need to isolate behavior in two forms from each other, for example, we just add another use case class.

You can think about the Business Transaction Layer as the Service Layer pattern, but typically running consumer side. (Of course, there are several different deployment scenarios, but here I'm talking about the layer in the context of a Windows Forms client talking to an application server.)

This was actually just one of several motivations for creating the Business Transaction Layer (and several other layers were also affected quite a lot because of this.) I will get back to discussing it more in detail in an upcoming article.

Design Patterns and Architecture Patterns with .NET

Wed, 01 Oct 2003 21:39:00 +0100

As I have mentioned before at my weblog (here), I have developed a new course that is called "Design Patterns and Architecture Patterns with .NET". In a few days it's time for the second run. If you find it interesting, there is some more information about the course in English here.

I think the course went very well the first time, but I have nevertheless refined it quite a bit. I have also added support for C#, so "everybody" that attends the course will get the discussions etc presented in their favourite language.

I just checked with LinSoft with whom I ran the course here in Sweden, and there are still some places available!

Demos and complexity

Thu, 25 Sep 2003 23:21:00 +0100

Those of you who have read my weblog know that I'm hoping Microsoft will show a lot more demos and recommendations for using the Domain Model pattern in the future. The basic reason for this is that currently it's sometimes hard to convince clients that the Domain Model is right for certain systems. Since Microsoft hasn't written much about it at all, especially not much that is positive, it might be considered that it is an approach not recommended by them.

Anyway, I spoke to Harry Pierson (DevHawk) about this the other day since he is joining the architecture group at Microsoft. He pointed me in the direction of this blog post of his. He makes a very good point here that I can apply to this problem of mine. In order to demo something, the demo should be simple. However, the Domain Model pattern is mainly of benefit in complex situations, which is kind of contradictory and, of course, raises problems.

BTW, Harry blogged more about our discussions here. As you understand from the blog post, I was looking for a good, crisp name to describe architectures for applications (apart from the presentation part) and services (not about connecting services, but rather how to architect them internally.) My initial attempt was "Application Architecture", although this might be misleading since it doesn't say much about services. Perhaps "Applications and Services Architecture"? Does anyone have any suggestions?

Working for IBM

Thu, 25 Sep 2003 23:20:00 +0100

I've been working mainly with Microsoft software since 1990, but so far I haven't worked for them. Now I'm going to work for IBM, but I have of course used IBM compatibles since mid 1980.

What will I be doing for IBM? I will be speaking at NRUF (Nordic Rational User Forum) 2003 where I will be giving a presentation called "Solving Five Architecture Problems with Architecture Patterns". I hope to see you there!

Dealing with phone spam

Thu, 25 Sep 2003 23:19:00 +0100

"Ordinary" spam is discussed quite a lot these days, and I for one really hate it. But I also hate what I call phone spam. By this I mean when a salesman calls trying to sell me stuff I definitely don't want to buy at any cost, and if I did want to buy I would contact them myself instead! Some of the things that irritate me are the stupid tricks they use, such as telling me that I should write down some codes so I can track that palm calendar they will send me. They won't, of course - at least that's what I suspect now after having being promised one three times, without even having wanted it in the first place!

Or when they ask for the guy who is responsible for light bulbs at the company. (I'm running a one man shop and I guess I buy light bulbs for less than 5 USD a year.) Or when they call from another country, speaking the worst possible English and want me to invest millions in their stock portfolios. Or... Well, you get the picture.

Anyway, when I complained about this to a friend of mine, he told me about a great trick. I should try to sell them stuff instead. So right now I'm sitting here, looking at the phone willing it to ring so I can give them very long and stupid codes they should write down. And will sell the callers "for loops" and such.

I know, I know. The people calling are just doing their job, and it's mean of me to tease them (or so my wife tells me), but I'm trying to do my job too. If I'm going to be interrupted, I think I should at least get a laugh, right?

Finally, though, I don't think applying this technique to ordinary spam is a good solution...

Our boat and XP, part 2

Fri, 15 Aug 2003 11:00:00 +0100

I will probably not blog next week at all so I thought I better post a third one today.

Do you remember my post about the XP principle of not doing anything up front that you only might need later? I found the article called "The Trip-Packing Dilemma" by Andy Hunt and Dave Thomas (authors of The Pragmatic Programmer) says something similar. So, watch out for DOGBITE (DO it or Get BITten in the End). As always, find a balance!

Protect Rollback() within a try block

Fri, 15 Aug 2003 11:00:00 +0100

I heard somewhere about how it's necessary to protect SqlClient.SqlTransaction.Rollback() within a try block, because Rollback() might try a ROLLBACK against SQL Server even though @@TRANCOUNT is 0. When I investigated this further with Lutz Roeder's .NET Reflector, I found out that the problem is solved in .NET Framework 1.1, but apparent in v 1.0. This difference may be well-known, but it wasn't to me. Perhaps someone else might have missed it too.

Either way, I think it's wise to always protect Rollback() with a try block because there are other reasons you might get an exception, as you can see if you inspect the discompiled code in Reflector.

Up until now I have not done anything about a possibly caught exception, other than swallow it. Perhaps I should actually investigate it and let the user know if the problem isn't that @@TRANCOUNT = 0... OK, from now on I will at least log the problem. I may do more than this later, if only to keep my paranoia under control.

JAOO 2003 in Aarhus, Denmark

Fri, 15 Aug 2003 11:00:00 +0100

If you have ever checked out my web site, or more recently my weblog, you will know that I mention conferences every now and then. So far I have only mentioned conferences that I'm speaking at myself, but today I'm going to make an exception.

Just the other day I was thinking about why there aren't any conferences in Scandinavia this autumn. Then I remembered JAOO in Aarhus and checked out their web site. It's a very good conference and I don't think many .NETers will have noticed it, perhaps because "JA" in JAOO stands for Java. This is a pity because a concept-oriented conference with some Java-focus is certainly very interesting to .NET guys too (there are loads of Java books in my bookcase, for instance).

There's also a lot of .NET at JAOO this year. For example, my colleagues from the INETA Speakers Bureau Clemens Vasters and Ingo Rammer will be speaking.

Other speakers are Kent Beck, Frank Buschmann, Jim Coplien, Ward Cunningham, Martin Fowler, Erich Gamma, Andy Hunt, Ralph Johnson, Robert Martin, Bjarne Stroustrup, Dave Thomas, and many more.

"Why" Instead of "How" and "What"

Mon, 11 Aug 2003 10:52:00 +0100

The other day, when I was working on one of our "Do It Yourself" projects, namely the garage, it struck me once more that useful documentation will answer the question "why" rather than "how" and "what". The previous owner of our house had started and finished several interesting renovation jobs, but I wonder "why"? (And I don't have any documentation for "how" and "what" here either...)

If we transfer this little story to programming, it reminds me about that I think we should be asking ourselves "why?" when writing comments. If you also need to write comments for "how" and "what", it might be a sure sign of smelly code and an indication that you need to do some refactoring.

WinSuMMit 2003 in Davos

Wed, 06 Aug 2003 11:05:00 +0100

I will be giving four presentations at WinSuMMit in Davos in October. The presentations are:

  • Solving Five Design Problems with Design Patterns
  • Solving Five Architecture Problems with Architecture Patterns
  • Choosing Data Containers for .NET
  • Master Transaction Design
I hope to see you there!


"You can't get too set in your ways!"

Mon, 04 Aug 2003 08:40:00 +0100

Around twelve years ago, one of my colleagues at the company I then worked at would occasionally pay a visit. His office was based elsewhere. On one of his visits he was smoking a cigarette during the lunch break and I was very puzzled because I had never seen him smoke before. When I asked him if he had started smoking at the age of forty something he said "you can't get too set in your ways!". (Translated from Swedish "man får inte stelna".)

I haven't suddenly decided to start smoking just so I don't become "too set", but perhaps my decision to move to C# as my default language instead of VB.NET could be explained in the same way?

I have worked with C# on projects, but so far it hasn't been my default choice. I'm also certain that I will do a lot of projects in VB.NET in the future, so in practice this decision doesn't really mean that much after all.

The Law of Leaky Abstractions

Thu, 31 Jul 2003 12:08:00 +0100

If you haven't read The Law of Leaky Abstractions, I recommend that you do. We should all be reminded from time to time that it's good to have under-the-hood experience and knowledge about stuff that a code generator fixes in a second or two, for example. The reason is that when it stops working, without the under the hood knowledge, you're toast. Another reason is that you might otherwise not even realize that you have a problem in the first place.

I remember a project several years ago where the data modeller was selected because he owned a shiny new data modelling tool that would generate the complete database schema from the model. The tool did what it was supposed to, but the guy at the keyboard knew too little about data modelling, and the generated database schema was flawed. (What he learned was that not every foreign key should be part of a compound primary key.)

My conclusion is that productivity enhancing tools are great. When you have the skill.

Choosing Data Containers for .NET, part 5

Mon, 28 Jul 2003 00:00:09 +0100

Now the last part in my article series for InformIT has been published. You find it here.

And here is a short description:
In this final part of his series on finding the best data container, Jimmy Nilsson looks at how the new architecture he works on behaves in relation to data container characteristics. On the way, he also discusses several tweaks without having to resort to custom serialization.

Work smarter not harder

Wed, 23 Jul 2003 10:31:00 +0100

Since I'm on vacation right now, I thought it was a great time to ask one of my friends, Christoffer Skjoldborg, to write a guest post for my blog. Here it is:

"Work smarter not harder!

When doing automated unit testing (using NUnit or similar) I often find myself getting into a paranoid mode where tests for every conceivable variation are written for every single Domain Object and then furthermore repeated in different layers to make sure a layer hasn't introduced a subtle bug. While this is all very nice when it's over and done with, it is teeeeedious code to write. Of course the code can always be abstracted somewhat by abstracting into helper methods etc., but since it has to work for every domain object I find it fairly difficult to abstract to a level where I can (almost) get rid of copy/pasting and searching/replacing - and the bugs usually associated herewith.

But then I realized that this is actually a perfect place to put the powers of reflection to good use. Performance is not so much of an issue in the test subs, and reflection can deliver some highly abstracted and general code that can work across different object types. Often I find myself writing test for the same base class methods that are being overridden in different sub-classes. Reflection can help me abstract this into a general test, for example.

But be careful! Reflection is a dangerous tool that should not be abused. When writing test suites you must take care that the code is tested in the way it is intended to be used. Make sure that property setters are not being circumvented, that you call the right methods when overloading etc. Reflection does give you power to circumvent just about everything and that is not exactly what we want in a test case."

Christoffer Skjoldborg, Independent Contractor,


Wed, 23 Jul 2003 10:30:00 +0100

The other day my friend Christoffer Skjoldborg drew my attention to the fact that not every dirty instance that is sent to a save method in the Service Layer should actually be saved. The problem is referred objects and the context is my new architecture.

Let's describe this a bit more. Assume you have a domain model instance for a customer and the customer has a number of orders. In the user interface the user adds a new order for the customer, but doesn't press the save button. Then the user edits the customer instance and saves it, and finally the user decides not to save the new order. Without taking extra care in the application, the new order was probably saved too, even though the user never intended it. The reason is that the order was dirty and was in the object graph that was sent to the Service Layer to be saved when the customer instance was sent. (OK, this was a simple problem that you could easily solve with other solutions, but translate this simple example to a general and advanced case.)

After having discussed this a little, Christoffer and I decided that a good solution might be to add ToBeSaved() as a method to the domain model classes. That method must be called explicitly or else the Persistence Access layer method won't care about the instance. This gives the user back the control of what is ready for being saved.

What we actually get is a three step process for saving, instead of the old two step one. The new one is like this:

  • Property is changed => instance gets implicitly dirty.
  • Instance get ToBeSaved() call.
  • Instance is sent to save method in Service Layer class.
What do you think? What's your favourite solution here? Send me your comments -

Part 6 of "domain model by db-guy"

Wed, 16 Jul 2003 10:55:00 +0100

Part 6 of my article series called "A pure object-oriented domain model by a db-guy" has been published. Part 6 focuses on the Persistence Access layer and you find the article here.

Meeting Jim Melton

Wed, 25 Jun 2003 22:40:00 +0100

The other day I was invited to an evening event by Mimer here in Sweden. (Thanks again, Mimer!) The ISO SQL standardization committee were having one of their annual meetings in Stockholm (discussing SQL:2003 and SQL:2007) and after a long day of working on upcoming SQL standards, they needed to relax for a few hours chatting with ordinary mortals in the industry.

This is how I finally got the chance to meet Jim Melton in person and it was just great speaking to him. Jim is the editor of the ISO SQL standard, and has written several books about the standard language for stored procedures, PSM among others.

The first time I "spoke" to Jim was when I was working part time as a teacher at a Swedish university. I thought it would be a great idea if we could get "guru supervisors" to help with some essays on a database course. Jim was one of these guru supervisors and did a great job in helping, guiding and engaging the students. As I remember, one of the essays he supervised was about XML as a query language and since this took place about five years ago, this was a completely undeveloped area at the time.

Three other guru supervisors were Joe Celko, David Jordan, and Martin Rennhackkamp. They also did a great job and they later gave presentations at a conference called DB-days that we held at the university.

BTW, both Jim and Joe are currently working on new books, and David recently published this one about JDO.

Serialization issue with DataTables when mixing versions

Wed, 25 Jun 2003 10:10:00 +0100

Today I have invited my friend Ingemar Lundberg to post a very interesting blog item. Read on!

"Am I the only one that has run into problems with .Net Framework compatibility problems in scenarios where Remoting is involved?

Here's the scenario. All assemblies are built with VS.Net 2002, i.e. 1.0 of .Net.

I have a server (actually a desktop PC, but never mind) that has v1.1 installed side-by-side with v1.0. I have a Remoting object hosted in IIS/ASP.Net.

I have a client with v1.0 calling that Remoting object. When retrieving a DataTable I run into trouble. To make a long story short, this stems from the fact that the Remoting object runs under v1.1 (even though built for 1.0) and the client runs under 1.0. The serialisation of DataTable passes version information of the System.Data assembly. The server has 1.0.5000.0 of the assembly and the client has 1.0.3300.0. Clash.

One way of solving this problem (which I prefer since it makes my assemblies run under the version of .Net they were built for) is to configure the Remoting hosting web to run under 1.0. With IIS 5+ you use aspnet_regiis like this:
C:\WINDOWS\...\v1.0.3705>aspnet_regiis -s W3SVC/1/ROOT/MyRemotingSvc

The specification of the web at hand is somewhat mysterious. MyRemotingSvc is the virtual directory (web) where I host my Remoting object. Next time you run you get another aspnet_wp.exe process on the server that uses v1.0.

With IIS 6 you configure the web to use an application pool with v1.0.

Ingemar Lundberg
Software Architect, Banverket

Is Microsoft moving to patterns? Part 2

Mon, 23 Jun 2003 10:55:00 +0100

The other day I blogged about the fact that Microsoft seems to be moving more and more towards recommending patterns in general and the Domain Model pattern [Fowler PoEAA] in particular. (Not as the silver bullet of course, but as one good solution for certain situations.) I think I found another very strong indication of this when I talked to Edward Jezierski the other day. Ed is program manager and solution architect of the Prescriptive Architecture Guidance Application Blocks for .NET and is responsible for a lot of the recommendations and best practices coming from Microsoft.

Briefly, what I said to Ed was something like how we don't expect Microsoft to build exactly what the developers want when Microsoft builds sample/reference applications. Instead, just by seeing some different versions, the developers would be able to get an idea of how the Domain Model pattern might behave. It would also be possible to get a sense of what productivity to expect. It's quite often said that productivity is really bad when the Domain Model pattern is used, but I don't think that's necessarily so in the long run.

Edward said the following: "I agree with you, that difference in approaches is what causes it to be an area ripe for long debates based on fuzzy metrics. My reco is - generally speaking for larger apps - if you have the skills available, pay the cost up front of designing it right & building up your infrastructure to increase the productivity (code gen, tools, etc) --> and that's where I see patterns and practices kicking in."

I'm pretty sure we will see Domain Model pattern best practice recommendations coming from Microsoft soon!


Mon, 23 Jun 2003 08:00:00 +0100

I took part in workshop the other day at BTH, the university where I used to work part time a couple of years ago. The workshop was about "variability" in applications, how to prepare for it, how to achieve it, where to apply it and so on. It was an excellent workshop and it made me even more confident that the Domain Model [Fowler PoEAA] Pattern is great for dealing with complexity.

BTW, one of the other participants was from Symbian/UIQ. He (Magnus Östvall) was part of the team that built the user interface for SonyEricsson's current flagship, P800. He made me realize that the whole thing about variability is even more of a problem when you have several third party vendors that code against your API, and when the devices can vary as much as cellular phones, PDAs, and so on do today.

I'm lucky in that my projects usually only deal with different customers' business rules, and sometimes there is only one customer per project. How clean and simple!

VS Live in Orlando

Mon, 23 Jun 2003 08:00 +0100

I will be giving a presentation called "In-Depth Transaction Design" at VS Live in Orlando in September. I hope to see you there!

Our boat and XP

Wed, 18 Jun 2003 16:07:00 +0100

I'm very fond of Extreme Programming (XP), Agile, test-driven development, and so on, but I must confess that I have a problem with the "don't do anything upfront" style. I have tried to cut down on my old behaviour of guessing what I should prepare for, but still I think there is stuff that should be dealt with up front.

The other day, when I was getting our boat ready for the coming boating season, I remembered an old metaphor that I have used to defend my behaviour even after being XP-ified. Say that I did no work on our boat until the time came to take it out for the first time that season. When my family finds that all conditions are met (nice weather, spare time and so on), we have to spend two days working on the boat. Not what we want. So, in not doing the work up front, it would mean that we wouldn't be using the boat. It's as simple as that.

On the other hand, in preparing the boat up front, I might be wasting my time. Hey, this is Sweden after all. The weather might be bad when we get to take the boat out around the islands, but so far I think my behaviour has been good.

What am I trying to say by all this? Well, you should still prepare a certain amount of stuff, but think carefully about it before you decide to. That is probably exactly what XP means too.

Stored procedures or not?

Sun, 15 Jun 2003 22:55:00 +0100

A few weeks ago Frans Bouma posted a blog saying that he wasn't going to use stored procedures for "ad hoc" queries anymore. Those who know me know that I really like using stored procedures. There are problems with stored procedures and one is ad hoc queries, but I still find it beneficial to use them. I have to check with Frans and find out if he is dropping stored procedures for everything. I'll be back.

You know you are a geek...

Sun, 15 Jun 2003 21:35:00 +0100

...when you feel happy that the label on your new socks is GoF.

Well, alright, it was really GOFF, but a story doesn't have to be true as long as it is good, right?

Is Microsoft moving to patterns?

Fri, 13 Jun 2003 9:20:00 +0100

I've earlier thought Microsoft have been pretty inactive regarding giving recommendations and best practices when it comes to design patterns, object-oriented domain models, and so on. For example, here is a quote from this document:

"It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. Generally, you should use a more data-centric format, such as a DataSet, to pass the data from the data access logic components to the business layers, and then use it to hydrate a custom business entity if you want to work with the data in an object-oriented fashion. In many cases, though, it will be simpler just to work with the business data in a DataSet."

Is it just me, or are they starting to change their ways? For example, look here and here.

Am I just reading too much into the signs because it's what I want to happen? For example it would be a great help in getting people to sign up for my courses this autumn.

Mail list about Agile and .NET

Wed, 11 Jun 2003 13:56:00 +0100

The latest mail list I have subscribed to is agiledotnet. It has so far been very interesting.

Current status regarding articles

Thu, 5 Jun 2003 08:30:00 +0100

I guess I'm just old-fashioned, but I'm still writing articles in this new world of blogging. The two series of articles I've been working on lately are:

  • A pure object-oriented domain model by a db-guy (part 4 is found here)
  • Choosing data containers for .NET (part 4 is found here)
Many of my upcoming blogs will probably refer to those series of articles so I thought it apt to mention them here.

A couple of weeks have passed since anything new was published. The current status is that I'm working on part 6 of the db-guy articles right now. Part 5 is in alpha mode, but it needs a lot more work and I will probably finish part 6 first. When part 6 is done, I will write part 5 of the data containers articles.

More on code vs data

Wed, 4 Jun 2003 23:22:00 +0100

There have been several blogs about code versus data which more or less say that code is context-dependent and therefore shouldn't co-exist with data. See, for example, the blogs of Clemens Vasters, Don Box and Tim Ewald.

In a way I agree, but I also see the beauty of having at least some behavior with the data. The keyword here is "some". It's great to have some code with the data so as to execute both at the consumer tier and at the middle tier. Some should execute only at the middle tier, and some only at the data tier.

OK, when consuming web services we obviously have a problem with the code. Perhaps we will soon see a new xml-based standard that describes behavior as well as just data.

New course on applying patterns

Mon, 2 Jun 2003 12:00:00 +0100

I've come up with a new course about applying patterns which is targeted at .NET. The three days are spent like this:

  • Day one + evening: Design Patterns
  • Day two + evening: Enterprise Architecture Patterns
  • Day three: My current favorite default architecture
The examples I give are currently written in VB.NET, but of course it is for C# fans too (I think I will translate the examples to C# as well.)

I ran the course for the first time last week and I think it went very well. More information (in Swedish only at the moment) is found here. Hopefully there'll be cause to translate the course into English soon.

A scalability report from Pragmatier

Fri, 30 May 2003 01:00:00 +0100

Pragmatier, who produce one of the O/R mapping products for .NET, have published a very interesting report about scalability here. They have rebuilt the Petshop example application with their product and it shows impressive scalability when executing the application in a Microsoft lab.

Disclaimer: The folks at Pragmatier are friends of mine and I was invited to be present during the first two days of the tests.

Better late than never!

Fri, 30 May 2003 22:00:00 +0100

At last I have a blog too. I don't yet know what I'm going to use it for, I just really felt I had to have one.

No, seriously, I plan to use the blog for writing down some thoughts on development. For example about patterns, object-orientation, databases, and so on. I will probably also add an announcement or two for new articles etc. We'll see.

Don't expect the blog to be as active as Robert Scoble's blog, for instance, but hopefully there will be a post or two each week.