Trond-Eirik is rambling on about stuff

General stuff about system architecture and development

Wednesday, June 06, 2007

There is not enough time

In the last couple of months I have done some attempt to stay on top of stuff and get new inputs from sources as IT-related newspapers, blogs, MSDN and reading some books.

I really wonder if I’m a totally slow reader, using way to little time on stuff or what. It’s just so much stuff out there that I should have loved to read, understood, tested and commented upon. However, there is really-really not time in my life to keep on track with all of it.

And that’s even if I’m just sleeping 5 hours a night and drop all social life.

Maybe that also some part of the problem, I’m actually trying to see my two children (and my wife) a couple of hours every day instead of sit down in my office and staring into my computer screen. And yes, it was that damn thing called “work”. What was that again? Ah, yeah. That was the reason for why I wanted to stay on top of stuff. And to get the basic stuff there done takes of course 8-12 hours a day…

I see that my RSS feed on “Recent Blog Postings (MS Architecture)” currently has 249 unread posts, and I’m pretty sure that at least 80 of those are really interesting stuff!

But hey, after one week away from the computer I’m actually up to date on several of the other RSS feed’s I’m monitoring…

I think I’ll get some more jogging/swimming/sporting/mounting walking under my feet the next couple of months and start studying speed reading or something like that J

 

For everyone out there contributing with all this great blogs and discussion/stuff, thanks!
Yes, I really mean it. There is so much great reading material out that there is right to the core of important issues that it’s really, really cool! If there was only some more time… What about introduction 48 hours days?

Labels:

Friday, June 01, 2007

Communicating with the customer

Over a number of years I have been working with a number of different customers while planning, designing and implementing systems.

 

Normally these customers have been people with great skills in their work, but with little or no experience in describing software systems.

 

In the process we have been using a number of different tools to try to communicate better with the customers. What I have often noted is that if you try to tell the customer that “we are using use-cases as a method of describing what the software should do” or “we are going to develop a requirement specification to describe how the system is going to work” the customer often seems to be distracted by the terms used. The customers is often willing or even interested in using the methods suggested, but often it seems to meet practical issues when trying to actually do this.

 

For me it seems as just introducing these terms and methods by names in an early process will by itself often cause the customer to feel unsecure or unfamiliar with the techniques and methods used when describing a system.

Due to this I think that you not necessarily should introduce naming for stuff in the early stages of a project. If you for example want to discuss and show the customer a use case diagram you should just show it to the user and discuss the content of the diagram, what the arrows means and so on.

 

Then, when the customer after some time actually discovers that the given type of diagram is coming up again-and-again you may fulfill his felt need of giving the diagram some name, for example “use-case-diagram” ;-)

 

My point here is that, when working with people that is not in the industry, we should and must use our tools (their good tools) by we should also be very careful about how we approaches the customer when discussing the issues at hand. I think it is important to keep the focus on the issues that the customer is familiar with and avoid introducing terms and words that adds confusion to the communication.

 

Labels:

.Net 3.0 is doing more for leaky .Net applications

After a bumpy start with .Net 1.1 (1.0 does not count) where several issues regarding memory consumption and especially releasing memory .Net seems to be going in the right direction.

.Net has always been memory "hungry". The ide seems to be based on "unused memory is doing no good to anyone".
So, problably based one something like that, MS seems to have decided that any .Net application should grap a really good chunk of memory if available.

And that idea is resonable enough, in some closed single user fantasy world!

It soon became clear that altough .Net 1.1 applications was great at hugging memory, they were not so great at freeing it. Basically, whatever memory a .Net 1.1 application had got it's gready fingers on, was lost forever (or at least until the app closed down). In a multi user envirment with a lot of users running their applications over a long time this behaviour would very fast lead to out-of-memory exceptions as the first 20 instances of the application has already used all available memory.

In .Net 2.0 this seems to have improved a great deal, and from what I can see the behaviour and freeing of memory is mutch better. Now an application actually seems to be able to release back some memory without shutting it down first.

Now, in .Net 3.0 it finally seems as MS have understood that it is not enought to say: "Hey, we have a managed language and a garbage collector"

You will still have memory issue if you do the wrong stuff. One of the sources for doing the wrong stuff is event handlers.

Whenever you start listening to event from a event source using += you are actually creating a reference to that object. If you do not remove that reference, the event subscriber will be kept in memory as long as the event source is alive.
If you for example hooks up to the Application.Idle event in a form, that form will not be available for the GC as long as the application is executing.

On of these issues that is really important to consider is notification enabled collections. For example collections that implements IBindingList or just implements change events.
Say that you have one such collection with 1000 items within. Then you create a reference to one of those 1000 items.

For a "normal" collection, the collection has a reference to all items within the collection, the items in the collection has no reference to the collection. As soon as you no longer holds on to the collection itself, the collection and the 999 items that you are not refering to becomes available for the GC.

If you have an event enabled list, the list must to be able to notify any listeners of changes in any object within the list. To do this the list has to subscribe to events from all the entities contained within the list.
Using regular events this will create a reference from the objects within the collection to the collection itself.

So, that single object in the list that you made a reference to will now also causes the list itself, and therby all the 999 other objects to be unavailable for the GC.
This is of course not very nice when it comes to memory consumption.

I soon discovered this when working with the business layer of ByggOffice. To handle and avoid this situation I made a couple of specialized interfaces and a managment class that used the WeakReference object to support multicast events. The weak references made it possible to dispatch the events and at the same time make ureferenced entities available for the GC.
This solution worked out very well.

Now, in .Net 3.0 MS has finally started to take this issue serious and have introduced stuff as the WeakEventManager class and IWeakEventListner interface.
They are also doing a lot of referals towords the "weak event pattern":

"In typical applications, it is possible that handlers that are attached to event sources will not be destroyed in coordination with the listener object that attached the handler to the source. This situation can lead to memory leaks. Windows Presentation Foundation (WPF) introduces a particular design pattern that can be used to address this issue, by providing a dedicated manager class for particular events and implementing an interface on listeners for that event. This design pattern is known as the WeakEvent pattern."

You can read more about the "WeakEvent pattern" here: http://msdn2.microsoft.com/en-us/library/aa970850.aspx

Labels: