Static Code Analysis with NDepend

A few years back I tried the first version of NDepend over a product we had. I was divided with the results. Well, not as much as the results, that were incredible, more with the imaturity of the interface.

Now that this problem is solved, let give it another try at ndepend.com.

Here's what Hanselman has to say about it.

Virtual PC 2007 released

Here's a not so new news. You can download it here.

Virtual Disk Conversions

Here's an interesting post about Virtual Disk Convertions.

Policy Injection Application Block

Here's something we all have been waiting for ages: the Policy Injection Application Block.

Here's Hollander's definition:

But first things first: what the hell is this thing? The short(ish) answer is that the Policy Injection Application Block will simplify the separation of business logic from cross cutting concerns, by letting you define policies and the objects/methods they apply to in a declarative way. Each policy contains a pipeline of "handlers" that are executed before and after a policy-enabled method is called. The handlers can do whatever you want, but the most common scenario will be to implement cross-cutting concerns such as logging, validation, exception handling and authorization. By amazing coincidence, Enterprise Library already includes blocks that implement these kinds of capabilities, so our out-of-the-box handlers will be simple wrappers over existing application blocks.

I see it as a very focused Aspect Oriented Programming. Let me show you why:

While the number of handlers and the details on how they will work are not
entirely set in concrete, here is what we are hoping to include:

• Validation Handler. This will look for validation rules applied on the method parameters or within types in the message signature, and call the Validation Application Block to check the supplied parameters against the validation rules. If validation succeeds the method will be called. If not, the handler chain will be aborted and an exception will be returned to the client.
• Logging Handler. This will call the Logging Application Block to write a log message either before the method is called, after the method is called, or both. Optionally the handler will be able to log details such as supplied parameter values and call execution time.
• Exception Handling Handler. This handler will do nothing before the method is called, and do nothing after the method is called unless an exception was thrown. If an exception was thrown, the handler will pass it to the Exception Handling Application Block using a specified exception policy, and any resulting exceptions will be returned to the client. In effect this will eliminate the need for boilerplate exception blocks when using the Exception Handling Application Block.
• Performance Counter Handler. This will create a number of performance counter instances measuring things like number of calls, calls per second, average call execution time and number and rate of exceptions thrown by the target method.
• Authorization Handler. This handler will use a specified authorization provider configured with the Security Application Block to check if the current user (obtained from the thread principal) is authorized to perform the current task (specified in the handler configuration). If so, the target object is called. If not, an exception will be returned to the client.
• Caching Handler. This handler will generate a cache key based on the target
  method signature and values, and use the Caching Application Block to see if the method has already been called with these values within the configured cache threshold. If a value was found in the cache, it will be returned to the client and the handler chain will be aborted (i.e. the object will not actually be
  called). If a value was not found in the cache, the method will be called, and
  the return value will be added to the cache on the return path.
  

Looking forward to play with these... We can now finally enrich the latest Active Record implementation of our choice with the authorization and logging funcionalities we always have. And we won't have to rewrite the code that generated those :)

Demystifying Vista memory usage

People are still afraid of Vista memory usage, even after reports of successful installation on some pretty old hardware.

It's true: Vista needs more memory than XP, but not as much memory as people may think. I believe the problem arises because of a Vista memory management policy: Vista tends to use memory unused memory! This is policy Unix users are used to, but not to Windows users.

Let me give you an example: on a recent machine Vista tends to use about 650MB PF usage on a clean install. This scares too much users, who think they won't ever be able to install it on a 512MB machine, or even use it on a 1GB one. On a previous post, I reported a successful installation on a 512 MB Celeron, reporting half the memory usage (ok, no Aero here).

But yesterday I had the most interest hint of PF usage somehow misleading information: on my Vista installation, when booting the first OS, VMWare player freezes the OS for 30 seconds or so. I decided to investigate, and the results were:

• Vista was reporting about 900MB of PF usage (I had outlook, IE7, an RSS reader and some utilities running)
  
• I booted VMPlayer VM
• PF usage rose to 2GB, leaving Vista stalled for about 30 seconds
• PF usage dropped to 372MB!
• PF usage slowly increased to 450MB, as VMPlayer claimed more memory

Uau! What's the meaning of this? A simple explanation could be: Vista is claiming way more memory than XP, but can live without it. Using this "unused" memory, Vista can boost a lot of operations, and above all, leave the disks idle. When that memory is needed for applications, Vista will free it.

If this is true, Vista is probably not being particularly assertive. The first problem with this is that Vista is misleading the memory management information - shouldn't it be marked as cache? The second problem with this approach is that it scares users away.

If this is true, people will probably write utilities that will claim and release memory just to keep users happy, loosing some of Vista's memory management capabilities.

Can anyone please confirm or deny this behavior?

PS: I'm telling you Vista does may need less memory than it tells you, I'm not advising you not to upgrade your memory with Vista. Let me be clear about it: if you can afford to spend 40 bucks, do yourself a favor and get more 512MB of memory.

