Regular expressions provide a powerful means to harness the capabilities of text.  Deeply ingrained in the heart of .NET is a vast and powerful regular expression toolkit found in the System.Text.RegularExpressions namespace.  This is a well-known fact.  Many developers, myself included have been using them for years and years because they provide unparallelled control over interpreting, parsing, extracting, replacing, and manipulating strings.

I'm not going to bore anyone by further explaining the benefits of regular expressions nor will I go into explaining how they are constructed and how they work.  Every single developer, IMHO, should have on his desk the fantastic book “Mastering Regular Expressions” by Jeffrey Friedl.  It is a MUST read.  It's a MUST read many times.  I absolutely love it.  Alright, enough evangelism.

When creating regular expressions in .NET you have the opportunity to establish how the regular expression will be used to process your text by a RegexOptions enumeration.  By default, the regular expressions that you create are interpreted and evaluated at runtime.  There is nothing particularly wrong with that.  If your regex is used infrequently then that can be perfectly adequate.  However, suppose your regular expression needs to be utilized much more frequently.  It is quite possible that your application's performance may begin to degrade because of such frequent interpretation of the regex.

One of the RegexOptions enumeration values is Compiled.  When you apply the Compiled option to the regular expression you are telling the .NET runtime that you don't want the regex interpreted, but rather that you want it to be compiled.  Ultimately, this will usually have the benefit of being more efficient.  However, there is a cost.  The compilation happens at runtime.  When the execution path hit the regex flagged for compilation the .NET runtime will dynamically generate an assembly, load it, and execute it.  So there's an initial hit.

This might be fine and dandy...but it's going to happen once for every compiled regular expression.  In other words, if you have 25 compiled regular expressions in your code, you'll end up with 25 dynamically generated DLLs in memory.  That doesn't sound good to me.

The wonderful thing is you can take this hit up front entirely and generate a single assembly that contains as many pre-compiled regular expressions as you desire.  This is accomplished through code - there's no built-in IDE support.  The added benefit of a pre-compiled regex assembly is that you can fine tune your regular expressions out-of-band with your application.  You don't have to recompile your application(s) to get the updated regular expressions.  Instead, you reference your regex library and you have access to them.

This magic is accomplished via the Regex.CompileToAssembly() method.

Over the past couple of days I created a little application that I call the “Regular Expression Assembly Builder”.  This tool provides you with the ability to gather your regular expressions, organize them, and ultimately compile them into a DLL.  Essentially, with this tool you can:

• Open and edit existing assemblies containing regular expressions (via Reflection).
• Create brand new assemblies.
• Organize your regular expressions into hierarchical namespaces.
• Strongly name (even Delay Sign) your resulting assembly with a key file.
• Apply several attributes to your target assembly.
• ...and much more

Here are a few screen shots of the application in action:

The application plus source can be downloaded directly here or from the link on the main blog page.

Enjoy!

NOTE: I didn't know a tool like this existed already, but when I was just about done with the project I stumbled upon a similar, yet distinct, project that you might also be interested in.  It looks like Brian Delahunty took the initiative to create this well before I did.  Good job!

Microsoft released Visual Studio 2003 SP1 today.  If you're a daily user of VS 2003, as I am, you'll want to get this update.  I'm now waiting for Microsoft to release a Visual Studio 2005 service pack; VS2005 is much more of a house of cards.  That said, there are many quirks in VS 2003 that this fixes.

I had the opportunity today to present over Live Meeting to a group of programmers all over the country for First Data Corporation on the topic of Threading in .NET.  While I use Live Meeting in some capacity almost every day (multiple times), I have never actually given a presentation over one.  As I tend to do, I had very few slides and almost all “on-the-fly” demos.  Until now, pretty much all of the presentations I've given have been live and in in-person.  It sure makes it easier to see reactions and demeanor.  Online presentations, are by their very nature, are more impersonal and without an audience present it's a little trickier.

Despite the unfamiliarity of the territory, I feel the presentation (though a little rushed due to time constraints) went pretty well and was well received.  I look forward to the opportunity of doing it again in the future.

