Really nasty VisualStudio2008 RTM bug

From kb945425

Lines of code may be missing if you compile a solution that has a complex project structure in Microsoft Visual Studio 2008. The solution may incorrectly compile to Microsoft intermediate language (MSIL) code that omits certain method calls in the compiled .dll. This problem occurs when there are method calls to classes that participate in an inheritance hierarchy that uses generic constraints.

This is really scary. You don't event notice that your application does not do everything it is supposed to.

Kathleen Dollard found this bug.

 

Technorati Tags: VB.Net

2007 data security summary

At the end of year 2006 F-Secure had 250 thousand malware detections. 2007 they added same amount of detections. If this trend continues, we'll be in big trouble.

 

 

How long  F-Secure, McAfee, Kaspersky and others can secure our computers? Sooner or later we need a different approach.  It's not acceptable that virus scanners slow down our computers too much. The security should by transparent. We shouldn't notice it at all. The network infrastructure should protect us. When do we see that?

Quote of the Day

 

Good to Great by Jim Collins

...the purpose of bureaucracy is to compensate for incompetence and lack of discipline -- a problem that largely goes away if you have the right people in the first place. Most companies build their bureaucratic rules to manage the small percentage of wrong people on the bus, which in turn drives away the right people on the bus, which then increases the percentage of wrong people on the bus, which increases the need for more bureaucracy to compensate for incompetence and lack of discipline, which further drives the right people away, and so forth

Active Record vs Objects

Robert C. Martin (Uncle Bob) wrote an interesting article about Active Record and objects. I do admit that he is partially right but I don't agree with him fully.

Martin Fowler's definition of Active Record is

An object that wraps a record in a database table or view, encapsulates the database access, and adds domain logic on that data.

Uncle Bob wrote

The problem is that Active Records are data structures. Putting business rule methods in them doesn’t turn them into true objects. In the end, the algorithms that employ Active Records are vulnerable to changes in schema, and changes in type. They are not immune to changes in type, the way algorithms that use objects are.

The fact that Active Record is based on database structures does not make it any less object-oriented. Active Record does not even try to solve the impedance mismatch between databases and objects. A full-blown ORM-tool should be able to solve the discrepancy. I don't see Active Record as an object-relational mapper at all. Ok, you can always say it's 1:1 mapper and it's hard to argue against that.

It has “hidden” data, and exposed behavior. I put the word “hidden” in quotes because the data is, in fact, not hidden. Almost all ActiveRecord derivatives export the database columns through accessors and mutators. Indeed, the Active Record is meant to be used like a data structure.

Active Record does not imply that data is exposed directly and this is the first time I've heard that AR is meant to be used like a data structure.  Most of the AR-frameworks just are a bit liberal on data visibility but so are also many ORM-tools.

Applications should be designed and structured around objects, not data structures. Those objects should expose business behaviors, and hide any vestige of the database. The fact that we have Employee tables in the database, does not mean that we must have Employee classes in the application proper. We may have Active Records that hold Employee rows in the database interface layer, but by the time that information gets to the application, it may be in very different kinds of objects. 

Active Record couples the object design to the database design. I don't see it as a problem. It's a design choice. In many cases it's totally acceptable approach. But if the business logic is complex or you want to use for example inheritance, the design gets messy quite soon. That will lead you to for example Data Mappers and full-blown ORM-tools. 

Hi, My name is Tapio, and I write crappy code.

 

It's been more than a day since a wrote crappy code. Today i didn't. I didn't write a single line of code. I know, I know, it's only an excuse. At 5 PM I almost slipped.  Tomorrow will be a difficult day. How can I avoid slipping?  Maybe I shouldn't write any new code. Just do some simple refactorings. We'll see.

While acknowledging you're a Terrible Programmer may be necessary to becoming a Great Programmer, it's not sufficient.

Thanks to Marc, Ted and Udi. Great posts. Atleast now I know, I'm not alone. 

