Michael Flanakin

Flash and Silverlight Jobs

Michael Flanakin — Mon, 28 Dec 2009 03:31:00 GMT

Silverlight has been Microsoft's golden child since v2 was released last year. The impact within the community has been astounding. Some demand the use of Silverlight without actually recognizing when and where the technology makes sense and others scoff at Silverlight either in favor of Flash or as a technology as "useless" as Flash. I roll my eyes every time I hear any of these three opinions... and they happen a lot. Flash went thru the hype cycle years ago and now it's Silverlight's turn. What I find amusing is that the hype seems to be much more powerful with Silverlight than it ever was with Flash. All we can do is fight the good fight.

Not every rich experience needs to be Silverlight. JavaScript frameworks are making life as a web developer easier and easier, so I'd recommend that always be the default choice. Unfortunately, most developers still find the pain of JavaScript development too great. While I'm a big fan of JavaScript, it is far from a perfect language and is severely lacking when it comes to development and debugging tools. Flash and Silverlight both simplify things with better tools and a single-platform vision that tremendously improves cross-browser development, but Flash is still lacking the one thing that makes Silverlight a no-brainer: XAML, backed by real programming languages.

XAML is immensely powerful and will continue to grow as more and more WPF features make it into Silverlight. XAML takes a new way of thinking, but it's well worth it for the simplicity and ease of development you get. But, more important than XAML is the fact that you have any .NET language you want and, with the inclusion of the Dynamic Language Runtime (DLR), there's virtually no reason not to use Silverlight. The one and only benefit Flash has is more mature tools. This is very important, but it is only a matter of time. Microsoft has both the will and the ability to overcome the current Flash tooling. The days of Flash are severely numbered. A look at the job market only confirms this. I just wish I had some of the same numbers from when Flash was initially released to compare the difference.

I truly believe that, if you're a web developer using any language, you need to take the time to understand how Silverlight can benefit you. Yes, HTML5 is coming, but the power and flexibility of environments like Silverlight will quickly surpass anything the W3C will ever be able to come out with a specification for. Heck, in less than 2 years, we've seen 3 releases of Silverlight and a beta version for the fourth, with speculations that Silverlight 4 is likely to release at Mix 2010, making it 4 full releases in 2.5 years. I'd like to see any one W3C spec ratified and fully released in all major browsers in such a timeframe. Such a feat is completely unheard of. Nevertheless, don't let me blab on about it. The numbers speak for themselves...

Lazy Load One-Liner in C#

Michael Flanakin — Sun, 13 Dec 2009 23:31:00 GMT

One thing I love about C# is that I'm constantly learning new ways to simplify and write less code. Perhaps PowerShell has a lot to do with this, but I put a lot of value in the power of the one-liner. With that, I wanted to share something small I recently discovered.

There are three main ways to initialize your read-only class properties: field initializer, constructor, or property accessor. The first thing you need to consider when determining the right approach is whether you should use a readonly or get-only variable. A readonly variable has two primary benefits: guaranteeing the value won't change and better ensuring thread-safety. I'm not going to go into either of these, but I will say, if you can make your variable readonly, do it. The main reason not to make your variable readonly is if its initialization is resource-heavy and the variable isn't always crucial. There are other things to consider, but I want to focus more on the implementation of this code rather than the reasoning behind deciding on a good approach.

Back in the .NET 2 days, I used the following approach to lazy loading.

private PersonCollection _people;
public PersonCollection People
{
    get
    {
        if (this._people == null)
        {
            this._people = new PersonCollection();
        }
        return this._people;
    }
}

One way to achieve a one-liner would be to use an inline if statement.

private PersonCollection _people;
public PersonCollection People
{
get { return ((this._people == null) ? (this._people = new PersonCollection()) : this._people); }
}

The main problem with this is there's more one-liner than simplicity. This is a common problem with the inline if statement. For this reason, I avoided this type of lazy load approach.

Recently, when hammering thru some code, typing == null just made me think about the ?? operator. For those that don't know, this is essentially a null-check included with .NET 2 to simplify the use of nullable types (Nullable<T>). If the value on the left is null, the value on the right is returned.

private PersonCollection _people;
public PersonCollection People
{
get { return this._people ?? (this._people = new PersonCollection()); }
}

Nothing revolutionary, but, as I mentioned before, I love my one-liners!

SharePoint Designer and Developer Position Descriptions

Michael Flanakin — Tue, 17 Nov 2009 00:30:00 GMT

I can't tell you how many resumes I've read and interviews I've performed in the name of finding a quality SharePoint developer. After seeing my customer painstakingly struggle thru this same process, I finally decided to put together a couple short blurbs to cover what it is to be a SharePoint designer and a SharePoint developer.

I lump administration and design/customization together because I honestly believe you can't have one without the other -- at least to some extent -- but I'm obviously looking more for the latter than the former. Let me just say that, if I was building up a team to build SharePoint solutions, I'd want at least one of each of these types. Obviously, you'll want someone more focused on administration, if you're also doing operations work, but I'm more focused on building solutions than hostings.

SharePoint Administrator/Designer
Experienced SharePoint administrator with a strong emphasis on customization. Extensive experience with SharePoint Designer and InfoPath are a must, as is a moderate ability to create customized web parts using a mixture of HTML, CSS, JavaScript, and XSL (i.e. using a Data View Web Part). Should at least have an understanding of:

IIS/SharePoint troubleshooting (i.e. event and ULS logs)
How to customize branding
SharePoint Designer workflows
InfoPath forms
Applicability and use of content types
SharePoint web service interfaces
Feature deployment
Standard features (i.e. search/indexing, content management, and Shared Service Providers (SSPs))
Enterprise features (i.e. Forms Server, Excel Calculation Services, and Business Data Catalog (BDC))
Reporting and business intelligence (BI)
Security concerns and audience targeting

Experience with PowerShell and ASP.NET development are a huge plus.

SharePoint Developer
Strong ASP.NET (C#) developer with experience building and deploying fully-automated SharePoint solutions. Must have an understanding of at least:

Standard ASP.NET (including membership providers and their applicability to SharePoint)
SharePoint object model and web service interfaces
SharePoint feature packaging and deployment
Web parts and web part connections
SharePoint branding components
Applicability and use of content types
SharePoint-hosted workflows
Standard features (i.e. search/indexing, content management, and Shared Service Providers (SSPs))
Enterprise features (i.e. Forms Server, Excel Calculation Services, and Business Data Catalog (BDC))
Reporting and business intelligence (BI)

Above all, developers are expected to "live" in Visual Studio, yet be ablet o identify when SharePoint Designer and/or InfoPath would be more pragmatic -- and follow through with such a solution.

Senior developers and software architects must have broad, hands-on experience across the entire software development lifecycle with formal engineering processes. Experience with defining and documenting an applicable taxonomy and governance plan is a must.

If you're interested in building SharePoint solutions, I highly recommend you find where you fit within these two descriptions. There's plenty of room to grow, but they cover the foundations I -- and many others -- look for when building out SharePoint teams.

Good luck and happy job hunting!

Silverlight 3 Tools Offline Install

Michael Flanakin — Sat, 12 Sep 2009 15:30:00 GMT

Ever try to install the Silverlight dev tools in an environment with "filtered" or even no access to the internet? If so, you've probably taken a look at the errors in the log and seen the following error:

Error from JobError Callback : hr= 0x80190193 Context=5 Description=HTTP status 403: The client does not have sufficient access rights to the requested server object. . Percentage downloaded = 0

For some tools, like .NET 3.5 and 3.5 SP1, there's an offline installer available on their respective download pages. Unfortunately, the Silverlight dev tools don't have that. I major oversight, if you ask me, but what can you do? Note that this was a problem with Silverlight 2 and 3. I haven't heard anything about a fix for the future, but I have to think they realize the work-around is ridiculous. Enough of my blabbering, tho...

Download and save the Silverlight 3 Tools for VS 2008 SP1 to your desktop
Create a new sltools directory on your desktop
From a command prompt, run silverlight3_tools.exe /x to extract the files
NOTE: You can also use a tool like 7-zip to extract the files
Specify the directory you created in step 2
Download and save the Silverlight Developer Runtime to the sltools directory
NOTE: My problem was that the Sl Dev Runtime is at a blocked URL, so you may have to download it offline and bring it into your environment
Run sltools\SPInstaller.exe to perform the actual installation
Delete the sltools directory

That's it. Not hard, but annoying.

Tim Heuer has a similar blog post for Silverlight 2, but I wanted to share this because the developer runtime is in a new location. ~~I'm still trying to figure out what the full URL is, so I'll update this if I get a chance to figure that out.~~

Update: Thanks to the Bob Pomeroy from the Silverlight team for helping me get the direct URL for the Silverlight 3 developer runtime.

Comparing Virtual Earth and MapPoint Web Service

Michael Flanakin — Sat, 02 May 2009 18:04:00 GMT

When I need to create a geospatial visualization, Virtual Earth is my default answer. When talking to someone who's been in this space for a while, he mentioned the MapPoint Web Service. I initially assumed this was a legacy offering that Virtual Earth replaced. Apparently not. Tatham Oddie has a very nice high level comparison to at least help you determine which makes the most sense in a given situation.

	Virtual Earth	MapPoint Web Service
Map Styles	Road, Aerial, Birds eye	Over 30 different styles (optimised schemes for night viewing, etc) however no aerial imagery
Integration style	JS control (best for embedding in web pages)	SOAP web service (usable anywhere)
Interface style	Drag and drop positioning, scroll wheel support, interactive pushpins, AJAX based.	Roll your own (it returns an image and you have to work out what to do with it).
Pushpin support	You create them all yourself on the fly using API calls – any clustering / filtering optimizations have to be done manually.	Can upload pushpin sets to their databases and they will handle plotting / clustering and filtering.
Routes	Specify a start point and an end point and they’ll give you a route in text. End of story.	Specify the waypoints, preferred road styles (back roads, highways, toll roads, non-toll roads) and it will return a machine readable result set.
Cost	Free (commercial use has some minor restrictions)	Per transaction
SDK documentation and support	Basic MSDN docs, active community (www.viavirtualearth.com)	Plenty of MSDN docs and articles, including VS.NET integrated help and plenty of websites (www.mp2kmag.com)

Visual Studio 2010 Will Make You More Productive

Michael Flanakin — Sat, 14 Mar 2009 14:41:00 GMT

Whether you've heard about Visual Studio 2010 and .NET 4.0 or not, you should really be watching the 10-4 show on Channel 9 . As you have probably guessed, the show talks about what to expect in Visual Studio 2010 (version 10.0) and .NET 4.0. The episodes I've seen cover things like ASP.NET, AJAX, parallelization, and overall enhancements to the VS IDE. Admittedly, I'm behind a few episodes, but that's just par for the course While each of these has been valuable on its own, I have to specifically call out episode 5, Code Focused in Visual Studio 2010. This episode talks about three things: code navigation, test-driven development (TDD), and extending the VS editor.

These first two areas, code navigation and TDD enhancements, are taking a page from the Resharper bible. If you haven't used Resharper, yet, you're seriously missing out. Resharper is the one VS add-in I can't live without -- GhostDoc isn't too far behind, tho. The first thing we're getting is the ability to highlight all references of an variable. This doesn't sound all that exciting, but it's really nice to see without having to look, if that makes sense. To top it off, you can bounce between these references with simple keyboard shortcuts.

Bouncing between variable instances is neat, but let's take it up a notch. If you're digging into new code, figuring everything out can be a true feat. To help us move down this path, VS10 is giving us the ability to view the hierarchy of calls related to a specific method/property. The call hierarchy tells you everthing that calls your code block and what your code block calls. This is going to make understanding code a lot easier. We're still short of my desired end-goal of having an automatic sequence diagram generated, but at least we're making steps in that direction.

From a productivity perspective, one thing I love about Resharper is that, if I need to open a file, I don't need to know where it is, I simply need to know its name. VS10 is bringing this to everyone. A simple shortcut, like Ctrl+T, and a dialog pops up, waiting for you to type in the file name. You can type a partial name, mycla to get MyClass.cs, or use the Pascal-casing and type MC to get MyClass.cs or MyComponent.cs. Pay attention to how much time you spend in the solution explorer. Imagine cutting that in half, if not more.

The TDD-based enhancement really isn't about TDD, but it does support TDD very nicely. Basically, the idea is, when you're writing code, you want to dig in to the real logic, not go around creating domain objects and data access layers. To support this, you just start typing. If you need a customer class, you just reference it in code. VS will tell you it doesn't know about that class, but this is where the feature comes into play: it'll give you the option to generate it. The same thing happens when you add properties and methods. VS will generate the stubs for you. This lets you focus on one method at a time, without having to divert focus to figure out how third party code needs to work. This is all about decreasing the noise, in my opinion, which is very hard to do sometimes.

The last thing the episode covers is something most people will probably underappreciate: the new WPF-based editor. Despite what people think, this isn't about flashy graphics. Nobody wants text to fly across the screen as we type it. There are two concepts here: (1) simple animation can go a long way to enhance user experience; and, (2) WinForms is now a legacy technology and WPF provides so many enhancements that it just makes sense to bring this to developers, making it easier to build and extend on the #1 development environment in the world. Everytime I think about this, I fall back on Resharper. Now that it's so easy to do amazing things with the editor, what is the Resharper team going to be able to give us? What is the community going to be able to give us? I can't wait to find out.

Failure to Yield Right-of-Way

Michael Flanakin — Fri, 30 Jan 2009 05:52:00 GMT

I'm one of the many .NET developers out there that neglects the enhancements in the framework. Not that I mean to, I just keep a running tally of things I need to catch up on, but rarely make the time to actually do any of them. In an effort to shame myself into taking care of a few of these things, I decided to dig into something I haven't spent any time trying to understand: the yield keyword, introduced in C# 2.0. I have to say, I was surprised at how simple it was... well, almost.

To attempt the obligatory textual description: yield, in conjunction with a return or break statement, tells the compiler that the code block should be treated as an iterator. This means the code block must return an instance of System.Collections.IEnumerable; but that will be almost completely hidden from you. All you need to do is "yield" each value within a loop. The compiler will wrap your code block and return each value as the enumerator is traversed.

There. Plain as day, right? Doubt it.

While reading about the feature, I was reminded about how crappy some help can be. I just wanted a code snippet to show me what I might do without the yield keyword and then what I'd do with it. Here's what you are probably writing today...

public List<User> GetUsers(IDataReader reader)
{
    // convert to list of users
    List<User> users = new List<User>();
    while (reader.Read())
    {
        User user = new User();
        // set user properties from reader
        users.Add(user);
    }

    // return
    return users;
}

This is pretty basic stuff. Now, let's look at how you'd do it with the yield keyword...

public List<User> GetUsers(IDataReader reader)
{
    // convert to list of users
    while (reader.Read())
    {
        User user = new User();
        // set user properties from reader
        yield return user;
    }
}

If you didn't catch it, we were able to get rid of the code that uses the List<User> instance. Sure, only 3 lines, but less code is typically better -- assuming we're not sacrificing readability. Those who're paying a little more attention probably noticed the fourth line that changed (well, technically, it was the first): the return type. Since yield only knows about IEnumerable (and IEnumerable<T>, by proxy), we have to change the return type to match that. I have to admit, I didn't like this. Using IEnumerable basically means I'm stuck with foreach blocks, which I hate using. This led me to investigating performance.

If you really want to know about the performance benefits of for vs. foreach, check out Joe Duffy's blog . Joe works on the PLINQ team and has a very nice post about perf considerations. From the limited tests I ran, I started to see horrid performance when using yield. Then, I reallized I probably needed to bump up my iterations to make it a bit more meaningful. Once I got into 10-50,000 iterations, I started seeing yield come out on top -- or, at least making it a better race. This goes along with what Joe talks about: you pay the cost of having the enumerator, which costs a lot, but will make up for it over the long haul, assuming you have a lot of iterations.

This isn't the whole story, tho. I ran this on a single core machine. Using a multi-core machine will produce better results. Why? Because yield is multi-threaded. What actually happens is, when you call a method that uses yield, it maintains a reference to that method. Then, your code will get an enumerator for it, typically via a foreach block. All this happens without actually touching your method. Within the foreach block, you actually reference the instance associated with the enumerator's location (i.e. users[i] in a for block). When you access the instance, that's when .NET actually digs into your method to get the next instance. The benefit of this is that you only process what you need to process. If you only need to loop thru 10 of the 1000 records, you only process 10, whereas all 1000 would be loaded into memory with the typical approach.

It's all a bit fuzzy until you play with it. I'd recommend creating a simple test to walk thru it yourself, if you really want to get a feel for it. It's as simple as debugging a test. As a matter of fact, here's a simple MSTest project that walks thru it. Hopefully, this helps you understand what's going on.

Getting the Value of a Dependency Property

Michael Flanakin — Sat, 03 Jan 2009 21:28:00 GMT

WPF and Silverlight have a daunting learning curve. There's no doubt about it. All we can do is take one bite at a time and, eventually, we'll finish the elephant. I've talked about my approach to today's WPF/Silverlight tooling and a good intro to routed events and commands, but there's so much more. I haven't talked about dependency properties, but that's probably the second concept you'll have to grasp (before events/commands) as you ramp up on the wide world of XAML. I'm going to skip over it, for now, because I've found something else worth noting: how the value of dependency properties are determined. Obviously, if you don't understand the concepts behind dependency properties, you'll need to brush up, first.

Traditionally, determining the value of a property is simple: you get it's value (referred to as "local value" in WPF/Silverlight). That's it. A call to person.FirstName would return the value stored in the private person._firstName field. If it hasn't been set, then the default value of that type would be used. Simple. If we need to inject any custom logic here, we typically start by doing so in the accessor. For instance, if we want to ensure the value cannot be empty, we add a check to the setter. Things can (and will) get more complex, tho. For instance, we might have a need to allow others to add in their own validation. This would traditionally be handled by an event handler with a Person.FirstNameChanged event. For better or worse, this is all custom and has a lot of room for "creativity." WPF seeks to standardize this and adds a bit of a framework around dependency properties to do so. Determining the value of a dependency property is accomplished in a five-step process.

Get
Evaluate
Animate
Coerce
Validate

For the most part, these are all pretty simple to understand. The first step is arguably the most complex, in my mind, because getting the base value isn't as simple as the aforementioned person.FirstName example.

1. Get the Base Value

Obviously, you need to know what value you're working with before you can proceed, but with features like templating and property inheritance, what the heck is the value!? In school, you had PEMDAS; in WPF you have... well, something a bit more detailed.

Local value
Style triggers
Template triggers
Style setters
Theme style triggers
Theme style setters
Property value inheritance
Default value

I'm not going to dig into each of these. I simply want to mention a few important aspects to keep in mind. First, "local value" refers to any call to DependencyObject.SetValue() (i.e. Height="123" in XAML or code or Canvas.Left="123" in XAML). The only other thing to concern yourself with, if you're a beginner to dependency properties, is the default value. Default values are not necessarily the same as that of the underlying type. For instance, FrameworkElement.Height has a default value of "NaN" (not a number), despite the fact that it's type, double, has a default of 0. Default types for dependency properties are set when the dependency property is registered.

2. Evaluate

If the value from step one derives from System.Windows.Expression, such as data bindings, WPF converts that to a real value. Pretty self-explanatory.

3. Animate

If the dependency property is currently being animated, the value we've retrieved/evaluated is pretty much ignored in favor of the value set by the animation.

4. Coerce

Next is the injection of custom code via the CoerceValueCallback delegate, if one is registered. Being custom code, you're really left to your imagination on what you can and should do here, but one common scenario is to ensure the value is within expected bounds.

5. Validate

Lastly, we inject one last bit of custom code via the ValidateValueCallback delegate, if one is registered. Validation returns a simple true of false, so there's not much you can do if you made it this far with a bad value. If validation fails, an exception is thrown. For this reason, be sure you take advantage of both coercion and validation, if you have a specific domain you're working in.

ReSharper Nightly Builds: The 4.5 Saga

Michael Flanakin — Wed, 31 Dec 2008 16:31:00 GMT

JetBrains started work on ReSharper 4.5 recently; but, more importantly, they just made nightly builds available online. I've said it before and I'll say it again: this is the best Visual Studio add-in I've seen... and I'm not the only one who thinks so. I'm a huge productivity geek and ReSharper helps feed my addiction to speed... as in quick. JetBrains won't give you drugs. Although, ReSharper may seem like it, when you work on a machine without it. Development without ReSharper is somewhat analogous to drug withdrawals... cold sweats, lots of twitching, and wondering if you'll be able to finish in time. Okay, maybe not, but I do dread life without it.

2008: Year of the Cloud

Michael Flanakin — Fri, 05 Dec 2008 21:23:00 GMT

Every year, there's one underlying theme that seems to be pushed in the technology arena more than anything. This year, I feel like it's the year of the cloud. The last time I did this was five years ago, so I'll have to back-fill a few years, but here are the themes I've noticed over the past 11 years.

2008: Year of the Cloud
2007: Year of User Experience
2006: Year of AJAX/Web 2.0
2005: Year of SaaS
2004: Year of Offshore Outsourcing
2003: Year of the Architect
2002: Year of Web Services
2001: Year of XML/.NET
2000: Year of Enterprise Java
1999: Year of Linux
1998: Year of the Web

We've been approaching "the year of the cloud" for a while, now. You can actually look back to 1998, when the web started to really catch on. A few years later, as Java started to build momentum and then .NET hit the scenes, which is when XML as a standard communication language started to catch on. Also tied to the .NET release was a huge push for web services. As this was more and more successful, service-oriented architecture (SOA) started to boom. In my mind, that was a big boon to the outsourcing trends, which have seemingly quieted down a bit, but not completely. SOA also led to the software as a service (SaaS) trend, which triggered Microsoft's software plus services (S+S) push, but that was more of a side story. With everything moving to the web, backed by [typically open] services, asynchronous Javascript and XML (AJAX) was the next big push. This was tied to the "Web 2.0" moniker, which I'd argue wasn't quite what Tim Berners-Lee intended. Either way, this led to the big push for better user experiences, which many people confuse with user interface design. The Web 2.0 push also kept the industry on its web focus, which is where we are left today.

It's easy to look back and see how we got here. Trends show that architectural changes typically take two or three years to gain momentum in the community, so we'll probably have a couple of years before the next major architecture peaks. The trend towards distributed computing has grown more and more, but I have a feeling things are going to start coming back a little. We've been pushing out to the web for a lot of reasons; one of which is the rise of the Mac. What we've been losing out on, however, is the power of the desktop. I see the S+S push to continue, but more as an underlying theme than a strong focus. Services will continue to be the foundation, maintaining the importance of cloud computing, but the desktop will be where the processing occurs. I see Silverlight proving a huge success, which will eventually bring .NET to the Mac. This will probably bring Novell and Microsoft a little closer together, with respect to Microsoft's relationship with Mono, but this may simply be a change in focus for Mono. Oh, and when I say, "bring .NET to the Mac," I'm not talking about the scaled-down version in Silverlight. I'm talking about the real deal. I see WPF and Silverlight merging along with the smart client architecture built into .NET today. This will take more than a few years, but it seems to be inevitable. Most likely, by the time all this happens, multi-core will be a way of life, as opposed to the we-should-be-thinking-about-threading thoughts most developers have today. Armed with a strong multi-threaded foundation, which is easy to use, the combined WPF/Silverlight presentation tier will quickly overtake Flash and Air. By this time, we should also start to see more integration into our everyday lives...

Okay, I'm probably getting a little out of hand here. If I go much further, we're going to be on the USS Enterprise, so I'll stop while I'm ahead. I'll just leave it at, it'll be interesting to see what's next. My money's on the power of the desktop, which we've lost over the past 10 years.

PowerShell Tip: Creating GUIDs and Code Generation

Michael Flanakin — Tue, 25 Nov 2008 19:30:00 GMT

I should start off by saying this isn't really about hard-core code generation. It's more about simplifying some of the more repetitive tasks we tend to do during development. In this instance, I needed to get 7 GUIDs to use in some test code. Sure, I could've use the Create GUID tool in Visual Studio, but what fun is that? Besides, I hate manual tasks and this tool would have forced me down a ~24 step process. No thanks. I'll stick to the 3 steps PowerShell can give me.

First thing's first, how do we create a GUID in PowerShell? I'm going to fall back to .NET for this one.

[Guid]::NewGuid()

If you run this, you'll get a blank line. What's up with that!? Admittedly, I'm not 100% sure why this is happening, but I have a pretty good guess. GUIDs are surrounded by curly-braces ({}), which are interpreted by PowerShell to be a script block. Putting 2 and 2 together, I'm assuming PowerShell thinks this is a script to run. Easy fix.

[Guid]::NewGuid().ToString()

That's it. The only other thing I had to do was add in my other formatting to create the GUID in code and slap that in a loop.

foreach ($i in 1..7) { 'new Guid("{0}")' -f [Guid]::NewGuid() }

You'll notice I opted to use the PowerShell shortcut syntax for string formatting. If you missed it, I talked about it as well as the static-method-calling syntax last week.

This tiny exercise reminded me of a pretty advanced Excel spreadsheet I created years ago because I was sick of typing the same bit of code over and over again. Since then, other tools, like GhostDoc and Resharper, have augmented my developer experience, enabling a much higher level of productivity than I had back then. Nonetheless, there is still room for improvement. This makes me wonder how much PowerShell could do for me with respect to code generation.

Bug When Changing Platform (32- vs 64-bit) in Visual Studio

Michael Flanakin — Fri, 29 Aug 2008 16:43:00 GMT

Someone I work with came to me recently and showed me an interesting bug. In Visual Studio, you can force a project to be built as 32- or 64-bit by going to the project properties Build tab and specifying the target platform. He did this and then proceeded to build the app. This put all the binaries in a \bin\x86 directory. WTF!? I tried it myself and -- not that I doubted him -- I got the same results. The build directory still had the previous value of \bin\Debug, so I found this odd. I changed the build directory to \__bin\Debug and guess what... that's exactly where it went. I thought this was odd, but remembered the IE7 bug on Windows Server 2003 I mentioned a few months back. I changed it back to \bin\Debug and everything worked like a charm.

It looks like changing the target platform changes the build location and, to get around that, change the build directory to something else, save the properties, and change it back. Annoying, but at least you only have to do this once. I went ahead and added this to Connect.

Visual Studio Web Project Fails to Open with COMException

Michael Flanakin — Tue, 26 Aug 2008 14:46:00 GMT

Symptoms

When opening a solution with a web project in Visual Studio, you receive the following error in a popup dialog:

System.Runtime.InteropServices.COMException

Cause

Apparently, this is an issue with IIS configuration. I'm not quite sure why we get such a useless error message, tho. Very annoying. If you're not sure you're seeing this with a web project, load the solution and, when the error pops up, look at the status bar. You should see a "loading" message with the path of the problematic solution.

Resolution

Ignore the errors and let the solution load
In the Solution Explorer, right-click on the project that failed to load, click Edit <project file>
Scroll down to the bottom of the file and look for <UseIIS>True</UseIIS> (located at \Project\ProjectExtensions\VisualStudio\FlavorProperties\WebProjectProperties\UseIIS)
Repace True with False
Save and close the project file
In the Solution Explorer, right-click on the project, click Reload Project

More Information

Applies to: Visual Studio 2005, 2008

Resharper Nightly Builds: Game On!

Michael Flanakin — Wed, 13 Aug 2008 02:09:00 GMT

I'm a month and a half late, but the Resharper nightly builds are back! I guess I stopped checking after not seeing any movement for a while. I'm glad to see some activity, tho. This is the most beneficial add-in to Visual Studio I've seen; especially as a productivity geek. What I've been most surprised about is the overall quality of the nightly builds in the past 6 months. Simply outstanding. If you're asking yourself whether to give it a shot or not, I say go for it. You're likely to run into minor issues, but if my experiences are indicative of how well they manage their day-to-day development, this is a team with a very tight ship. I always grab the latest and try to update a few times a week, depending on what I'm in the middle of. If you're not quite as confident as I am, grab a "works here" release. I'm sure you'll see how great this tool is in relatively short time. An absolute must-have for all code-focused developers.

Programmatic User Login (aka Win32 LogonUser)

Michael Flanakin — Fri, 11 Jul 2008 13:04:00 GMT

Nothing new here. I just wanted to save this code snippet because it's popped up a few times in the past year and I have to go find it over and over. At least this will make it a little easier for me. This is by no means an authoritative reference -- it's simply what I have used. If you know of something I'm missing, please let me know.

First, you'll need to import the Win32 LogonUser() function:

using System.Runtime.InteropServices;

[DllImport("advapi32.dll", SetLastError=true)]
public static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, out IntPtr phToken);