This month, the monthly Utah .NET User Group meeting will be one week late (Thursday, August 17th, 2006).  These summer months have been a challenge with respect to scheduling and our speaker isn't in town today, but will be next week.

To quote from our email reminder that went out:

Matt Smith is a Senior Consultant with Microsoft Consulting Services in Salt Lake City and will be speaking to us on Domain Specific Languages (DSL) and DSL Tools. This is surely to be a very exciting and informative session as Matt has worked intimately with these tools for the past few years.

You definitely will NOT want to miss this awesome session. So show up, invite your friends, colleagues, parents, and anyone you know - it'll surely be a great time.

          Time: 6:00 PM
          Date: Thursday, August 17th, 2006
          Place: Neumont, University (10701 South River Front Parkway, South Jordan, Utah)

See you at there!

This should be a fun meeting!

The tradition goes on

We'll be having our monthly DevUtah Geek Dinner on August 22nd, 2006 at Los Hermanos in Lindon.  Come enjoy the great Mexican food and a fun-filled time.  Spend time with your fellow geeks.  In addition to the great food, you'll be able to share in a brief discussion on Net Neutrality led by Utah Senatorial candidate Pete Ashdown.

It should be a great time.  Please RSVP if you're coming.

See you there!

I wrote this function a long time ago, but stumbled across it again today when I needed the functionality.

I've been updating a custom installer wherein I needed the ability to programmatically enable/disable a control on the dialog.  Unfortunately, there is no mechanism built-in (I'm using InstallShield X) that provides this functionality.

This simple function takes a dialog box name (which is a string), the id of the control (an integer), and the desired enabled/disabled state (a boolean):

prototype void SetCtrlEnabled(STRING, NUMBER, BOOL);

function void SetCtrlEnabled(szDialogName, ctlId, enabled)
   HWND hWndDlg, hWndItem;
begin
   hWndDlg = CmdGetHwndDlg( szDialogName );
   hWndItem = GetDlgItem( hWndDlg, ctlId );
   if ( IsWindow(hWndItem) ) then
      EnableWindow( hWndItem, enabled );
   endif;
end;

You can call this function with the following code:

#define DIALOG_MYCUSTOMDIALOG "MyCustomDialog"
#define RES_CTL_TXTSAMPLE     1000

SetCtrlEnabled( DIALOG_MYCUSTOMDIALOG, RES_CTL_TXTSAMPLE, TRUE );

Ok, this is ridiculous.  Do home builders just not care?

I've done my share of moaning and groaning about how well (or how poorly) my house was built.  Errant pipes here, wires run underneath ceiling joists in the basement, massive pipes protruding from various walls and supports, the non-squareness of the walls, etc.  I know that the builders are working with imperfect supplies and wood bends.  Sometimes the easiest approach looks like the best one.  Sometimes it is.  I don't think that's always the case.

I try to cut them some slack.  Coming in and doing work after someone was already there can be tricky and daunting.  It's a lot like software.  It's in pretty much every industry.

But today I found something in my house that is making me livid (and I don't usually get mad; frustrated, yes, annoyed, sure, but mad, rarely).  We've had issues with our air conditioning ever since we moved into this house.  The house gets pretty hot in the summer time.  For a long time we've attributed the problem to the air conditioner not working or needing more coolant, or whatever.  We've paid for people to come out every year (yes EVERY YEAR) and fix it.  The fix has been temporary at best.  There has always been one vent (in the small bathroom) that hasn't ever really worked.  I always assumed that there was blockage.

Well, to help mitigate the problems we've been having we hired a duct cleaner to come out today and do his magic (it's been long overdue anyway).  In attempting to clean out the bathroom duct he noticed that he wasn't getting any suction.  He reached his hand in and felt insulation.  No, it wasn't insulation that was in the pipe, it was insulation because the pipe wasn't connected to the boot.  He could see light through the vent.  Grrr.

