Sooner or later, a professional software developer will encounter one of these, and will have to deal with it. Not only the technical aspects surrounding the bug, but also all the human interactions involved in finding the cause and the solution for it. In this story, we get acquainted with Ethan Levin, the software engineer responsible of the UI layer for a database application at software company. Throughout the book, we are invited to see how his life will change to chaos as the lifespan of this bug goes from days to months. A bug which he was assigned to fix. A bug which he doesn’t know how to fix because of several reasons very well explained by the author, Ellen Ullman. The story also introduces us to Roberta Walton, a novice tester who first made acquaintance with the bug. Not very much interested in the technicalities of programming (compilers, languages, operating systems, device drivers, etc.), she is somewhat obliged to learn and get familiar with them because without those tools and knowledge, the bug will get her too. Together, they will try to hunt and kill the bug.

What I found interesting about the story, is how familiar a computer bug can be. For example, a bug could have such a personality and character that it reminds us of someone. Sometimes it can resemble ourselves. That’s when it gets scary! I had a lot of trouble putting the book down. I read it when I was doing my physio exercises, on the way to church, while my wife was shopping at Wal-Mart, etc. Whenever I had free time, I would dive right into it. The story reads itself so well that I could easily imagine the scenarios, the faces and the emotions each character was going through.

In one instance, after having found the solution to get rid of the bug, Roberta reflects on how much trust we put into other software-driven appliances (machines, Web applications, vehicles, etc.) that surround our lives :

“Which led me to the question: Was it still a bug? If a flaw is there and you don’t see it, is it still a software error? Or is it more like a defective gene, waiting for an environmental trigger to come along and kill you? […] This latent, dormant, sleeping bug could then awake, and everything – a program thought to be working – would suddenly crash. I think about this every time I get on a plane, or make an electronic payment, or get an X ray, or step into an elevator. Code, all around me. Working, as far as anyone can tell. Somewhere in there – hiding, biding its times, only waiting for a software patch, or a device-driver update, or a network installation, or a well-intentioned programmer to come along and tweak the code – is a bug […] ready to bring the system down.

What’s funny about this observation is that I ask myself the same thing whenever I step into a plane, a car or an elevator! Just the thought about it makes me think that one day we might read in the front page of a newspaper the following headline: “He died because of a bug. A glitch.” A person born from a mother, nourished and well educated, died (if not to say ‘murdered’) by a couple of misbehaving ones and zeroes. What a thought!

I highly recommend this book to CS and SWE students that would like to get a taste of what the industry is like. What kind of human and professional behaviors to avoid, and which ones to adopt, because there is SO much more to software development than code. I also recommend it to software developers, testers, consultants, managers and teachers too. It’s superbly well-written! A great entertainment for the geek in us.

P.S. There is actually a small bug in the book. Look at page 176. Can you guess what it is?

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

[$CURRENT_DIRECTORY$]
$DATE$ $TIME$ >

While searching around the Web to get an idea how to do this, I landed on this page which does a great job explaining how to do exactly this. I’ll resume the steps here, but feel free to visit that site for even more information on this matter:

1. Launch a Command Prompt which will be used a sandbox to try out your new prompt.
2. Use the table below as a reference to the symbols you can use to define your new prompt.
3. Type prompt followed by the symbols as they appear and press <Enter>.

For example, if I wanted to display only the current date followed by a greater-than symbol, I would type: prompt $D$G and press <Enter> (don’t close that window yet!):

At this point, you can view what prompt will be used. Unfortunately, this will not stay as the default prompt. If you close the window, you’ll see again the default prompt which is $P$G (show the current path, followed by the greater-than sign).

To permanently make the changes for all instances of the command prompt window, you will have to play in the registry. Trust me, this one is pretty easy:

1. Fire up the registry editor (START, RUN, type regedit then press <ENTER>)
2. Navigate to the following node: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
3. If it doesn’t already exist, create a new string value named Prompt
4. Assign your custom prompt as the data value to it (see the following screenshot for an example) and press OK.
5. At this point, you should restart your computer to affect the changes permanently.

Next time you’ll launch a command prompt window, it’ll show your custom prompt.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My first though to verify that everything was working fine with the new DNS settings was to visit my site from another computer hooked up with another ISP. So I launched a remote desktop session with my PC at work, and from there I could clearly see that my site was accessible and running well.

I pinged my domain name from that PC and received an IP different from the one I got when pinging the same domain name from my own PC hooked up with my ISP. So which IP was the right one then? I visited Network-Tools.com to get this answer. Bingo! My ISP’s DNS server was pointing my domain name to the previous (old) IP addresses. I called the technical support, but they told me that they cannot flush the cache of the DNS server for one site.

So I tried a couple of different things on my end:

• I tried to release and renew my network adapters with these commands: ipconfig /release and ipconfig /renew.
• I tried to flush my local DNS resolver cache: ipconfig /flushdns.

Nothing! Every time I would visit my site, I would still receive an error somewhat to a “Could not locate remote server” (I’m an Opera fan). Even after doing a tracert briandicroce.com, I could see that the route would break after a couple of hops.

Anyhow, I managed to fix my problem by modifying the local HOSTS file (see link to find the location of this file in your computer) and manually mapping my domain names (blog.briandicroce.com and briandicroce.com) to the IP addresses of my new hosting servers. Here are the steps to follow in case you’re having the same problem I did (Windows machine only):

1. Edit the HOSTS file (no extension) with a text editor using Administrator privileges. The location of this file is in %SystemRoot%\system32\drivers\etc\ by default. Note that users of 64-bit versions of Windows Server 2003/2008, and Vista (Windows 7 excluded) cannot access the HOSTS file with a 32-bit editor.
2. Enter the mappings of your domain names to their corresponding IP addresses. The first value should be the IP address that the domain name (second value) should point at. Make sure to separate the IP Address from the domain name with a whitespace.
3. Save the file.

And that’s it. Now when you access your domain name, Windows will check to see if there’s an entry for it in the HOSTS file and will use its corresponding IP address, therefore bypassing your ISP’s DNS server’s resolver to direct to the site.

After a couple of days/weeks/months, you could probably remove those entries in the HOSTS file in the case that the DNS server actually flushed its cache.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Sure, there are some extra things I wish it had, such as the possibilities to extend the taskbar on external monitors and to pin windows on top of other windows, etc., but I understand that we can’t have it all…all the time. I’m a software developer too, so I get it.

Anyhow, as I was looking around for a good “multiple virtual desktops” application that I could use to load applications in various desktops, I managed to find a little jewel : Windows Sysinternals Desktops. If you know about Windows Sysinternals, then you know that those guys don’t release crap. This little app is great because it’s small and it works! No hassles! Here’s a small description of it that I’ve taken from their website:

Unlike other virtual desktop utilities that implement their desktops by showing the windows that are active on a desktop and hiding the rest, Sysinternals Desktops uses a Windows desktop object for each desktop. Application windows are bound to a desktop object when they are created, so Windows maintains the connection between windows and desktops and knows which ones to show when you switch a desktop. That making Sysinternals Desktops very lightweight and free from bugs that the other approach is prone to where their view of active windows becomes inconsistent with the visible windows.

I kept the hotkeys by default, so that Desktop 1 is mapped to ALT+1, Desktop 2 is mapped to ALT+2, etc. That way, I can have Outlook and Opera sitting quietly on Desktop 1, Visual Studio on Desktop 2, a virtual machine on Desktop 3, and Word/Excel on Desktop 4. That’s right, you only get four virtual desktops with this little nifty tool (why would anyone need more than four?). And it works great with multiple monitors too!

What I like about it, is that each virtual desktop manages its own taskbar, system tray, and applications. Which means that when an application is loaded, it is running in its own desktop. Suppose you loaded Visual Studio on Desktop 3, but you’re currently working on Desktop 1. If you shutdown Windows, it will say that some apps are still running and you might not know why or where…the best guess is that it is running in one of the other desktops.

One little caveat of using this tool is that my favorite Windows application launcher, Launchy, will only work on Desktop 1. So, I’m kinda screwed if I’m in Desktop 2, 3 or 4 and trigger Launchy…because it won’t work! But like I have previously said, I’m a software developer too, so I get it that I can’t get it all…all the time. If you know how to make Launchy works on all virtual desktops, please tell me how you did it. It will be very much appreciated.

If you’re looking for a fast, free, small (62kb), simple virtual desktops manager that runs once downloaded (there’s no useless installer with this one!), look no more! Windows Sysinternals Desktops is the tool you need. I love it!

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The transition of my blog, which is powered by Wordpress, didn’t go as smoothly as I hoped. While at BlueHost, the blog was being hosted in a LAMP environment. At WebHost4Life, the blog was going to be hosted in a Windows/IIS/ASP.NET environment. I thought it was just a matter of transferring some files from servers and importing a backed-up database script. Nope.

Here are the steps I followed to successfully transfer my Wordpress blog from a LAMP environment  to a Windows/IIS/ASP.NET environment. Or more specifically, how to transfer your Wordpress blog from BlueHost to WebHost4Life:

NOTE: Make sure you have properly configured DNS settings for the domain name that points to your blog or site.

On the BlueHost (or LAMP environment) side :

1. Upgrade your current Wordpress to the latest version available.
2. Make sure your plugins work with the latest upgrade. If they don’t, either upgrade or delete them.
3. Deactivate all your plugins to avoid any problems when migrating your current database.
4. Backup your current Wordpress database. This should generate a SQL file which will be used to restore the database in another instance of MySQL.
5. Make a local copy of your Wordpress/blog directory for backup purposes. You’d normally do this with an FTP client. If you don’t have any FTP client, I highly recommend you use FileZilla.

On the WebHost4Life (or Windows/IIS/ASP.NET environment) side :

1. Install whatever version of Wordpress available through their automated script installer. You want to do this because the automated installer will create the database for you, configure the correct values for the database server name and other settings which you don’t have to enter manually. If you aren’t lucky enough to have an automated script installer provided by your hosting company, simply install the latest version of Wordpress directly in the server (don’t forget to create the database for your Wordpress blog).
2. Import/restore the backed up database script that was generated in step 4 of the previous section.
3. Copy all the content of the Wordpress directory that you backed up in step 5 of the previous section in your server. WARNING : Make sure not to overwrite the wp-config.php file in the root of your Wordpress installation directory.
4. Fire a browser and go in the admin page (\wp-admin) and log in to make sure everything is fine.
5. Activate any plugins that you have deactivated in the previous section.
6. If you’re using “pretty” permalinks for linking to your posts, they might no longer work because IIS 6.0 does not support mod_rewrite (read this to know more about this and why it doesn’t work anymore). In short, “pretty” permalinks result in HTTP 404 errors which is actually a false negative since it should work. The solution to make this work is to create a PHP file which provides a URL mod-rewrite workaround for IIS 6.0 and Wordpress (works with v2.8+). Read the following article to know how to do this (trust me, it’s very simple). I named that file ‘404-handler.php’ as was suggested in that article. Upload the file somewhere in your Wordpress directory (I just put it in the root installation directory).
7. Now you should configure the custom error pages handled by IIS so that when a request generates an HTTP 404 error, IIS will redirect to that ‘404-handler.php’ created in the previous page which will take care of the magic. So to this:
1. Log in your WebHost4Life control panel.
2. Click on the “Site Admin” tab.
3. Under the “IIS Manager” section, click on “Set Custom Error”.
4. Click on the “Go” link associated with the domain name for your blog.
5. For the error associated with 404, click on the “Edit” link.
6. Specify the location of the ‘404-handler.php’ file (relative path).
7. That’s it! Your “pretty” permalinks should now work!
8. Now you must set the proper security permissions to your Wordpress directory structure so that you can edit files from the dashboard. To do this, follow these steps:
1. Log in your WebHost4Life control panel.
2. Click on the “Security” tab.
3. Under the “Site Access” section, click on “File Permission”.
4. Locate your Wordpress folder then click on the “Edit” link associated with it.
5. In the drop down list, select the NETWORK user and give it the following rights: READ, WRITE, EXECUTE and DELETE.
6. Make sure to tick the checkbox next to “Propagate changes to sub directories and files”.
7. Click on “Make Changes” (ONCE!!!) and be patient.
9. You will also need to activate/configure the “Cimy Swift SMTP” plugin which comes with the installation to send email notifications from within your Wordpress site. It’s really not that hard. Read this article to know how to configure the plugin.
10. That’s it! You’ve made it! See if everything works correctly…or post your question if it didn’t. I’ll try my best to help you out.

