When you continuously seek out the limit, you’ll realize that it’s often much higher than you expected. Yes, you can make that screen even simpler than the bare-boned version you’re looking at. Yes, you can trust your employees much more than you imagined. Yes, you can launch without a billing system.

Once you train yourself to seek out the limit in all endeavors, you’ll get better and faster at correcting the inevitable oversteps, and hit that peak performance.

But if you never dare venture close to the limit, you’ll find that it’s shrinking all the time. There will be even more people you could possibly offend, even more bells that need whistling, ever more realities of the real world you cannot change.

From Seven degrees of slip.

Lately one of the limits I’ve hit were advanced threading concepts in .NET. It’s an area where I haven’t stepped much aside from some rather simple use cases & basic usage. But recently I had to solve few (non trivial for me) threading puzzles/exercises and today I’ve been hit by IIS showing ‘Deadlock detected’ for one of our Server components. It hurts…

In the same time it clearly shows a limit in my knowledge and experience. So, let’s hit it with an action plan: dig dipper in Threading. Then review those threading puzzles and sort out the deadlock out of the system.

Resources:

• Threading in C# by Joseph Albahari. It’s a book available online for free
• Concurrent Programming on Windows by Joe Duffy. Paper book and Kindle from Amazon

Both are well recommended on StackOverflow…

…the keynote speaker shared a story about a failed project. He joined the project a couple of years into the development, and the team had yet to release anything to production. He went on to detail that he was on the project another year and a half, with no production release in sight, and left the project.

This project was one of those legacy re-writes, given pretty much unlimited budget and resources, in hopes that this would produce the best possible replacement for the existing product. The project had budget, resources, executive backing and visibility, technical leadership, support from domain experts etc. etc. Yet the project was still a colossal failure. Why? It never released!

There are many reasons why you should release as soon as possible. But the main are to get a feedback from your target audience and validate your technical decisions. Both of them are extremely important at early development stage in order to confirm that you’re building what people will buy and you’re doing it right.

So, how are you doing it with Caliburn.Micro? Take same way, it just works!

However, there’s a small touch of Caliburn.Micro goodness you can add to your code to make it more maintainable. When you’re setting the URI for your Tile, use the INavigationService.UriFor<>() extension method. This will make your code a little more friendly for an eventual refactoring and for sure will save you from few nasty bugs.

Sample code:

var newTileData = new StandardTileData
{
    Title = "my tile",
    BackTitle = "my tile details",
    BackContent = "description",
};

ShellTile.Create(navigationService.UriFor<MyViewModel>()
                     .WithParam(x => x.ViewModelParameter, "some value")
                     .BuildUri(),
                 newTileData);

Piece of cake!

First of all, let’s define our application facing progress service:

public interface IProgressService {
    void Show();
    void Show(string text);
    void Hide();
}

Pretty simple, yes…

The implementation was partly inspired by Jeff Wilcox’s article about creating a global ProgressIndicator.

It’s pretty simple and straightforward: we’re getting the Root Application Frame and hooking up to the Navigated event. His arguments contain the page being navigated to. Then we’re attaching our instance of ProgressIndicator to that page. And the service uses Show/Hide methods to manipulate the state of indicator. The code:

public class ProgressService : IProgressService {
    const string DefaultIndicatorText = "Loading...";
    private readonly ProgressIndicator progressIndicator;

    public ProgressService(PhoneApplicationFrame rootFrame)
    {
        progressIndicator = new ProgressIndicator {Text = DefaultIndicatorText};

        rootFrame.Navigated += RootFrameOnNavigated;
    }

    private void RootFrameOnNavigated(object sender, NavigationEventArgs args)
    {
        var content = args.Content;
        var page = content as PhoneApplicationPage;
        if (page == null)
            return;

        page.SetValue(SystemTray.ProgressIndicatorProperty, progressIndicator);
    }

    public void Show()
    {
        Show(DefaultIndicatorText);
    }

    public void Show(string text)
    {
        progressIndicator.Text = text;
        progressIndicator.IsIndeterminate = true;
        progressIndicator.IsVisible = true;
    }

    public void Hide()
    {
        progressIndicator.IsIndeterminate = false;
        progressIndicator.IsVisible = false;
    }
}

The last piece of this mini-puzzle is wiring up the service to container and made it available to the rest of application:

public class AppBootstrapper : PhoneBootstrapper {
    private PhoneContainer container;