The only question you probably have is about the logon type and provider parameters. The only provider I know of is the default, 0, which uses "negotiate" (Kerberos, then NTLM) for Windows XP/Server 2003 and later machines. Windows 2000 defaults to NTLM. If you don't know the difference, let me know and I'll explain that in more detail. Here are a list of logon types:

Interactive (2) -- Intended for interactive use (duh) with something like terminal server or executing a remote shell. This type caches credentials for disconnected operations.
Network (3) -- Intended for high performance servers to authenticate plain-text passwords.
Batch (4) -- Intended for batch servers, which act on behalf of the user without his/her direct intervention. Typically used to process many plain-text auth attempts at a time.
Service (5) -- Intended for service accounts, which have the "service" privilege enabled -- don't ask me what that is because I don't know.
Unlock (7) -- Intended for GINA DLLs (whatever that is) that will interactively use the machine. This type includes some auditing.
Clear Text (8) -- Intended for double-hop impersonation scenarios where credentials will be sent to the target server to allow it to also impersonate the user. As I understand it, this is what IIS "Basic" authentication uses. To perform a double-hop, you'll actually have to do a few other things. I won't get into that here, but let me know if that'd be of interest.
New Credentials (9) -- Clones current credentials and uses new credentials for outbound connections. Supposedly, this doesn't work with the default provider -- it requires the WINNT50 provider, whatever that is.

The following is a list of the supported providers. I don't know anything about the non-default ones, but figured I'd list them for completeness..

Default (0) -- "Negotiate" (Kerberos, then NTLM) for Windows XP/Server 2003 and later; NTLM for Windows
NT 3.5 (1)
NT 4.0 (2)
NT 5.0 (3) -- Required for the "new credentials" logon type.

Next, well... just use it. As you can see, the last parameter in the LogonUser() function is an out parameter for a token which represents the user. This is key. All you need to do is initialize a WindowsIdentity instance with this token and you're well on your way.

using System.Security.Principal;

/// <summary>
/// Creates a new <see cref="WindowsIdentity"/> using the specified credentials.
/// </summary>
/// <remarks>
/// This method assumes an interactive logon for simplicity.
/// </remarks>
public static WindowsIdentity GetIdentity(string domain, string userName, string password)
{
    IntPtr token;
    bool success = LogonUser(userName, domain, password, 2, 0, out token);
    return (success) ? new WindowsIdentity(token) : null;
}

Pretty simple. Of course, we still aren't there, yet. Now that you have the identity, you most likely want to impersonate it. Luckily, this is a simple 2-liner... well, technically two 1-liners. I should also say that, if you want to do impersonation with an already-obtained WindowsIdentity (and you don't have a password), you'll start here.

ImpersonationContext context = GetIdentity("mydomain", "me", "mypassword").Impersonate();
// do work as impersonated user
context.Undo();

That's it. Enjoy!

MSTest Helper: Create Private Accessor

Michael Flanakin — Thu, 10 Jul 2008 21:03:00 GMT

I just found something very useful in Visual Studio 2008 a few days ago. I've been using MSTest for about 2 years, now, and one thing I liked initially was the wizard that would generate test stubs for you. I liked that it gave you somewhere to start. After using it more and more, I began to hate it, tho. I guess the problem is I'm anal about how my code looks and I end up changing everything. So, I started generating the classes myself. The only problem with this approach is the private member accessor the wizard generates is no longer there. Not desirable, but there's an easy fix: run thru the wizard quickly and delete the methods. At least, that was until a few days ago. In VS08, all you need to do is open the file of the desired class, right click the background, select the Create Private Accessor menu item, and then pick the test project to add it to. VS has so many menu items, it's easy to overlook the really useful ones, so I figured this one was worth sharing. Hopefully, Sara Ford is listening.

"To Be [null], or Not To Be [null]," says the String

Michael Flanakin — Fri, 27 Jun 2008 22:46:00 GMT

David Kean mentions his thoughts on string handling and I have to say I completely disagree. He states that you should always return String.Empty instead of null. I hate this. An empty string and what equates to "no value," by definition, mean two different things. David, on the other hand, contends that the two should always be treated as the same. To be clear, I'm not saying the two should never be handled the same. On the contrary, I believe that's the norm... and rightfully so. With that, however, there are still cases where they need to be handled differently. Besides, the benefits you get from returning an empty string are immediately invalidated when considering consistency principles.

I'd even go as far as to say, returning empty strings promotes bad practices. Why? Because the developer then treats what is returned as a non-null value. While this isn't a problem, it typically goes further. The same developer will start assuming all methods that return strings act the same way. Let's not forget what they say about people who make assumptions... For this reason, I believe it's a good practice to always use String.IsNullOrEmpty() to validate string values, no matter what you think/know is returned.

I could list a number of what-if scenarios depicting why this is so important, but I won't. It should be pretty clear. Let's face it, we've all fallen victim to a null reference exception, which is essentially what happens when you assume a variable has a value. Clarify your assumptions with good exception handling.

Lastly, one other reason I like null over empty strings is because it uses less memory. Yes, this is very trivial, but it's true. The bottom line is that, whether you return null or empty string, you have to treat it as if it were null. For this reason alone, I believe it's cleaner to simply use null. Using empty strings is a hack, in my mind, unless it really means something different than "no value."

Thoughts on SharePoint Development

Michael Flanakin — Fri, 20 Jun 2008 14:19:00 GMT

It's been entirely too long. I've had a new project take over my life for the past few months. I'm trying to get back into things and catch up with the blogs I read, but it's sometimes hard. This is my first big SharePoint-based project and I have to say it's been "an experience." If you're a developer and you haven't heard about how much SharePoint has been taking over, you've probably been living/working in a cave. It's amazing. I've learned a lot, with respect to SharePoint, and I can sum it all up with this: SharePoint is the new VB. I don't say this from the drag-n-drop point of view that made VB so easy to use, but from the ease in which you can get something done. To put it another way, SharePoint is to hobbyist web "developers" what VB was to hobbyist client-side "developers." I say "developers" for a reason. I've been very clear about my thoughts on hobbyists, so I'm not going to get into that.

Perhaps the best way to put it is to liken SharePoint "development" to the creation of a Rube Goldberg device. And, if you want to throw in AJAX features and a standard user experience that looks/feels nothing like SharePoint... well, let's just say you have your work cut out for you. As if portal development wasn't odd enough with respect to deployment. All I can deduce is that SharePoint was built for tech savvy users (not even power users) and not developers... definitely not developers.

As most who know me already know, I've been a fan of DotNetNuke (DNN) for quite a while and even worked on the dev team for a few of the modules. I feel lucky to have gone thru that because DNN gave me a nice perspective to some key issues around portal development. It's also let me experience the difference between portals built for developers instead of for users. This is the key difference between SharePoint and DNN. I know there's been a lot of talk in the past about differences, but it all comes down to that. SharePoint has the polish necessary to make your portal much more user-friendly and feature-complete, but DNN has the dev backing to make it a breeze. I'm really hard-pressed to pick a favorite, that's for sure. I've been in talks with a few key people within the DNN and Microsoft teams to get more involved with DNN in an official capacity, but I think I'm going to back off of that. Between the two portals, I see SharePoint having the most promise for the future. DNN is fantastic and I'll continue to recommend it where it makes sense, but SharePoint is much more powerful. The big hole in SharePoint is the developer experience. I see this as a huge opportunity.

More and more, I hear about how we need to focus on specific technologies. I'm not the type to whole-heartedly dig in to a single technology from top-to-bottom, but I do see value in filling this gap. The training I continue to see around SharePoint is all about small-time hacks. We need an enterprise solution. Some true patterns and practices for enterprise SharePoint development. Given the Rube-Goldberg-ian nature of SharePoint, this may be hard, but someone has to do it. Of course, this is all going to depend on the project opportunities I have. For now, it's just a bag of thoughts I've thrown together, but I'm hoping I'll have a chance to sort them out and pull it all together in the future.