Best of luck!

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

As I was thinking about the reason behind this, something hit me: I should be conscious of my decision whether I should use a constant or a field when dealing with strings.  The reason is simple: avoid unnecessary performance hits.  Take note that the only valid reference type for a constant is either string or null because you cannot instantiate a reference type in compile-time, which is when constants are evaluated.

I made a simple test to verify my little theory, since I couldn’t find a good answer for it on the Web. The test consist of a class that declares both a constant string and a static read-only string field. In its entry method, I call various methods which iterate a certain number of times (10, 100, 1000, 10 000 and 100 000) and use either the constant or the static read-only field respectively.  Here’s a sample code I used for this test:

class Program
{
  private const string Constant = "Constant";
  private static readonly string field = "field";

  private static void Main(string[] args)
  {
    // 10 iterations
    DoConstant10();
    DoField10();

    // 100 iterations
    DoConstant100();
    DoField100();

    // 1000 iterations
    DoConstant1000();
    DoField1000();

    // 10000 iterations
    DoConstant10000();
    DoField10000();

    // 100000 iterations
    DoConstant100000();
    DoField100000();
  }

  private static void DoField100000()
  {
    string s = string.Empty;
    for (int i = 0; i < 100000; i++)
	  s += field;
  }

  private static void DoConstant100000()
  {
    string s = string.Empty;
    for (int i = 0; i < 100000; i++)
	  s += Constant;
  }

  // And so on...
}

Next, I profiled the application with JetBrains DotTrace 3.1 (using the standard configuration options) and got the following results:

We clearly see that for the same iterations, using a string as field rather than a constant has almost a 2:1 performance improvement ratio over the latter.  Now, the title of the post is “Why you should use…” and not “Why you must use…” because there are some scenarios when using a string constant is better suited, such as when the constant is being used as a case in a switch statement (you cannot use a static readonly field as a case in a switch statement because its value will not be known until runtime).

Another thing you should be conscious of is relying on your experience rather than a tool’s recommendation. For example, when you declare a static read-only string variable, ReSharper will recommend you to transform it as a constant.  You shouldn’t always obey the tool unless you know exactly the tradeoffs and have considered the impact and risks associated with the decision.

Be a good judge over your codebase. Analyze the evidence and study the tradeoffs. There’s nothing like a good profiler to uncover the truths behind your code.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The “..exited with code 1” leaves me dreaming about a ton of causes for this error. When manually copying the file to the destination directory (as copying AmazonBookLinker.dll to C:\Program Files\Windows Live\Writer\Plugins\) via Windows Explorer, I get the following second strike:

At this point, I’m playing around with security permissions for both files and destination directory without any positive result.  The solution I came about this problem is to actually run Visual Studio with administrator privileges by right-clicking your Visual Studio file icon, and selecting “Run as administrator”. If you want to make this a permanent solution:

1. Open the properties window for Visual Studio
2. Go to the Compatibility tab
3. Under the “Privilege Level” box, check the “Run this program as an administrator”
4. Click on OK
5. [Optionally] Click on the “Change settings for all users” button apply this privilege to all users on the machine.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

As a matter of fact, I would get the following error message when launching the drivers setup file (186.03_notebook_win7_32bit_international_whql.exe).

Therefore, I had to get my little act together and manually install the drivers.  The following instructions should help you install your NVIDIA’s video card drivers on Windows 7 if the setup file won’t do it for you…for some reason.