Now it just happens that we just finished (and by just I mean yesterday) drywalling, taping, mudding, and texturing the walls in the basement.  This wasn't looking good.  The only bright point to this whole rant is that there is just one place in the whole basement that isn't finished: the utility room.  The bathroom happens to sit right above the utility room.  Thank heavens!

So we went down to have a look.  Sure enough, the boot is sitting there attached to the bathroom floor in the ceiling.  There's also a pipe that should be attached.  It's just sitting there.  The end closest to the boot had duct tape on it.  At the other end of the pipe was an elbow.  The elbow should be attached to the main air conditioning shaft.  Upon inspecting the elbow, however, it was never dove-tailed, cut, taped, screwed anything - it looked as pristine as it would be in the store.  Frustrated, I then felt around for a hole.  Sure enough, there it was.

But it gets better.  It wasn't that it wasn't connected - that would be an easy fix.  The builders, in their great wisdom, saw fit to run a floor joist smack over the middle of the hole - right in line with the boot to the vent in the bathroom.  There is no way it was ever connected, nor could it be.

Now it turns out that this hole is the hole nearest to the air conditioning unit.  Naturally it would receive the greatest amount of air pressure.  For seven years we've been venting the majority of our air into the insulation below our bathroom, robbing the rest of the house of much needed cooled air.  No wonder it's never really cooled off the house and our electrical bills have been astronomical.

I don't know how this ever passed inspection.  I wonder if it was even inspected.  I wonder how someone could just not care enough to finish the job.  I guarantee that had it been the builder's house things would have been different.

Chalk that up for yet another problem :-(

• The entire circuit breaker was wired backwards (we had incessant breaker tripping for years just running the microwave and a blender at the same time) which had led to countless computer hardware issues and crashed drives because of surges.
• I had to furr down almost the entire basement because of pipes and wires running beneath all of the joists.
• Air conditioning ducts never even connected.  The pipe was just laying there, never even connected - venting the majority of air into the insulation beneath the bathroom.

I know that there's pressure to get stuff built.  There are time constraints, but do we just not care about the quality of anything anymore? Everything is disposable, nothing is made to last.  This is ridiculous to saddle someone with a half-baked, not even working product and call it good with a clean conscience.  Had I not been doing this inspection I never would have known the problem and would have lived on, ignorant of the problems within the system, tolerating the output.

It's a lot like crappy software.  I'm sick of a lack of quality.  Where's the pride in what we do?

There comes a time in software development when enough is enough.

As developers we (I'm not excluding myself from this group) will design and create toolsets called frameworks to support the software that we're writing.  It's natural.  It's easy (usually).  Of course, much of the code we write tends to be specific to a particular problem domain...but that's completely unacceptable.  We must abstract away any hint of specificity and genericize all aspects of our applications.  We then create support libraries that create objects and provide services of some generic, not-known-until-consumed-by-an-application type for some mystical reuse that probably will never happen...but just in case.  Heaven forbid that our framework have any knowledge or insight into what our application will do or how the information might be utilized.  These frameworks then tend to get bloated and so generic as to lose all sense of meaning.

We create frameworks to support some greater project or set of projects.  If new functionality needs to be added to our application it's inconceivable that the functionality should be applied directly to the program.  Rather, the supporting framework should be enhanced in a generic manner such that the program can consume some service provided by the framework to supply the functionality.  Inevitably, the project scope balloons and the framework bloats to support some obscure functionality, further diminishing the framework's usefulness.

As developers we lose sight of what we were originally trying to achieve: the writing of software.  Instead, we like to focus on the innards that supply functionality to our software.  Sometimes that enough - but not always.  Oftentimes, the creation of the framework is too specific.  It would be better if we got down closer to the metal and wrote the supporting code for the framework.  By identifying the services the framework needs to properly function we can add new, even more generic functionality, thereby enabling our framework to support more theoretical applications.

You know, there's really no end to the insanity.  All we wanted to do in the first place is create a simple program.  But we couldn't simply use the functionality already available to us, we had to go reinvent the wheel rather than simply pumping up the tires.  All I wanted was a Universal Hammer.

NOTE: Joel Spolsky's blog post is a great read.  If you write software, read it and take it to heart.