There's so much more I could say about SharePoint, DNN, and the other things I've mentioned here, but I've babbled on long enough.

One Use for Extension Methods

Michael Flanakin — Fri, 18 Apr 2008 00:44:00 GMT

I like extension methods. Some people suggest you avoid the feature, which I believe is understandable, but the more I think about it, the more I want to use it. Don't get me wrong, I'm not using them all over the place, but when they make sense, it can make your code much cleaner.

As you may know, I'm working on custom code analysis rules to enforce coding standards. To make the rules testable, I decided to front the code analysis types with my own object model. To do this, I created a factory to create my types -- CodeItemFactory.Create(Member). While creating a new rule, I wanted to see if the current member had a sibling member with a specified name and then return that. At first, I started to add a new method to the CodeItem class, but then I realized I'd have to reference the CodeItemFactory class. While I'm in the same assembly, I didn't like the idea of putting this logic into the domain object and creating a circular dependency. Plus, since the code analysis framework isn't "officially supported," there are no promises on what will be available in the future. Keeping my integration code separate is just a good idea. So, I ultimately decided to create an extension method to do what I needed -- CodeItemExtension.GetSibling(this CodeItem, string). This enabled me to have a clean code implementation and keep my purist ideals of separating integration code -- codeItem.GetSibling(memberName).

There are plenty other reasons to love extension methods, but I just wanted to share this because I feel like it's a very nice solution that keeps life simple.

Testing Custom Code Analysis Rules

Michael Flanakin — Tue, 15 Apr 2008 10:55:00 GMT

Over the years, I've been asked to put together coding standards again and again. The nice thing about this is that it enables me to pull out the old docs and touch them up a little. A year or two ago, I heard something that made a lot of sense: developers never really read coding standards and, even if they do, they don't usually adopt them. Let's face it, if you don't adopt a standard as your own, you're not going to use it. The only way to ensure the standard is applied is to catch the problem before it gets checked in. I tried a VS add-in that attempted to do this as you type, but it wasn't quite as extensive as I want, but I grabbed onto the concept. For the past year, I've been wanting to start this and have finally decided to do it.

As I sat down and started to investigate writing custom code analysis rules, I asked myself how I was going to validate them. After hacking away at one approach after another, I started to realize I wasn't going to get very far. Apparently, with the latest releases of Visual Studio and FxCop, there's no way to create the objects used to represent code. After talking to the product team, the official position seems to be that, since custom rules aren't "officially supported," they're not going to support their testability. I'm not sure who made this decision, but I think it's a bad one. Of course, I say this without knowing their plans. Well, not completely, anyway.

It's not all bad news, however. It turns out there are hopes to start officially supporting custom code analysis rules in the next major release, Visual Studio 10. Nothing's being promised at this point, it's just something the team would like to deliver. I should also say that the upcoming Rosario release isn't the major release I'm referring to. I'm expecting Rosario to be a 9.1 release that will probably hit the streets in early 2009. That's a guess, tho. If that's true, the VS 10 release probably wouldn't be until 2011. All I can really say about it is that it'll be a very exciting release. I can't wait to get my hands on a beta. Speaking of which, some of the goals they have for the product will make beta testing much much easier... I'm talking about a hugely evolutionary change, if not revolutionary, considering where the product is today. That's all I can really say, tho.

Back to the point, since there's no realy testability of the code analysis framework, I decided to create my own object model. The part I'm missing, obviously, is the factory logic that converts code analysis types to my types. I'm hesitant about this approach, but it's working so far. Hopefully, I'll have something to deliver soon. I keep bouncing around, tho, so at this point, I want to deliver a release with only naming conventions. That release is mostly complete, I just need to get approval for a distribution mechanism. If I don't get that soon, I'll just release it on my site.

PowerShell and Project Euler

Michael Flanakin — Fri, 04 Apr 2008 20:40:00 GMT

So, my "daily" PowerShell tips haven't gone like I imagined. I have a list of topics to post. I just haven't had the time to type them all out. Either way, I'm still stuck on PowerShell. As a matter of fact, I just heard about a geeky website, Project Euler, which is dedicated to math and programming problems. When I first heard about it, I was thinking it sounded like a great way to hone your performance tuning skills. After trying the first problem, I'm not sure that's the case, but the problem was very simple. As a matter of fact, I solved it with a one-liner. If you're actually interested in solving it yourself, you may want to ignore this post. Then again, it's pretty simple.

I'll probably check out more of these. I'm not sure if I'll post the andwers or not, tho. Then again, as you progress, they get more and more complicated. If you're a sucker for pain, you can jump to one of the more complicated problems. I don't know how hard they'll be, but I'm sure it'll take longer than the 2 minutes this one took me.

Problem 1

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

My Solution

All I did was loop tthrough all numbers and added the number to a running tally if it was divisible by 3 or 5. Gee, that's pretty much what the problem statement was. Like I said, this one is pretty simple.

$sum = 0; ForEach-Object ($i in 3 .. 10) { if ((($i % 3) -eq 0) -or (($i % 5) -eq 0)) { $sum += $i } }; Write-Output $sum

What really surprised me was that this script ran from 3 to 1000 in 0.0156 seconds. I don't know what typical numbers are, but I was expecting it to take longer. For learning purposes, the aliases for ForEach-Object and Write-Output are foreach and echo.

Revisiting UpdateVersion

Michael Flanakin — Fri, 04 Apr 2008 11:51:00 GMT

It's amazing what sticks and what doesn't. Back in Aug 2004, I caught wind of UpdateVersion, a tool Matt Griffith wrote to update version numbers in AssemblyInfo files. The tool is pretty simplistic, but provides an absolute benefit. Every couple of months, I get asked for a copy of the changes I made... despite the fact that they've been available online for years. Nonetheless, it's about time I created a project on CodePlex for the utility. At this point, I don't really expect to make any changes to it, but I will if someone sees value in it. If I were to make any changes, I'd probably go ahead and convert it to .NET 3.5 and possibly even add a PowerShell cmdlet.

Adobe's Air Mistakes

Michael Flanakin — Tue, 01 Apr 2008 14:31:00 GMT

Air is Adobe's initial foray into desktop development. As you might imagine, Air is essentially Flash for the desktop. I'm not impressed at all. Air gives you 3 development options: Flash, Flex, or HTML.

Flash is primarily used by designers for ads, video playback, and small games -- notably, no "real" development. Seriously, what intelligent person is going to develop a significantly sized app with ActionScript?

Flex seems to be the preferred method for creating Flash and does so using a proprietary markup syntax. Flex still uses ActionScript, tho, which begs the question: who in their right mind would use this for anything more than a trivial app?

Finally, the HTML option gives us something feasible to work with. Here's a technology all web developers know and love... oh, wait... We don't love HTML. As a matter of fact, most devs I know have been complaining about it for the last 10 years. I've always been one to embrace JavaScript, but it's far from ideal. Actually, I think that's what most devs hate more than HTML. This is why there's controversy surrounding the EcmaScript standard update. All that aside, it's the only feasible platform for Air development, in my mind. Because of this, I think Air is flawed.

If I was Adobe, I'd latch onto a more powerful platform, like Java -- I'd say .NET, but we all know that won't happen. I don't see Air going too far due to the lack of strong underpinnings. Then again, I have been surprised at the apps that have picked up on it. Perhaps HTML support is more about migration strategy than a quality development platform. I'm definitely interested in seeing where this goes. With Silverlight 2.0 on its tails, Adobe is under the gun to make some serious movement in this arena.

Ruling the Business

Michael Flanakin — Thu, 27 Mar 2008 11:32:00 GMT

One trend I've noticed growing more and more is the use of rule engines within applications. More often than not, the rule engine is tied to a workflow engine, like WF or Biztalk. This makes a lot of sense because workflows are, by nature, rule-oriented. But why are workflow engines so special? Truth is, they aren't. For this reason, I'd like to see a managed rule engine built into .NET. This would allow everyday apps to take advantage of a standard, enterprise-scale rule engine with quality tools for developers and technical business analysts to manage rules without significant releases. I'm talking about something that's the equivalent of changing a column in the database, but with more structure and better performance. I envision rule libraries compiled into assemblies, which can be individually deployed. I like this because it's built on existing techniques and doesn't use reflection. I'm just throwing some ideas out, tho. There's obviously more thought that would need to go into this, but I'd be interested in seeing something to solve this pain for developers and the companies they work for. Too many people are building rules directly into the app, which requires a lot of overhead to tweak, test, and deploy rule changes. Having something a bit more dynamic that takes the developer out of the loop would be awesome.

VS 2008 and Legacy ASP

Michael Flanakin — Fri, 21 Mar 2008 11:08:00 GMT

While not my favorite code to maintain, I still have to deal with legacy ASP once in a while. One thing I've been happy about over the past 8 years is that I can still maintain this code in the same editor I've always used, Visual Studio. In fact, it's been nice getting teams to upgrade from Visual Interdev and Visual SourceSafe to Visual Studio 2005 and TFS. Unfortunately, legacy ASP is no longer supported in the latest incarnation of the IDE. I can't say I'm surprised, I guess. Microsoft likes to drop legacy technologies after about 8 years.

Google Chart API

Michael Flanakin — Thu, 28 Feb 2008 12:12:00 GMT

This is old news, but it's still worth mentioning. Google has always been known for its simplicity, which is one thing I wish Microsoft would learn, and the announcement they made back in December is no different. Surprisingly, I haven't seen much adoption of the service, but Google's new chart API looks pretty nice. The fact that you can build charts with relatively simple URLs is pretty nice. Admittedly, maximizing SQL Server Reporting Services is a much richer experience with much more options, but this API is still nice for smaller scale needs. If you haven't already, check it out. There are still some kinks that need to be worked out and parts that are harder to grasp than is really necessary, but they have made a huge improvement on something that just about every developer could use.

El Titulo en Español

En Español

Ésta es noticias viejas, pero vale el mencionar. Google se conoce para la simplicidad, cuál es algo yo desee que Microsoft aprendiera, y el anuncio que hicieron en Diciembre no es diferente. Asombrosamente, no veo mucho adopción del servicio, pero la nueva API de gráfico de Google parece bastante bueno. El hecho que crea gráficos con un URL simple es mucho bueno. Yo admito que SQL Server Reporting Services es una experiencia más rica con mucho más opciones, pero este API es bueno para las necesidades pequeñas. Si no tiene, lea sobre él. Todavía hay algunas torceduras que necesidad de ser fijado y piezas que son más duras de agarrar que realmente necesarias, pero tienen crear un servicio que es una mejora enorme que los todos desarrollos podría utilizar.

XNA Game Studio Announcements

Michael Flanakin — Thu, 21 Feb 2008 12:57:00 GMT

There are two significant gaming announcments that came out recently at the Game Developers' Conference (GDC) 2008. First, Xbox Live Community Games is the official release XNA Game Studio was intended for. Now, small-time game developers can play and share their games with others. This is pretty sweet for anyone interested in gaming, which is perhaps every developer at one point or another in their career. I know small-time gaming is what initially caught my interest.

The second announcement, made during the same keynote at GDC 2008, was that we'll be seeing games for the Zune in the future. What's nice is that the games will also be supported on first gen Zunes. Microsoft has been pretty good about supporting early adopters with respect to the Zune. I'm not sure how long that will last, but it's much appreciated... especially since I have 2 Zune 30s and don't feel like the second gen Zunes add enough to warrant an upgrade. I'll be looking at the third gen Zune for sure, tho. Microsoft stated that we'll see another release of XNA Game Studio to support the Zune in the spring. There haven't been many details about this admittedly early announcement, but I'm sure we'll hear more in the coming months.

One thing that gets me about this is the distribution model to be used for Zune. The fact that Microsoft has Windows Marketplace, Xbox Live Marketplace, and Zune Marketplace annoys the crap out of me. Microsoft needs to come out with a generic marketplace with "channels" specific to Windows, Xbox, and Zune. Sure, having something specific to your market is nice, but it just seems like overkill. The fact that each has its own purchasing model has to be even more frustrating to people who use more than one of these services. I guess I want something a little more integrated. That's not too much to ask for, is it? I'd like to see Zune games released or managed via Xbox Live Marketplace, but that probably won't happen, since they'll most likely be distributed via Zune Marketplace. Hopefully, this will drive the first integration between the two services.

Microsoft's Official Position on UML

Michael Flanakin — Wed, 06 Feb 2008 11:44:00 GMT

I made a few comments about Microsoft's work around MDA and how I don't quite understand Microsoft's official position on UML. David Cutler pointed out that I should take some initiative and dig around for some reasoning behind that. Well I did, and I found out that things are changing. Visual Studio "Rosario" will have a number of UML designers built on the DSL Tools designer framework. I'm very glad to hear this because I've been looking for them for quite a while and remember scoffing Microsoft for not investing more than a class diagram in Visual Studio 2005. I had hoped Visual Studio 2008 would have included some new designers, but alas, it didn't. The November 2007 CTP includes two new designers in Team Edition for Architects (Team Arch) and obviously the all-up Team Suite. I haven't used the new sequence or logical class designer, yet, but I'm definitely intrigued by them. I doubt the sequence diagram will be auto-generating at first, but you never know. Either way, I'm glad to see Microsoft is embracing UML more.

Of course, this doesn't answer the question of what Microsoft's official position on UML is. That's a hard one to answer, considering we're a company of individuals who have individual thoughts and ideals, just like any other company. Most of the people I talked to were the vocal few, but it's clear that UML isn't the unanimous terror that Microsoft seems to have made it out to be. I'm glad I'm not the only one to believe that. While I'm not making any anouncements today, I can say that we will get a clearer message of where Microsoft is going with respect to UML. As I understand it, there will be more designers on the books for the next CTP in the March/April time frame, so I think I can finally say we're on the right track. Better late than never, right?

Mix or SD West: The Decision

Michael Flanakin — Thu, 31 Jan 2008 11:32:00 GMT

In early December, I asked myself whether I'd rather go to Mix or SD West this year. I haven't been to either, but have wanted to go to Mix since its inception. After some thought, I've decided to go to SD West. The main reason for that is because I feel like it'll have better content given my focus. The first year of Mix was all about the web and the second year was a mixed designer+developer event, but still heavily rooted in the web world. I definitely feel at home with that mix, but things seem to be changing again. This year, it sounds like there's going to be even more focus on designer content, so I'll let Mix shake itself out one more year and check out SD West. I look forward to it.

Mix o SD West: La Decisión

En Español

En Diciembre, me pregunté si debo ir a Mix o SD West este año. No he estado a tampoco, pero tengo quise ir a Mix puesto que comenzó. Después de pensar en él, decidía ir a SD West. La razón principal es porque pienso tendrá mejor contenido, basado en mi foco. El primer año de Mix estaba todo sobre la web y el segundo año estaba un acontecimiento para los diseñadores y desarrolladores, pero todavía basado pesadamente en la web. Soy cómodo con los dos, pero el acontecimiento está cambiando otra vez. Este año, pienso que habrá más foco en contenido del diseñador. Dejaré Mix solidificar uno año más y iré al SD West.

What's Your IQ?

Michael Flanakin — Mon, 28 Jan 2008 12:48:00 GMT

I saw Simon Guest talk about user experience back in August and one of the things I liked was a tool he had to help decide what user interface platform was the best. Microsoft has 30-something user interface technologies. Sometimes it's hard to know which will be best. More often than not, we use the one the tech lead is the most comfortable with, which is pretty much a crap-shoot. Simon's app, UXIQ, asks 12 questions which you answer on a sliding scale. Ultimately, you're given three recommendations to decide on. I'll definitely keep this tool in my arsenal and suggest you do the same -- both the app and source are available on Simon's blog post.

¿Cuál es su Índice de Inteligencia?

En Español

Ví Simon Guest hablar sobre experiencia de usuario en este Agosto pasado y me gusta un aplicacion que ayuda decidir lo que plataforma de interfaz es el mejor. Microsoft tiene alrededor 30 tecnologías de interfaz. Es a veces duro saber cuál será el mejor. A menudo, usamos la tecnología el plomo técnico es la más cómoda con, cuál puede o no puede ser una buena opción. La aplicacion de Simon, UXIQ, pide 12 preguntas cuál usted contesta dentro de una gama. En última instancia, da tres recomendaciones de elegir de. Guardaré definitivamente esto y sugiero que usted haga iguales -- la aplicacion y el código son disponible en el poste de Simon.

WPF++

Michael Flanakin — Mon, 21 Jan 2008 14:17:00 GMT

I was just telling a co-worker how, despite the fact that it hasn't been said, I believe WPF will be the future of Windows development. This seems obvious, but my initial take on WPF was that it was merely another option. I even question a potential attempt to relace the myriad of web development technologies with a XAML development experience. I don't see this being overly successful, but the idea of a single development model intrigues me. If that were to happen today, it seems like XHTML + JavaScript would have more potential. Either way, I don't see it happening any time soon.

Whether or not we see a single language span Windows and web, it looks like we have something new to look forward to. Apparently, Microsoft is looking into yet another UI platform. I seriously question why, but welcome the change. I'd really like to know what WPF is missing that requires a new platform. At this point, tooling is my only real complaint about WPF.

WPF++

En Español

Yo decía a un amigo cómo pienso WPF será el futuro de desarrollo de Windows. Parece obvio, pero mi primera impresión fue que WPF era simplemente un otra opción. Dudo un intento substituir la miríada de las tecnologías de desarrollo de Web con XAML. Dudo que esto esto fuera acerto, pero la idea de un modelo desarrollo me intriga. Si ése era pasar hoy, parece XHTML y JavaScript tendría más potencial. Cualquier manera, dudo pasará pronto.

Independientemente de si vemos una lengua para Windows y Web, parece tenemos algo nuevo anticipar. Al parecer, Microsoft está investigando un otra platforma de UI. No sé por qué, pero abrazo un cambio. Quiero realmente saber que WPF falta que requiere una plantforma nueva. Las herramientas son mi solamente queja de WPF.

Are You Mobile OK?

Michael Flanakin — Fri, 18 Jan 2008 11:09:00 GMT