1. Go to NVIDIA’s Windows 7 drivers download page and download the drivers specific to your video card.
2. Run the downloaded executable which should extract the files in a directory (by default C:\NVIDIA\DisplayDriver\###\International, where ### corresponds to the version of the setup file.  Mine was 186.03, therefore the directory was C:\NVIDIA\DisplayDriver\186.03\International).
3. Browse to that directory (C:\NVIDIA\DisplayDriver\###\International) and in the Display folder, open the ListDevices.txt file with your favorite text editor.
4. At this time, you’re looking for the specific INF file which holds the drivers information for your card. This step should be easy if you know the model of your video card (check your PC manufacturer’s website if you have no clue what is the model of your video card). For example, my video card is a NVIDIA Quadro NVS 140M. Therefore, I would either search for “NVIDIA Quadro NVS 140M” precisely or simply “140M”.  The search result tells me that the INF file I should be interested in is NVDM.INF (the one in a red square in the following screenshot).

5. Now that we know which file holds the drivers information, we should locate it without problem. In my case its path is C:\NVIDIA\DisplayDriver\186.03\International\Display\NVDM.INF.
6. Now open your display settings (Control Panel\All Control Panel Items\Display\Screen Resolution) and click on the “Advanced settings” link.

7. On the Advanced Settings window, click on the Adapter tab, then on the Properties button.
8. From the adapter properties window, click on the Driver tab, then on the Update Driver… button.
9. On the “How do you want to search for updated driver software?” window, click on the “Browse my computer for driver software” button.
10. On the “Browse for driver software on your computer” window, click on the “Let me pick from a list of device drivers on my computer” button.
11. On the “Select the device driver you want to install for this hardware” window, click on the Have Disk… button.
12. On the “Copy manufacturer’s files from:” text box, simply specify the INF file path from step 5 or simply browse for it, and press the OK button when done with this step.
13. Now simply select your NVIDIA video card model from the list and click on the Next button (click on YES if you get a warning from updating the driver). Windows 7 should now be installing the drivers for your video card.
14. Restart your computer to apply the new video settings.

I hope this post helped you to install your NVIDIA video card drivers on Windows 7. Feel free to post you question or comments.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Two documentations that I use the most when programming in .NET are the ReSharper 4.5 Default Keymaps and the C# Language Specification (ECMA-334).  In order to quickly access those two documents (and future documents I might need), I simply created an entry in the External Tools section of Visual Studio.  In order to do this, you can follow these simple steps:

1. Go to Tools -> External Tools…
2. In the External Tools window, click on the Add button to create a new entry
3. Fill in the required information, such as Title, Command, Arguments, etc.  In my case, the Command is simply the path to the executable of my favorite PDF reader (Foxit Reader) and the Arguments is simply the path to the PDF file.  You can also define a keyboard shortcut for them by prefixing the “&” symbol to one of the letters that aren’t already defined as shortcuts. 
4. When you’re done, click on OK. 

Take a look at the following screenshot:

With this little setup, I don’t need to go to either the ReSharper or ECMA’s website, not even launch Windows Explorer to look for those files.  I have access to those files directly from Visual Studio.  No more context switching.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

1. David Heinemeier Hansson on The Secret To Making Money Online (less than 30 minutes)

In this talk given in 2008, David Heinemeier, the creator of the Ruby on Rails framework and partner at 37Signals, gives a very creative and down-to-earth talk on how to create a profitable startup company.

2. Guy Kawasaki on The Art of Innovation (less than 60 minutes)

This is the first time I heard Guy Kawasaki speak.  This guy is a one of my “online heroes”.  He’s smart, he’s funny, and he speaks from experience.  In this talk, Guy talks about innovation about products, services and marketing.  He shares his experience from his work at Apple to now as a venture capitalist.  You’ll also learn about the 10-20-30 rule that can increase your chances in not only getting fund for your business, but most importantly, getting your point across.

3. Joel Spolsky on What Makes a Great Software (less than 60 minutes)

This is a talk that Joel Spolsky, founder of Fogcreek Software, gave as a keynote at RailsConf 2008, where he shares his valuable insight in what really makes a great software, so much so that we can actually qualify the software as great.  His talk is fantastic: it’s entertaining, it’s focused and it’s without a doubt an eye-opener for software developers to watch out some common pitfalls that can make your software not being adopted at all by potential users.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The Architectural Journal is an independent platform for free thinkers and practitioners of IT architecture.  New editions are issued quarterly with articles designed to offer perspective, share knowledge, and help you learn the discipline and pursue the art of IT architecture.  The Architectural Journal reaches over 67,00 subscribers worldwide.

I think one reason that it isn’t getting much attention is because its “feedless”, meaning you can’t directly subscribe to a feed, through your browser, that will notify you whenever a new issue has been published.  So in order to get notified when a new issue has been published, you need to subscribe through a fairly simple, but tedious, subscription workflow.  Once subscribed, you’ll get the quarterly journal as a PDF as soon as it’s released.  In short, here are the steps you should follow in order to subscribe to The Architectural Journal:

Go to the e-newsletters page in the Profile Center.  You may be required to sign up for a Windows Live ID account if you don’t have one already.  You may use your current email account or create a new one if you don’t have one.  From there, you follow these three steps:

1. Find The Architectural Journal in the list of available communications on the left and select it.
2. Press the Subscribe button.  You should now see your choices in the list on the right.
3. Select your delivery format: HTML (suggested) or plain text.

(Note: it would’ve been much easier had someone put an RSS feed link instead.)

So that’s it! Now, you should be getting four issues per year.  All great content about software architecture topics.  All free.  Past topics include:

• Distributed Computing
• The Role of an Architect
• Mobile Architecture
• Software + Services
• Web Architecture
• And more.

You can also skip the whole subscription process and directly download the current and previous issues in English, French, Spanish, etc., as a compressed (ZIP) file.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

1. Find dependent or referenced code

Using this new feature, you can find dependent or referenced code at either a project or file level.  Before going forward with this feature, it is important to understand what is meant by “dependent code” and “referenced code”.  Both of these terms have to do with dependencies/coupling.  When you ask ReSharper to tell you the dependent code at the project level, you are actually asking it to tell you which other projects (or assemblies) are dependent on that specific project.  On the other hand, when you ask ReSharper to tell you the referenced code at the project level, you are asking it to tell you which other projects (or assemblies) that specific project depends on.  For example, suppose the following UML class diagram:

In this scenario, I have four different assemblies: one client console executable (Client), and three class libraries (Provider, Utilities and SecurityManager).  Our Client executable references the three other assemblies because it’ll make use of their services.  Those references were created when I asked Visual Studio to add me the references for those three projects at the project level.  Now, if I were to ask ReSharper to tell me the dependent code at the project level (which means that you right-click on the Client project in the Solution Explorer, and then click on the Find Dependent Code contextual menu item), a message box will appear telling me that “Code dependent on project ‘Client.csproj’ was not found”: 

This is normal, because according to our class diagram above, Client has an afferent coupling of zero (Ca = 0). 

Afferent coupling(s) is the number of class(es) outside this component (i.e., Client) that depend on classes within this component (i.e., Client). 

On the other hand, if we were to ask ReSharper to tell us the referenced code at the project level (for Client), by this time clicking on the Find Referenced Code contextual menu item, you will get the following results:

In this case, ReSharper is telling us the types which are being used in that specific project (Client), even .NET types and assemblies like mscorlib.dll.  Since the Client class has a positive non-zero efferent coupling (Ce > 0), we actually get a result.

Efferent coupling(s) is the number of classes inside this component (i.e., Client) that depend on classes outside this component (i.e., Client).

These results could look daunting at first sight, but that’s because the results window is showing too much information.  All you have to do to get a more simplistic and lighter view of the results is simply to click on the Filter Usages button (that’s the one surrounded in red in the screenshot below) and unselect the Show Attribute Usage from the proposed choices, as you don’t really care that you’re depending on the AssemblyAttribute class for example.  Furthermore, you should also click on the Merge Occurences on the Same Line button (that’s the one surrounded in green in the screenshot below), so that you eliminate some of the redundancy usages on the same line.  Finally, choose an appropriate view to group your results (in this case, I have chosen to group the results by Namespaces and Types.  That’s the one surrounded in blue in the screenshot below).  This will give you the following (much more compact) result view:

NOTE: If you only reference external projects or assemblies in a project without actually using the public types or members in those external dependencies, ReSharper will not tell you that you are actually referencing those dependencies.  This is pretty slick, as you can visually know whether or not a reference is unnecessary, and thus proceed with its removal.

Ah, much better! And you know what?  That’s pretty much right, because the Client class is actually using those classes (Provider, SecurityManager and Utilities), as shown in the screenshot below:

At the file level, you only get to ask ReSharer to tell you the referenced code, through the Find Referenced Code contextual menu item.  In this case, the results will include any type being used in that file.  Suppose for example that in the SecurityManager class, you’re using an instance of a Logging class to log some errors in a few critical methods.  In that case, the results will include the Logging class, as it is a type being referenced in that file.  So far, so smart.

2. Go to implementation (Ctrl+Shift+Alt+B)

This one is pretty simple and very much useful.  Suppose you have the following class hierarchy:

In the previous versions of ReSharper, you couldn’t ask the tool to directly tell you which concrete classes derived from an abstract type.  Instead, you had to select the abstract type and ask it to tell you the derived types (or inheritors) through the Ctrl+Alt+B shortcut, which would give you a list of all the types deriving from that abstract type…even if those derived types were abstract themselves.  This was pretty frustrating when you had a hierarchy with a lot of abstract relationships amongst types, as it was the case in one WCF-driven project I was involved in, because you would lose a couple of seconds filtering out the concrete types from the abstract ones in the results list.  Well, that’s an old story because now you can get the list of all the concrete types (or implementation types) directly from a new shortcut: Ctrl+Shift+Alt+B, or through the “Go to implementation” command in the “Go to” navigation menu.  For example, if you asked ReSharper to tell you the concrete classes for IProvider, it’ll tell you that MembershipProvider and SecurityProvider are the only ones.  It will ignore ProviderBase, as it is abstract.  Well done!

3. Naming styles

With ReSharper 4.5, we get more flexibility in the naming style department.  You can apply either a common naming style for both C# and VB code, or set one differently for each of them.  It’s up to you.  The UI interface to manage the naming styles is pretty simple.  Here, for example, is the Naming Style window pertaining to both C# and VB:

So you get a list of predefined styles out-of-the-box which might suit most of your basic needs.  The flexibility offered by these features comes in handy when you want to create new styles, modify some existing ones, etc.  Suppose you want to add a new naming style for private fields only, and make them prefixed by an underscore.  You would simply click on the “Add” button under the User defined naming rules panel, which will show the following window:

All I have to do is select the affected entities, which in this case would be “Field” and “Readonly field”.  Then I would specify the access modifiers, which sould be Private and Protected. Following that, I will specify the underscore as the name prefix and tick the lowerCamelCase naming style, as to be follow the .NET design guidelines.  Finally, I would set the rule description to something explicit, such as “Private fields”.  That’s it!  Now I can save and share the code style file with my team.

4. Collapse all project nodes (in Solution Explorer)

Suppose you have the following project structure in Solution Explorer:

This would be a very typical folder structure in an ASP.NET MVC project, for example.  Every time you collapse the node associated with the SecurityManager project, and you expand it later, you will see the same result as above.  This can be very frustrating when you have dozens of projects with their child nodes expanded in a similar way in Solution Explorer, and God forbid you have also expanded the References node, because it tends to visually pollute the Solution Explorer.  ReSharper 4.5 introduced a new feature that allows you to definitively collapse a node, be it a folder or the project node itself, so that the next time you expand the root node, the previously collapsed node stays closed!  This might sound like nothing, but have you ever calculated how many seconds you probably were wasting trying to navigate the Solution Explorer when you have a multitude of projects with folders, or solution folders, all open at the same time even though you don’t really need them to be?  That’s not being productive.  That’s not being professional.

So here’s the trick: when you’re done with one node and you need to collapse it for good, simply right-click on it in the Solution Explorer, and choose “Collapse All”.  This would permanently collapse the node until you explicitly expand it again.  For example, if I decide to execute this “Collapse All” command on the Users folder, then each time I expand the SecurityManager node, the Users folder will stay collapsed, until I explicitly expand it.  In my opinion, this should’ve been a standard option for Visual Studio.  Good thinking once again!

5. Inline field (Ctrl+Alt+N)

The fifth of my favorite new features in ReSharper 4.5 is the possibility to inline a field.  As to tweak the original Inline Temp refactoring definition to suit this one:

You have a field that is assigned to once with a simple expression, and the field is getting in the way of other refactorings.  Replace all references to that field with the expression.

I think that little definition sums it up well what Inline Field does.  Simply highlight the field, then hit the Ctrl+Alt+N shortcut, and you’re done.  Here’s a last example.  Suppose you have the following class definition:

As you can see, the someString field is used only once in this class, which is pretty much useless.  In that case, I will place my cursor on it, then hit Ctrl+Alt+N to have it inlined:

And that’s it! Now through all the code, the field’s expression will be inlined.  This was a simple scenario, but I’m sure you can think how useful this refactoring could be in your codebase.

[UPDATE: 2009-04-14] The Inline Field refactoring also works to inline methods and properties, not only fields! This is very sweet.  They should call this command Inline Construct as it doesn’t just inline fields.

But there’s more!!!

Of course, my list of favorite new features in ReSharper 4.5 isn’t the whole story behind this new release.  For a complete list of new feature in ReSharper 4.5, I’ll invite you to review its What’s New in ReSharper 4.5 features page. ReSharper is getting better and better through each release, and I can’t wait to see what the team is going to include in the 5.0 release.  But meanwhile, if you haven’t upgraded to this new version, I urge you to do so.  Plus, the upgrade is free if you’re already a ReSharper 4.x licensee, so you really have no excuse.  And if you’re not currently using ReSharper at all, then I hope that the following post has incited you to ask your tech lead or manager to get a license for it (I would suggest to start with the trial, then demo it to your group).  I’ll also invite you to read my post on The Case for ReSharper in the Enterprise which might give you some pointers on the necessity of this tool in your development toolbox.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

What started as an article a few years ago, titled 10 Things Every Software Architect Should Know, has morphed into a collection of essays written by software professionals and for software professionals. The author of the original article, Richard Monson-Haefel, did well on following the suggestion of Jay Zimmerman to publish a book as a collection of essays sharing pragmatic experience, wisdom, insight and diversity in the field of software architecture.  From the back cover, we can read the following:

In this truly unique technical book, today’s leading software architects present valuable principles on key development issues that go way beyond technology.  More than four dozen architects – including Neal Ford, Michael Nygard, and Bill de hÒra – offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they’ve learned from their years of experience.

Published by O’Reilly, “97 Things Every Software Architect Should Know” turns out to be authored by a multitude of different people from around the world and from diverse companies.  The common point of interest amongst all the contributors is their role on the job, that of a software architect.  As the title suggests, there are in fact 97 different essays written by many practicing software professionals that were willing to share their experience, wisdom, proven techniques, mistakes, lessons learned, etc., about their profession and role of that of a software architect.

But what exactly is a software architect?  Though there isn’t a specific definition for that title, there are many accepted ones.  According to Wikipedia (source),

Despite the lack of an accepted overall definition, the role of software architect generally has certain common traits:

Strategic thinking
Architects address the technological aspects of business needs by considering what a given technology can contribute to the overall functions of the system, as distinct from how that technology will perform its own functions.  This encourages opportunities for re-use of the technology and ultimately contributes to the organization’s efficiency.

System interactions
Architects deal with the interactions of systems, whether between components written in different languages at different time and at different locations, or between components of the same software system that use the same coding language.

Design
The architect makes high-level design choices much more often that low-level choices.  In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms, so as to advance business goals rather than to place arbitrary restrictions on the choices of developers.

Communication
Architects also have to communicate effectively, not only to understand the business needs, but also to advance their own architectural vision.

As there are many different traits pertaining to software architecture, there also many different roles a software architect can play, be it: Enterprise Architect, Application Architect, Infrastructure Architect, Security Architect, etc.  As the author acknowledges,

“97 Things Every Software Architected Should Know” provides advice from software architects around the world on everything from how to avoid common pitfalls to how to build talented teams.  It’s a smorgasbord of advice from established software architects for other software architects or those who aspire to become software architects.

Throughout the book, you will find many essays dealing with at least one of these traits and some specific to a role.  The essays aren’t categorized in any way, so each one you read can deal with something different than a previous one, which might be a good idea…or not.  I would’ve preferred if the essays were categorized by traits (or other subject) so that I can focus my reading on a group of them when I want or need to.  For example, if I want to read some essays pertaining to effective team building, I could focus on reading a subset of those essays.  As it stands, I have no much choice but to read each of them sequentially, which can become quite tedious as some essays can be lightly equivalent to another in terms of idea and interest.  Nevertheless, since the content of the essays are rich, insightful and resourceful, I don’t mind too much about the overall layout.  On a last note about the structure of the book, I was very pleased to see that each essay was presented on a two-page presentation (left page and right page).  In other words, if you turn a page, you get a new essay.  At the end of each essay, you also get a brief bio of the author who wrote it so that you can either stalk him…or Google him.  Finally, there aren’t only male authors who contributed in this project.  As a matter of fact, Allison Randal and Rebecca Parsons (CTO of ThoughtWorks) also contributed their own insights.

Many of the co-authors that participated in this project were unknown to me, so reading this book actually allow me to plug into the world of some them through their personal websites or blogs.  Amongst the list of people who contributed to the book are Erik Doernenburg, Udi Dahan, Niclas Nilsson, Neal Ford, Keith Braithwaite, Gregor Hohpe, and many, many more.  Funny thing is that two articles that I very much enjoyed  much reading were written by a guy I’ve never heard of before: Timothy High, a software architect working for Sakonnet Technologies.  In fact, he’s the author of two of my favorite essays in the book: the first one being Empower Developers, in which he urges managers and architects to essentially “protect developers from nonessential parts of their job.  Too much paperwork and too many office chores add overhead and reduce their effectiveness.” and making sure developers have the tools, the skills and the trust necessary to get the job done; and the second one being Record Your Rationale where he suggests that architects should write down their rationale behind some of their technical decisions, as it may come in handy in a number of situations, as he writes:

• As a means of communication to developers regarding important architectural principles that should be followed
• To get the team “on the same page,” or even head off a mutiny, when developers question the logic behind the architecture (or even to humbly accept criticism if it turns out a decision doesn’t hold up under scrutiny)
• To show managers and stakeholders exactly why the software is being built the way it is (such as why an expensive piece of hardware or software is necessary)
• When handing off the project to a new architect (how many time have you inherited a piece of software and wondered exactly why the designers did it THAT way?)

Another interesting thing about this book is that O’Reilly agreed that all of the content of the essays should be freely available (Creative Commons) for to anyone through the book’s website.  Excellent idea, O’Reilly!

In essence, this book is all about software architecture, but not only for software architecture, but rather anyone involved in the software development lifecycle (testers, developers, QA, analysts) and even up the corporate ladder (CIO or CTO).  The content being technology-agnostic, there’s no doubt that the audience for this book will be heterogeneous, so whether you’re a .NET, Java or Ruby fan, you will surely find the essays valuable.  And just like the Head First series, this book has sprung another series focused on a “97 Things Every [fill in the blank] Should Know” idea.  [Note from my wife, the environmentalist: “There goes more trees!”].  If you’re a developer aspiring to take on more responsibilities and challenges for a software project, I would highly recommend you get a copy of this book.  Furthermore, I would also recommend reading a good complement for this book: “The Role of an Architect” published by The Architectural Journal (Microsoft).

[UPDATE: 2008-04-15] You can also read the other proposals which didn’t make it to the final cut.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Amazon Book Linker v1.0 is a free plugin for Windows Live Writer which provides many innovative functionalities for searching and linking books from Amazon on your blog post.  It allows you to specify your own Amazon Associate Tag to every link (you only have to provide this information once, and the plugin will remember it next time) so that you can make a sales commission out of a direct sale from one of the links.  Furthermore, it empowers the HTML ninja (or ninjette) to also customize the HTML template to better match the link layout to your own design.  In order to assist you with this process, the plugin also lists you a series of predefined macros to use.  You can also choose your preferred Amazon locale (US, CA, CO.UK, JP, FR or DE) too!

For more information, I’ll invite you to check the brand new Projects page on this site.  Meanwhile, here are a few screenshots.

Now that this little project is out the door, I can resume posting new ideas on our beloved craft and technologies.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

“Visual Basic .NET is not Visual Basic 6 with inheritance tacked onto it.  Rather, Visual Basic .NET has been entirely rewritten to be fully object-oriented.” For a programming language to be a true OOP language, the language must meet the following criteria:

• Abstraction: Abstraction manages the complexities of a business problem by allowing you to identify a set of objects involved with that business problem.
• Encapsulation: Encapsulation hides the internal implementation of an abstraction within the particular object.
• Polymorphism: Polymorphism provides for multiple implementations of the same method.  For example, different objects can have a Save method, each of which perform different processing.
• Inheritance: The excitement of Visual Basic .NET lies in inheritance.  Visual Basic 5 introduced the concept of interface inheritance, which allows you to reuse the interface of a class, but not its implementation.  Visual Basic .NET provides for true implementation inheritance whereby you can reuse the implementation of a class. [Source: MSDN]

Chances are that a VB6 veteran, that has been programming with VB since its earliest versions, will tend to write VB.NET code in a more traditional “procedural” way, instead of an “object-oriented” way. This is sad because .NET itself is not only built around, but also provides a rich object-oriented model for programming.  However, that doesn’t rattle my cage too much, because with enough practice and mentorship, they could learn to embrace the OO way of analysis, design and programming, as well as to appreciate its benefits.  What rather tends to rattle my cage is that I said could (in italic in case you haven’t noticed) because there’s not much out there that benefit Visual Basic (VB6 and VB.NET) programmers to really appreciate the OO paradigm to its fullest.

C++ and Java programmers coming to .NET via C# tend to reap more of the benefits from the platform than VB6 developers do when jumping on the .NET wagon with VB.NET, because they are already minded to the OO way of doing things.  I think the main reason that makes this balance shift more on one side than the other is because there is just SO MUCH MORE resources (open-source projects, books, blog posts, articles, training, etc.) that focus on the C-family languages, such as C++, JavaScript and C# (for the sake of this post, I will also include Java in this family).  OO concepts such as inheritance, encapsulation, polymorphism, and constructs such as interfaces or abstract classes, tends to be very hard subjects to grasp for VB6 and VB.NET developers (on a professional level, I can only support this fact through those same comments I get from VB developers taking my VB.NET courses and from fellow developers at user groups).   The VB development community will be in a much better position to take advantage of the OO model, the same way that C++, Java and C# developers did, if for every OO book, article or blog posts, there would be the equivalent counterpart code samples in VB.  Last time I checked on Amazon, there wasn’t many books focused on design patterns for Visual Basic developers.  However, there is a ton available for C++, Java, C# and even Ruby developers.  It’s hard for VB developers to grasp the essence of design patterns if they struggle to understand the concept of inheritance and polymorphism.

You know what?  Let’s dig a little deeper on the programming books case.  Table 1 shows the total number of books found in Amazon for Visual Basic, C#, C++ and Java:

Table 1. Books results for various programming languages at Amazon.com (search made on March 10th, 2009)

 
This is very shocking, because if my memory serves me well, Visual Basic is much older than C# and Java! I’m going to spare you the proportions for each of these books, because I think the numbers speak for themselves.  However, I do want you to notice something important: if we consider C# and Java being almost equivalent (putting the CLR and JVM aside), that means that VB developers have close to 68,000 books less to read from.  There’s a little “gotcha” in this study though: just for the programming related books for all these languages, Java comes first with 12,241 books, C++ comes at second place with 10,465 books, Visual Basic comes at third position with 6,351 books and C# comes last with 3,884 books.  However, most of the VB books are for VB6 and older versions (and maybe VBA or VBScript).  Joking aside, there’s not even a Head First series on Visual Basic!!! There is though a Head First C#, Head First JavaScript, Head First Design Patterns (Java), Head First Object-Oriented Analysis and Design (Java), even a Head First Rails and Head First SQL!  Here’s my point: some of the most influential books on software development and programming such as Design Patterns (by the GoF), Patterns of Enterprise Application Architecture (Fowler), Refactoring to Patterns (Keriesky), Implementation Patterns (Beck), Domain-Driven Design (Evans), even hardcore .NET books like CLR via C# (Richter) and the Effective C# series (Wagner), without forgetting the books from the Robert C. Martin series (Agile Principles, Patterns, and Practices; Clean Code and Working Effectively with Legacy Code) hold a vast, deep and rich knowledge of the craft of software development that VB/VB.NET developers are mostly ignorant of.  No wonder that I also tend to see more jobs offering for C# developers than VB.NET when it comes to .NET positions.  I don’t know about you, but that’s very unfortunate.  However, this paragraph was mostly about books.  What about tools and open-source projects?

When I teach the intermediate and advanced VB.NET courses, I tell the students that they should take a look at Enterprise Library from the Patterns and Practices Group at Microsoft (watch a video of it here) for it can save them time, cost and effort in common development situations.  I even tell them that it is open source, which means they have access to the code.  However, I don’t get much excitement from their part, mostly because the code is written in C#.  Code reading aside, I haven’t even heard of one VB developer simply using Enterprise Library in his projects.  The same goes for projects like nHibernate, the Castle project, NUnit, even mocking tools like Rhino.Mocks and Moq.  That’s very sad, because by not using some of these tools, VB developers tend to stay far behind common practices such as TDD and technologies like ORM tools.  What doesn’t help also, is that most of the screencasts where you see someone showing a piece of code or an utility, such as TDD with NUnit and Rhino.Mocks for example, the language is more often than not…wait for it…C#.  The only screencasts that I see a couple of developers programming in VB is in DNRtv.  Furthermore, I don’t recall ever seeing a VB example from the guys at CodeBetter.  Worse, I don’t even have one example written in VB in any of my posts!

One H U G E advantage that VB6 (or even VB.NET) developers tend to have when learning C# to program with .NET is that they can also be more comfortable in reading C# and Java books and source code (which the latter being as most important as reading books IMHO).  By doing this, for example, a VB developer having trouble understanding the implementation of a design pattern in VB, can easily learn it from another example written in C# or Java (and perhaps C++ if the VB developer understand the notion of pointers).  The last remark I said in parenthesis is important, because of all the .NET constructs, it seems to me that the one that causes much headaches to VB/VB.NET developers are delegates, which are essentially lists of method references.  It’s one of those concepts that I tend to spend more time on explaining to VB developers jumping to VB.NET, than C++ or Java developers learning C#.

Though there isn’t a simple and easy solution for VB developers in this situation, I can only encourage them to take a look at C#.  By doing that, they will also be more comfortable in exploring the world of Java, and perhaps even play around the JVM and see how it compares to .NET.  As Benjamin Franklin once said,

“An investment in knowledge always pays the best interest”, and

“The only thing more expensive than education is ignorance”.

In his article, “What VB Dev Should Know About C#”, Bill Wagner actually encourages VB developers to learn about C# (and C# developers to learn about VB) by saying that,

“Our discussion also covered the need for developers to get out of their comfort zones and learn something new.  Yes, the two languages are similar in features, but there are idiomatic differences between the languages, and some tasks are significantly easier in one language than the other.  In fact, you’ll find yourself much more skilled and much more in demand if you know the best features in both languages, as well as how to build applications that rely on both languages.”

And if what I’m writing about isn’t encouraging you enough to learn a new language, then maybe President Barack Obama can persuade you to learn more than “one language”.

I personally speak three languages (Spanish, French and English) and I’m very grateful that I can speak and write in those languages as it gives me a lot of opportunity to learn and embrace foreign cultures, philosophies, relationships and literature.  On the more technical side, I’m also fluent in C++ (not as much as the other languages though), PHP, Java, C# and Visual Basic.  The same benefits apply here, as I can read code written in those languages and books using examples also written in any of those languages.   I can also more easily conduct code reviews with other developers as I’m in a better position to understand their intent, disregard the programming language that was used.

So next time you’re thinking about starting a new personal project, see to it that you write it in C# (if you’re targeting the .NET framework), or even in Java for a change.  If you struggle, don’t quit.  There are many online language conversion tools out there to translate C# code to VB and vice-versa.  The Pragmatic Programmers once advised developers that they should learn at least one new language every year.  This year, Dear VB developer, make a commitment to learn a new language (I’d recommend C#) as it will make you more valuable and employable, and also more comfortable in learning about new ideas emerging in the world of software development.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Oh yes, you shaped me first inside, then out;
you formed me in my mother’s womb.
I thank you, High God – you’re breathtaking!
Body and soul, I am marvelously made!
I worship in adoration – what a creation!

You know me inside and out,
you know every bone in my body;
You know exactly how I was made, bit by bit,
how I was sculpted from nothing into something.
Like an open book, you watched me grow from conception to birth;
all the stages of my life were spread out before you,
The days of my life all prepared
before I’d even lived one day.

Psalm 139:13-16 (The Message)

Though I am not perfect, I am perfectly made.  I did not ask for either a working set of eyes or a complex and functional brain.  Never did it occur to me that my heart would be responsible for pumping my blood or that my lungs would filter the oxygen from the air that I breathe.  I am not a creator of life, but I do create a virtual kind of life, where instead of blood and oxygen there is a complex symbiosis of binary mathematics and electrical pulses.  As a software developer, I do bring life to objects that are responsible for the inner workings of my system.  I sometimes wonder whether the objects and components that we build for our software would thank and praise us in the same degree that King David praised his Creator.

Lately, there has been a popular trend going on in blogs and podcasts around object-oriented programming, notably with the SOLID principles, a composite of acronyms about key design principles introduced by Robert C. Martin.  One of the principles that I adhere stronger than the others is the Single Responsibility Principle (SRP).  According to Wikipedia’s definition,

The single responsibility principle states that every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility.  [Wikipedia].

In the words of Uncle Bob, aside from a type having a well defined responsibility, it should have one, and only one, reason to change.  Going to back to the human body, we can clearly see that our inner components are highly cohesive and loosely coupled.  For example, when I pick up a broken piece of glass from my kitchen’s floor and suddenly I cut myself on the finger of my right hand, I shouldn’t expect my right eye to go blind.  Nor do I expect the other fingers to stop working!  Of course not!  That’s because I am wonderfully made!  And so are you!  When I cut myself, my body knows how to heal itself and within days I have no scar.  Leaving the “cutting” aside, we can clearly see how the eyes, the nose, the tongue, the teeth, the nails, the hair, the skin, etc., all have a single and specific responsibility, and if one member should stop working, it can be replaced by another compatible member.  For example, we can do heart transplants, lungs transplants, etc.  Given that the human body is so much more complex than any software ever created, how come that when my printer driver stops working, the whole operating system goes down with it?  How come when a component in an application stops working, it affects other components as well?  Take, for example, a tree: it looks very simple on the outside, but inside of it, God has clearly encapsulated the inner workings of the tree.  A tree that’s been around for decades can still grow and participate in photosynthesis.  It’s incredible.  Software systems tend to be replaced every year or two.  Anyhow, I want to keep writing on the topic of single responsibility for an object.

Suppose you have the following simple Car class:

Now, what do you think about the methods (or responsibilities) of this class?  Does it violate the SRP principle?  Here’s a simple test you can do to answer these questions (if you answer ‘NO’ to any of these questions, then you know that your class doesn’t adhere to the SRP principle.  Even better: if the question doesn’t seem to make any sense to you, then it’s a ‘NO’ by default):

• Can a car change gears by itself?
• Can a car change a radio station by itself?
• Can a car drive itself?
• Can a car idle by itself?
• Can a car park itself?
• Can a car start itself?

Unless you’re the lucky owner of the Knight Rider, you probably answered ‘NO’ to a few of these questions.  For every question or observation you have answered ‘NO’, you should more than likely refactor the class and move some of its responsibilities elsewhere.  But where exactly can you move these responsibilities?  Well, before we dive to some of these answers, let’s see if we can directly some of the original questions pertaining to our Car class:

• Can a car change gears by itself? ANSWER: Sure, if it has an automatic transmission.  Otherwise, only the driver can shift gears.
• Can a car change a radio station by itself?  ANSWER: Nope, only the driver (or the passenger) can change the radio station.
• Can a car drive itself? ANSWER: Not unless it’s KITT!  Only a driver can drive a car.
• Can a car idle by itself? ANSWER: Sure it can.
• Can a car park itself? ANSWER: Nope! Only a driver can know how to park a car.
• Can a car start itself? ANSWER: Uh, no.  Once again, only the driver can start the car.

Do you see how by answering such questions or observations you can better get through a cleaner design?  The pattern is pretty simple too: Can a [type] [action in the infinitive] itself? Though I picked a very trivial example, you could do the same test for any of your classes, e.g., an Order class, an Employee class, an Account class, a Repository<T> class, even interfaces!  Continuing with our beloved Car class, we see that it has a couple of responsibilities it cannot fulfill by itself, because either it doesn’t make sense that it should, or plainly that it isn’t logical for the class to offer those services in the first place.  From our answers, we can also see that we need another class to make all well orchestrated: a Driver class.  The driver should know how to fulfill some of these responsibilities.  How would you associate the Driver to a Car?  You can go with the Dependency Injection pattern on this one if you like, or pick another strategy.

So we talked about a few things here: the Bible, Knight Rider and Uncle Bob.  But more importantly in this post, we talked about some easy and simple techniques we can use to determine whether methods or properties (responsibilities) actually belong in the right type.  Unfortunately, following this technique isn’t a silver bullet for every situation!  You must still rely on your experience and wisdom to better answer that question.  If you are part of a team, that’s even better because it is those deep and insightful conversations that actually bring about a much suitable solution.  For example, what if our Car needs some reparations?  Should we create a Repair() method in the Car class or the Driver class?  Well, you can first of all use our little technique to answer this question:

• Should a car be able to repair itself? ANSWER: Not in this world, that’s for sure!
• Should a driver be able to repair a car? ANSWER: Well, it depends!  Maybe the driver can repair the car, and if not, maybe we should introduce a Mechanic class that knows how to repair the car.  This is when we should discuss it in front of a whiteboard.

I hope this little tip will help you to better evaluate your design.  And don’t stress too much about it if your design doesn’t follow the SRP or any of the SOLID principles.  Just be thankful that you’re wonderfully made and that you have Google at your disposal.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The Marker class

For this demonstration, I will be using a custom Marker class that will simply output text in the console.

This is the Marker class in C# (the class is equivalent in the Visual Basic module):

class Marker
{
    public Marker(string text)
    {
        Console.WriteLine(text);
    }
}

The Base class

Let’s kick off the idea with a single C# class (no inheritance whatsoever):

class Base
{
    private static Marker staticField = new Marker("base static field");
    private Marker instanceField = new Marker("base instance field");

    static Base()
    {
        new Marker("base static ctor");
    }

    public Base()
    {
        M();
        new Marker("base instance ctor");
    }

    protected  virtual void M()
    {
        Console.WriteLine( "base M() was called" );
    }
}

Here’s the same class in Visual Basic:

Class Base

    Private Shared staticField As New Marker("base static field")
    Private instanceField As New Marker("base instance field")

    Shared Sub New()
        Dim temp As New Marker("base static ctor")
    End Sub

    Public Sub New()
        M()
        Dim temp As New Marker("base instance ctor")
    End Sub

    Protected Overridable Sub M()
        Console.WriteLine("base M() was called")
    End Sub

End Class

When we instantiate the Base class, we get the following output in C# and Visual Basic.  The main point is that the results are the same whether we instantiate the C# or Visual Basic version of the Base class.

Instantiating a child class of Base in C# and Visual Basic

Here’s now the entire code in C# of the Base class (same as before) and a Derived class inheriting from it:

class Base
{
    private static Marker staticField = new Marker("base static field");
    private Marker instanceField = new Marker("base instance field");

    static Base()
    {
        new Marker("base static ctor");
    }

    public Base()
    {
        M();
        new Marker("base instance ctor");
    }

    protected  virtual void M()
    {
        Console.WriteLine( "base M() was called" );
    }
}

class Derived : Base
{
    private static Marker staticField = new Marker("derived static field");
    private Marker instanceField = new Marker("derived instance field");

    static Derived()
    {
        new Marker("derived static ctor");
    }

    public Derived()
    {
        new Marker("derived instance ctor");
    }

    protected override void M()
    {
        Console.WriteLine( "derived M() was called" );
    }
}

And here are the same classes in Visual Basic:

Class Base

    Private Shared staticField As New Marker("base static field")
    Private instanceField As New Marker("base instance field")

    Shared Sub New()
        Dim temp As New Marker("base static ctor")
    End Sub

    Public Sub New()
        M()
        Dim temp As New Marker("base instance ctor")
    End Sub

    Protected Overridable Sub M()
        Console.WriteLine("base M() was called")
    End Sub

End Class

Class Derived : Inherits Base

    Private Shared staticField As New Marker("derived static field")
    Private instanceField As New Marker("derived instance field")

    Shared Sub New()
        Dim temp As New Marker("derived static ctor")
    End Sub

    Sub New()
        Dim temp As New Marker("derived instance ctor")
    End Sub

    Protected Overrides Sub M()
        Console.WriteLine("derived M() was called")
    End Sub

End Class

Here’s the output generated when instantiating the Derived class in C# and Visual Basic (This is where the fun begins!  Try to notice any difference between the C# and Visual Basic execution before continuing.) :

As you can see, the order of execution in an inheritance relationship is both different in C# and Visual Basic (regardless of whether or not a virtual/abstract method was called from either constructor).  The danger of calling a virtual or abstract method from a constructor (in C# or Visual Basic) is that the overridden method will be invoked prior to the derived class’ constructor.  If that method tries to access or modify the state of the yet-to-be-fully-constructed object, you might end up with a corrupt or invalid instance.  The worse scenario is in Visual Basic.  As you can see from the results, the overridden method gets called not only before the derived class’ constructor (as it was with the C# version), but also gets called before the class’ instance fields get initialized.  Now, that’s even more dangerous if the overridden method tries to access any of its instance fields because chances are that they will default to Nothing (null in C#) for reference types since they haven’t even been initialized yet!

Referencing a Visual Basic assembly from a C# application and instantiating the Visual Basic version of the Derived type

Here’s another potential dangerous scenario: From a C# application, you reference a Visual Basic assembly that holds the exact same code as the Base and Derived classes shown above.  You then decide to instantiate the Visual Basic version of the Derived class:

static void Main(string[] args)
{
    Console.WriteLine( "From C# Program" );
    Console.WriteLine(  );
    new VBModule.Derived();
}

Here’s the output generated from instantiating the Visual Basic version of the Derived class in the C# application:

 As you can see, it is no longer having the same execution cycle as when instantiating the C# version of the Derived class from the C# code itself.

Referencing a C# assembly from a Visual Basic application and instantiating the C# version of the Derived type

This time, we’ll switch the roles and from a Visual Basic application, we’ll reference a C# assembly that holds the exact same code as the Base and Derived classes shown above.  We then decide to instantiate the C# version of the Derived class:

Sub Main()
    Console.WriteLine("From VB Program")
    Console.WriteLine()

    Dim d As New CSharp.Derived
End Sub

Here’s the output generated from instantiating the C# version of the Derived class in the Visual Basic application:

As you can see, it is no longer having the same execution cycle as when instantiating the Visual Basic version of the Derived class from the Visual Basic code itself.

Conclusion

You should never be calling a virtual or abstract method from a constructor in C#, and even more in Visual Basic, because in either case a derived type will invoke an instance method prior to the object being fully constructed!  In other words, the dynamic linking edition kicks in as soon as you instantiate a class.  According to Microsoft,

When a virtual method is called, the actual type that executes the method is not selected until run time.  When a constructor calls a virtual method, it is possible that the constructor for the instance that invokes the method has not executed.  The constructor should be redesigned to eliminate the call to the virtual method.

As you saw, the execution cycle is different for both languages even with the same codebase.  It gets even more interesting when referencing either assembly (C# or Visual Basic) in either language, because you just wouldn’t know what you’ll get at the other end.  Having a tool like ReSharper can be of a greater benefit in this circumstance as it’ll catch this kind of code and notify you about it.  By default, this situation will be treated as a warning, but I’ll suggest you to treat it as an error as to make it stand out better (ReSharper->Options…->Inspection Severity):

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

So these are the steps you should follow if your TweetDeck doesn’t show up in the primary (and only) monitor because it’s thinking it should display on an external monitor:

1. If you’re using Windows Vista, browse to the following directory: C:\Users\<username>\AppData\Roaming.  If you’re using Windows XP, browse to the following directory instead: C:\Documents and Settings\<username>\AppData.
2. Locate the folder that begins with TweetDeckFast.  For example, the complete name of that folder on my PC is TweetDeckFast.F9107117265DB7542C1A806C8DB837742CE14C21.1.
3. Open the Local Store folder.
4. Edit the preferences_<username>.xml configuration file with your favorite text editor.
5. Change the windowState XML element’s x attribute to 0.  If you don’t see the TweetDeck UI, it is because the x attribute’s value is negative (which makes sense if the external monitor was on the left side).
6. Save your changes to that file and load TweetDeck.  You should now be able to see the UI.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

If a window is broken and left unrepaired, people walking by will conclude that no one cares and no one is in charge.  Soon, more windows will be broken, and the sense of anarchy will spread from the building to the street on which it faces, sending a signal that anything goes.

I couldn’t help myself thinking how this theory fits well with the current state of software development.  When a software project first begins, it is void of any imperfection for no one began to write a single line of code for it.  Then as the team forms and the tasks are being assigned and executed, the team members start to breath life into the software.  That software could have a very different life depending on various factors of the team in charge of developing it, such as the team members’ experience, skills, knowledge, professionalism and passion for the craft. 

From my days of consulting and working as a team member, I more than often see a lack of responsibility from the individual team member for the most important organ of the software: the source code.  Once the source code has started to rot, it doesn’t matter how colorful or beautiful your design documents are or how detailed your development plan is…your software has a cancer and it will die unless you do something about it.  The typical scenario of the Broken Windows theory in software development goes like this: Robert, a programmer, is working on a subroutine for the Shipping module.  While at it, he notices that the NotifySupplier method is lacking a couple of guard clauses and the comments don’t reflect the code at all.  Since he wasn’t the one to write that code, he ignores it and continues working on his work item.  Will he remember to ask the developer who wrote the NotifySupplier method that it is in need of some fixing?  Who knows.  One meeting here, one phone call there, and chances are that Robert will forget about it.  Upon that time, the software has started to confirm the theory.  It now has a broken window.  What’s even more dangerous is that this theory can cascade all over the core of the software if its internals show a high degree of coupling with many components.  A good analogy would be like a tree burning in a forest.  It doesn’t take much time for the fire to spread to the other trees.  The outcome of this is simple: chaos.  The remedy is also simple: you.  What are you going to do about it?  Are you going to run from it or are you going to take corrective actions to prevent the cancer to spread all over the system?

Another potential risky situation that may arise from the Broken Window theory in software development is that if you don’t take care of fixing the broken code as soon as humanly possible, your junior developers and interns (if you have any) will have the impression that all this is normal in our industry.  The result of this is that as they continue to build and ship software in the future, those junior developers and interns will have shipped products with broken windows in them.  The theory can also backfire on your organization as the developers, sooner or later, realize that the organization isn’t mature enough and might decide to work somewhere else that will provide them the proper environment to appreciate the craft of building software and pay attention to the smallest details.   Here are a few examples of what I consider a broken window in the code and that should get fixed as soon as possible:

• Missing unit tests
• Comments out-of-sync with the target code
• A method, class or module that should be refactored
• A complex piece of code that could be replaced with a design pattern to better express its intent
• A broken build
• Etc.

There are also some solutions to prevent this theory to hinder the software project:

• Performing code reviews at least once a week
• Encouraging pair programming, as four eyes are better than two
• Putting in place automated tools that will break the build when rules are broken (FxCop, NDepend, NCover, etc.)
• Having the programmer check in her modifications in a private build such that if it succeeds then the modifications are merged to the repository.  Have a look at Team City for it does that very well.
• Providing intelligent tools to your developers so that they can work more effectively with the codebase.  A tool like ReSharper quickly comes into mind.
• Instilling an atmosphere that considers quality as the most important instrument to drive the organization to success.

But the tools and processes aren’t the heart of the solution.  What will either make or break the software is the attitude of every single individual affected to the project.  To encourage the growth and maturity of this attitude, developers should educate themselves on the trends of software development.  Developers should constantly thrive to do as much as possible to become more valuable software professionals.  

Though he doesn’t talk about this theory explicitly in his book, Agile Principles, Patterns, and Practices in C#, Robert C. Martin does reflect on the basis of the Broken Windows theory and also does provide a remedy to fight this problem in software.  According to him, and I agree with his statement, it’s all about having an attitude of being professional:

The attitude that agile developers have toward the design of the software is the same attitude that surgeons have toward sterile procedure.  Sterile procedure is what makes surgery possible.  Without it, the risk of infection would be far too high to tolerate.  Agile developers feel the same way about their designs.  The risk of letting even the tiniest bit of rot begin is too high to tolerate.

The design must remain clean.  And since the source code is the most important expression of the design, it too must remain clean.  Professionalism dictates that we, as software developers, cannot tolerate code rot.

Remember: Only YOU can prevent broken windows in your software project from spreading like cancer.  You have access to a grand vast of online resources and tools to help you fix those broken windows before it’s too late.  Do you have the attitude to do as such?

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

The set of basic delegates that I think .NET developers should be familiar and comfortable using are the generic Action<T>, Comparison<T>, Converter<TInput, TOutput> and Predicate<T> delegates.  I will introduce you to each of these delegates by describing their usage with a simple example so that you can start using them in your codebase where needed.

The Action<T> delegate

In .NET 2.0, the Action delegate, declared in mscorlib.dll, has the following signature:

public delegate void Action<T>(T obj);

When Microsoft released .NET 3.5, four more Action delegates were included in System.Core.dll:

public delegate void Action()

public delegate void Action<T1,T2)(T1 arg1, T2 arg2)

public delegate void Action<T1,T2,T3)(T1 arg1, T2 arg2, T3 arg3)

public delegate void Action<T1,T2,T4)(T1 arg1, T2 arg2, T3 arg3, T4 arg4)

