I've been setting up my new laptop with all the requisite software for me to blog while on the road and today I decided to install w.bloggar v4.00 as my posting tool. Setting it up is to post to a Community Server 2.0 site is not as intuitive as one might think. When you open the w.bloggar setup wizard you're greeted with a dropdown list holding a schwack of different blogging server softwares. Community Server doesn't appear in the list though. I was lucky enough to find this article by Scott Watermasysk which will walk you through each setting with some darn fine screen shots included. When I got to the last step of the w.bloggar configuration (enter user name and password) I clicked the finish button and was greated with a dialog box displaying the following text
      Operation could destabilize the runtime

It turns out that the metablog.ashx file will not run in a Medium trust environment. If you can make changes to the web.config file on your host server, you can fix this by changing the level attribute, in the trust element, from Medium to High (see this MSDN item for more info). This did fix the issue, but it wasn't as straight forward to determine the root cause of the error as it should have been.

I'm the Igloo Coder and I'm out on the town for some Indian tonight so please excuse me while I break into a Bollywood dance scene.

Three of us made the journey down the QE2 today to watch the Alberta .Net User Group's guest speaker Scott Hanselman.  The presentation was great and, although advertised as a talk on dasBlog, it covered a wide variety of coding subjects which were displayed using the dasBlog source code.  The new, and continuing development of my most recent project (www.bloggingonit.com) was starting to pose some questions to me and lucky for me Scott covered a number of the subjects today.  Probably the two most interesting for me were the elegant caching pattern and the use of IHttpHandler and response.Redirect combined to make a friendly URI.

I'm the Igloo Coder and I was shocked to hear Scott Hanselman describe a local bloke as his hero.

Dmitry has upgraded his RSS Toolkit (download here).  I'm currently using the tool to run my newest site www.bloggingonit.com.  Great work Dmitry, and thanks a bunch.

I watched Jean Paul Boodhoo's DNR TV segments today (download Part 1, Part 2) and they were great!  Jean Paul did a fabulous job of showing (sometimes I learn better seeing something done) how to do Test Driven Design/Development.  At one point he says that it might take some time for the light to go on when you first are learning TDD practices, but when it does it will shine ever so brightly.  I think that watching his demos was the last step before that light shines for me.  It's so informative just sitting and watching how someone writes their test.  What things they test for, how they name the tests, and how they locate their test projects within the solution.

The other thing that was interesting was his adamance that the Model View Presenter pattern was the only way to create a system.  I've very little experience with this pattern, but his passionate arguements and explaination of the pattern has made me seriously consider it's benefits and possibly has start to convert me on that front too.

I'm the Igloo Coder and Jean Paul has an open invitation to sit next to the whale oil heater and I'll just sit and listen.

From what I've seen of the Integration Pack for MS EL so far it's pretty darn sweet.

colinco - Avanade Integration Pack for Microsoft Enterprise Library Released

Avanade.IntegrationPack.EnterpriseLibrary.NOSOURCE.msi (1.08 MB download)

I'm the Igloo Coder and I have to go configure my way into some better caches.

I stumbled on this site today (www.400plusdifferences.com).  It's nothing more than a marketing campaign for Visual Studio, but some of the clips are pretty damn funny (I can relate to #308 & #172 alot).

If you're anything like me you tend to open a lot of different projects of solutions over a period of time.  The first thing that you'll notice is that the Most Recent Projects menu item and Start Page section get plugged up and, especially if you're opening projects with the same names, it gets confusing and potentially dangerous.  Well, today I found a way to fix this problem.  Bobby DeRosa has created the MRU Cleaner Add-In.  Another must add to the developer toolkit.

I'm the Igloo Coder and I'm going to delete something else while I'm on a roll.

I'm currently working on my first web project in Visual Studio 2005 and .Net 2.0.  Right now I'm trying to figure out how to properly, and easily, deploy the beta version of my site.  While I've been searching around I dug up Rick Strahl's blog and this post on deployment specifically.  It's a good article and I'll be making a beta anouncement soon.

Via Rob Caron