I'v been a mobility enthusiast for a while and it's nice to see others picking it up as well. I feel like the iPhone has a lot to do with that, which I find somewhat humoroous, but that's neither here nor there. Berners-Lee announced a new W3C validator, mobileOK, which checks web pages for standards-compliance and proven practices. This is definitely a step in the right direction. I'm looking forward to initiatives that'll bring the same capability to dev tools. Of course, it's the developers that need to change more than the tools.

¿Es Usted Válido Móvil?

En Español

He sido una entusiasta móvil durante algún tiempo y es bueno que otras están comenzando a covenir, también. Parece el iPhone tiene mucho hacer con eso, que pienso soy divertido, pero eso está ni aquí ni allí. Berners-Lee anunció un nuevo control de validación de W3C, mobileOK, que comprueba páginas web para compatibilidad con estándares y prácticas probadas. Éste es sin duda un paso en la dirección correcta. Anticipo alegre las iniciativas que traerán la misma características a las herramientas de desarrollo.

New Security Certification

Michael Flanakin — Wed, 16 Jan 2008 12:22:00 GMT

Looks like there's going to be a new certification by the SANS Software Security Institute on the market for those specializing in secure development. Honestly, its intended for -- and probably be obtained by -- all developers, but I don't see it playing out that way. My initial take on it was that it was a great idea, but after remembering the security exam I took for my MCSD, I'm wondering what the difference is going to be. Another thing I should mention is that there will be exams specific to most major platforms (i.e. .NET, Java, C/C++). So, my quandry only applies to the .NET world. This one seems much more structured and thorough than the MS exam, so I will say there's some good potential. Either way, it'll be interesting to see how it plays out.

Nueva Certificación Segura

En Español

Parece allí es una nueva certificación del SANS Software Security Institute para la gente que se especializa en el desarrollo segura. Esta es ha sido para y probablemente habrá obtenido por todos los desarrolladores, pero no pienso que sucederá esa manera. Mi primera impresión es que esta fue una gran idea, pero después de recordar el examen de la seguridad pasé por mi MCSD, pregunto lo que la diferencia sea. Una otra cosa debo mencionar es que habrá examenes especifico a la mayoría de las plataformas importantes (es decir .NET, Java, C/C++). Tan mi pregunta solamente aplica al mundo de .NET. Éste parece mucho estructurado y cuidadoso que la examen de Microsoft, tan hay un cierto buen potencial. Cualquier manera, será interesante ver lo que sucede.

Microsoft's MDA Foundations

Michael Flanakin — Tue, 08 Jan 2008 07:16:00 GMT

I don't know if I'll ever understand Microsoft's official position with respect to UML. Sure, the concept behind domain specific languages (DSLs) is sound, but is it truly necessary? I haven't seen any proof of that. Well, to be more specific, I should say I don't see a need for DSLs when it comes to software analisys and design -- UML has just about everything I've needed and extending it seems to be the logical answer. On the other hand, DSLs are absolutely fantastic for applications that can visualize their data. Honestly, I think more apps should consider DSLs, but when most developers either don't know or don't use software modelling tools, I have to say I'm not surprised. I, for one, have been meaning to dig into Microsoft's DSL Tools, but haven't had the time. One of these days, perhaps. Either way, this is the foundation for Microsoft's MDA approach... well, the development environment, at least. There's an interesting story there, but I'll blog about that later.

Fighting with Arguments

Michael Flanakin — Wed, 26 Dec 2007 22:37:00 GMT

Since I first had a chance to really get into it, PowerShell has been great. For the first time, I have a real issue, tho. PowerShell handles arguments differently than cmd.exe. Specifically, the difference is the colon (:). In cmd.exe, arguments are split by spaces; but in PowerShell, the colon translates into a new argument. For instance, myapp.exe -arg1 -arg2:abc translates to { "-arg1", "-arg2:abc" } in cmd.exe, but { "-arg1", "-arg2:", "abc" } in PowerShell. Sure, we can code around this; but why should we?

The Power to Esc[ape]

Michael Flanakin — Thu, 20 Dec 2007 14:52:00 GMT

Given my new venture, I have to complain about something... small tools/utilities that don't close when I hit Esc. Don't get me wrong, I'm not saying everything needs to close on Esc, but there is a lot that could. Take, for instance, the vast number of utility windows in Windows... wait, no, let me revise that... How about every control panel applet (or whatever you call them). Ok, sure, a lot of them are dialog-based and close as you'd expect when Esc is pressed. Let's look at the Windows Update window in Vista, tho. Since it's based on Windows Explorer, Esc doesn't close it. There's no OK/Cancel button; no buttons at all. So why would it hurt to support Esc? Perhaps this is simply an oversite, but it's one that way too common. I can name a dozen places like this in Windows, but I'll spare you the agony. Microsoft isn't the only culprit, tho. All I ask is that developers think about their users a little more. Is there any way you can shave one keystroke, one mouse move, or even a transition from the keyboard to the mouse. All these things add up to big points in the user experience arena.

Brief Intro to HTML 5

Michael Flanakin — Fri, 14 Dec 2007 12:16:00 GMT

To my surprise, HTML 5 has been in the works since 2004. While still 5 years late, in my mind, this just shows the ridiculous nature of these standards. I'm not saying all standards are this way... who am I kidding? I love the idea of having standards, but they take entirely too long to make it to the real world. It's like seeing a fantastic project in a research firm. It most likely resolves something you've been pained by for years, but you won't be able to benefit from that work for several more years, most likely. But, I digress... HTML 5 seems to have 3 main goals in mind: flexibility, interactivity, and interoperability.

When thinking about flexibility, HTML 4 gives us a lot. One of the problems HTML 5 seeks to attack is the lack of meaning to one of the most popular tags. No, not the <table>, which is used entirely too much; the <div> tag. Wondering what the problem is? So was I at first glance, but I think what the group is coming up with is better. There will be new tags to represent different sections of a web page. I liken this a lot to a newspaper or magazine, but it works fairly well for the web. The idea is, instead of creating <div> sections to correlate to your header, navigation, different sections and the footer, you'd use more descriptive tags (i.e. <header>, <nav>, <section>, and <footer>). Consider the following images. The first represents what you might do in HTML 4 and the second in HTML 5.

The markup would then look like this for HTML 5...

The first thing I thought was that this new model may not map 100% to all sites. Then I realized, they're just websites. You may not think about things as "articles," but that doesn't mean there isn't an equivalent in your context. There are, of course, more and more apps are moving to the web, so depending on how that happens, these may not work. I don't see this getting rid of the <div> tag, tho; merely offering something more specific to use, when applicable. Mixed with CSS, these new tags could be very nice.

