In every company there is more demand for applications than there is ability to create those applications. In the past, a workgroup in a Microsoft shop might create their own workarounds the limits of IT resources by using tools such as Microsoft Excel, Access or even a little bit of VB.NET code.

Excel is great for simple reporting, charting and even light data tracking as a intermediate step before the main line of business applications. However it quickly runs against the wall if the data being worked with is more complex than a few tables and look-ups.

Once that wall is reached, Access provides a great stepping stone for data management and feeding Excel data for charting and reporting purposes. With a fairly simple parent/child linked forms, it allows going to the next level with data, unlocking the power of a full relational database.

Access, however, is "opinionated software" and it is challenging for non-programmers to make custom user interfaces that don't work the "Access Way". (It is possible to make completely custom experiences in Access, but it somewhat defeats the purpose of the provided form editors.)

Additionally, while .NET languages can talk to Access, it isn't the native experience. After working with C# for years, VBA is a painful step backwards. Finally, Access never did play well with the Internet, having some half-hearted web interface options that I have not seen deployed to production in any serious capacity.

Enter Microsoft LightSwitch. In many ways I now think of it as "Access for Intranet and Web". LightSwitch is opinionated software, like Access. It goes even farther than Access in that you can't edit the layout of a data page explicitly. Instead, the order of fields is specified and the layout engine takes care of the actual presentation.

This sounds incredibly limiting, but we just deployed our first LightSwitch application. The process of connecting to our SQL databases was easy and had some surprising benefits. Like many organizations we have multiple applications with distinct databases. Normally we use the "linked server" feature to allow cross database access to tables, but LightSwitch understands the concept of federated data access, going so far as allowing the definition of virtual foreign keys across data sources. This made making a cross database application actually easier than our tradition method.

More importantly, after building a quick prototype example I was able to hand the tool off to a non-programmer who was able to quickly put together new needed data access pages in just an afternoon. Best of all, the underlying programming environment is Visual Studio 2010 with C# or VB.NET, retaining all the benefits of the modern development environment.

The output from LightSwitch is a Silverlight application. It can be deployed as to websites (although the user of the application must have Silverlight installed, which isn't as common as Adobe's Flash, for example). For Intranets this is much easier to ensure. Alternatively, it can be deployed as a desktop application (which is nothing but a container for the Silverlight code, so Silverlight is still a requirement). I would have preferred a native Windows Presentation Framework (WPF) application, but it does ensure that all deployments have the same user experience.

Overall our initial experience has been good. The only thing I do see as a problem going forward is that LightSwitch does not seem to have a way to integrate existing .NET business logic modules. This makes sense in that POCO (Plain Old CLR Objects) business logic modules don't have a defined interface. I have seen some posts where people have usedWindows Communications Framework (WCF) to access business logic, but I have not tried this process yet.

Still, LightSwitch has a place in the toolbox for quick and dirty data access projects. I see it replacing Access in this role in our shop, if only because we can leverage our C# know-how and work with Federated databases far easier than any other tool. Recommended, with those noted caveat.

I had a machine with slow response in Remote Desktop. I found this article, but the primary solution was regarding Windows Vista/7 automatic configuration.

However, in the comments I found the following sequence, which does seem to reset troubled adapters even on XP:


netsh winsock reset
netsh int ip reset
netsh interface ip delete arpcache
netsh winsock reset catalog
netsh int ip reset reset.log


When I repaved my development machine, what got reinstalled... and why? Here is my list, in alphabetical order.

Adobe Web Premium 5.5 Suite, from which I primary use Acrobat X, Illustrator, Photoshop, Flash Pro and Dreamweaver.

Bulk Rename Utility, the ugliest UI in the world, but priceless when you need to rename some crazy batch of files in some regular way.

Carbonite, to access my online backup (and eventually it will be unfrozen and backing up the new install).

DevExpress Refactor! Pro/CodeRush, for code efficiency.

Filezilla, for GUI ftp access.

Google Chrome, as my primary browser.

grepWin x64, bringing the power of Grep to Windows.

KeePass Password Safe, because using the same password twice is a bad idea.

Logitech Webcam, for meetings.

Microsoft IIS Webserver, for development.