In his keynote today [Thursday March 16th, 2006] at SDWest 2006, Rick LaPlante announced that we’re releasing Visual Studio 2005 Team Foundation Server tomorrow. Last year we took the tough decision to disconnect Team Foundation Server from the rest of Team System, but promised that Team Foundation Server would ship in the first quarter of this year, and we’re delivering on that promise.

I'm working on some code to consolidate the feeds of all the Edmonton .Net bloggers that I can find.  I think we developers in the City of Champions need a better and bigger community to be involved with.  This is the first project that I'm going to take on in an attempt to help with the better and bigger stuff.  Others are in the works and will follow I'm sure.  This is also a great excuse for me to explore the ASP .Net RSS Toolkit made by Dmitryr.

I'm the Igloo Coder and I've got one hand on the keyboard.

Last night's presentation, by John Bristowe, on WinFX and it's components was very well done and the information was great.  I have to admit I did get a little geeked about the Windows Workflow Foundation stuff.  It was great to see and hear about a product that will be able to increase the productivity of developers and also deliver big benefits to our clients.  Be on the lookout here for a sample project in the next few months.

I'm the Igloo Coder and I'm going to start doing some work on the ice flows outside.

Call me a prude, but this is one of those images that I just didn't need to see.  It could only be worse if someone had photoshopped Mike's face onto this body.  Hang on....it could be worse than that.  It could be this guys face on Mike's body.  <shudder>

I'm the Igloo Coder and I'm having PM Boy flashbacks.  Someone pour me a drink.

I got word today that my training request for VSLive Toronto has been approved.  I will be going!  I've never done any formal training with any employer I've ever had (software industry or not) so this is a big treat for me.

I'm the Igloo Coder and I'm wondering if they'll charge more to let my dog team stay in the room?

I spent part of the weekend working on upgrading the blog to Community Server 2.0 for .Net 2.0.  I didn't have any problems performing the upgrade (other than the fact the upload of the new application took hours).

The only problem that I ran into during the process was getting the blog reconfigured to run from the root of my server.  There is a helpful blog posting by Dan Bartels that got me started but a few things were still non-functional when I completed.