Regardless of the different signatures of the Action delegate, its semantic is to encapsulate a method which doesn’t return a value, and which holds a variable number of parameters:

• If the method is parameterless, you should prefer the Action delegate.
• If the method accepts one parameter, you should prefer the generic Action<T> delegate.
• If the method accepts two parameters, you should prefer the generic Action<T1, T2> delegate.
• If the method accepts three parameters, you should prefer the generic Action<T1, T2, T3> delegate.
• If the method accepts four parameters, you should prefer the generic Action<T1, T2, T3, T4> delegate.
• If the method accepts five (or more) parameters, you should prefer reviewing your design

A quick analysis with Reflector on the these delegates show that only the Action<T> delegate is being used by .NET in a couple of places, notably as a parameter for the ForEach method of both the static Array class and the generic List<T> class.  The other locations where this delegate is being used aren’t publicly accessible, so we will restrain ourselves to understanding the use of this delegate with a simple usage with the ForEach method of the generic List<T>.

Suppose we have a collection of toys which we want to iterate to display each of its name on the console.  A possible solution to satisfy this requirement without using the Action<T> delegate could be:

// Create our toys collection
List<Toy> toys = Repository<Toy>.FetchAll(); // Not that important how we get our toys collection here

// Iterate through the collection using a foreach statement and display each toy's name on the console
foreach(var toy in toys)
{
  System.Console.WriteLine(toy.Name);
}