There will also be better support for the head (<h#>) tags. Currently, most people use different tags at different levels and style them appropriately, so every <h1> looks the same, no matter what level they're at. With HTML 5, head tags will be more contextual, where different levels will be treated differently. Actually, I'm making an assumption here that probably isn't true at this time -- that CSS will know the difference between the different tags at different levels. CSS 2 most likely won't be able to, but hopefully CSS 3, whenever that's supposed to be out, will. Here's a block of HTML to portray the structure I'm referring to...

<section>
<h1>Level 1</h1>
<section>
    <h1>Level 2</h1>
    <section>
      <h1>Level 3</h1>
    </section>
</section>
</section>

My vision is that the 2nd and 3rd <h1> in this example would be treated as <h2> and <h3> tags today.

While the new tag structure is nice, it's more for designers than developers. The feature developers will be happy to see will be the additional interactivity support, which will require much less work and more compliance across the board. Given the rise of multimedia content online, native support for multimedia content via <video> and <audio> tags is one of these improvements. One of the things that aggravates me about the current talk of these tags is a controls attribute, which specifies whether to use the default or custom controls. This is an attribute with no value, which isn't XHTML compliant. I know HTML isn't XHTML, but it'd be nice if the damn standard would at least take a step in the right direction. The additional ="true" wouldn't polute the spec. Despite that, the tags look promising. With the ability to customize the UI and built-in support for common actions like play, pause, and setting the current play time, I think most people will be fairly happy. That's not it, tho, there will also be APIs to support 2D drawing, storage, offline capabilities, editing, drag & drop, messaging, and my favorite, back button management. I haven't seen much about these, but I'm very excited about storage, offline, and back button management capabilities. These are problems that plague web developers.

As for interoperability, HTML 5 will be represented by its structure, rather than syntax. The key benefit of this is that it allows better support for the two formats HTML documents support: HTML and XHTML. As I understand it, the dual support is to provide better backward compatibility support with HTML. I see this and think, "Then why the hell would I even use HTML?" Maybe it's just me, but I'd rather use the markup language that provides the most forward compatibility. XHTML also provides some integration with external XML formats. The argument for HTML seems to be all about supporting lazy designers/developers who feel burdoned by the enforced structure. To me, they just need to get over it. The lack of structure in HTML is one of the main reasons the language sucks so much and causes so many problems across browsers. You could probably liken this to the VB vs. C# wars that were kicked off 7 years ago. To me, forward compatibility is more important than backward compatibility (aka laziness ). Different strokes, I guess.

More Versioning BS

Michael Flanakin — Thu, 13 Dec 2007 01:26:00 GMT

It's been a while since I've complained about version numbers, but Rocky Lhotka's latest post about his versioning scheme for CSLA has sparked another bout. What Rocky is doing is retarded. He's dumbing down version numbers for those who fine versioning difficult. When .NET was first released, this is something I knew was coming. Look at Java, where developers deal with a dozen different frameworks and tools just to work on their project and guess what... they're all different version numbers! Hell, even the desktop and server frameworks are different. Ok, so the latter is a tad ridiculous, but the former makes complete sense. Every tool should have its own version number which accurately depicts its version. Major version numbers only change when there's a major change in the code -- typically a breaking change. Sure, this might include .NET 2.0 vs 3.0, but it doesn't have to. Don't blame Microsoft's stupid version numbers on yours. If your users don't understand proper versioning, why the hell are you listening to them!?

I still have to say .NET 3.0 isn't necessarily wrong. WPF was a major change that should've been introduced as a major upgrade. I'd say that all four parts of .NET 3.0 are major updates. The real problem I see with .NET 3.0 has nothing to do with the version number, but the lack of any other improvements, which would've further justified the version number. Honestly, I would've been fine with 2.1 or 3.0. The real butcher of a job Microsoft did on version numbers was 3.5. What the hell was that!? There were no, nor were there ever planned to be any intermediate versions. Again, I'd have been fine with 2.2 or 3.1, but 3.5 was just stupid. I had hoped this wouldn't turn out to be the next version, but no such luck.

On the lighter side of things, the big improvement for Silverlight will now be Silverlight 2.0. I imagine this had something to do with the .NET 3.x version issues. Either way, it's nice to see.

Mix or SD West?

Michael Flanakin — Tue, 04 Dec 2007 12:30:00 GMT

A few weeks ago, Mix 08 was announced. I started to check it out and contemplate how much I wanted to attend, since I missed the first one and decided to skip the last one and go to PDC instead... which was cancelled *grumble, grumble* Well, I'm not making that mistake this year. However, another conference I have an interest in attending just popped up: SD West 2008. At first, I was thinking how nice it'd be to check out both. Mix started out being a web developer conference, but has become more about user experience, which I have a great deal of interest in. SD West is an architecture forum. Unfortunately, I just found out they're both happening the same week. Decisions, decisions...

Given the fact that Mix has slightly moved away from the more technical developer content, I think I might opt for SD West. Of course, SD West has more non-Microsoft content I may not be interested in. I'd be lying if I said location doesn't matter. Mix is in Vegas, which is definitely fun; but SD West is in Santa Clara, which would be a first. I've been to San Fancisco, but that was quite a while ago. I'd like to get some feedback from someone who's been to both, but I guess I'll have to take a deeper look at the content of each to see which one would be more valuable.

Use Cases are Requirements

Michael Flanakin — Mon, 19 Nov 2007 23:08:00 GMT

In preparation for my cert upgrade -- did I mention how much I hate certs? -- I'm skimming thru some of the self-paced training books. For the most part, the books have all been decent. I'm not big on books, tho, so don't take my word for it. I do have one complaint, tho. I open the Designing and Developing Web-Based Applications Using Microsoft .NET Framework book and don't even get 10 pages in before I find a blatant fallacy. With the 5 names on the cover, I'm not sure who's to blame, but I'm inclined to put it on all of their shoulders, as co-authors. What's the problem? I quote, "Use cases and requirements are not the same thing." What!? You've gotta be kidding me, right? What is a use case if not a requirement? What, are shall statements the only way to define requirements? A use case is a requirement -- a functional requirement. Let me defer to Wikipedia: "A use case is a technique used in software and systems engineering to capture the functional requirements of a system."

The book continues by stating that "a use case is a Unified Modeling Language (UML) model meant to describe a set of user steps that accomplish a task." To clarify, a use case has nothing to do with UML. UML is simply a "language" used to visually explain a concept. While there is a use case diagram within UML, all that does is visually depict system use cases and their relationships with each other as well as system actors. You don't need a use case diagram to have a use case; it's just helpful when visualizing the aforementioned interdependencies. Perhaps more useful than the use case diagram, tho, is the activity diagram. An activity diagram visualizes the steps of the use case and, if desired, can also specify who performs those steps. I'd argue that having a visual representation can greatly simplify requirements for all parties involved. Despite the fact that these things might be helpful when documenting your use cases, they are not required. Back to the comment, tho, I will say the latter part is completely right.

I'm not sure how the authors came to these misguided conclusions. Honestly, I question how much they've even used use cases. The term "requirement" is so ambiguous, there's no way to say what does or doesn't qualify. As a matter of fact, any demand of a system can be considered a requirement. Some people may define a requirement as, "the system must have accept usernames of up to 20 characters," while others might define the requirement at a higher level by saying, "the system shall require users to login." Which is correct? Neither. Both. It's all about perception. Use cases are a bit more grounded in reality. A use case for this scenario would define the login process. Within the use case, each of these requirements would be listed to ensure developers know exactly what they are required to implement to satisfy user needs. This is the value of a good use case -- it defines the contract you, as a developer, are signing up for and will be tested against. In some cases, business rules will need to be extracted and referenced from multiple use cases. For instance, password complexity requirements might be managed separately for simplicity, manageability, or purely because they are used or referenced elsewhere.

While I'm on the details of business rules, another problem I had with this section of the book was that it suggested you should avoid adding too much detail to use cases. While I completely agree, the tone of the section gave me the impression the authors were suggesting you avoid most detail. Granted, I may have received the wrong impression, but either way, it didn't do use cases justice. I'd argue use cases should be detailed to whatever level is required to explicate user needs for developers. Use cases should never describe the implementation -- well, unless there are specific implementation details that must be adhered to; however, even then I'd be hesitant to do so. I'd rather leave implementation constraints for the architecture document; but I digress. The level of detail you add to your use cases is going to depend very heavily on the team you're working with and the relationships of team members; especially, those between the business analysts and development staff.

I could go on about this, but I think I've said enough. I'm astounded at how many people don't get requirements, but then again, after working with so many people and projects, I shouldn't be. I am by no means an expert, but I could definitely teach these authors a thing or two about requirements management. Whatever you do, please avoid these discussions in these books and perhaps any other books on the subject by the authors in question.

.NET-Java Interop via JMS and WCF/BizTalk

Michael Flanakin — Sat, 17 Nov 2007 02:39:00 GMT

Well, there's one more way to connect Java and .NET systems, now: Java Message Service (JMS). For the uninitiated, JMS is similar to Windows Communication Foundation (WCF) on the .NET side only not quite as simple to implement or complex in its operation. JMS did come first, however, and was undoubtedly reviewed during the initial design phases for WCF. Either way, JNBridge has built JMS adapters to communicate with .NET and with BizTalk. As a matter of fact, the .NET adapter was built with WCF, which should work very well with .NET apps willing to upgrade to .NET 3.0. It'll also be good when BizTalk finally makes use of .NET 3.0. I haven't heard anything definite, but I'm assuming that'll be in the next major release. That release should also include support for Windows Workflow Foundation (WF).

File Names for Generic Classes

Michael Flanakin — Mon, 12 Nov 2007 12:34:00 GMT

I'm pretty big on the practice of naming a file after the class it contains. And, yes, I follow the one class per file practice. Ever since .NET 2.0, tho, generics have thrown a kink in the system. We can't have file names with angle brackets (< and >). So, what is the best practice for naming generic class files? Java has the same problem -- perhaps more so since their file names have to be the same as their classes (a restriction I wish .NET had). I haven't touched Java since before generics were introduced, so I'm not sure how it implements that. I'd be interested in seeing, tho. I may have to give that a look at some point. Until then, I started using brackets ([ and ]) to represent generic class file names. For instance, I created a model-view-presenter (MVP) class that extends Control with a signature of Control<TView,TPresenter> and a filename of Control[TView,TPresenter]. That works, of course, but I'm wondering if there's a better way.

On a side, but perhaps related note, GhostDoc will document a generic class/member by HTML encoding the angle brackets; however, Resharper replaces them with curly braces ({ and }). I'm curious as to which is the "right" approach. If it's the latter or both, I might opt to name files with curly braces rather than brackets.

TFS Offline Capabilities

Michael Flanakin — Mon, 12 Nov 2007 11:48:00 GMT

I love TFS for everything it provides, but one of my top aggravations is its horrible support for disconnected users *grumble, grumble* Subversion was better *grumble, grumble* I saw something that made me put 2 and 2 together, tho. Will TFS be introducing better disconnected support a la Microsoft Sync Framework? It's too late to tie this into the TFS 2008 release, which is coming out at the end of November, so I'd say we should definitely see something in Visual Studio "Rosario," which I'm expecting to see in early 2009, at the latest. Of course, this is something I imagine they'll want to get out to people a lot sooner, so I'm actually leaning more towards the possibility of a power tool. The TFS team has done a good job of getting power tools out. It'll be very nice to have the current tools integrated into the core platform, but I still look forward to what else is coming down the road. I don't know about you, but I'm keeping my fingers crossed on this one. Despite the fact that I think this was a horrible oversight on the TFS team's behalf, better late than never.

Microsoft Gunning for Google Gears?

Michael Flanakin — Thu, 08 Nov 2007 16:02:00 GMT

Microsoft recently announced the Microsoft Sync Framework, which keeps disconnected users connected. Those familiar with it might wonder how this relates to Google Gears. There is a key difference, however; Gears is a browser plug-in, while the Sync Framework is, well, a framework. Don't get me wrong, this is a step in the right direction, but Google definitely showed Microsoft up on this one. I imagine we might see something from Microsoft in the way of a browser plug-in, but that's not Microsoft's typical style. Actually, I'd put my money on sync integration built into Silverlight 1.1. Coding in .NET and built-in sync? Silverlight's sounding better and better. Eat your heart out Flash.

Enhancing Concurrency Development Models

Michael Flanakin — Wed, 31 Oct 2007 02:27:00 GMT

Looks like C++ will be seeing an upgrade in the coming years. Seeing as tho I don't use C++, I was about to brush this aside. Then, I started to get curious about the changes. In what has been dubbed C++ 0x, there will be changes to remove errors and inconsistencies, add garbage collection, and support for concurrency and multithreading. While the former two sound like big wins for the C++ community, the last one triggered something. Anyone can tell you the only constant is change, but looking at where hardware is moving and today's limitations in programming, it's become apparent current approaches to multi-threading need to be revised. Of course, this leaves us with the all too often asked, "how can we improve this?" Honestly, the change in C++ is just about promoting features from system-specific libraries to the core language, so there's nothing revolutionary going on. I want more. We now have Linq; I want Lint -- languge integrated threading. I don't really know what this means, yet, but the idea just sounds right. I want the compiler and/or run-time to make some decisions about how to manage threading code blocks or method calls. Attributes are a gimme to identify methods to thread, but I feel like there's so much more we can do. Forcing someone to create a method to contain threaded code may not be all too bad of an idea. I guess what I'm thinking of would include a thread{} block with some sort of eventing mechanism. Perhaps something like thread (ThreadArgs t = new ThreadArgs()) {...}. Like standard event handlers, the ThreadArgs class would be extended for special scenarios. The key to this class would be its built-in eventing structure and thread processing instructions. The framework would know how to manage the thread based on a ThreadHandler<ThreadArgs> instance. Factory and provider patterns jump out at me here, but I'd have to put more thought into it to determine what would be the most beneficial. The heart of the idea is that threading patterns would be programmed into handlers or providers, which would provide an extensible way to enable .NET to manage threads without forcing the developer to wrap his/her head around how it will work.

As nice as something like this may sound in my head, I don't think the full capabilities are coming out in my explanation. The real value lies within the ability to describe how a thread should execute in the ThreadArgs and the robustness of the handler to be able to execute that. This is still only half of the equation, tho. The compiler needs to be smart enough to detect common pitfalls, like deadlocks. This is obviously the harder problem to attack. Tooling also comes into play, when looking at how to avoid these problems.

All this is pretty half-baked, tho. In truth, someone a lot more threading savvy than I needs to look at this. I have no doubts that is going on, tho. I'd be interested in seeing what comes out of it all. I'm betting we'll see improvements inn .NET 4.0. Not that any such release has been discussed, but I suspect we'll start hearing feature news by mid-2008 and see a release in 2009 with the next OS release. Again, I know nothing. I'm merely making wild speculations.

Why Shelving is Better in Subversion

Michael Flanakin — Tue, 23 Oct 2007 14:00:00 GMT

Shelving was a heavily touted feature for TFS when it was first released in early 2006. Microsoft seemed to try to sell it as a new concept, but I argued it was simply an adjustment to an old concept: branching. I will say it's probably a good thing Microsoft put so much into selling the idea. Without it, I don't think most developers would know about such a capability. Then again, there seem to be a lot of developers who still don't know about it. Anyway, back to my point... After playing with shelving in TFS, I'm getting mildly annoyed with it. I guess the reason I say that is because I want it to be treated more like a branch. I believe in the concept of committing logical changesets, meaning I make small changes and commit them individually. Perhaps I take this to an extreme, but I want each change to be tracked independent of any others. When I shelf code, it's usually a sizable change. I'd like to be able to shelf the first change and then incrementally update the shelf with my changes as I go along. I'd also like the ability for others to commit to my shelves, which speaks to the collaborative nature of shelves. This is all a given when you use Svn shelving (aka branching); I just wish TFS was up to it.

Difference Between Use Cases and Scenarios

Michael Flanakin — Mon, 22 Oct 2007 21:08:00 GMT

Scott Sehlhorst does a good job of discussing the difference between use cases and scenarios. I think this is important for those following the Microsoft Solutions Framework (MSF), which uses scenarios. Personally, I think scenarios are too specific and don't offer the amount of flexibility you need to make your requirements easy to manage. One of the nice things about use cases is you can make them as fine- or course-grained as you want. To sum up what Scott says, a scenario is a single run thru a use case. So, while a use case may have several alternate flows, only one of those flows, from end-to-end, would make up a scenario. Pretty simple, but I feel it's an important fact to acknowledge.

A Bug's Life

Michael Flanakin — Tue, 16 Oct 2007 00:25:00 GMT

I've used about half a dozen or so bug and issue tracking systems over the years and, with that, have come to favor specific setups. The main configuration I'm referring to includes work item status, resolution, priority, and severity. When I first dug into TFS, this was something I looked at and didn't like all that much. With the ability to customize work item templates, tho, I wasn't too concerned. Given that not too many people who work with TFS seem to have much experience with other, more mature bug tracking systems, I figured I'd share my thoughts.

Work item status in TFS is limited to active, resolved, and closed, by default. Without some sort of reason or sub-state, this just isn't enough. I want to say sub-states are probably how most people get around this, but I'd argue that full states are better. This is obviously an individual preference, tho, and only really comes into play when you look at reporting. The statuses I prefer are as follows: unconfirmed, new, assigned, in progress, awaiting info, reopened, resolved, verified, and closed. As with the rest of what I'll cover, anyone with Bugzilla experience will recognize some of these values. Bugs are created as "unconfirmed" and are moved to the "new" status after being triaged. By default, TFS includes a triage property, but I feel this is better covered by status. Again, just my opinion and it comes more into play with reporting. I prefer bugs to remain unassigned by default and then have the status changed to "assigned" when it's actually been assigned to someone. "In progress" and "awaiting info" are gimmes. Once completed, the bug should change from "in progress" to "resolved." When this happens, a resolution needs to be specified to indicate what actually happened. Resolutions are pretty standard: fixed, invalid, won't fix, duplicate, unable to reproduce. I'm thinking there are more resolutions, but this is all I can think of off the top of my head. Once tested, the bug is changed to the "verified" state and ultimately to "closed" once it has been deployed.

Priority and severity go hand-in-hand. All-too-often, I see teams trying to calculate what bugs should be in a certain release by priority alone. While this is a great start, I don't think it's the only factor. Let's just start with priorities, tho. Personally, I like to have at least 5 priorities because it gives you a bit more flexibility than 3 or 4, which seems to be fairly common. That's just a start, tho. I had a conversation with a co-worker, Allan Askar, last week about putting some meaning behind these numbers. We haven't put this to use, but I'm pretty confident that it should make prioritizations across the team much clearer. The key here is that priority is based on the iteration a work item is assigned to. If not assigned to a specific iteration, the work item's priority indicates when the work item should be implemented: 1's in 2 weeks, 2's in a month, 3's in 2 months, 4's in 4 months, and 5's in 6 months. The idea is every wok item would be assigned to the backlog and given a priority based on its importance at that time. During release planning, every item on the backlog would be evaluated to update it's priority and determine whether it should be included in the upcoming release. If an item is included in the release, then priority loses its time-based meaning and picks up a relative priority that simply indicates what order it should be worked on, as you would typically expect. In smaller chunks, we felt the abstract nature of relative priority was adequate; however, a larger group, like the backlog needs more meaning and should work much better. I guess we'll see how that works for us. Obviously, any time frames could work. We just chose some that seem to be somewhat typical on our current project.

Lastly, severity is what brought me into this whole thing. Originally, severity was all about workarounds (on this project). I never felt comfortable with this, so I suggested the following: critical, major, normal, minor, trivial, and enhancement. My guess is that most people are fine with this until they hit "enhancement." To most, a bug is a bug and an enhancement is something completely different. I disagree. I see a "bugs" as code-changing tasks that require testing. This includes simple refactoring changes. Why? Because they have to be regression tested to ensure everything works as expected. If this is skipped, you're risking breaking the app. Seriously, how many times have you saved something without checking it only to find out it either doesn't build or simply breaks logic? Yeah, I thought so. If that's not enough of a reason, then I'll stick to something everyone likes: simplicity. Bugs and enhancements are the same for the most part. Separating them just overcomplicates reporting and tracking.

I should probably modify the default bug and task templates to add some of these things in. Severity probably only works with bugs, but the status and priority concepts are arguably the same.

Defining Your Requirements

Michael Flanakin — Fri, 12 Oct 2007 21:16:00 GMT

In the past, I've put a lot of effort into defining all or at least the majority of a given system's requirements up-front. The reason for this is because I've worked in fairly process-heavy environments. While I continue to see the value of this effort, it simply isn't feasible in most environments. Actually, I beg the question: is it feasible in any environment? Most developers find the requirements definition process a pain and question its value; however, experienced engineers recognize the value and strive to find a way to work it into the software engineering process. Unfortunately, this doesn't happen enough. For most small systems, this may not pose an issue; however, once these systems grow to a significant team size or fall victim to enough attrition, new team members start to feel the pain of this missing documentation. New team members aren't the only ones who feel the pain of limited documentation. As anyone who's witnessed one of the many failed contracting efforts in the software or construction industry can attest to, faulty requirements definition can be the death of any project. For this reason, I hope more developers will find the value of requirements and seek to develop them for their own projects. What is the right way, tho? How should we solidify the abstract thoughts that form the projects we engage in? Tyner Blain does a good job of describing an agile approach to requirements definition. I hope more take this to heart. Due to a change in scenery over the past year, agility has been more important than process. The change in viewpoint has been interesting and ultimately driven me to the same opinion Tyner has, where a full definition is desired, but is easier to swallow one bite at a time.

Extension Methods

Michael Flanakin — Wed, 10 Oct 2007 22:02:00 GMT

Karl Seguin talks about extension methods , which are part of the next release of both C# and VB; specifically he suggests avoiding them. He quotes the C# documentation by stating...

"Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible."

This is pretty much the impression I've had about them since I first saw them. I love the idea of having them, but all it really gives us is a new way to call our existing functionality. When you think about it this way, it seems pretty useless; especially when you consider the fact that it comes with some baggage. I can see developers getting confused when they see an extension method used in one project, but can't seem to find the same method when on a different project. The problem here is that simply looking at a code snippet doesn't clue you in on the fact that a method is an extension method. For this, you'll have to at least hover over the method and gleam that knowledge out of the tooltip or intellisense. Based on this, I'd tend to agree with Karl and say extension methods should be avoided; then again...

Karl claims he can't think of a potential use of extension methods, but I have two that I've thought about a few times. The first, which was the very first thing that hit me after being introduced to extension methods, is extending .NET. If you can't imagine that, let me introduce you to the universal problem that is the string. .NET 2.0 brought us String.IsNullOrEmpty(), but that's not enough. Why not? Because I need something that also checks for whitespace. Essentially, what I'd like is a String.IsBlank() method. Pretty simple, but very useful.

public static class StringUtil
{
    public static bool IsBlank(this string value)
    {
        return (value == null || value.Trim().Length == 0);
    }
}

Which would you rather see: StringUtil.IsBlank(username) or username.IsBlank()? Personally, I like the latter. The alternative is extending the class in question, but for something like String, which is so ubiquitous, that's not a serious option.

Want another example? I'll give you two, both of which relate to domain objects. Domain objects, as opposed to business objects, hold state and only state. You don't see any actionable methods on a good domain object. Typically, these objects are used to pass state between different systems or even throughout a single system. Business logic doesn't need to be everywhere, so a pure, state-based object is often the answer. Of course, some people like methods off of their state-based objects. Extension methods can give us the best of both worlds -- the simplicity of a condensed logical structure and the flexibility of a layered architecture. The first example I'll show is with validation.

public class IForm { ... }
public class BasicForm : IForm { ... }
public class AdvancedForm : IForm { ... }

public static class FormValidator
{
public static bool IsValid(this BasicForm form) { ... }
public static bool IsValid(this AdvancedForm form) { ... }
}

As you can probably gather, this will add an IsValid() method to the two concrete IForm implementations. Sure, we could simply call FormValidator.IsValid(), but that's just not as clean. Still not seeing it? Let me add something else to the story...

public static class FormDelegate
{
    public static void Create(IForm form) { ... }
    public static void Update(IForm form) { ... }
    public static void Save(this IForm form)
    {
        if (form.IsNew)
            Create(form);
        else
            Update(form);
    }
}

If you're not seeing the value of separating logic from state, you're just not going to get this at all. I could go into my reasoning behind some of the decisions I made in these implementations, but I'll save those for another day. For now, let me just finish up my code sample with the code you'll actually be using. Oh, and by the way, I prefer create/read/update/delete (CRUD) method names, but "save" comes with a graceful simplicity. I go back and forth, but seeing as tho this is about simplicity, "save" makes more sense.

IForm form = FormFactory.Create(...);
...
if (form.IsValid())
form.Save();

This pretty much saves you from having to use the more verbose...

if (FormValidator.IsValid(form))
FormDelegate.Save(form);

And that's it. I love the idea... as if you couldn't tell. I do think the practice should be somewhat limited, however. And I don't know whether or not I'd do this in my projects. I merely thought about the ability to do this when I read Karl's post. I'd be interested in seeing how others might take advantage of the feature.

Silverlight vs. .NET 3.0 vs. Flash/Flex

Michael Flanakin — Mon, 17 Sep 2007 18:33:00 GMT

I just came across Loke Uei Tan's comparison of Silverlight, .NET 3.0, and Flash/Flex . I don't think .NET 3.0 or, more specifically, WPF should be included in this comparison, but whatever. I guess it does come into play if you're truly looking at a user experience decision, as opposed to a rich web interface decision. Then again, you can use WPF in the web, but that's Windows only, so I usually poo-poo that idea. But, I digress... I also noticed 3d capabilities weren't mentioned. I know WPF does support 3d and Silverlight doesn't, but I don't know about Flash/Flex. If I had to guess, I'd say it doesn't; otherwise, I imagine it would be a highly touted feature. Of course, this isn't a huge deal if you're willing to do the math yourself. Having the feature is more about easing development. I'm curious what else was missed, but this is at least a good place to start. I'm surprised to see Flex missing so much, but knowing Adobe, I probably shouldn't be. Either way, I don't see Flex doing much for the Flash market . Adobe needed to bring Flash to applications, but that just never happened on a large scale. With integration into .NET, Silverlight will be an obvious answer for most developers.

Silverlight on Linux

Michael Flanakin — Wed, 05 Sep 2007 17:39:00 GMT

In a somewhat interesting turn of events, Microsoft has officially launched Silverlight 1.0 with support for Linux. Don't get me wrong, I'm not saying I expected Linux to be left out forever, but I didn't expect it this soon. Good stuff! What I really thought was newsworthy about this, tho, wasn't that it happened, but that it happened in collaboration with Novell . Not sure if this has anything with the much-debated Microsoft-Novell deal, but I kind of doubt it. I get the impression this is more about Microsoft wanting to provide Linux support and the Mono team already having an implementation . I do wonder how long this collaboration will hold, tho. Not because of either party's interest in that collaboration, but because of the .NET support in Silverlight 1.1. If the collaboration would continue, I can see this growing and possibly even expanding into cross-platform .NET, the exact Mono was created. This wouldn't be the first time Microsoft stepped on its partners. Of course, Miguel de Icaza has mentioned that he'd be happy to see Microsoft pick up .NET on Linux. I don't know how this would go over in the community, tho. Those on the Windows side looking for cross-platform solutions would love it, but those on the Linux side might see it as an anti-competitive strategy. Of course, those who do think that will most likely be the zealots who think anything coming out of Redmond is pure, unadulterated evil. Unfortunately, that would never change.

Is Web 2.0 Coming to an End?

Michael Flanakin — Mon, 27 Aug 2007 16:26:00 GMT

Jim Rapoza mentions something that should probably be in the back of all our minds: the probability of the Web 2.0 bubble burst . He mentions a few well thought-out observations about previous bubbles. I, for one, am looking forward to this burst. Part of my reasoning behind that is the fact that, at its peak, the bubble becomes more about marketing than the elegance of the technology in question. After a burst, things even out and it's back to business as usual, except we then have a technology we can implement without the overzealous polluting the waters... well, at least not as many of them. Beyond all of this, tho, I'm excited about the potential of Web 2.0 getting back to it's roots. Too many people think Web 2.0 is about a dynamic, AJAX experience when, in fact, it's about a more consumable, "semantic" experience. The closest we've been to this original dream is the abundance of service-orientation around technologies such as RSS and Atom. You'll see this in intriguing mash-ups such as those created from services like Pipes and Popfly. One of those recent mashups centered around the Windows Live family of services is Tafiti, a Silverlight-based search utility.

This burst couldn't come any sooner, but I'm afraid we probably have a bit longer to deal with this bubble. While the burst is inevitable, I don't expect to see a significant change until late 2008. Of course, by that time, we'll be seeing the beginnings of the next big thing. I just wonder what that will be...

.NET-Cold Fusion Interop

Michael Flanakin — Tue, 14 Aug 2007 21:09:00 GMT

A friend just asked me about the integration story between .NET and Cold Fusion the other day. It figures something like this would come out, but apparently Adobe is looking to enhance CF8 with the ability to access .NET objects. Back in the Macromedia days, this level of integration with Java was already added. Seeing the sharp decline of Java in the enterprise, it's no wonder Adobe's making this move. My only question is, how does this relate to the Dynamic Language Runtime (DLR)? I remember hearing something about Cold Fusion support when the DLR finally gets released, but I haven't followed it that much. It's probably no surprise, but I'm not a fan of dynamic languages. I'm sure I'll get flamed for this, but it seems more like a lazy wo/man's language. Beyond that, there ~~seems~~ is a greater potential for buggy software. I just don't understand the selling point. To each his/her own, tho. That's why .NET is so great -- we can make these language choices on our own, yet still integrate with the rest of the platform.

TFS 2008 Final Feature List

Michael Flanakin — Wed, 08 Aug 2007 18:09:00 GMT

If you've been wondering what'll be in the next release of Team Foundation Server, Brian Harry's done a great job of summing up the final feature list for TFS 2008 in a fairly concise list of bullets. Brian's been doing an outstanding job of evangelizing TFS both internally and externally. If you're interested in its future, this is definately a man to watch!

Programmer Personality

Michael Flanakin — Fri, 15 Jun 2007 11:19:00 GMT

I'm such a sucker for these personality type tests. After seeing Chris Sells' post on his programmer personality type , I had to give it a spin...

Your programmer personality type is:
DHSB

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.

You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We're not writing on paper anymore so we can take up as much room as we need.

Of course, with every one of these tests, I always want to have another option. They never truly give you enough answers. Then again, nobody ever said they were scientific.

Windows Sidebar Gadget Development Resources

Michael Flanakin — Mon, 28 May 2007 16:53:00 GMT

Someone recently asked about Sidebar gadget development resources and I wanted to share the links that came out of it. Now, I haven't used all of these, so I can't speak to their value; but without further ado...

Windows Vista Sidebar downloads
Windows Live Gallery Developer Center
Sidebar Gadgets on CodeProject.com
Gadget Development Overview on MicrosoftGadgets.com (from Vista Beta 2)
Creating Gadgets Pt 1 on TechNet (I have no idea where pt 2 is)
Sidebar Gadgets Pt1 and Pt 2 by Tim Heur
Sidebar Gadget Manifest on MSDN
Gadget Development Overview on MSDN
Gadget Corner (official Sidebar team blog)
Sidebar Gadget Forum
Vista Sidebar Forum on JoeJoe.org

Making Sense of Mix '07 Announcements

Michael Flanakin — Tue, 01 May 2007 10:58:00 GMT

Well, I was off on my guesses (1 , 2 ) at what was going to be announced at Mix '07 . In the same breath, I'm kind of disappointed. Here's what I've seen...

Astoria is a new project to provide a service-based view of data over HTTP using XML and JavaScript Object Notation (JSON) . This is definitely a good thing, don't get me wrong, but not really a big surprise. If you ask me, this is just another part of the overall Windows Communication Foundation (WCF) vision.

Jasper is another new project , announced by the ADO.NET team , which aims to simplify application development by providing a built-in data layer. Granted, I haven't seen anything about this, but I severely question it. Sure, it'll be better than what most people are doing, but is it enough? I can't say for sure without digging into it; but I'd look at it pretty hard before assuming it is. I like to have a lot of control over my applications, so building a data layer is just worth it, for me. I'm fine with the additional time it takes, which isn't all that much in my opinion, because it allows me to customize it to meet project-specific needs easily. This is by far the most flexible way to go. Of course, the problem is the amount of time it takes. Like I said, we'll have to see. I'm interested, but skeptical.

Apparently there's an early edition of Blend 2 available which supports Silverlight. This was an obvious progression, but I didn't expect it to happen this quickly. Heck, I didn't even know Blend 1 was released... ~~oh, wait, it hasn't!?~~ While completely understandable, it's kind of an odd move. Let's face it. Will you buy Blend knowing Blend 2 is on its heels? I'm sure there will be some sort of promotion for all Blend 1 owners; but that hasn't been announced, yet. I just hope it's better than the typical upgrade cost. In the end, I'm thinking this is probably going to be more of a 1.1 release than a 2.0 release, but a necessary one nonetheless. My hopes are that they'll go for a small upgrade fee of $23 or so, like they did for the VS 2002 to 2003 upgrade. Only time will tell.

Dynamic language support has been made official; but again, expected. I will say I didn't expect this to be a separate runtime environment, but I can imagine there might be some technical issues limiting the dynamic nature on top of the CLR. I'm interested to see how these two ciblings grow up together. In the same breath, I'm curious as to the number of different versions of .NET and the CLR. We're quickly approaching half a dozen, if not more.

While I was thinking Silverlight itself could be the "big announcement," it wasn't. I wasn't too far off tho. Three Silverlight announcements came out: (1) Silverlight will support .NET on all it's supported clients, most notably including non-IE browsers and Mac; (2) there's already an alpha release for this; and, (3) Windows Live has a new Silverlight Streaming service to give you 4GB of streaming content. Ok, this last one is definitely a marketing move, but one you can benefit from, if you have content to push. But I do have to touch on the fact that, before Silverlight 1.0 is out, we've got preview bits for a follow-on release. This is unheard of. I don't think I ever remember seeing this happen with any other companies. Not that I'm saying Microsoft is a great company simply because of this, but I do think it's a strong testament to the direction the company wants to move in. This will be very interesting in the coming year as Silverlight starts to push into the Flash space. Then again, Flash has only pierced a niche market. I'm very confident that Silverlight will surpass that small portion and make it into the true web application space. Heck, I'm already seeing viable options for Silverlight in a number of apps I'm privvy to.

So, the Silverlight on Mac announcement was probably one of the most surprising to people, as it seems. When a friend first said, "CLR will be supported on multiple OSes," I got very excited. Then, when he clarified that it was within Silverlight, I just responded, "Oh. I already knew that." I mean, seriously, wasn't that known? Maybe I just assumed it. I'm not trying to take away from it; I definitely think it's a fantastic progression. I just expected this. Nonetheless, there was some good stuff that came out of Mix. I ultimately decided against going this year, but I may have to rethink that for next year.

Expression Tools on MSDN

Michael Flanakin — Wed, 04 Apr 2007 02:16:00 GMT

I called it! The Expression tools will be available on MSDN . I figured this was an easy one to guess, seeing as tho the Expression suite is Microsoft's first attempt at design tools. I have to say that I'm not impressed, but I have faith that future releases will be much better. I still want to play with them more, but just haven't had much time. Nonetheless, I think their availability on MSDN will make them much more likely to be adopted. The only thing I'm wondering now is, what will the big announcement at Mix '07 be? Hmm... There are still a number of things I can think of, but my curiosity is even more piqued given this turn of events.

Announcement at Mix '07

Michael Flanakin — Thu, 29 Mar 2007 11:20:00 GMT

Everyone who knows about Mix '07 most likely knows that we're expecting a big announcement. I have to admit that I don't know what it is, but I have a couple of guesses. If I had to pick one, I'd have to say it'll be the announcement that the Expression tools will be available on MSDN. This has been a complaint I've heard from countless sources and, I honestly don't think Microsoft will drive too much adoption without this. I understand Microsoft's logic behind not putting the tools on MSDN, but I think it makes more sense to put it there.

I will say some of the talk I've heard leads me to believe my guess isn't big enough of an announcement. Trying to think of what else might be on the horizon is kind of hard, tho, seeing how open Microsoft is. Perhaps the biggest announcement I could see would be the release of Visual Studio codename "Orcas". In the same breath, I don't see this being released at a mixed developer/designer event; especially considering this event has a lot of designer-friendly content. With that, I'm left with the announcement of WPF/e and/or a friendly WPF/e design/development tool. If that's it, all I can say is I hope they come up with a nice, "cool" product name. I wish they'd just fall back on the codename, Sparkle. Beyond these ideas, I can come up with a few small possibilities, but nothing that is too big of a deal. I ultimately decided to skip out on this conference, so I won't be there to get the announcement, but I'm excited to find out what it is.

Shall Statements are the Devil

Michael Flanakin — Mon, 26 Mar 2007 23:11:00 GMT

I read a post about requirements and there was a brief mention of using shall statements to manage requirements. I have to say I absolutely abhor shall statements. If you ask me, a use case represents a functional requirement. A shall statement just doesn't cut it. Every time I see a shall statement, I just shake my head in disappointment. Luckily, it's been pretty easy to get people to switch sides in the past. I just don't understand why people still use shall statements today, tho. Bleh...

document.createElement() in IE

Michael Flanakin — Sun, 11 Mar 2007 21:07:00 GMT

I just ran into a very annoying bug in IE7. This may be a known issue, but it's the first time I've run into it. I added some JavaScript to dynamically add a <link> tag to a page. When adding a known element using document.createElement(), IE creates a non-XHTML-compliant element -- the tag name is uppercase, not all attribute values are surrounded by quotes, and the element isn't closed. This might be ok in some situations, but it's obviously not kosher when you're using XHTML.

var h = document.getElementsByTagName('head')[0];
if (!h) return;
var l = document.createElement('link');
l.rel = 'stylesheet';
l.type = 'text/css';
l.href = 'my.css';
h.appendChild(t);

I haven't found a way around this, yet, but hopefully I will later. For the time-being, I'm gonna set this one aside. If anyone knows of a work-around, I'd love to hear it.

Virtual Earth (Live Maps) Simplicity

Michael Flanakin — Fri, 09 Mar 2007 21:18:00 GMT

I've been meaning to post about my great experience with the Virtual Earth SDK, so I guess I'll take this opportunity to share something that came up recently. A question came across one of the internal email groups asking whether or not Live Maps supports specifying lattitude/longitude . While I can't say whether or not the official Live Maps site can take this input, I do know from experience that the Virtual Earth platform definitely supports it. The code for this is very simple, too. It's all JavaScript, which can be good or bad, depending on your point of view. Here's a truncated code snippet of what you'll need...

All of this is documented on the Virtual Earth interactive SDK, so have fun with it. After seeing this, I was very excited at what was available to me. I'd love to get this tied into an application someday, but just haven't had the opportunity, yet. Maybe one day...

Application- vs. Database-Driven Design

Michael Flanakin — Mon, 26 Feb 2007 21:26:00 GMT

With all the good and bad that goes with it, I focus a lot on the design of the applications and application components I work on. This, in part, stems from my appreciation for both the art and science of software development, which is a topic I've been meaning to post about for some time. Since I put a strong emphasis on architecture and design and I'm usually supporting other people's projects, I tend see a lot of different design approaches. Most of these approaches have been centered around the database, which I think is inappropriate for most systems. What I mean by this is that the developers start with a relational database structure and design their domain objects and business services around that. This is typically done by developers who either don't have a lot of design experience or have a strong background in database development. While I admit that every approach has its pros and cons and every project has its priorities, I typically try to focus developers on the application first, whether or not a data store already exists. I've seen bad data structures drive the application's design too many times. I actually discussed this with a coworker a few days ago and we both agreed that most applications should focus on the domain model and core business services during design rather than developing them from a pre-existing data model. Jeremy Miller talks about this in a recent post, Don't Let the Database Dictate your Object Model . I'm glad to see others professing this practice because I think it's very important and not enough people take it into consideration. All too often, database-driven application designs force unnecessary constraints on the system, limiting innovation, growth, and extensibility.

Is it Really Consulting that Needs to Change?

Michael Flanakin — Fri, 16 Feb 2007 16:19:00 GMT

Eric Wise recently posted his complaints about consultants and consulting in general , which I found somewhat interesting. The key problems he points out are that consultants aren't true stakeholders, they can potentially abuse contractual politics, and unethical practices in general.

First off, I have to say that these are only issues when you're dealing with unethical people. I would hope these points wouldn't be an issue for any consultant or consulting firm worth the money. Then again, these are issues that typically come up because of individuals rather than businesses. By this, I mean that businesses don't typically make official (or unofficial) policies of doing any of these things.

The next point I have to make is that none of these are truly consulting issues. Not that they don't apply to consultants, they do; but they don't solely apply to consultants. These issues apply to a myriad of positions across the board -- some more than others, of course. Despite that, they are definitely applicable to consultants, so I'll talk more to that end -- I just wanted to make sure it was known that this isn't a consulting issue alone.

If you ask me, it sounds like Eric has fallen victim to unethical consultants and/or bad decision making in engaging with consultants. This probably happens quite a bit. I know I've always been very skeptical of consultants and I think everyone else should be, too; but it doesn't stop there. Unless you truly know the source of your information, you're better off verifying it against multiple sources. There's no right and wrong way to do development (or much of anything, for that matter); but there is always a better way. Anyway, on with my comments...

Rightfully so, Eric doesn't like the fact that consultants don't have a stake in the success of a project. I completely understand and sympathize with this issue; but I can't say I whole-heartedly recommend that it change much. There should be shared responsibility, but something you have to realize is that nobody has to listen to a consultant. A consultant's job is to say, "I recommend X because of Y and Z; otherwise, you'll have to deal with problems A, B, and C." Granted, it's not always this simple, but that's how I've approached my consulting ventures. My job isn't to make the decisions, but to ensure others make informed decisions. With that, there's no way a consultant can be held responsible for everything that happens on a project. Of course, this does depend on the purpose of the project and how it's setup. I do think there should be some accountability, tho, so don't think I'm against the idea. I'd be open to hear ideas to improve on this. The idea about providing incentives is nice, but I don't think it would really solve the real problem here. Also, I have to say this isn't always appropriate. I've been in a number of projects that change scope halfway in -- haven't we all? There's no right or wrong here, but if a consultant comes in to look at one problem and finds another, everything can change in a heartbeat. With this flexible nature of a consultant's life, I don't think there's any hard-fast rule that would work across the board.

Eric's second point is a very important one. All too often, contract terms aren't defined well or defined at all. This isn't the fault of the contractor/consultant, tho; this is the fault of the customer, who must define the purpose and scope of the project. With a background in government work, I could go on for hours about the seemingly immeasureable time and money wasted due to poor contract definition; but I won't. I think this is clearly the customer's responsibility. In the same breath, I will say ethics does come into play when contractors/consultants read into and possibly try to twist the contract logic to their own benefit. You'll see this from "contract politicians" a lot. I can't tell you how many times I've seen this from government contractors who're always trying to beat out the other guy. Taking their lack of ethics out of it, tho, this wouldn't be an issue of the contract terms and conditions were defined better. There will always be someone smarter than you, so there's no way to be 100%; but make sure you learn from your (and others') mistakes.