When I tried to open archived month folders, specific posts and the comments sections, among others, I would get redirected to a page not found error.  It turns out that the URLs being substitued for these links did not include my first level domain in them (i.e. http://archive/2006/03.aspx instead of http://www.igloocoder.com/archive/2006/03.aspx).

To fix this problem I opened the SiteUrls.config file and made the changes to some of the url elements.  In the path attribute for the elements there was a value of ##blogdirectory## and I replaced that with blogs/.  I didn't make this change in all locations, but rather changed one at a time, as I found incorrect URLs on the website, and retested them.  I'm sure that some of the values I neglected to change will need to be changed in the future as I find places that the site is not working.

I'm the Igloo Coder and I think I've been hogging the seal skins at night.

I got an invite to Windows Live Messenger beta today.  I’ve installed it and started to play tonight.  I got all excited and spread around the invites.  Once I had some people online I started to say how I really like the animated backgrounds, the offline messaging and the VoIP stuff.  My bubble was burst when I was told these things all have existed in the current version of different messenger products.  I was so happy crawling out from under my rock and then all of a sudden….Wham!…the damn rock falls on me.

I’m the Igloo Coder and I think I’m stuck.

John Bristowe is coming to Edmonton on the 14th of March.  He is doing a presentation on WinFX for the Edmonton .Net Wizards User Group.  Here are the instructions on where to find the meeting.  Hopefully this is a trend to the good for the user group as things have yet to really gotten off the mark for it.

I’m the Igloo Coder and I’m why the fuck is it called an Eskimo Pie when it has nothing to do with the eskimos?

Seems that Mike over at Fire in the Hole has decided to blog about developer management.  His first series (Lazy managers are good, Don’t panic, delegate, Two more stories on lazy managers) discusses how to be a lazy manager.  Is it odd that I see him as being an expert already just due to the fact that 2 of his first 4 posts were posted either during the work day or suspiciously close to the end of it?  Regardless, good stuff to read through if you have to, or could be doing, delegation.

I’m the Igloo Coder and if I catch Sir Paul and his ho out on my ice flow again, Danny Williams and I are going to turn the clubs on their fuzzy little asses.

I’ve been working on this side project using .NET 2.0 for the last 6 months and some of the features are really starting to grow on me.  The project is a WinForms application which provides a nice contrast to my day-to-day web development.  Most of my previous forms development was done in VB6 which, although a decent tool, did leave a lot of things up to the developer.

In the last few months I’ve really started to like the new WinForm controls that are bundled with Visual Studio 2005.  If you use Panels, Splitters and Flow & Table layouts in combination with the Dock, Anchor, Margin and Padding properties on controls, it is possible to completely eliminate the need to write any resizing code.

The example that I’ve worked with is a dynamic database driven form that will load up a number of control pairings (a label and another data entry control).  In my previous, VB6, life I designed a form like this that had thousands of lines of code that managed the location of the controls, the spacing between them, their sizings and finally the location of the Save and Cancel buttons on the bottom of the form.  Oh, and don’t forget to write some code to resize the form itself so you don’t end up with a massive block of dead grey space, or, worse yet, controls being cut off by the edges of the form.

I was able, in a weekend instead of a month, create a dynamic, sizable form that has absolutely no resizing code.  Imagine you have 100 such forms in your application and each one has, on average, 250 lines of code to handle resizing.  That’s 25,000 lines of code that you need to maintain, and resizing code is notoriously difficult to maintain.  Say you can take 50% of those forms and implement the resizing without any code.  Not only have you increased the stability of the software, decreased it’s brittleness and saved some poor developer a tonne of unenviable work, but you’ve also reduced the amount of system maintenance that you will have to perform.

Not such a bad thing eh?  Check out the MSDN articles on the following topics for some more information:

How to: Anchor and Dock Child Controls in a TableLayoutPanel Control
How to: Anchor and Dock Child Controls in a FlowLayoutPanel Control

If you want a good read on WinForms development check out Programming Microsoft Windows Forms 2005 Edition and read chapter 3 on Panels and Dynamic Layout.

I’m the Igloo Coder and my ship has Docked, Anchored and we’re calculating the Margins.

In the past I’ve worked on a lot of reporting solutions.  My most recent work project has no reporting component which is contrary to what I think software needs.  If your system is collecting and storing data, your users will most likely want to get that data back out in some meaningful way. 

I’ve seen reporting solutions be as simple as a grid listing in the software itself that can double as a report when printed (i.e. a Customer Listing report).  I’ve also built a couple of systems that were database driven solutions which could dynamically create a selection criteria window, assign the user selections to a T-SQL statement and alter the appearance of the report formatting based on database entries (see Crystal Report vs Active Reports for brief descriptions).

Currently I’m working on a side project that uses all the newest technologies.  The application is written in C# 2.0, the database backend is SQL Server 2005 and the reporting solution  I’m using this time is SQL Reporting Services 2005.  I’m intending on writing a fully detailed account of Reporting Service in the next short while that will be provide the final comparison between SRS, CR and AR.

On this side project I’m once again working on a fully database driven solution, but I’ve made a few changes to the way that I’m structuring it.  One of the most significant changes is that I’m no longer using T-SQL stored in a database field as the source for the reports queries.  Instead I’m using stored procedures (the name of the procedure is still stored in the database) and parameters.  One of the reasons for choosing to put the report queries in the database was to allow for the report to be easily altered without need for software upgrades.

For a couple of reasons I think the use of T-SQL was flawed.  One of the reasons was that it didn’t really make the maintenance all that much easier.  SQL statements stored in a database field were tremendously difficult to recover, reformat, alter and upgrade (primary difficulty being the reformatting).  Another reason was that we did, on occasion, create SQL statements that were larger than a varchar(8000) field could hold.  To overcome that we used a text data typed field, but it added more difficulty to the retrieval of the queries.  Because we were inserting the selection criteria of the users straight into the base T-SQL queries, we had also opened up the possibility for SQL injection attacks.

By using the stored procedures with parameters I have significantly reduced the possibility of a SQL injection attack, the stored procedures are much easier to work with through the upgrade cycle and flexibility does not appear to have been compromised.  The only thing that has become more difficult is the passing of multi-valued selections into the stored procedures.  There are ways around this and I will outline the one I’m using in a future post.

One of the things I did on the last framework I built was create a utility program that allowed for the creation and editing of the database components of the reporting solution.  I’m planning on creating this feature again, but this time with the additional ability to create an easy upgrade process for disseminating the new, or altered, reports.

Currently this reporting framework is not as functional as the ones I’ve built in the past.  It still requires the ability to alter the report layout and groupings, as well as the ability selection criteria to trigger changes in the state of other selection criteria.  Once these things have been created, along with some sample reports, I’m planning on posting a thorough article on the framework and it’s portability.

I”m the Igloo Coder and I’m reporting today from deep inside the bowls of a mink whale while I wonder which end of the whale I will be extricated from.

There is an INETA webcast coming up on Wednesday March 22, 2006 between 1:30 and 2:30 MST that will discuss the ins and outs of setting up a Code Camp.  Via Thom Robbins.

For about 11 months now I’ve been at my current employer.  One of the things that has been different in that time is that the development team has had, and been able to request clarification on, software specifications.  In tribute to my experience with specs, I’ve decided to blog about my thoughts on them.  By no means is this intended to be a comprehensive review of software specs.  If you want that, read Software Requirements 2 by Karl Wiegers. 

Specs are so much more than documentation on how the system should work.  In addition to providing a strong foundation for the development of the intended software, specs will allow for the resulting software to be thoroughly tested, comprehensive documentation to be written and the development of training materials.  Probably the one thing that I’ve seen thus far that out ways any other benefit of having good specs has been the ability to use them to control scope creep.

Like any document, a software spec is only as good as the content it contains.  Not only does the content needs to be comprehensive and accurate, but the document also needs to be constructed in a searchable, scalable and readable format.  Because software specs can, and should, be used to create so many additional documents they also need to be written so they do not cater to any one specific role in the software development process/team.  Software specs also need to practice good encapsulation to ensure that contradictory specs don’t exist and, so that when the inevitable change requests start pouring in, the changes can be made in one location.

Document formatting is a finicky thing, even if it isn’t for specs.  Everyone has their own idea of what is best.  Regardless of the decided format, the document needs to be clear.  If possible, segment the contents of the document into sections using the formatting power in MS Word and then use the Table of Content feature to create a searchable outline.  In the end, decide on a format and refine it when necessary.  Even if the format is not perfect (few things ever are) maintaining consistency will go a long way to ensuring communicating effectively with the spec’s intended audience.

The contents of software specs will vary depending on the type of system and the type of contents being spec’d.  Software specs might include any number of things.  For example, a UI spec document may include information on control tab orders, data entry validation, and data display formatting.  The one item that seems to be missed regularly from these documents is a section that outlines what to do in exceptional circumstances.  When we create software specs and envision the system at it’s completion, we don’t think about how to handle situations that may break it.  Always ensure that there is a section outlining these situations and how to handle them.  If you think that there aren’t any, review the spec again because you’ve probably missed some.

The real reason for writing the software spec’s is to facilitate the transfer of knowledge between people in different roles during the software development process.  You must know the audience that you are writing the document for.  Yes, it could be read by anyone in the end, but if you write it for the broad audience it will not be informative enough to be helpful to the primary audience.  Imagine trying to read a document meant to describe business process and practice that has been written focusing primarily on the technical implementation of said business process.  It wouldn’t be informative to a business user and possibly would cause more confusion then it would answer questions.

One of the ideas of OOP is encapsulation.  This may be the one case where business can apply programming practices to it’s daily work.  By robustly encapsulating software spec’s, the writer offers distinct segmentation of the information provided by the specs.  Encapsulation of spec documentation will also reduce the possibility of specific items existing in multiple places with multiple contradicting definitions.  General, system wide specifications should be defined centrally and those spec documents should be referenced rather than the information repeated.

If you disagree with what I’ve written or if you have something to add, leave a comment or drop me a note.