Moore's Law again

Forecasting the desktop developing requirements for the next 3 to 4 years can't be done without some history retrieving. From the RAM usage perspective, my developing workstation had the following evolution:

. 1999 128 MB
. 2001 256 MB
. 2003 512 MB
. 2005 1024 MB
. 2007 2048 MB

Cool, ehm? Looks like Moore's Law is still active after all. At least on my RAM...

Converting videocasts for my Zen Vision

Most of Channel9 videocast just don't run on my Zen Vision:M. After looking for free converters, I ended up choosing Microsoft Encoder. Give it a try - it's free!

A fresh aproach for SoC over data and business tiers

Howard Dierking has posted this great article, where he proposes to couple/decouple data and business implementation using C#3 extension methods. Cool!

On an Stroustrupian approach, we usually kept operations near data. The need for tier isolation has bring them appart. Maybe this is the time to bring them back together again...

Vista day 5: certificates messup

This morning Live Messenger stopped working, with a certificate error.

I make sure my clock was ok, and after some googling I found the answer here. I had to disable «Check for server certificate revocation». Oops... But it did work...

Vista day 3: I've got my good old soft phone back!

Well, kind off...

Truthfully it isn't running directly on Vista, but on a Virtual PC guest...

My desktop is turning it self on a very silly machine: I've got a VMWare player running an XP with a development environment, and Virtual PC running my VoIP soft phone. Long live VMs!

Refactor!™ for ASP.NET (BETA)

Let's face it: I'm getting old. And old enough to know how to refactor my own my code, right? Wrong. There's no age limit for how much refactoring tools can help us. Here's a nice and free one, from the guys from DevExpress:

Refactor! is freely available to all ASP.NET 2.0 developers and offers a
comprehensive suite of tools that enable you and your team to simplify and shape
complex code and HTML markup - making your web applications easier to read and
less costly to maintain.

Borrow the folowing links from this post:

Training Videos 12-minute Training Video (1024x768):
http://www.devexpress.com/Products/NET/IDETools/RefactorASP/Presentation/Refactor_for_ASP_NET/
Same Training Video, full size (for larger monitors):
http://www.devexpress.com/Products/NET/IDETools/RefactorASP/Presentation/Refactor_for_ASP_NET_Full/
Screen Shots
http://www.devexpress.com/Products/NET/IDETools/RefactorASP/Presentation/MoveStyleAttributesToCss.png
http://www.devexpress.com/Products/NET/IDETools/RefactorASP/Presentation/MoveToCodeBehind.png
http://www.devexpress.com/Products/NET/IDETools/RefactorASP/Presentation/SurroundWithUpdatePanel.png

PS: it's true, those who know me know I don't use CodeRush or ReSharper. Let me explain why: because they are expensive, and because they are not garantied to be bundled on Visual Studio - just imagine having to refactor by hand after moving to a company that doesn't use a refactoring tool :)

Vista day 2: no SIP

My 2nd day in Vista was very disappoint one, as I couldn't get x-lite to log to my SIP local proxy. If someone knows of a SIP soft phone alternative that works on Vista, please drop me a comment.

Yet another Vista review

This is not my first Vista installation - I've been experiencing Vista since the early builds, either on old hardware or on virtual machines. At last I get to install it on my main development station.

My workstation specs are not impressive: I've an old D820, the first dual core generation, with 2GB of RAM and 160GB of disk. It's mounted on my Dell GX520.

The installation almost stopped before it started! Windows installer refused to install on my unformatted SATA disk. I had to partition and format it with an old XP installer. After this silliness, the rest of the installation process was simple and clean.

The only device that wasn't recognized out of the box was audio. I just went to device manager and updated the driver from the internet. Cool, all drivers were now recognized.

After stopping 4 or 5 services I could live without, only 380MB of PF memory usage were reported. It's a report I can live with.

The next step was to ensure I could keep on working: I've downloaded VMPlayer and my booted up my developing virtual machines. I was now ready to work! Thank god for VM!

Finally I've installed Office 2K7, Visual Studio 2K5 and a bunch of utilities, started Outlook, Studio 2K5, Media Player, Messenger and IE. Opened an XP virtual machine where I've opened TOAD, IE and Visual Studio 2K3. Simulated some work over all of those applications and collected the following:

• Task Manager reported 1.6GB PF usage.
• Disk usage reported over 20GB of disk just disappeared...
  
• The overall experience was great - the VM was responsive, and Media Player kept serving me audio.

I suppose with little help from me Windows can easily suck the remaining 400MB of RAM. Until that day comes, the 2GB will sufice.

Finally a word for the activation process: remembering good old Microsoft at their best, when I tried to activate Vista I was presented with a good old 0x8........ error, and something like "DNS error" as an extended information. It was probably looking for the license server, which we haven't installed yet. I used an MSDN seat licence and the activation worked fine.