BaffleBox.Show() #1

Self explanatory really:

Yep, gotta stop that operation completing successfully.

The WinRT / Windows 8 crux

Windows 8 looks like it is a crux were Windows desktop application developers no longer have an exclusive desktop/web differentiation. The boundaries are now blurred. With Windows 8 users will now come to expect a 'Metro' style look and feel meaning that WPF/Winform developers will either need to roll the own or move towards WinRT.

Perhaps it has never been about technology but about look and feel?

I like the idea of a technology change driven by user demand for look and feel. It does not feel as fundamental as the DOS/Windows crux of the late 80s but it does look like a tsunami.

Can Gnatt chart project management be agile?

Can a project be managed using Gantt charts and be agile? Of course, but why would you want do? Life is too short. The question is more telling than any answer.

Gantt charts have been widely used for a hundred years. Like all tools they have their sweet spot. Gantt charts are great for visualizing projects with immutable dependencies. That is dependencies that fundamentally cannot be changed. Like; do step A and then  step B, where step B cannot start until step A is finished. The common example is building a house, you cannot start the walls until the floor is completed. Likewise the roof cannot be constructed until the walls are completed. This approach has been, successfully, used by software development teams for decades. The UI can be built after the middle ware.

It is a question of what can you can do and efficiencies. If your team works best with a big design up front (BDUF) then this is probably your sweet spot, that is, you optimal. But if your team is more adaptable (dare I say agile) then this is a solution but not the optimal and may be a much slower way to completion. A question of potential and achievable.

Try managing  a project using a Gantt chart in Microsoft Project where the developers, to reduce time to delivery, develop the house's roof before the floor is done.

Assuming that commercial success is the goal (big assumption), the best option to report to higher management is always the facts. The project is X% completed and its estimated time of completion is XYZ. Management understands that. In fact, that is what they try to extract from a Gantt chart. But, like many approaches, Gantt charts can be used to redefine success with complex presentations that nobody understands.

The real issue is to measure functional completion where functional means 'functional' not just developed. This means accepted (testing) by the real users.

Planning for failure warning signes:

• More reference to "Gantt charts" than project management.
• Releases defined as 'coded' prior to user testing.
• Management repeatedly referring to 'sign off' on specifications.
• Demonizing the customers.
• Focus on department values over company commercial needs.

Am I allowed to buy movies?

I've spent a couple of hours tonight trying to find a sites where I can (legally) buy and download movies. Downloading movies is not now new, it is 2012. But I find that because I'm in Australia I cannot buy movies from many sites. Doh!

I'm a person ... with money ... in any case why does it that where I'm sitting? The movie has probably already been copied, I just want the warm and fuzzy of giving you money. Please take my money, right now $AU may be worth more than $US anyway.

I promise I will not let a wombat get the video .

Migrating from Silverlight to WPF

I've just completed migrating a Silverlight application to WPF. All up it took a few days. Not difficult, mostly tedious, but it become evident that some preparation and knowledge helps. So here are my notes.

The application's vital statistics:

• Silverlight 4
• Visual Studio 2010 with Resharper 6
  
• Several VS Silverlight projects with multiple common library assemblies
  
• MVVM
• No Silverlight IoC used
• Automated UATs using White (Silverlight) framework
  
• Telerik RadControls using charting, ribbon bar, data grid views, etc
  
• Highly interactive UI
  
• Multiple WCF services
• Entity framework & SQL server back end

Preparation

Changes and research needed prior to changing references to the WPF framework ...

Do a spike

I found a spike run useful. I converted a few base assemblies until I got to one that had a Silverlight control (e.g. a user control or page). This took a few hours and help greatly in planning the real attack. Discard the spike, you will do it better the second time.

Assembly Dependencies

Understand your application's Silverlight assembly dependencies, you need to work up from the bottom.

WPF reference assemblies

Do some research into Microsoft's WPF/Winforms reference assemblies. Referencing the wrong library is just too easy and can be time consuming to correct. Both WPF and Winforms have TextBox controls and Resharper is great but not a mind reader (yet). Take care when adding references.

e.g. PresentationFramework.dll, WindowsBase.dll, PresentationCore.dll

Clean-up orphaned files

Sometimes files are removed from an assembly without being deleted or removed from the repository. You need to make sure these 'orphaned' files are removed before migrating. Select each project in turn and click on the show all files button in Visual Studio. Delete the orphans from your disk and the repository.

Navigation

Remove all web page navigation before you start the migration proper. This may be the biggest part of the job, the application needs to behave as one application rather than multiple web pages.

Search your code for 'href', 'Uri', 'MappedUri', and 'NavigationService'. These must go.

Web specific controls

In our case we had a RadControls HtmlPlaceholder which we used to display PDF files. This was removed prior to migrating the code and a PDF reader added post code migration. I could not see a refactoring option here.

Code Migration

Getting the code to compile as a WPF application ...

Telerik RadControls

Possibly the easiest part. Got the WPF version and it compiled with very few differences. Actually, I do not remember any compile time changes. Nice one Telerik.

Note: Mitigated the cost of buying new WPF licenses by timing the change close to our Silverlight licenses renewal. Tell the bean counters the new license costs are X but this is offset by dropping the cost of license Y making our cost ....