The above solution works and your unit tests should pass.  But does it warrant a check-in to the source code repository?  This code we have written to satisfy the requirement seems to me very imperative, almost like how a robot would think.  I am mixing both the “how” and the “what” in this context.  For instance, I am iterating on the collection with a foreach statement (the “how”) in order to fulfill my intent which is to display the toy’s name on the console (the “what”).  Since my brain is better at processing one information at a time, I rather focus on the intention rather than the implementation.  Maybe we can hold on that check-in and see if there’s a better way to do this.

As a matter of fact, there is.  The generic List<T> class defines an instance method which iterates the collection and performs an action for each of its element via an Action<T> delegate.  The Array class defines the same method but it is added as an extension method on that type.  That being said, if there’s another data structure that implements IEnumerable<T> or IEnumerable which doesn’t have an equivalent of a ForEach method, there’s nothing stopping you from creating one on the type via an extension method.  This is the second solution that satisfy this requirement and which clearly brings out my intention forward because I don’t care how the collection is being iterated or what algorithm is used for the iteration, I’m just concerned of doing something with each of its element in a sequential manner.

// Create our toys collection
List<Toy> toys = Repository<Toy>.FetchAll(); // Not that important how we get our toys collection here

// Display each toy's name in the console (using a lambda expression)
toys.ForEach(toy => System.Console.WriteLine(toy.Name));