    protected override void Configure()
    {
        container = new PhoneContainer(RootFrame);
        container.Instance<IProgressService>(new ProgressService(RootFrame));

That’s all. Now declare a dependency on IProgressService whenever you need it and show/hide to give a nice feedback to the User when your application is doing something long. You never forget that User is the ultimate chief and judge in our business, right?..

It’s just a collection of simple projects that I’ve put together when a coworker asked me to show how he can use WCF without configuration files. He got feed up working with XML in web.config and wanted a cleaner and more understandable way to configure Windows Communication Foundation.

What’s in:

• How to use WCF in your unit tests (WcfWithoutConfigFile.Tests project). Sometimes you want to get your code tested at service boundaries and you want to involve also WCF. It contains, among a simple unit test, a base class for your tests so the test cases are clean and don’t contain plumbing code.
• Hosting WCF services in IIS (WcfWithoutConfigFile.WebHost project). Defining the service in .svc files and all required infrastructure to instantiate the service via code-only configuration.
• My favorite – hosting WCF service in IIS using Castle’s WcfIntegration facility  (WcfWithoutConfigFile.WebHost.Castle project). It leverages Castle Windsor container and WcfFacility to easily host/run/consume your WCF services. It also configures the service to use Windows authentication and shows how to retrieve client’s WindowsIdentity in the service. There is also a client project, WcfWithoutConfigFile.WebHost.Castle-Client that connects to service and does some operations.

WcfWithoutConfigFile.WebHost.Castle requires some configuration to get it working properly. Be sure to:

• Run it in IIS Express
• Enable Windows Authentication in project properties

And everyone is guessing what will be Microsoft pushing in the segment currently occupied by Silverlight. Now we have two available options, the new guy in the block – the HTML 5, and the good old and trusty WPF. Won’t mention Windows 8 here as it’s way to the Enterprise is too long to be considered as an option.

So, everyone is watching the next move of Microsoft as there is not a clear winner – HTML 5 is too young to be considered seriously and WPF is too old to be considered as a long-time investment. When Silverlight was a competitor the choice was rather easy, now picture is much more blurred.

In my view

XAML & .NET will stay with us. Will it be WPF, Metro or anything MS will roll out for Desktop and LOB applications it will be based on those two pillars. At least for 7-10 years we’re assured.

I’ll make few guesses, what MS’s steps will be after Silverlight end will be announced (it will be interesting to read it in a year or two):

• A promise that Silverlight 5 will be supported for next 3-4 years
• A tool for a relatively easy migration from Silverlight to WPF (and/or Windows 8 programming model) will be available
• Newer versions of WPF will promote features previously hyped as Silverlight’s exclusives (in-browser apps, sandboxing, web deployment & updates and others) minus the ability to run in browsers on various platforms.

As for companies struggling with the choice right now (and it will probably true for near future), you’ll have to decide:

• Interaction and Data intensive applications, Rich User Experience, Resource Intensive application, deep OS integration – embrace the WPF and be happy (if you don’t mind to lock yourself to MS and Windows).
• Platform independent, high user base, moderately interactive UIs, presentation and manipulation of small amounts of data – your best bet is the Web: HTML5, CSS3 and JavaScript will be your tools.

And if you still struggle with the choice the best thing you can do next is to look at your current development team. If they are more experienced and efficient with Web technologies you’re set. If they are mostly Desktop specialists then you’d want to explore their productivity to the max and get the release date closer. You’re sorted.

And the last word: don’t be a mono-disciplinary developer. Don’t lock yourself exclusively in Desktop or Web, Microsoft or LAMP or whatever. The day you’ll fail to pick, learn and use efficiently a new tool/framework will mean your career as a Professional Software Developer is done. Be open. Look around, there are so many amazing things in Software Development industry. Just pick something new and learn. It will be one of the best investments you can do in your future. You can do it right now…

And if you’re waiting eagerly for this update and nothing is coming, try this trick, it helped lot’s of people to get it when Zune says it has no updates.

So, now I have an unbranded Samsung Omnia 7 device with next software parameters:

• OS version: 7.0.7392.0
• Firmware revision number: 2424.11.2.3
• Hardware revision number: 3.15.0.4
• Radio software version: 2424.11.2.2
• Radio hardware version: 0.0.0.800
• Bootloader version: 5.2.1.4
• Chip SOC version: 0.36.2.0

And Zune says it has an update to 7.0.7403.0. Is it the Mango or some intermediary release? There is no way to see it unless… Let’s go!

Update log, just curios look later at the whole process and install experience

It’s 21:18, pushing Update button:

• Download is quick
• 21:19, Step 6 of 10: Restarting your phone…
• 21:20, Step 7 of 10: Creating a backup…
• 21.26, Step 8 of 10: Installing updates… (progress bar on the phone is moving)
• 21:31, Step 9 of 10: Restarting your phone…
• 21:31, Completed!

And right after that Zune started new update, saying it’s 7.10.7720.68. Is THIS Mango?

• This time download takes longer…
• 21:37, download completed
• 21:38, Step 4 of 9: Transferring updates
• 21.28, Step 5 of 9: Preparing to install
• 21:40, Step 6 of 9: Restarting your phone
• 21:42, Step 7 of 9: Installing updates (progress bar on the phone moving slowly)
• 21:59, Step 8 of 9: Restarting your phone
• 22:01, Step 9 of 9, Completing updates

“Checking for additional updates” – WHAT?

No, it’s finished now. It took ~45 minutes to install two updates.

Starting logo is changed, red now. Hey, it looks like I got Mango!

Software components that were updated:

• OS version: 7.10.7720.68
• Firmware revision number: 2424.11.8.5
• Radio software version: 2424.11.7.2
• Bootloader version: 5.8.1.9

So far I’m loving it.

Interesting moment came when he wanted to see if his service actually works. He quickly created another project (Windows Forms) to try connect to newly created service. When I’ve seen that I’ve suggested that a unit test project would be easier and more useful, he preferred to go his route and added buttons, large text block and some plumbing code to take service’s response to the screen.

I’m not blaming here (as he is rather new to .NET platform), but his approach has few disadvantages versus verifying a service using unit tests:

• it’s slower to create a minimally meaningful solution: a crappy screen with a button “connect” and large text box to see results? I’d prefer a test with an assertion and may be some console output
• it’s slower to analyze results: you have to scan the screen to see/analyze replies. I’d prefer that a test assertion would take care of that.
• it’s error prone: you have to rely on human input to test it. I’d prefer an automated approach.
• it’s not repeatable nor scalable: what if you have second service? 10 methods in service?. I’d create new test fixture and refactor existing code, not UI.
• …

… lot’s of things that are wrong with this approach.

Even if it’s a short living spike, new project, new feature – whatever needs a proof of code in working state – I’d prefer to write a test for it. And I’m not talking here about rigorous Test-Driven-Development approach. It’s more like acceptance testing at service or component boundaries, only to be sure that it works as expected. And creating an UI just to see that a service works – it sounds wrong to me. But those are “cultural differences”, I think…

PS: By “cultural differences” I mean past experience, habits, education, professional environment and so on…

Now, to reproduce the problem we have to follow Caliburn’s guidelines then make few changes:

• Create new Silverlight 4 application
• Add Caliburn.Micro NuGet package
• Configure your application to bootstrap Caliburn
• Add new Resource Dictionary to host your common styles/brushes/whatever
• Include your dictionary in MergedDictionaries section
• Add a fancy color brush and use it in ShellView.xaml by referencing it as a static resource
• Build your app

Your application will compile and run fine. However, you can spot few issues with your code:

• ShellView.xaml:
  • Xaml editor displaying warning: “The resource could not be resolved”
  • VS Designer will not use your resource on design surface
• App.xaml
  • Xaml editor displaying warning: “The designer does not support loading dictionaries that mix ‘ResourceDictionary’ items without a key and other items in the same collection. Please ensure that the ‘Resources’ property does not contain ‘ResourceDictionary’ items without a key, or that the ‘ResourceDictionary’ item is the only element in the collection.”

To solve this problem you have to modify your App.xaml.

The original App.xaml fragment, as by following recommendations:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Themes/Generic.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
        <local:AppBootstrapper x:Key="bootstrapper" />
    </Application.Resources>

Now, the corrected version that removes all issues I’ve described earlier:

    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="Themes/Generic.xaml" />
                <ResourceDictionary>
                    <local:AppBootstrapper x:Key="bootstrapper" />
                </ResourceDictionary>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

Actually, this fragment is the recommended way of instantiating boostrapper for WPF version of Caliburn.Micro. Why it isn’t recommended also for Silverlight? I don’t know. For our rather large project I haven’t seen any downgrades and issues using this approach. Just few annoying bugs were gone…

• Only highlight the issue in your revision details and allow quickly open it in browser
• Connect to your JIRA and show the list of issues with all filters, view details and pick issues to include in your commit.

Now we’ll focus on the easiest option to implement – displaying issue number in commit message  and open it in browser.

Required settings:

• Open Issue Tracking category in Settings dialog of TortoiseHG
• Set properties to
• Issue Regex: \b\w{3,7}-\d+\b
• Issue Link: http://your.jira.server.com:8080/browse/{0}
• Ignore the rest of settings for now

See the screenshot, it should look like this:

Now if your commit message in revision details will contain a code of an Issue (or what will be detected as code) it will be highlighted as a hyperlink and clicking it will open a browser with your Issue details in JIRA.

I’m trying to get a deeper integration working, unsuccessfully so far. When it will be done will publish a follow-up post…