However there were a few run-time behaviour differences which were probably base WPF framework differences. I list these later.

Migrating assemblies

The procedure to migrate an assembly, working up the reference hierarchy was:

1. Add a new dot net assembly (not Silverlight) with the same name as the one being replaced but with a clear suffix like "_X". Important: Tell VS to create it in the same folder as the existing assembly.
2. Remove the newly created assembly from the solution.
   
3. VS has created a folder for the new project in the existing assemblies folder. Navigate to that folder and move the project file down into the same folder as the existing project.
4. Add the moved project to the solution. As VS sorts projects alphabetically you will find in just below the one your replacing.
5. Copy the project's name space from the original project (do not change it until the entire migration is finished). Set the assembly name to be the same but with a suffix like the project name.
6. Add a reference to, as a minimum, PresentationFramework.dll, WindowsBase.dll, PresentationCore.dll.
   
7. Select the new project and click on "show all". Select all of the source files and folders and add them to the project until the new project has the same files and folders as the original project.
8. Try to compile the new project. You will need to change used namespaces. Typically the change will be to half a dozen namespaces in many files. So you will learn to do a search and replace (within the one project). This will break the compile of the original assembly but that does not matter so much.
   

Keep the old project in the solution until the migration is finished, you may need to navigate to solve errors in the migration, etc.

Migrating WCF service references

I did not find a way to migrate WCF service references. Create new ones in the new Dot Net assembly.

Run Time (Post code migration)

I did find some breaking differences. These were:

• Had to change a few Page controls to UserControls. WCF class hierarchy is a bit different. The compile error is clear and it was not difficult to do.
• The initialisation sequence is a little different. I need to move some initialisation code to different event handlers. I do not remember the details. This did take a few hours and was hit and miss. On one case I do remember I had to move some initialisation to an OnActivated event and add an "initialised" state. I'm sure that is not the intended way, but it worked.
• I had one binding that did need considerable rework. The binding was to an indexer. Looked like a control binding defect, should have worked. This one also took a few hours to resolve.
  

Conclusion

It proved viable to migrate our Silverlight application to WPF with few problems. Medium complexity job.

Code conversion took one developer a week. Planning and changes to the application are required before changing references to the WPF framework. Risk is low-moderate provided that your libraries, like Telerik, have a common WPF and Silverlight API.

However, defects were introduced. Most had very high visibility (ribbon bar blank) so are relatively low risk. A few were changes in control behaviour so rigorous post migration testing is required. So allow the same time for testing and introduced defect fixing as was required for the code conversion (pre-testing) stage. But ... if you have good automated UATs manual testing will still be necessary but there will be few introduced defects.

The Convenience of Conspiracy

Conspiracy is a respone for the ineffectual to resolve their position in a complex society.

Isn't being ineffectual somebody else's problem?

Using Log2Console from NLog via MSMQ

I've been using Log2Console to view real-time logging for a while using the Chainsaw target and UDP. But UDP is not reliable for fast real time logging. I found a simple way to configure NLog to send messages via MSMQ in the Log4JXml format used by Log2Console. It recon this could be used with any NLog target.

Here is the NLog config:

    <target name="messageQueue" xsi:type="MSMQ" queue=".\private$\log">
      <layout xsi:type="Log4JXmlEventLayout"/>
    </target>

So simple.

Rob

Cube Farm Designs That Cut Out Conversation

The 2006 Waterfall Conference proves to provide timeless value. Those who know of Alistair will appreciate his input on office layout here.

Code Smell Metric - Doco Fluff Metric (DFM)

Code documentation is one of those things that is so easy to do to without adding anything useful. The problem is that the added lines of code/text appear have no value and reduce code readability. A case of less is more. Documentation can be useful, but nonsense documentation is worse than no documentation at all.

So a metric that detects nonsense documentation ("fluff"?) is another little helper.

Here is a real world example:

        /// <summary>
        /// Thread Name.
        /// </summary>
        public string ThreadName;
        /// <summary>
        /// Time Stamp.
        /// </summary>
        public DateTime TimeStamp;

A trival example but I recon it is less readable than:

        public string ThreadName;
        public DateTime TimeStamp;

So the metric is: If the documentation, with white spaces removed, case insensitive matches the property, method, or type then flag as doco fluff.

Agile Software Testing 101: Stress Testing

So your a software tester and you have received a new build with a new feature to test. How do you stress test it? Not difficult, you just need to know the pattern of "Stress Testing" to find those weak points. Here is a simple agile "how to".

Agile principles can be applied to testing. When done they leverage the tester's skills with the developer's skills.

Steps:

1. Being agile (as we all are) you let the developer responsible know that you are about to test the new feature.
2. As agile means collocated, you make sure you are near the developer and he/she can see your screen. Think of this as limited-pair testing perhaps, an agile balance of full pairing and letting the developer get on with his job.
   
3. To enhance your pairing make sure you have a mirror so you can see the developer. Collaboration is critical to stress testing.
   
4. Now go to the UI page that uses the feature and sweep your mouse pointer over the page watching the developers. When you see signs of stress ... click.

Stress testing saves time and leverages agile principles of, well, whatever your company says is agile today.