The "bait and switch" Eric refers to is, in one sense, an ethical issue; however, I don't think this is always the case. If I'm going into an organization to discuss what my people can do for them, I'd want to bring someone I felt very confident in to back me up. Assuming I make no promises to who would be actually working on the project, I see absolutely no problem with this. Plain and simple, there's no telling who will even be available at the time the contract is awarded and the project started. Eric's suggestion to review resumes and even conduct your own interviews is right on target, tho. I'd recommend this to anyone who has the technical know-how to accomplish the interview. The only problem is, when you hire a consultant, that's typically because you're in a situation you can't get yourself out of. If that's the case, the chances are you don't know what you need to ask to ensure the consultant knows what s/he needs to know to get the job done. You also have to take into account the fact that consultants don't always have 100% of the knowledge they need to get the job done. I remember going on a job recently that I was very excited about because I knew ahead of time that it'd be a challenge. I didn't know everything I needed to know, but I knew how/where to get that information. I worked very hard to educate myself on what I needed to know and was able to deliver on the promise. This isn't always the case, but I think it's very common.

Honestly, I think Eric has a jaded view, which is common. The reason most look into contract developers is because they truly are cheaper when you take benefits and training into account. You just have to make sure you're putting your money into a company that puts it back into the consultant's future. When going to a contracting or consulting firm, you're not just hiring another developer. You're putting your money into an investment for someone who should be more experienced and has continuous training planned and, ultimately, you're hiring the company. This means the person who actually joins your team better know what resources are available to him/her and how to access them; otherwise, you're limited to what's in his/her head. If any of these aren't there, you should ask some important questions. If two aren't there, you should look elsewhere. Of course, this is only part of the equation. As usual, there's no 100% solution to ensuring you get the most bang for your buck. This is where learning from your mistakes and the mistakes of others comes into play.

The Ultimate Developer Machine

Michael Flanakin — Wed, 14 Feb 2007 14:48:00 GMT

As with the vast majority of projects I've worked on, developers working on my current project are using their dev tools directly on their machine, as opposed to developing within a virtual machine (VM) care of Virtual PC . I admit that I have somewhat of a love-hate relationship with Virtual PC; but, in the end, I'm typically glad I have things setup that way. Initial start-up time will sometimes be slow when compared to local development because I'll have to load up a saved VM, but when things go haywire or when it comes time for cleanup, I'm usually very thankful to have the VM in a single file that I can delete, if necessary. The ability to simply move that file around and delete it to start from scratch is very valuable to me. Honestly, whether you like VMs or not, what I'm working on now goes beyond that. I need to create a "standard" development environment we can pass on to new developers. With that, I plan on compiling a list of the most valuable development tools and utilities to add to the VM. Of course, I plan on starting with Scott Hanselman's Ultimate Developer and Power User Tools List as well as my personal favorites , which I'll be upgrading as I work thru this. If anyone has any special tools they like, I'd love to hear about them. Once I come up with the version 1.0 list of what will be included, I'll make sure to post it.

CSS Overflow

Michael Flanakin — Sun, 04 Feb 2007 14:17:00 GMT

Due to limitations of the HTML dropdown list (<select> tag), I played around with the ASP.NET AJAX Control Toolkit's Dropdown Extender . I've used this before on a small app I did for a group of friends and it worked out very well, so I figured I'd see how it'd work in a more professional environment. All-in-all, the extender is very easy to implement. The great thing is, the sample style is great, so it's an automatic default. To meet our needs, there needed to be an icon displayed to the left of each item, so I added that with a style, which was very simple. The only visual problem we had was the list of list entries was very long, so we had to set an overflow on the dropdown portion. Easy, right? Well, yes and no.

First, to get the list to scroll, the following style was added: height:250px; overflow:auto;. This tells the control to scroll contents past 250 pixels. Unfortunately, this had a side-effect. The control scrolled vertically, as expected; however, it also scrolled horizontally. Since the list was dynamic and each item was set to not wrap (white-space:nowrap;), I couldn't set the control's width to a standard across the board. Now, before I say what I did to "resolve" the "problem," let me say that the horizontal scroll was for ~3 pixels. No text was being cropped. The problem I had was simply that it looked better without the horizontal scroll. So, to achieve the vertical-only scroll I wanted, I had to go for an IE-only solution, which I hated doing: overflow-x:hidden;. In conjunction with the previously set height and overflow, this allowed the control to scroll vertically, as intended, on IE, which is the "standard" for the system. Like I said, I hated doing that, but seeing as tho it was the only work-around I knew of and it still worked in non-IE browsers, I figured it was acceptable. Honestly, I think this should be part of the CSS standard. Note that I haven't tested this on Firefox or any other browser, yet.