// You can also use an anonymous delegate to do the same thing...only with more keyboard typing than is necessary
toys.ForEach( delegate(Toy toy)
              {
                System.Console.WriteLine(toy.Name);
              }
            );

Ignoring the instruction using the anonymous delegate, and instead focusing on the one using the lambda expression, we can clearly see that our intention is much clearer.  On a side note, I will use lambda expression whenever needed for the following examples to keep them shorter.  I just added the anonymous delegate if you weren’t too familiar with lambdas.  As you see by using the lambda expression that I don’t have to use the delegate keyword and I can safely rest on the compiler’s type inference  functionality which are both a time saver.  The bottom line with the Action delegate is that it is there for you to do something (perform an action) on an element.  It is commonly used when some action must be performed on an element during an iteration over a collection, but keep in mind that it doesn’t have to be used just in the context of an iteration over a collection.  The Action delegate is also a powerful move to consider when, for example, a collection doesn’t offer a specific iterator that you’re looking for, such as an EvenNumberIterator.  In this case, for every iterated element, you’ll do something specific if the number is even, such as displaying it on the screen (notice that to use multiple statements with lambdas, those statements should be enclosed within braces):

List<int> numbers = Generator<int>.GenerateSequence( 10 ); // Generate a sequence of 10 random numbers

numbers.ForEach( number =>
                 {
                     // Display the number only if it's even
                     if ( number % 2 == 0 )
                        Console.WriteLine( number );
                 }
               );

Something to keep in mind with all the parameterized Action delegates is that the parameters are passed by value which means that any modification to anyone of them will only be local to the scope of delegate’s body or the method being invoked by the delegate.  In other words, the collection’s items won’t be modified.  The multiple parameterized Action delegates introduced in .NET 3.5 allow you to use them in case you need to do something with either two, three or four parameters (they can all be of the same type if needed).

The Comparison<T> delegate

Introduced in .NET 2.0, the generic Comparison<T> delegate is mostly used for sorting elements within a collection.  It is currently used by the Sort methods of both the Array and generic List<T> classes.  This delegate has the following signature:

public delegate int Comparison<T>(T x, T y)

The nature of the delegate is identical to the IComparer<T>.Compare method in that:

• if x > y, then a positive value is returned (traditionally that value is 1);
• if x < y then a negative value is returned (traditionally that value is -1);
• in the case where both x and y are equal, a value of 0 is returned.

This shouldn’t be too much of a surprise because internally the Sort method of both the Array and generic List<T> classes use the generic FunctorComparer<T> to wrap the delegate so that it can be used as an IComparer<T> object internally.  When the IComparer<T>.Compare method is invoked by .NET, it is actually the Comparison<T> delegate that is fired.  Pretty neat, uh?  The semantic of using this delegate (or the IComparer interface for that matter) is to define an alternative order for sorting elements within a collection.  Getting back to our toys collection, suppose we want to sort them by name (a string).  We could provide the following code to satisfy this requirement:

List<Toy> toys = Repository<Toy>.FetchAll();  // Again it doesn't matter how we get our toys

// using a lambda expression to define our sorting algorithm
toys.Sort((x, y) =>
           {
               if (x == y) return 0;

               if (x == null) return -1;

               if (y == null) return 1;

               return x.Name.CompareTo(y.Name);

           }
        );

This solution is great if you only have one sorting strategy and you foresee that it will not change in the future.  But there’s a better way to use this delegate.  In fact, the power of the Comparison<T> delegate is that…it’s a delegate!  This means that we can do some crazy and complex sorting if we must by combining various strategies!  What if we want to sort our toys first by name, then by price and also by a different criteria?  Using a lambda expression is asking way too much trouble.  Let’s see how we can take advantage of the Comparison<T> delegate in this case.  Let us now sort our toys by name, then by price.

private static void Main(string[] args)
{
    List<Toy> toys = Repository<Toy>.FetchAll();  // Again it doesn't matter how we get our toys

    // Instantiate our Comparison<T> delegate in a way that we want to sort our toys by name (first order), then by price (second order)
    Comparison<Toy> comparison = CompareToysByName;
    comparison += CompareToysByPrice;

    toys.Sort(comparison);
}

// Compare two toys by name
private static int CompareToysByName( Toy x, Toy y )
{
    if (x == y) return 0;

    if (x == null) return -1;

    if (y == null) return 1;

    return x.Name.CompareTo(y.Name);
}

// Compares two toys by price
private static int CompareToysByPrice( Toy x, Toy y )
{
    if (x == y) return 0;

    if (x == null) return -1;

    if (y == null) return 1;

    return x.Price.CompareTo(y.Price);
}

This is awesome because we can simply mix our sorting strategies through a simple delegate which will be used as a parameter to the Sort method of both an Array and generic List<T> classes.  Once the Sort method has finished its job, your collection will be sorted by the criteria you have specified. 

The Converter<TInput, TOutput> delegate

The next delegate that I would like to be familiar with is the generic Converter<TInput, TOutput> delegate which was introduced in .NET 2.0.  Just like its other counterparts, this delegate is being used by both the Array and generic List<T> classes, more specifically in their ConvertAll<TOutput> methods.  The signature of the Converter<TInput, TOutput> delegate is as follows:

public delegate TOutput Converter<TInput, TOutput>(TInput input)

This delegate is useful whenever you have to define a strategy to convert an object from one type to another type.  For example, you might want to convert an object of type System.Int32 to a type System.String.  Continuing with our toys example, let us consider the following simple requirement: we want to create a list containing only the names of every toy from our toys collection. 

List<Toy> toys = Repository<Toy>.FetchAll(); // Not really important how we get all our toys.

List<string> toysNames = toys.ConvertAll(toy => toy.Name);

It’s that easy!  Our strategy is basically that given a Toy (this is our closed type for TInput), we’ll return a String (this is our closed type for TOutput).  Just like we have done with the Comparison<T> delegate example, you can also mix in some conversion strategies.  Just remember that variance on delegates isn’t supported in C# 3.0.  For more information on this topic, I strongly suggest you to read Eric Lippert’s eleven-part posts on covariance and contravariance.

The Predicate<T> delegate

Though being used once again by the Array and generic List<T> classes, the generic Predicate<T> delegate is more used by the framework than the three other ones.  This delegate represents a method that defines a set of criteria and determines whether the specified object meets those criteria.  You can also see this delegate acting like a filter on a collection. The signature of the Predicate<T> delegate is as follows:

public delegate bool Predicate<T>(T obj)

Like I said, the .NET framework uses this delegate in both the Array and generic List<T> classes in many of their methods (Exists, Find, FindAll, FindIndex, etc.).  In short, you provide an evaluation context for a parameter where you either return true if the condition for that parameter is met, false otherwise.  Continuing with our toys example, suppose that we want to 1) find out whether we have a toy with a specific name and year, and 2) find all the toys that were made in Canada.  We could simply use the provided methods (Exists and FindAll) and passing them a Predicate<T> delegate that will contain our logic for evaluating whether or not the condition is satisfied.

List<Toy> toys = Repository<Toy>.FetchAll(); // We're not particularly interested in knowing how we got our toys.

// 1. We're interested in knowing whether we have my favorite Transformer of all: Megatron!  
// I have a couple of them, but I'm specifically interested in the one my parents bought me in 1985.
bool containsMy1985Megatron = toys.Exists( toy => toy.Name == "Megatron" && toy.Year = 1985 );

// 2. We're now interested in retrieving all our toys made in Canada.
List<Toy> myDecepticons = toys.FindAll( toy => toy.Country == "Canada" );

By simply invoking those methods and passing them a Predicate<T> delegate, I can concentrate on what I want in a more declarative way because I don’t have to explicitly iterate/loop over the collection with either a foreach statement, a for loop, a while loop, etc.  I just want to iterate over my toys, and either find out if a match was found or retrieve all my toys that satisfy some condition.  This last statement is also true for any of the other delegates that I presented here.

Conclusion

In this post, I wanted to familiarize you with some of the basic delegates that are offered by the .NET framework BCL (outside of ASP.NET, ADO.NET, etc.) that allow you more flexibility in specifying different strategies for various contexts (such as in finding, retrieving, converting or performing an action to an element of a collection).  In other words, these delegates allow me to concentrate more on the business logic rather than, for example, writing the plumbing necessary to iterate over a collection, because they are commonly used as a parameter to a method which already implements the plumbing on my behalf.

Whether I’m consulting with companies or training developers, more often than not I see these kind of delegates redefined in code because the developers were completely ignorant of the existence of these delegates!  That’s too bad, because violating the DRY principle forces you to document, test and maintain more code than you would actually need in your codebase.  Remember that the .NET framework isn’t solely C#.  The .NET framework is a huge toolbox that provides you with many tools (interfaces, classes, events, delegates, etc.) to build various applications.  The more you know about those tools and how to use them properly, the better your code will be and the more valuable you will become to your organization and team.

For more information on delegates, I highly recommend you the following links:

• Get a copy of More Effective C#: 50 Specific Ways to Improve Your C# by Bill Wagner.  More specifically, take a look at Item 18: Decouple Iterations from Actions, Predicate, and Functions to get a better understanding of Action, Predicate and Func delegates.
• Get a copy of C# in Depth by Jon Skeet.  This is one guy who has been very helpful in the .NET community by writing many useful articles and also published, in my opinion, the best practical book on C# 2.0/3.0 to date.
• Check out dnrTV’s episode on events and delegates with Mark Miller.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

For example, I tend to see a severe chronic problems amongst C# developers towards operations related to boxing and unboxing. Reading some newsgroups posts, blog posts’ comments and working with many .NET developers that have never heard these terms before made me aware that this chronic problem was pretty much widespread. This phenomena is even more real for developers that are too keen on using coding/refactoring tools, like ReSharper, because they tend to rely more on the suggestions of those tools instead of relying on deeper knowledge to decide whether or not a change in the code is due. Before building on this idea, I think it’ll be a good idea to refresh our concepts of boxing and unboxing in .NET. For this, I’ll share some notes from the excellent book on .NET programming, CLR via C# (second edition), by Jeffrey Richter.

Let us consider what happens when boxing occurs:

It’s possible to convert a value type to a reference type by using a mechanism called boxing. Internally, here’s what happens when an instance of a value type is boxed:

1. Memory is allocated from the managed heap. The amount of memory allocated is the size required by the value type’s fields plus the two additional overhead members (the type object pointer and the sync block index) required by all objects on the managed heap.
2. The value type’s fields are copied to the newly allocated heap memory.
3. The address of the object is returned. This address is now a reference to an object; the value type is now a reference type.

The C# compiler automatically produces the IL code necessary to box a value type instance, but you still need to understand what’s going on internally so that you’re aware of code size and performance issues.

You see that I have put the last sentence in bold. What Jeffrey is saying there is extremely important, because some tools aren’t smart enough to handle every single mechanisms of the compiler, therefore “you still need to understand what’s going on internally so that you’re aware of code size and performance issues”. Let us move on.

Let us now consider what happens during unboxing:

Unboxing is not the exact opposite of boxing. The unboxing operation is much less costly than boxing. Unboxing is really just the operation of obtaining a pointer to the raw value type (data fields) contained within an object. In effect, the pointer refers to the unboxed portion in the boxed instance. So, unlike boxing, unboxing doesn’t involve the copying of any bytes in memory. Having made this important clarification, it is important to note than an unboxing operation is typically followed by copying the fields. Frequently, however, an unboxing operation is followed immediately by copying its fields. Internally, here’s exactly what happens when a boxed value type instance in unboxed:

1. If the variable containing the reference to the boxed value type is null, a NullReferenceException is thrown.
2. If the reference doesn’t refer to an object that is a boxed instance of the desired value type, an InvalidCastException is thrown.

Now that we have a general idea of what boxing and unboxing are and how they work, we should consider the following as an important principle:

Obviously, boxing and unboxing/copy operations hurt your application’s performance in terms of both speed and memory, so you should be aware of when the compiler generates code to perform these operations automatically and try to write code that minimizes this code generation.

In a nutshell you get boxing whenever a conversion from a value type to a reference type occurs. Conceptually, unboxing is the reverse operation where a conversion from a reference type (such as an instance of Object) to a value type occurs. In .NET, value types are any object that derives from System.ValueType, such as your familiar primitive types (Int32, Boolean, Char, Decimal, etc.), structures and enumerations. Reference types are classes, interfaces, events, delegates, exceptions, etc. (basically anything that doesn’t derive from System.ValueType). The key element to understand is not necessary the mechanisms involved by the compiler, but rather to be conscious that there is a performance hit whenever boxing and unboxing occurs. Since the introduction of generics with .NET 2.0, we don’t have to deal as much with such concepts because generics provide type safety and better performance by avoiding boxing/unboxing operations. But not everything in .NET is generic and it’s extremely important to discover those potential “danger zones” where boxing/unboxing operations can occur within the framework, especially if you’re using development tools like ReSharper.

I’m a big fan of JetBrains and all their products that help me be more effective as a developer. Their continuous integration tool, TeamCity, is in my opinion the most innovative and complete software to set up a CI environment. Their dotTrace profiling application is also one of those tools that is installed whenever I set up a fresh development environment. But the one tool that I cannot code without is none other than ReSharper. I believe so much in that tool for making me more productive and effective when I code that I even wrote a post about reasons why the enterprise should seriously consider ReSharper for its developers. Unfortunately, ReSharper isn’t perfect. Excellent yes, but not perfect. Which means that developers should still use their knowledge about the programming language and the compiler to really take advantage of the .NET platform. This statement is even more pronounced when potential boxing/unboxing situations can occur. For example, consider the following code:

private static void Main()
{
  string name = "Brian";
  int age = 27;
  System.Console.WriteLine("Hello, my name is " + name + " and I'm " + age + " years old.");
}

At first sight, it seems that the above code is right.  I would agree with you at some extend.  I agree that it compiles just fine and that it outputs the correct message on the console.  If you had ReSharper installed, it will also say that the code is well formatted and that you’re good to check it in (the feedback for this is a little green icon on the top right side of the code window in Visual Studio).  The underlying problem with this code is that your application gets a performance hit because a boxing operation has occurred.  In fact, if you view the IL emitted by the compiler you will see a box instruction which forces the CLR to perform boxing for the value type.  The reason for this is that implicitly, this overloaded version of Console.WriteLine() calls one of the overloaded versions String.Concat() which accepts Object parameters (a tool like Reflector or ILDASM can help you to see this for yourself).

This is the point where knowledge and experience kicks in.  The proper way to write the above code is as following:

private static void Main()
{
  string name = "Brian";
  int age = 27;
  System.Console.WriteLine("Hello, my name is " + name + " and I'm " + age.ToString() + " years old.");
}

The reason the code above is superior is that you get all the benefits of the first version without the performance hit because no boxing occurs (again you can check this for yourself by viewing the IL emitted by the compiler).  As a matter of fact, calling a ToString() method on a value type will tell the CLR to invoke that method instead on that particular instance instead of boxing the value type as a reference type and then calling Object’s ToString() on it.  If you call Console.WriteLine( age ) instead, you might be surprised to know that no boxing occurs because one of the overloaded versions of that method actually accepts an Int32 as a parameter. 

This is why I said that knowledge and experience counts because unless you know these nifty facts you could blindly follow your tools’ recommendations which might propose some false positives.  An example of a false positive can be ReSharper graying out the ToString() method call on the age variable and recommending you to remove it.  Most developers using ReSharper will blindly follow such recommendation and actually remove the invocation of ToString() on the value type by either hitting ALT+ENTER on the line and let ReSharper remove the invocation or by reformatting the whole code file by hitting CTRL+ALT+SHIFT+F.  Though the above example seems pretty negligent, you can imagine this kind of operation in a loop or anywhere else a boxing/unboxing operation might occur in a library or within the framework itself.  A simple profiling on the application should detect such a performance bottleneck.  In other words, don’t checkmate yourself by blindly following your tools recommendations!

Even though I only touched on the subject of boxing and unboxing, it’s important to understand that there are many other areas that this post’s ideas apply.  For example, knowing when to explicitly implement an interface, deciding when to favor composition over inheritance, justifying the encapsulation level of a class and its members, etc.  These are strategies that some tools can’t provide a hint for, therefore you should rely on your knowledge and experience on the platform and the programming paradigms (object-oriented, functional, etc.) currently used.  If you have the chance of working in a larger team, I highly recommend your team to conduct code review sessions so that each team member can leverage each other’s knowledge and experience on the platform.  On the other hand, if you don’t have the privilege of participating in code reviews, or even worse if your organization doesn’t encourage such a practice, then you’re pretty much on your own, but you’re not alone!  In that case, I recommend you to read the following books which will no doubt make you a better C#/.NET programmer:

• CLR via C# (Second Edition) by Jeffrey Richter
• C# in Depth by Jon Skeet
• Effective C# by Bill Wagner

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

One thing that I wish came out of the box, but is currently missing, is a shortcut that allows me to run my unit test in the current context (by context I mean where my cursor is currently located.  If my cursor is currently in the body of TestA, then that shortcut will run the TestA unit test).  This will allow me to use the mouse even less, because right now I’m using the mouse to tell ReSharper to execute the current test. It turns out that though this functionality is lacking in ReSharper 4.1, the possibility to do so still exists. 

Here are the steps to follow if you want to map a keyboard shortcut that will run a test in the current context:

1. In Visual Studio, go to Tools –> Options
2. Expand the Environment node, then go to Keyboard
3. In the commands list, search for Resharper.Resharper_UnitTest_ContextRun
4. Assign a shortcut for that command.  In my case, I have decided to map it with Alt + X in the Global context.  That shortcut is intuitive (X for "execute”) and easy to trigger.  You can choose whatever mapping you want, just make sure there are no conflicts with other existing shortcuts.

Here’s a screenshot of the above steps in action:

Now you can place your cursor in a test context (test body or test method name) and hit that shortcut (Alt + X in my case) and that test will get executed.  A good tip to follow is to save your Visual Studio keyboard settings (and ReSharper settings too) under a backup repository (such as Live Mesh for example) so that you (or your team) can re-use those same settings in your Visual Studio sessions in other machines.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

A couple of things that made me jump while listening to this interview were when Michael Feathers says that in one company, in which he consulted, none of the developers have heard of the “Design Patterns” book by the GoF.  Even a story that Pete McBreen told us about a developer who didn’t checked in his code after working on it more than four weeks.  This is a very important interview that the JAOO folks have made public and even more important for managers and developers to watch it together.  A special thanks for this discovery goes to Dave Hoover who started a thread on “apprenticeship” over at the Software Craftsmanship Google group.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

A couple of years ago, Edsger Dijkstra was interviewed for sharing his thoughts on the discipline of programming.  For example, he mentions the beauty of code being measured in terms of quality, correctness and elegance.  That’s a key value which I hold tight in my heart when programming:  Always having that struggle with my ego, my mind and my intuition about how to write or change an implementation to make it just right…not perfect, but just right.  But what is just right?  See…that’s the kind of struggle I constantly have.  I love it.

While watching the interview, he seemed pretty sad or disappointed with the current state of computer science in the industry, as well as in the academia.  No doubt that we still have a long way to go to bring beauty in code, but I think that we have also make a strong progress since that first 1968 NATO conference on software engineering.  I believe that we’re living in exciting times in this industry.  I don’t know if Dijkstra would agree with that statement.  What do you think? 

NOTE: I came about this video from the most excellent blog of Peteris Krumins.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

Mike Swanson has prepared for us a simple list of all keynotes and sessions by code and title from this year’s PDC.  This is some really cool stuff!

Remember that you can also browse the sessions by tag on the Channel 9 PDC 2008 page.

Now, let’s see what Azure is really all about…

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

• Code is easier to maintain because any change can be isolated to a very limited number of objects (hopefully only one)
• Code is easier to use and reuse because your objects are not tightly related to a web of other objects
• Code is easier to understand because we can focus on the behavior of a very limited number of objects (hopefully only one)
• Code is easier to test because of the reasons stated above (it also reduces the use of mock objects in our tests which simplifies writing and maintaining them)

The last point is very important.  Code that is easier to test favors the writing of unit tests, which avoids potential bugs infesting the system, and embraces change as we have confidence in refactoring the codebase because our unit tests act as a safety net so that if we should brake something in the system, we’ll be notified in a short time…if the tests were well written of course, but that’s a subject for another post.

The Principle of Least Knowledge, also known as the Law of Demeter, is one of those principles which favor low coupling in your codebase.  The most excellent book “Head First Design Patterns” defines this principle as the following:

The Principle of Least Knowledge guides us to reduce the interactions between objects to just a few close “friends”.

But what does this mean in real terms?  It means when you are designing a system, for any object, be careful of the number of classes it interacts with and also how it comes to interact with those classes.

This principle prevents us from creating designs that have a large number of classes coupled together so that changes in one part of the system cascade to other parts.  When you build a lot of dependencies between many classes, you are building a fragile system that will be costly to maintain and complex for others to understand.  — “Head First Design Patterns”, pages 265-266.

In other words, this principle states that given an object, any of its method should only invoke methods that belong to:

• The object itself
• Objects passed in as a parameter to the method
• Any object the method creates or instantiates
• Any components of the object

Least but nonetheless important is another pointer which makes the whole difference (like spreading Nutella on whole wheat bread): methods should avoid invoking methods belonging to objects that were returned from some other call.

For example, you should avoid writing the following:.

public void DepositAmount(int accountId, double amount)
{
  Account account = bank.GetAccount( accountId );
  account.Deposit( amount );
}

And instead opt for this:

public void DepositAmount(int accountId, double amount)
{
  bank.Deposit( accountId, amount );
}

You should see that the latter implementation is easier to maintain, reuse, understand and test.  We haven’t changed the interface of the method, just its implementation.  This implementation is easier to reuse and test because we don’t have to rely on another external (whether concrete or abstract) object, in this case an Account, to fulfill the service.  We only have one object, the Bank, to deal with.

One of my mentors refers to this principle as the “Tell, don’t ask” principle.  It makes a lot of sense.  Alec Sharp, author of Smalltalk by Example, summarizes this principle in other words:

Procedural code gets information then makes decisions.  Object-oriented code tells objects to do things. — Alec Sharp

That was the theory behind the principle.  Let’s see a concrete and simple example which demonstrates what we should avoid and what we should strive for in our design.

This example doesn’t follow the Principle of Least Knowledge:

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      var car = new Car();
      var driver = new Driver( car );

      driver.Car.Engine.Start(); // Not good.
                                 // Changing the signature of Start() will force to change
                                 // the callers too because of the strong coupling.
                                 // It also breaks the encapusalation of CarEngine because
                                 // the Driver knows too much about that class.
    }
  }

  class Driver
  {
    public Driver( Car car )
    {
      Car = car;
    }

    public Car Car { get; private set; }
  }

  class Car
  {
    private readonly CarEngine _engine;

    public Car()
    {
      _engine = new CarEngine();
    }

    public CarEngine Engine
    {
      get
      {
        return _engine;
      }
    }

    public class CarEngine
    {
      public void Start()
      {
        Console.WriteLine( "vroum! vroum!" );
      }
    }
  }
}

Whereas this same example does respect the Principle of Least Knowledge:

namespace ConsoleApplication1
{
  class Program
  {
    static void Main(string[] args)
    {
      var car = new Car();
      var driver = new Driver( car );

      driver.Car.Start(); /* Much better.  Why?
                             Now, we can also make CarEngine private to the Car class.
                             Even though CarEngine.Start is public doesn't mean we should
                             use it!  Here we decided to remove the Engine property in the Car
                             class.

                             With this approach, the Driver could care less HOW the Car gets
                             started.  Now, CarEngine can evolve on its own without impacting
                             the rest of the system.

                             In other words...just because there's a gun laying on the ground
                             outside Montreal East and it's past 2AM...doesn't mean you should
                             take it!  Not everything that's public is good to take.
                             */
    }
  }

  class Driver
  {
    public Driver( Car car )
    {
      Car = car;
    }

    public Car Car { get; private set; }
  }

  class Car
  {
    private readonly CarEngine _engine;

    public Car()
    {
      _engine = new CarEngine();
    }

    class CarEngine
    {
      public void Start()
      {
        Console.WriteLine( "vroum! vroum!" );
      }
    }

    public void Start()
    {
      _engine.Start();
    }
  }
}

As you can see from the preceding example, adopting the Principle of Least Knowledge in your design allows you to easily evolve other components in your system since they’re not tightly coupled with other components in other areas of the system.  In this instance, I can easily evolve CarEngine without impacting the rest of the system.  For example, I can change the way an engine is started.  Furthermore, I can even make the CarEngine class abstract, then have various implementations of it and still avoid rippling changes to my system.  The Principle of Least Knowledge gives me so much ease, flexibility and possibilities to evolve my design and test my system.

Using a tool like NDepend can help you to pinpoint locations in your code where coupling is strong so that you leverage this principle and step-by-step eliminate the unnecessary coupling among components.

In conclusion, I urge you to not get too personal with objects.  Don’t be too polite with them neither.  With people yes, but not with objects.  If you need an object to do something for you, tell it to do so.  Another variation of "tell" is "command".  Don’t tell the object to ask another object to do some job for you.  If you see that happening, you should remove the intermediate object and have the one that knows more about the underlying operation to execute the job for you.  In his book Applying UML and Patterns, Craig Larman refers to the Information Expert pattern for this kind of situation.  According to that pattern, you should "assign a responsibility to the information expert – the class that has the information necessary to fulfill the responsibility".

As you can see, there are many different interpretations for this principle.  Whether you know it as the Principle of Least Knowledge, the Law of Demeter or the Information Expert pattern, what’s important is that you understand and apply the essence behind it.  It’s all about doing object-oriented development right.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008

For each of these exams, I have used the “self-paced” book series (the same series used for 70-536 and 70-529), which are:

• MCTS Self-Paced Training Kit (Exam 70-528): Microsoft .NET Framework 2.0 Web-Based Client Development
• MCTS Self-Paced Training Kit (Exam 70-526): Microsoft .NET Framework 2.0 Windows-Based Client Development
• MCPD Self-Paced Training Kit (Exam 70-549): Designing and Developing Enterprise Applications Using the Microsoft .NET Framework

Now, I’m going to say it straight and simple: all of these books suck.  The only good thing about them is that the authors have done a pretty good job copy/pasting the right MSDN documentation so that we wouldn’t waste our time doing it ourselves.  The major drawbacks I have against these books are the really poor coding style of the authors towards their examples.  A big portion of the examples contain errors, are sometimes misleading and some of them clearly won’t compile if you copy/paste the code in Visual Studio.   It’s sad to see so many mistakes like these, especially when each book is written by so many authors, because the credibility of these individuals take a pretty bad hit in the public’s eye.  I’m sure they were pushed by the deadline, but I wished they’ve polished the examples a little bit more.  I know…I know…Nobody’s perfect…I know.  But that’s still no reason to deliver mediocre products.

All right.  So just in case you’re thinking (or already started) to get your MCPD-EAD credentials, I am going to tell you how I’ve managed my time to pass each of these exams in hope that it might help you to pass them successfully.  In average, I dedicated about 40 hours per exam:

• 15 hours to read the book (1 hour in the morning and 1 hour in the evening should be enough for you to read the whole book within a week.  You don’t have to read EVERYTHING.  If you’re proficient in C#, then skip all the VB.NET examples.  Same idea goes if you’re more proficient in VB.NET than C#.   Whenever the authors mentions something in a box with the title “Real-World Scenario” you SKIP it.  It doesn’t matter.  The “real-world scenario” isn’t in the book…it’s in the REAL WORLD.  Don’t waste your time.  Also, don’t do all of the activities at the end of each chapter.  Just get through the book because you don’t want to waste too much of your time.  Here we’re really trying to cram our brain with tons of information.  The exams are roughly 80% based on memorization of the content and 20% on actual thinking.  Feel free to write notes and underline important ideas as you read along.  I used to write “EXAM” in red ink on the margin so that I can review it at a later time.)
• 20 hours to practice with Transcender or MeasureUp exams.  I have only used Transcenders, so I can’t say much about MeasureUp.  I’ve heard they’re quite good too.  Whichever you decide to do, I strongly suggest you to do all of the questions more than once.  Then when you’re confident enough about the material, take a moment to answer the questions in the “certification” mode to give you a better feel for the exam.  By the way, none of the questions of either Transcenders or MeasureUp were in the exams I’ve taken.  To be honest, the mock exams’ goals are to deepen your knowledge with the various technologies.  That’s it, that’s all.  Don’t put too much confidence in them, because what I’ve concluded at the end of each real exam is that the mock exams only helped me about 20% on the “knowledge” stuff and 80% on the actual “feeling” for the exam.  Take a week or two to practice these.
• 5 hours to practice some things I didn’t fully understand (proper use of some class, understanding the use behind some interfaces, getting comfortable with the security model, etc.) inside Visual Studio.  I strongly suggest you use Reflector to assist you in quickly discovering the information behind some objects in the framework.

I also suggest you to book your exam in advance.  For example, suppose you start studying for an exam today, then you will book an exam date four weeks from now.  This should motivate you to stay on course and respect your schedule.  And if that’s not enough, then mention to your boss and your fellow co-workers that you intend to pass this exam by that date.  Feel free to also share you exam date as a comment on this post! That should put enough pressure to get the job done…wouldn’t it?

In closing, I found that the 70-526 (Windows Applications) exam was the easiest exam of the bunch.  As for the hardest, I must say that it was the 70-529 (Distributed Applications) exam, mostly because I’ve never done .NET Remoting in the past.  And now that WCF is in the neighborhood, I doubt I’ll even have to touch .NET Remoting in the future!  It all depends on your experience with these technologies.  The more you practice and learn, the greater your chance in passing.

My name is Brian Di Croce, a passionate software developer living, coding, blogging and working in Montreal, Canada. Feel free to visit my website/blog for more great content related to software development with .NET! ©2007-2008