This has not happened before

 

This can't be happening to me. The system will be in production in two weeks. No panic, no emergency meetings, not even acceptance test defects anymore. We must have forgotten something really important. This has to be a dream. Things like this don't happen in real world. Did we do something differently? Not really. Maybe we paid more attention to testing. It helped a lot but it alone didn't cause this. The most important thing was our team. It's nice to have a bunch of smart people working in the same team. Smart people are not afraid of asking questions. If they have opinions they usually are willing to share them. Good communication gives us a better chance to spot problems in our design and find better solutions. Little by little everybody understands how the system works and how different parts of the system work together.  The system might get a chance to succeed.

Linus Torvalds on Git

Would you like to use this kind of features in your .Net development environment?

 

Anonymous methods and maintainability

Anonymous methods are a cool language feature in C# 2.0. I'm not a big fan of using them but they are certainly useful in many scenarios. After reading some articles (here, here, here and here) I realized that even if you can write very elegant code using them, there is a real danger hiding behind the corner. The code might seem clear and obvious but subtle differences can have a huge effect on behavior. This is not always a problem but in some cases it will be. Somebody else will have to maintain your code. If the new guy is not aware of all those subtleties he will have hard time maintaining your code. A small change could break your code and it might be very difficult to find out why it's broken. Keep those unit tests up to date. Without them you are asking for trouble.  

 

Technorati Tags: .NET

Thread Local: A Convenient Abomination.

A couple of weeks ago i tried to find a storage place for sessioncontext(s)  so that one WinForms application could have multiple sessions open at a time. I noticed that there are no easy solutions for that problem. Today i read an article that describes the other side of the coin.

Thirteen years ago, while working on my first book, Jim Coplien and I were having a debate on the nature of threads and objects. He made a clarifying statement that has stuck with me since. He said: “An object is an abstraction of function. A thread is an abstraction of schedule.”

It has become the norm, in Java applications, to assume that there is a one-to-one correspondence between a thread, and a unit-of-work. This appears to make sense since every Servlet request has it’s own particular thread. Framework authors have built on this assumption by putting unit-of-work related information (e.g. session) into ThreadLocal variables.

Clearly, the more ThreadLocal variables that hold unit-of-work related information, the more that the thread and the unit-of-work are related. While very convenient, the basic assumption is dead wrong.

It doesn't matter if you have 1 or 10 threads. The problem is always the same. UnitOfWork or SessionState should have a place that does not depend on threads. It's a dangerous assumption that UnitOfWork is directly related to one single thread. That assumption seriously limits your other architectural choices. 

So, though convenient, ThreadLocal variables confuse the issue of separating function from schedule. They tempt us to couple function and schedule together. This is unfortunate since the correspondence of function and schedule is weak and accidental.

What we’d really like is to be able to create UnitOfWorkLocal variables.

Couldn't agree more.

 

Technorati Tags: WinForms

Zune Phone Parody

 

Rodrigo y Gabriela

Do you like acoustic guitar? Well they are really, really, really freakin' good.

 

 

DDD + IoC + WinForms = Headache

 

I'm trying to wire up DDD-style domain classes, NHibernate and Windsor IoC into one nice mini-framework and separate it from UI/Application layer.  At first sight everything seemed pretty straight forward. But then I hit a wall. Some of my domain classes needed a reference to a session-object. This session-class contains instances of Windsor’s IWindsorcontainer, NHibernate’s ISession, user-object etc and might also contain some other application-data.  Where should the application store this session-object? How can domain-objects find it?

In ASP.NET world this is not a problem. Session specific data can be stored into HttpContext and any object can access it easily. The only disadvantage is that then I've still got to reference System.Web from my domain-assembly.