Version Control Standards

Michael Flanakin — Sun, 28 Jan 2007 19:01:00 GMT

Standards are very important; especially in team environments. One thing that's been getting to me the past few months is what seems to be a lack of standards when it comes managing Visual SourceSafe (VSS) and Team Foundation Server (TFS) repositories. Since most of my version control experience is with Subversion, I want to bounce back to the fact that data in the repositories is managed very simply. You have three (or four) top-level directories that represent the major version controlled entities: branches, tags, and trunk. The term "tag" may not be familiar to some, so let me just say that tags and labels are the same thing -- an ear-marked version of the repository in a significant state. "Trunk" is another term that some may not be familiar with, but it is essentially the main line of code you're working with. I love the fact that Subversion introduces you to these right off the bat because it almost forces you to learn and abide by good version control practices. You don't have this in the VSS/TFS world. For those who caught on to the optional fourth directory with Subversion, that would be shelves. "What? Subversion doesn't support shelving!" you say? Not true. A shelf is simply a branch in the Subversion world . (Shameless plug: Woohoo! I'm the first result when searching for shelving in Subversion.)

As I mentioned, digging into VSS and TFS for the first time, you don't really see these same principles. It's too bad, because that can cause chaos in the field. Well, maybe the word "chaos" is too strong of a word; but you'll be hard-pressed to find two implementations that work the same exact way. Putting some thought into it, I guess the best thing I can come up with is having an application directory with branch directories sitting alongside it. For instance, if my application is called MyApp, I would have MyApp, MyApp-1.0, MyApp-2.0, and MyApp-2.1. These map to the main and release branches, respectively. Not rocket science, I know, but I just haven't seen a common practice. If anyone has one, I'd love to hear about it. If I have more than one releasable project within my repository, then I'd include all project-related branches within a parent directory called MyApp, or something similar. Then, other releasable projects could sit alongside this one. Again, pretty simple.

Beyond this structure, which will probably change over the coming months, I also have something else of mild interest. Time and time again, I need to explain version control concepts to developers who haven't dealt with configuration management before. Not that I mind, but I recently created an image to visualize this for a project I'm on. I figured I'd share this for others to take advantage of. Looking at it, it's fairly easy to explain how the release cycle works and when/where branching and merging comes into play.

Note that this isn't specific to any type of repository, so whether you use VSS, TFS, Svn, or any other version control solution, it should apply to you just fine. The dark blue line represents the main branch (or trunk). At some point, a code freeze is identified, which is when the codebase is branched for the release. Testing is performed and bug fixes are applied to the release branch while, at the same time, changes are also made to the main branch for the follow-on release. Once the release branch is considered stable, a tag/label is applied (identified by the red star-burst), the release is deployed, and the changes applied to the branch are merged (identified by the orange line) back to the main branch (or trunk). Over time, while development on the main branch is moving along, there will inevitably be bugs in the production system. Let's just say your next major/minor release isn't for another 6 months. In that case, you'll probably want to do a point release to push out a bug fix or two (ok, 10 or 20 ). In this case, developers will pull the latest (aka head) from the specific release branch and apply necessary fixes. This is again tested, tagged/labeled, and re-deployed. To get these changes back into the main branch, the release branch is again merged to the main branch. This process will continue for the life of the project.

Honestly, it's all pretty simple; but as they say, "a picture is worth a thousand words."

...2 1/2 Years Later

Michael Flanakin — Wed, 17 Jan 2007 14:37:00 GMT

I just ran across a 2 1/2 year old post about what a software architect is on Mike Sax's weblog that was a comment to a post I made . Mike quotes Alan Cooper quite nicely:

Web designers are called programmers, programmers are called engineers, engineers are called architects, and architects are never called!

I just wanted to say that I am (and was at the time of my original post) familiar with Alan's quote and whole-heartedly agree!

Defining Your Process

Michael Flanakin — Sun, 17 Dec 2006 20:41:00 GMT

Processes exist for a reason. I think we all know that. Nobody can acurately say that processes are bad. They can be taken too far, tho, which is why agile processes have grown so rapidly in the software development arena. Personally, I think a lot of that has to do with trying to get away without documentation, but that's a different issue. Honestly, agile processes don't have anything to do with the level of effort put into documentation. Anyway, all of that's besides the point. I read a post, If Not Agile, Then What , by Rockford Lhotka a while back and I've been meaning to remark on it. Over the years, I've put a lot into defining and working to better development processes. This came from being in a process-heavy organization. At the same time, I've always appreciated the fact that the processes in place were more than I thought necessary. There are certain architecturally significant steps I believe are important for any development project, but the level at which they should be achieved can vary a great deal.

Rockford talks about how nobody follows any process 100% and no process was built to be 100% followed. Well, those aren't his words, but it's the basic jist of it. One thing I've always wanted to do was create something like a step-by-step process for defining your own development process. Basically, you'd input your criteria and out would pop a suggested process, documented from front to back. You could, of course, pick and choose what you actually used; but the core concept is that the practices -- along with their pros and cons -- would be given to you so you can make an informed decision. That's one thing you have to be able to do as a consultant: allow your customers to make thier own decisions. If you want to bury yourself, I'll hand you the shovel; but not before telling you what I believe could happen, what to look out for, and what your options are going to be if my foresights have come to pass. Defining and following a development process is a weak point in most organizations. Sure, people might deliver, but is there enough documentation? Beyond that, how much is enough? There's no single answer for these questions and the thousand others that would typically follow. This, of course, is why I've always wanted to formulate the process generator I mentioned. I don't know if I ever will, but it will always be in the back of my mind.

If you're interested in software engineering processes, I suggest you give Rockford's post a read. I'm always interested in people's opinions regarding engineering processes because it helps me take in different viewpoints and better understand the necessary flexibility for any process to survive across multiple projects, which is almost a must-have for a development organization. The more processes in one organization, the more wasted time and money that goes into managing these processes. I don't think most developers realize the importance of a well-defined process because they haven't been exposed to larger system development teams and organizations where project scheduling and documentation isn't something that can be debated without risking project success.

5 Minute Vista Gadget

Michael Flanakin — Fri, 15 Dec 2006 18:17:00 GMT

Edgar Sanchez mentioned how he created his first Vista gadget in 4 simple steps. Of course, it's merely a hello world gadget, but I was surprised to see that it was so simple. I've been wanting to create a gadget for a while and this makes me want to do it even more. Now all I need is a good idea, but I'm full of those... Well, I'm full of ideas; we won't talk about how good they are.

The Potential of Control Adapters

Michael Flanakin — Thu, 14 Dec 2006 00:47:00 GMT

I read an article, Extreme ASP.NET , in the October edition of MSDN magazine that talked about control adapters, a new feature in .NET 2.0. I've heard of control adapters and I knew about the browser capabilities, but I never put the two together like this. Actually, I have to admit that I didn't know much at all about the way the stuff worked, I just knew vague tidbits about them. After reading this article, tho, I'm amped! I can't wait to dig into control adapters!

I'm a big (read: very big) fan of applying standards to your development work. Because of this, I try to use XHTML and CSS wherever possible. The problem is that most developers in the .NET world don't care. Rightfully so, developers are more interested in getting features implemented. I completely understand that and can't argue it -- heck, that's what we get paid to do. But, I can't help but get aggravated when I open a .NET project in Firefox, for instance, and it goes haywire. This is probably more common than you think, too. I admit that IE does add some great features; however, standardization shouldn't be an optional thing. If Microsoft believes so heavily in the added features, then push for them in the W3C. Actually, I can't say too many bad things about Microsoft's lack of applying standards because there has been a huge improvement over the last year or two. I am proud to say that, as a company, we are making great strides in the right direction. Believe it or not, everything's not all about the money... but it does put food on our tables. Anyway, back to control adapters...

One great control adapter implementation is the CSS Control Adapters , which was recently released. In a nutshell, control adapters allow you to give a control a completely new look and feel. This set of control adapters resolves non-standard coding practices built into the existing set of ASP.NET controls by providing a standards-based implementation. I love it! I still need to play with it, but I'm merely excited to have the capability.

Simon Guest's 10 Tips for Setup Programs

Michael Flanakin — Wed, 22 Nov 2006 13:21:00 GMT

Simon Guest mentions 10 tips he'd like everyone who creates an installer take into account. I have to agree with his list. Here's a paraphrased version of his list with a few comments of my own...

Include prerequisites in installer
If your app requires something else, at a minimum, create an extra installer that bootstraps the prereqs. This is handled by .NET and I know I've seen a lot of Java apps include the JRE, so that's good. I still end up seeing this rule violated every once in a while, tho. One instance is when a Visual Studio add-on required another add-on. The one in question should've checked for its prereqs and installed them if they weren't there. The task isn't that hard.
Don't require a restart unless it's absolutely mandatory
I have seen a lot of apps that don't really need a reboot, but I've also seen the ones that do. What I'd like to see is a note for more information on why the installer needs a reboot and/or what will happen if you don't. Not rebooting can cause consequences. I'd like to know what those are, so I know whether or not I should really stop what I'm doing just to reboot.
Avoid unnecessary animation and menus
I don't know that I've seen any violations in this area that often, but I can definitely understand how over-use might be an annoyance.
Limit options
Installers need to be simple. The best installers are the ones that don't need a lot of thought put into the actual installation process. Sometimes options are necessary, but what I'd like to see is different automated installs. For instance, give me an option for a typical, complete, and custom install. Also, when you do give these options, try to describe what's included in each so users aren't guessing what the difference between typical and complete is.
Ensure uninstaller removes everything
This used to be a huge problem a few years ago. The biggest thing I'd have to say is, don't use the registry. I admit that the registry is required sometimes, but not always. Be judiscious when using it or any other system-wide resources and when you do, be sure that your uninstaller knows about them so it can remove everything. There's nothing worse than having to manually clean out the remnants of uninstalled programs... ok, maybe there is.
Make necessary permissions known
I'm one of the many people who runs as admin, so I don't see this too often; but I have worked for organizations that don't allow admin priveleges to get out. When a user doesn't have the necessary privileges, tell them. If your installer doesn't, you're risking a install errors, which could essentially leave the system in a half-installed state, which could corrupt further installations or even the system, depending on what your installer does.
Add ability to close necessary applications
This is pretty simple. If you need apps closed prior to install, give an option to do it for the user. The only thing I have to add is, if it's possible to bring an app back to its previous state, do so. One example is a browser add-on. The installer should see if the browser is open, save as much state information as possible (even if it's only the URL), install the product, and return the user to the state s/he was at prior to installation. If I found an installer that did this, I'd be very happy. I usually do this manually to get around it.
Display accurate time remaining
This is pretty simple. As a user, I want to know how long the process is going to take. Figure in average network and disk access time, where applicable. Don't use the current time because that's probably not going to be consistent. Don't tell me about a percentage of files, because some files are larger than others. Be smart and determine the best installation metrics for your process. Where possible, group actions in steps and show the user where they are in that whole process.
Automate unpacking and clean up after yourself
This is another big one for me. There aren't too many installers that do this, but it does happen. There's no reason an "installer" should unpack files to a directory and quit. At least run the installation. Oracle's .NET data provider does this, for instance. And when the installation is complete, remove the files you created. Simon also mentions that the system %TEMP% directory should be used. I whole-heartedly agree. I don't like temp files clogging up my directory structure any more than they have to.
Is an installer really necessary?
I have to say that this is probably the biggest one for me, personally. If an app doesn't require system resources and/or is going into one directory, give me an option to not use an installer. Personally, I like to keep my apps which don't need to be installed into the system separate from the others. These are typically more portable, which allows me to take them from one computer to another without any repercussions. These tend to be small apps that I can't live without -- in part because of their portability.

I'm sure, with some thought, we could all come up with our own 10 installer annoyances; but I think Simon came up with a good list to start with.

Coding Standards

Michael Flanakin — Tue, 07 Nov 2006 15:14:00 GMT

Having been in a consulting role for some years, now, coding standards have become very important to me. I'm not going to weigh in on what coding standards I think are most important, but I do have plans to get a document up sometime. Beyond that, Jeremy Miller posted his thoughts on coding standards a few weeks ago. I have to say that I really like the basis of his ideas. To sum it up, creating a 100-page document covering every aspect of software development may be the best way to document all the standards that probably should be applied to any given project; however, we all know developers won't read it and/or remember the standards therein. The best you could hope for with this approach is that developers and code reviewers together cover the foundation of those standards. Even this is a long-shot, in my opinion. Jeremy likes the "by the team, for the team" approach, where coding standards grow over time and are truly (or, at least closer to) a shared vision of what standards are appropriate. I like the comradery and team buy-in this method would generate, but I don't think it really gets to the heart of the problem. For instance, what happens when, after a year, a project now has a 15-page coding standards doc and a new developer joins the team? Well, this would be almost the same as handing an existing doc to a team and telling them to work with them -- that new developer will most likely not go thru the entire document. The problem isn't really solved with this approach.

Personally, I like the idea of grabbing existing standards and changing those as you see fit. There are reasons people put these things together. Again, this doesn't resolve the problem at hand: developers don't want to read standards docs. What's the solution, then? Well, having a document might be a good idea to solidify the standards in their entirety. I don't think we can get away from that. The real problem is getting people to abide by a document that sits in an arbitrary directory and has no real effect on whether or not the software functions as needed. This is a maintainability and extensibility issue, in most cases, which is an afterthought for most projects... unfortunately. What we really need is automation. We need a tool that will tell developers when the code doesn't abide by standards.

The first tool that comes to mind is the built-in code analysis feature of Visual Studio (or the stand-alone FxCop application ). Anyone can write rules for this that will be used to analyze code and point out problems. While I like what the tool offers, this is a lot more explicit than I'd like it to be. I want something that the developer doesn't have a choice with. I want to say, "HEY! Look at this! You're not supposed to do this!" In my opinion, this is the best way we have to-date to ensure standards are abided by. Think about it. When using Word and you get a squiggly saying you spelled your last name wrong -- that happens all the time for me -- do you tell Word to ignore the error or add the word to the dictionary? Or, do you just leave the squiggly on the page? More often than not, you'll find that people don't want to see the squiggly because it's saying that they're wrong -- or, might be wrong, in this case. I admit, when it comes to my last name, I've grown to ignore the squiggly, but in code, that's a different story. No developer will want to have squigglies all over the place if someone else is going to look at it. Sure, maybe a small handful would be ok, but nothing extreme. Either way, this is better than not applying any standards between developers.

The next potential solution I found was something new (to me): Code Style Enforcer , by Joel Fjorden . Now, this is what I'm talking about! The tool does exactly what I want: it tells the developer what's wrong. The only problem I have with it is that it doesn't cover nearly enough of what would be in a typical standards document. All it covers is implicit vs. explicit implementation of interfaces and abstract classes, naming, and what visibility settings should be available. This isn't nearly enough. Also, I have a problem with the way some of the naming standards work. For instance, you typically don't want a method name with an underscore (_); however, the standard control event handler is in the form of <control>_<event>(). Obviously, this is a direct conflict. So, the only way you can avoid a warning on these event handlers is to change the rule to accept an underscore. I don't like that because I don't want underscores to be in other methods. I do have to admit that this is better than nothing, tho.

I need to do some more looking to see if there are any other VS add-ins out there. If not, I may work on 3 things, which I think would bring the best level of coverage. First, I'd create code analysis rules for all the coding standards. This way, a team could bring them into their project and select the ones they do and don't want to apply. Second, and probably more useful on a broader range, would be to create an implicit code analysis execution for the current page. The only problem with this is that code analysis typically runs on compiled code. I'll have to look into that to see if there's a way around it. Probably not. Lastly, I'd like to have something that could auto-generate a standards document based on the approved code analysis warnings. This would be helpful for new developers and process/documentation enthusiasts. I honestly think this 3-parter would be very valuable; but before I commit to anything, I'll have to do some looking to see what else is out there.

When to Generalize Classes

Michael Flanakin — Mon, 06 Nov 2006 13:58:00 GMT

Sijin Joseph wrote about his experiences with abstraction/generalization (in the form of interfaces) a few weeks back. I have to say that this is a very common problem developers face when they hear about best practices. All too often, people will hear about how good something is and they'll almost blindly apply it everywhere. Then, when they run into problems with their overuse of the practice, the deem it as useless and go on a crusade against it. This is obviously an extreme case and I'm not saying that's what Sijin has done. I'm merely stating that this is a common problem that we must all be aware of so we don't fall victim to it.