Microsoft Office 2010, mostly for OneNote, which I'm finding replaces my old mind mapping software.

Microsoft Silverlight, for development.

Microsoft SQL Server 2008 Developer's edition, for development.

Microsoft Visual Studio 2010, for development.

Microsoft Visio Pro, for quick diagrams.

Microsoft LightSwitch 2011, for evaluation.

Mozilla Firefox 5, for the rich plugin environment which turns it into a power web development tool.

Notepad++, for quick and dirty text editing.

QuickBooks Pro 2011, for accounting.

Skype, for the IM features.

SQL Compare/Data Compare, Redgate's excellent database tools.

Synergy, to link my main keyboard and mouse to the notebook and server.

Terminals, to manage the many remote sessions I use.

TortoiseSVN, to manage the SVN repositories. I do wish there was a good SVN UI that didn't attach to the explorer, as I find the performance slower than dedicated tools and the icon overlay fights with Carbonite.

URecover for Windows Backup, which I used prior to finding the scripts for accessing the Image Backup internal data.

WhoCrashed, useful for checking bluescreen dumps while I get the drivers sorted out (which I seem to have done).

WinHTTrack Website Copier, for mirroring content so it can be used in unit tests when making changes to sites.

WinRAR 4, because there is the occasional RAR file that needs to be opened.

SEO companies have created an interesting dilemma. On one hand, they have created a market for their services which is self perpetuating: a company without good SEO is at a disadvantage compared to one with strong SEO behind it, which creates more demand for their services. The amount of disadvantage depends on the companies business.

Impulse buys for products in a narrow category may be profoundly impacted by search rank as that may be the primary customer acquisition technique. On the other hand, companies providing highly specialized services to corporations that do due diligence before purchases are probably fairly immune to search rank as long as they rank on their own trademarks.

On the other hand, there are only a limited number of things that can be done to a website before it is "optimized" 95% of the way and further effort is going to yield poor return on investment. That is when people turn to "link building". Link building is one of those practices that falls into a grey area. Overly aggressive link building campaigns can lead to results like The Dirty Little Secrets of Search.

The specific rules that most SEO companies like to play fast and loose with are Little or no original content and Cloaking, redirects and doorways. At the end of the day the goal of these techniques is to allow "non organic" linking to be hidden from the search engine enough that they won't be discounted. The problem of course is that when you are too successful, you end up like JC Penny: trying to do damage control on their reputation and search position.

A clearing house for techniques that I really like is the link building wiki. The opinions linked from that page are varied and understanding the sum total of those links will put you in the head of the SEO professionals, minus the worst practices.

SEO isn't going to go away, so living with it, understanding it and coming to peace with the techniques that you can live with and understanding that avoiding those that you can't will go far farther than most SEO firms which focus heavily on building links inorganically (and thus, eventually, drawing the eye of Google's spam team).

Since .NET 2.0 came out, the TransactionScope class has provided an excellent way to manage complex transactions in the simplest way possible: using the scoping rules of the language itself. The basic method for using a TransactionScope couldn't be easier:

using (TransactionScope scope = new TransactionScope())
{
    ... your transactional code here ...
    scope.Complete();
}

An overview of TransactionScope can be found on MSDN.

The idea here is that when you fall out of the scope of the using block the transaction will COMMIT or ROLLBACK. If you call scope.Complete(), the transaction will commit. If you fail to make that call then leaving the scope of the using block will rollback all the work done.

What makes this so amazing is that anything that implements the System.Transaction infrastructure will respect these rules, so you are not just able to work with database providers (which are the most common implementer of System.Transaction) but MSMQ (Micrsoft Message Queueing) and other enterprise components.

There is a trick that is so blindingly obvious that it eludes some programmers for years: the ability to use TransactionScope to test database access code.

The primary problem with testing database logic is that you need to reset the database back to its original condition before you can test again, yet the databasic logic that really needs testing is very complex and includes things such as triggers, constraints and other database level resources that are difficult to mock out.

Enter the TransactionScope: simply wrap your hair raising database logic within it and you gain the ability to make changes to the database, verify the changes are correct and then undo those changes seamlessly. Triggers will fire, constraints will be respected and more importantly all those things will vanish when you fail to call .Complete().

TransactionScope. It isn't just for failed operations.