WinForms is another beast. If the application has only one form open at a time, I could save the session-object into the CallContext. What if the application has multiple forms open at a time and each of them wants to have a separate instance of my session-class?  CallContext is out of the question. So are all thread-specific alternatives.  What is left? Nothing?  I’m not the first person pondering this issue. A solution probably exists but I can’t find it. Do I really have to inject the session-object into every object instance that might need it? Or should I refactor a lot behavior from domain-classes into services and inject the session-object into them. I don’t like this approach because I want my classes to be more than data containers.  

Sigh.

Technorati Tags: DDD, IoC, WinForms, NHibernate, Windsor, .NET

Visual Web GUI

Visual Web GUI is a solution that allows you to write a winforms application and at compile time transform it into an ASP.NET application. The application has same look and feel as winforms applications and it will behave exactly as the winforms application does. So instead of creating an ASP.NET page you create a VWG-form. At Build time the form and controls are translated into ASP.NET, Ajax and JavaScript code.

I’m speechless. The whole thing is so amazing that you must see it before you believe it. Take a look at it.

And the whole stuff is open source and licensed under LGPL.

Roy Osherove wrote more about VWG.

Google moon

Amazing details from the moon!

Remember to zoom it enough!

Douglas Crockford on programming and quality

Douglas Crockford presentation on Quality.

ADO.Net Entity Framework and persistence ignorance

I read an ADO.net Entity Framework blog post and realized that those guys don’t fully understand why people are so concerned about lack of persistence ignorance in ADO.net Entity Framework.

Separation of concerns and single-responsibility principle (a.k.a. cohesion) are very important concepts in OO-design. Basically, you want to keep classes, functions, etc. focused so that there is only one reason for them to change. If your domain classes aren´t fully persistence ignorant you have 2 reasons for a business class to change. First, when you need to change the persistence logic, and second, when you need to change the business rules. This “violates” the SRP.

If your domain classes are fully persistence ignorant, it makes them more testable. If they are too tightly coupled to persistence mechanisms, how do you test them? Objects are not just data containers. They also contain behavior and business rules. Testing will be a nightmare if you can’t test behavior without persistence.

Msdn blogs had also an interesting thread.

Happy Father's day !

Are you ALT.NET?

David Laribee summarized
nicely a movement in the .NET community - ALT.NET

What does it mean to be to be ALT.NET? In short it signifies:

1. You’re the type of developer who uses what works while keeping an eye out for a better way.
2. You reach outside the mainstream to adopt the best of any community: Open Source, Agile, Java, Ruby, etc.
3. You’re not content with the status quo. Things can always be better expressed, more elegant and simple, more mutable, higher quality, etc.
4. You know tools are great, but they only take you so far. It’s the principles and knowledge that really matter. The best tools are those that embed the knowledge and encourage the principles (e.g. Resharper.)

When tools, practices, or methods become mainstream it’s time to get contrarian; time to look for new ways of doing things; time to shake it up. The minute Entity Framework surpasses NHibernate, I mean the very instant it empowers me to better express my intent, so long NHibernate. It’s been real, it’s been nice, but I’m on to the better thing. Of course it’s not as black-and-white as all that. It’s up to us to stay aware, educated, and to give our input. It’s not a game of wait-evaluate-wait-evaluate, it’s a matter of contribution.

But Ayende@Rahien made a good point. It's not about choosing between the good and the bad. It's more like

A developer that seeks to find the best tools and practices, and judge them on merit.

The Tao of Programming

Ancient wisdoms.

A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''

The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''

NASA May Have Killed The Martians

CNN reports that NASA may have found life on Mars via the Viking space probes in 1976-77, but failed to recognize it and killed it by accident.

LOL !!!

Software Development Lifecycles (SDLC) and the 3 rules of moron-dynamics

Tom Shope wrote an excellent article about pitfalls of SDLC. I almost agree with him. There is no substitute for talent. He says that "average programmers will never produce great code". But you also must remember that good design can force average programmers to write great code. At least it makes it less probable that the project would end up into a disaster.