TechShorts

Why waste everyone's time with a bunch of meaningless just-in-case wrapper code? Start with the simplest thing that works-- a public variable. You can always refactor this later into a property if it turns out additional work needs to be done when the name value is set. If you truly need a property, then use a property. Otherwise, KISS! Update: As many commenters have pointed out, there are valid reasons to make a trivial property, exactly as depicted above: * Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties. * You can't databind against a variable. * Changing a variable to a property is a breaking change. Source: Coding Horror: Properties vs. Public Variables So this answers the question on why you use properties in .NET and not just public variables. I've always used properties but on occasion of used public variables. Small object, needed it quick so didn't bother with the getter or setters

Ok, so I found another alternative to BlogJet: Performancing.  This is an extension of FireFox so I have to have that installed. So far it looks like it is easy to use.  It can't seem to be able to insert an image like Live Writer but I think it will be easier to blog about something I found on the web. I have a feeling I will keep using Live Writer and only use this on occasion. powered by performancing firefox   OK I don't like that Performancing does self promoting.  That is a big minus.

So I just heard about the Windows Live Writer Beta.  I am a big fan of BlogJet so when I heard about this new Microsoft program I was skeptical.  So far I like it. Now if it uploads this picute then I will have a reason to start using it and not use BlogJet. I am always on the lookout for new and better tools.  If this does what I need it to do then I will switch to it.

I was working on a stored procedure the other day, not one that I wrote originally but one that was causing performance issues in out system. The procedure was taking any where from 40 to 60 seconds to run, which is unacceptable in a web service. This in fact was causing the web service to time out. An inspection of the execution plan showed that one part of the procedure was doing an index scan and that it was this that was taking up over 85% of the execution time. I was totally baffled, it was hitting the index so why wasn’t it faster? Then I learned three things all at once: Implicit Conversion non-sargable kills performance Index Seek is preferred of Index Scan Implicit Conversion In the stored proc a variable was defined as an NVARCHAR(20) but the field in the table it was being compared to was a CHAR(10). This lead to an implicit conversion of the variable to a CHAR(10), which lead into the next issue: Non-Sargable Kills Performance Sargable refers to the pseudo-acronym

The other day, though, I stumbled over yet another software quality assessment tool: Lattix LDM. And what impressed me immediately was it´s easy to understand output based on the intuitive concept of the Dependency Structure Matrix (DSM). Ralf's Sudelbücher : .NET naked - See these hitherto unpublished pictures of the .NET Framework architecture . Ralf demonstrates how a Dependency Structure Matrix can reveal the overall architecture quality of a product.  A very cool concept and another tool to add to the toolbox.