Whenever you hear about a new best practice (or, new to you, at least), you really need to take a judiscious approach to applying it. Definitely give it a try on something small, if you have that luxury. The problem there is that we don't always have something small to try it out on; and, when we do, you may not see the full benefit of the practice in a small environment. This is why software architecture isn't for all developers. Some of the best software architects have no development background. I'm not going to get into that, tho. Knowing how and when to apply best practices, such as abstraction, is something you have to grow into. Honestly, I know I'm not completely there. I tend to over-design throw-away projects because I enjoy the art in my creation (one day, I'll post my thoughts on the art and science in software development). Before you can really determine when to and when not to apply a given practice, tho, you have to have the vision to see its benefit and the experience to know when that benefit will help.

As for my opinions on when to generalize classes into interfaces and/or abstract classes, I typically take a few approaches. First and foremost, I look at the solution and determine whether it needs to be build with extensibility in mind. If I'm creating something that needs a plugable environment, it's a given. Honestly, there are probably a handful of obvious situations like this one, so I'll skip those. Outside of those, I'd take a 1-2-3 approach. When you create the first class, take about 5 seconds to think about extensibility. Is it necessary? Think about the overhead of creating that extra layer. It's not always as simple as an interface. Ok, it's never that simple. You have to know how to deal with the interface at every point in which it will be used. This may be insignificant or a huge effort. There's no telling because it's completely contextual. The second time you create a similar object, you should take at least 30-60 seconds to think about it. How similar are the two objects and are they related? Hmm... As you can imagine, you'll need to have a lot more of an understanding at this point to know and understand the ins and outs of the application to be sure that an abstraction wouldn't break something. For larger systems, this is sometimes impossible, which is why I can't completely back the write first, design later methodology. The third time you create a similar object, you really need to look at everything and ask yourself how much repetition you're doing. Chances are, by this time, you've duplicated some logic. If you ever get to this point, it's pretty much a gimme that you need to generalize something.

Honestly, there are a bunch of factors in this discussion and there's no way for me to cover all aspects here. These are the main situations I've run into, tho, so hopefully you'll find some solice in them. I have.

DSL Tools Teaser

Michael Flanakin — Tue, 24 Oct 2006 13:27:00 GMT

If you haven't seen it yet, check out the domain-specific language (DSL) tools video on Channel 9 . I admit, the video isn't all that exciting, but the capability is. The simple fact that we can now build designers so easily is astounding to me. I've never been one to care enough to learn some of the advanced graphics stuff you can do in .NET, but I've always wanted a complete model-driven architecture (MDA) environment. This is a means to that end. I'm excited about it. I can't wait to dig in and create my own! Then again, there's always that pesky time thing...

Google Reaches Out to Developers

Michael Flanakin — Thu, 05 Oct 2006 15:14:00 GMT

Here we go again... Google is doing what it does best: reaching developers. This time, by providing a code search . This is one thing that Microsoft doesn't seem to understand, which is odd when you take into consideration the fact that a developer focus is how Microsoft won the desktop OS wars. Well, maybe it wasn't a war, but more of a gradual push into a new market. Google, on the other hand, has rooted itself in the concept that, if you gain a strong-hold in the developer mindset, they will proliferate their tool usage throughout their contact list like a virus. And, it truly is like a virus (in terms of spreading, at least).

Think about how you heard about the Google search engine. I first started using it on a daily basis in 2000. I'd seen it before then, but never really thought about how much I really searched for content online. When I was re-introduced in early 2000, tho, the benefits finally sunk in. A developer showed me and what did I do? I told all of my developer buddies. Not only did I stop there, I told my friends and family. I would slowly start to convert girlfriend after girlfriend to Google. I did pretty good as a mindless bot, if you ask me

Google takes this and exploits it to the fullest. I can't say whether Google realized this in the beginning -- or even now, for that matter -- but Microsoft is still playing catch-up and just hasn't done a lot to surpass Google. Live Search is good. I admit that it isn't quite as good as Google Search sometimes, but my life after Google has been pretty satisfactory. I can honestly say that I haven't had the urge to look back once... in the text search realm, anyway. Microsoft did introduce the idea of macros to online searching, which was an attempt to reach the tech-savvy, but I don't think that capability has really reached everyone. Part of that might be due to the fact that the concepts behind search macros aren't widely known. I, for one, looked into it and lost interest fairly quickly due to a lack of documentation. I didn't know where to start and since I clicked a link out of sheer curiosity, I didn't care enough to figure it out more. Perhaps one day I'll go back and check it out, but from what I saw, it was merely a way to perform scoped searches slightly easier. Not really something I'm all that interested in, but the idea is nice. Microsoft needs more, tho. Microsoft needs a wiz-bang feature that no search engine has. I don't know that this will happen anytime soon. I have one idea, but it's so specialized, it might not be worth the efforts. I've passed it along, but don't expect to see much out of it.

We'll see where Google's new code search goes, tho. The concept isn't new, but this is the first major search engine to pick it up. I used a couple of the previous code search providers, like Krugle and Koders , but it was never something I could get into. I would only need something like that once in a blue moon. My problem with them is that you have to know the code you want to look for. If there was more documentation that would lead you to the code you wanted, then that'd be a different story. Until that day, I just don't see this being an industry-changing capability. Well, unless there was an integration into the development environment that could alert a developer that they're typing code that's been created before. Sort of a context-sensitive, auto search capability that would display similar code. That could be useful, but would require a drastic change to how development is currently done. I almost think that any such effort would be doomed from the start.

Giving AJAX a Shot

Michael Flanakin — Fri, 29 Sep 2006 13:22:00 GMT

One of the things I've been meaning to try out for quite some time is the ASP.NET AJAX (aka Atlas) framework. There are 3 parts to this framework, but only two that I need to be concerned about when doing ASP.NET development. The 3 parts are the client-side library, which is available for any server-side platform; the main ASP.NET controls, which enable AJAX capabilities; and, the extra ASP.NET controls that provide specialized functionality. You can get more info on these from Scott Guthrie's weblog entry, "Atlas" 1.0 Naming and Roadmap . I did start to play with AJAX before the ASP.NET AJAX framework was available, but I never commited enough time to actually focus on it. Since then, the one reason I've hesitated the most on it was because I really wanted to see some wiz-bang beautiful feature that I couldn't live without. Granted, the main purpose of AJAX is not to enhance the user interface (UI), but to enhance the user experience (UX). Nonetheless, I wanted something I could show users, who are more impressed by the explicit combination of UI and UX -- by definition, UX implicitly includes UI, but that isn't always the main focus of UX enhancements. What I was really waiting for was something I didn't realize existed: the ASP.NET AJAX Control Toolkit . If you haven't checked it out, this is a must-see that will really convince you that it's time to give ASP.NET AJAX a shot. Beyond this, I was uterly suprised at the amount of work I needed to do in order to AJAX-enable my application. There are 3 very simple steps: (1) add a reference to the ASP.NET AJAX assemblies; (2) add an instance of the <atlas:ScriptManager /> control to your page; and, (3) surround the controls you want to be AJAX-enabled in an <atlas:UpdatePanel></atlas:UpdatePanel> control. All very easy and with a quick turn-around to see results.

Now, as I mentioned, I wanted to see more than this in my AJAX efforts. I was talking to a co-worker about what I'd like to create in a demo I was working on, but didn't have to time to invest. That's when he introduced me to the ASP.NET AJAX Control Toolkit. When I gave that a look, I was gleefully surprised. I'm not sure why I didn't know about this sooner. If I would have, I'd have definitely played with it earlier. I admit, these controls don't add capabilities to your web application, but they do save you time and effort in making your app perform and look better.

I've used this ASP.NET AJAX in a demo app and a very small Media Center management app I worked on for someone and have been extremely impressed. I plan on doing a little work for a local football league in the coming weeks, too, and ASP.NET AJAX will definitely be part of my arsenal. I honestly can't see doing things differently. I'm a very big UX geek, so anything I can do to make the application look and feel better, I'm all about it. Hopefully, I'll get a chance to post on the Media Center and football stats projects I'm working on.

Effect of Dynamic Interfaces on Accessibility

Michael Flanakin — Thu, 28 Sep 2006 16:24:00 GMT

Wallace McClure recently posted a comment on the fact that AJAX actually inhibits accessibility . I can say that I personally never even thought about this, as I'm sure most developers haven't. I typically work with government customers, but as of yet, Section 508 hasn't been a big issue. Despite that, I still view 100% accessibility as a goal I would like to reach in all of my projects. Let's face it, tho, even in projects where it is a factor, complete compliance is rarely obtained. The recent move towards highly dynamic user experiences makes me wonder why this hasn't come up before. Well, I'm sure it probably has, but the issue hasn't been raised a great deal, from what I've seen. This is definitely something to keep in mind. There are obviously intrusive ways to get around the immediate issue of not knowing when content has been updated (i.e. alert the user that something has changed), but I don't see that becoming the norm. I would be interested in a solution, but will have to wait until it becomes an issue for one of my projects before I investigate more.

If anyone else has any details on this or other accessibility issues/work-arounds, I'd love to hear them.

CSS in IE 6 vs 7

Michael Flanakin — Tue, 19 Sep 2006 11:30:00 GMT

I just ran into my first IE 6 vs 7 CSS issue. This is probably the first only because this is the first time I've started a project with IE6 and switched to IE7 mid-stream. Oh well, here goes nothing...

Turns out the problem just looked a lot worse than it really was. I had nested DIV tags to lessen my use of tables and I set the background image on each of them to be fixed. This seemingly forced the background image to start at the left edge of the page, which I didn't want, since the DIV was moved to the right about 150px. After removing the fixed style (background-image:url(...) no-repeat ~~fixed~~;), everything worked just fine. I was surprised. The layout seemed to be worse off than just that, but I guess it was just the images that were messed up, not really the format.

A Tidbit on Sun and Java

Michael Flanakin — Fri, 01 Sep 2006 22:59:00 GMT

For the past month or so, I've been watching quarterly stock percentage changes for a few top tech companies and I've noticed that Sun went down a good bit, but then jumped up pretty quickly, too. Sun made the largest jump by far in the past month. Interesting...

On a side and perhaps related note, Java is moving towards supporting more languages. Java 6 is currently in beta 2 and has added some support for JavaScript, but plans for Java 7 include adding support for even more languages, one of those being Visual Basic. Now, this isn't all that surprising. A few years back, Sun started a program to try and get VB developers over to their side and this seems like more of the same. Don't get me wrong, I think the move is probably a good one, but I don't know how much it'll help. It all depends on the strategy they'll put behind the move. This is where they've failed in the past. From what I understand, they won't plan on supporting a specific Microsoft-released version of VB, but instead support some "popular" features of VB.NET. What that means is really up in the air, but it'll be interesting to see how things play out. The best move Sun could make with respect to VB would probably be to support VB6 to try to bring some of those "estranged" developers to the Java world. Then again, I can't imagine that this would be an easy task.

There are a lot of mixed emotions about the changes in the next two versions. Those looking for multi-language support are excited about the changes; however, the traditional Java developers who have been supporting Java-only systems for a while aren't very interested in the upcoming versions. I believe everyone sees some good in the move, but the question seems to be: How much will this actually affect the Java ecosystem? I can see the potential of the ideas, but I seriously don't think it'll change the Java market enough to effect .NET. Sun is simply attempting to capitalize on the big shift back to dynamic languages. We'll see...

Unable to Start Mobile App in VS 2005

Michael Flanakin — Wed, 30 Aug 2006 13:00:00 GMT

Symptoms

After creating a new mobile application in Visual Studio 2005 and running it in the debugger, you receive an error message that is similar to the following:

Unable to start program '%CSIDL_PROGRAM_FILES%\MyMobileApp\MyMobileApp.exe'.
The system cannot find the file specified.

Cause

Honestly, I'm not even sure what the problem is. I searched and searched and never really found an answer that worked. There were only a very small handful of topics I could find relating to the subject. If someone knows what the problem is, please let me know.

Resolution

Well, this might be an obvious one, but oh well... When I first started with this project, I was using the basic VS 2005 install, which provided support for Pocket PC 2003 and SmartPhone 2003. I knew I needed Windows Mobile 5.0, but wasn't too concerned with this. After not finding a solution to my problem, I decided to download the Windows Mobile 5.0 Developer Resource Kit. Installing this and the Pocket PC 5.0 SDK which comes with it solved my problems. I created a new project and everything worked beautifully.

Also of note: If you have an MSDN subscription, you can download the kit there.

More Information

Applies to: Visual Studio 2005

Mass Mobile Storage

Michael Flanakin — Sun, 27 Aug 2006 08:07:00 GMT

Currently, I'm looking into different storage options. The latest USB memory sticks are up to 4 GB for around $100. I like them because of their size, but I just think they're a waste of money because, as time goes on, they'll become somewhat useless. I have a 64 MB stick that I got in 2002 or 03 that's pretty much pointless. So, in trying to come up with something that'll be a little more flexible and cost effective, I come to hard drives and enclosures. With these, I have two choices: laptop or full-size hard drives. The problem is, with around $75, I can get 80 or 250 GB, respectively. No question, right? Well, let's not forget that my plan is to bring this with me everywhere. Adding one piece after another to your mobile pack gets pretty heavy. I noticed this pretty quickly after picking up a top-of-the-line Inspiron (that is still flame-free, I might add).

Actually, while I'm on the topic, I have to say that my Dell Inspiron 9300 runs better and cooler than my Toshiba Protege M400. The Toshiba's a tablet, but it sucks and it's hot as all get-out. If it's your money, save it! Get a tablet, yes, but not this one.

Anyway, where was I? Oh yeah, hard drives... So, the question is, what's the weight difference between the two? I haven't really looked into that, yet, but I will. One of the things I like about the laptop drive is that I can organize content on each one. Let's say I have a library of hard drives. If I need to work on a BizTalk solution, i can grab my BizTalk drive that has virtual machines from random BizTalk projects I've worked on. Same thing goes for SharePoint and any other tool or technology I may work on. That seems very useful to me. I'm all about finding the best way to manage information; especially, as I consolidate 4 machines and bring in 7 years of work backups into the picture. Trying to organize all of this information so I have the right level of access when I need it can be a pain. Someone's gotta do it, tho... This is when I need an intern. Damn... Any takers? No? Oh well, it was worth a shot.

If anyone has any experience or insight in dealing with additional storage space, please share your experience. Let me know what you're thinking about doing, what you did do and how it turned out, or why you avoided the situation all-together. I'm interested. I want to make a decision fairly soon, but the chances are that I'll mix it up a little and end up getting a little of both.

Sitting on the Plane, Gears-a-Churnin'

Michael Flanakin — Wed, 09 Aug 2006 06:03:00 GMT

I was sitting on the plane today on my way to Seattle and I started fiddling with the monitor that was in the headrest of the seat in front of me. The first thing I thought was interesting was the map of where we were and how far we had to go. Now, this is nothing new and what I'm about to delve into isn't anything world-changing, but I thought it was interesting and I'd be interested in throwing something together just as a proof of concept.

Everywhere I go, no matter what I'm doing, I take notice to the processes people implement in their daily lives. In particular, I focus in on bottlenecks and areas where there could be user experience (Ux) and performance benefits. The possibilities are endless and the solutions vary a lot. One of the biggest bottlenecks is person-to-person (P2P) interfaces. These are also the most problematic. Well, to be exact, any user-facing interface is expected to be problematic -- if you've ever done use case estimation, you should already have acknowledged this -- so, of course P2P is a double-whammy. In most cases, when I see this, I think of how nice it'd be to simply input my request within a system of some sort and have everything start working from there. Of course, this is going to require users to be a bit more tech savvy, but it'd be well worth the results -- given some ramp-up time, of course.

As I mentioned, this isn't new by any means. Look at retail stores. I've noticed automated POS machines at Wal Mart and Home Depot. I love these. I think they could use for a better Ux, but all-in-all, the concept is great. Imagine those times your server didn't refill your drink or get your check back to you fast enough. We've all had this happen. Now, imagine if you went to the same restaurant and there was an electronic menu that you simply select the items you want; bluetooth-style cups would alert the server when they're low on fluid or, better yet, detect that the consistency of the drink has changed too much to denote a watered-down beverage, which should be replaced altogether; and, when you're ready to go, you simply check out thru a small machine on the table that would send everything to a back-office server for processing and print or email a reciept to you. I think I'm in love!!

Well, I'm getting off topic. My original idea was to enable that airplane map with Windows Presentation Foundation (WPF) to give the user an interactive interface which is much more feature rich. Combine that with a service to call the destination airport to gather follow-on flight information or even request help if you either need to get to a gate faster or are disabled. We already have radio and TV, why not have web and email? If I had web access, I'd be in heaven on a plane. With a small monitor, I may be limited on space, but I'd be so much more happy than having to deal with pulling out my laptop and trying to work in such cramped spaces -- especially when the person in front of you leans back (which I hate with a passion -- it's so inconsiterate). You get the idea. The list goes on and on. I can just imagine an interface that would allow users to seemingly fly thru the interfaces and select one feature after another to make the experience much more enjoyable. Heck, this would probably take your mind off the fact that you're so uncomfortable.

For now, this'll just have to be my little pipe dream. If there are any airlines or even train stations that might be interested in a concept like this, let me know. Perhaps we can work out a deal with Microsoft Consulting Services.

.NET on Oracle!?

Michael Flanakin — Tue, 01 Aug 2006 04:33:00 GMT

Now, here's something that I didn't know... Apparently, Oracle 10g R2 supports running .NET code just like SQL Server 2005. I found that very interesting. Obviously, this isn't something Microsoft promotes very widely because SQL Server 2005 is their focus, but it's definitely something of interest for .NET developers working with Oracle. I've had to work with Oracle a lot in the past, so I found this very interesting. There are still pros and cons to using this approach, but having the option is what's important. I encourage anyone with a .NET+Oracle environment to look into this and play around with it. I will definitely look into it the next time I work on a project like that.

Most Popular IDEs

Michael Flanakin — Sat, 15 Jul 2006 02:44:00 GMT

I found this article interesting. I question the results, tho. I'm not surprised at the order of the most used IDEs, but I expected different numbers. Beyond that, I would've liked to have seen a lot more people surveyed.

VS in Windows!?

Michael Flanakin — Tue, 27 Jun 2006 12:32:00 GMT

A post on TSS.net, triggered by a post by Jeroen van der Bos, asks whether Visual Studio should be part of Windows. I just don't think having a full development environment would be a good idea. First off, if someone wants to develop in .NET, they should know where to go. I do think the additional visibility would be good for .NET growth from a hobbyist/student perspective, but I'm just not sure it's appropriate. I admit that I first started playing with scripting languages on a Mac when I was in high school, but that's pretty much the equivalent of DOS (and now, PowerShell) batch files. A full development environment might be a little too dangerous for some. It's like scissors - sure, they're great to cut paper, but would you want to leave them sitting around so you can grab them at any time to cut paper when a small child may be running around? Or, would you want to put it somewhere where those who were capable of not hurting themselves (or others) knew how to get to them? It's a pretty simple question and very applicable to this situation.

Legality was brought up, but I don't think there would be a problem. A development environment is simply a utility to provide extra reach into the system.

Another point was brought up about how useful this would be. I have to agree that the vast majority of Windows users could really care less about doing any scripting, let alone development within the OS. Jeroen is definitely looking at this idea from a biased point of view. I won't discuss the claims, but it's just not something the community has been asking for.

All-in-all, the idea might be interesting from the perspective of someone who grew into development by playing around, but it just doesn't make sense for the Windows user-base. I will say that I would like to see the VS framework bundled with Windows. It should be an optional addition that may not even be included by default, but having it available would be nice. This way, other utilities could be built off of that framework. I see this being something like MMC, in a sense. There are tons of MMC plug-ins within Windows. Most vendors don't build off of that because of its complexities; however, if the VS framework was available, it could be utilized in a similar manner. My guess is that the framework SQL Server Management Studio is built on will probably be replacing MMC, but who knows. I haven't played with Vista, yet, tho.