I did a little survey to ask what people’s favourite albums were to code to, here’s the results. Hopefully will give some ideas for some different aural code fuel.

I’ve removed spurious entries and also those without albums which included:

SHARE:

I just had my 10th Pluralsight course released; Building .NET Console Applications in C# teaches how to create well-designed, fully-featured .NET Console applications.

When I hit 7 courses I wrote Three Things I’ve Learned Being a Pluralsight Course Author and those learnings still stand but there’s three other things that I think I also appreciate more now.

1 Continuous Improvement

As the saying goes: practice really does make perfect; though aiming for “perfection” is probably not a path to happiness. To paraphrase Mother Teresa: don’t try to do great things in this life, just do small things with great love.

We did not weave the web of life, we are merely strands in it

Continuous improvement doesn’t just apply to code, it applies to ourselves as a whole. A the name of this site implies, if we don’t take good care of our health (mental, physical, spiritual) then our code will be affected adversely. We know this from our own experience, we can bang our head against a problem and stay late for hours only to leave work without success, feeling tired and unproductive. The next morning we start work and solve the problem in 10 minutes. We are not machines, we shouldn’t think of ourselves as such. We are not Human Resources, we’re just Human.

I’ve learnt loads by being a Pluralsight author, maybe one day I’ll make it to 20 courses, there’s one thing for sure: my 20th course will be better than my 1st. We should all look for and feel a sense of progress, if we aren’t then maybe it’s time to revaluate our circumstances.

The goal of getting better and making progress is, I think, a better goal than becoming perfect.

2 Gratitude

No matter how cool the things we do for work are, it’s easy for the common to become unconsciously ignored.

Having my 10th course published is probably a good time to reflect with gratitude.

I’m grateful for:

• Being part of the Pluralsight vision to democratize online tech training for people around the world, because
• The work I do on course production helps people to get better at what they do
• The opportunity to create, and have what I create viewed by thousands of people around the world
• Being part of what really is a revolution in tech training, and Pluralsight really is leading the way for tech training
• And finally, simply being able to teach.

3 Changing the World

We sometimes don’t think of the ripples we send out into the world by our actions. No thing exists purely because of a single cause. A complex web of things brought the thing into existence.

Continuous improvement doesn’t just apply to code, it applies to ourselves as a whole

Take for example the clothes you are wearing right now. You aren’t wearing them simply because you bought them: someone made them, someone made the machine that made them, someone harvested the cotton that made them, someone planted the cotton, someone drilled the oil to make the diesel that delivered that t-shirt to the store, and so on.

In the same way, the work we do sends ripples into the world. When we make software, we change people’s lives. When someone learns and uses something from one of my courses, their software gets better, and their lives and the lives of their users is improved. This is a pretty amazing thing to be part of.

“We did not weave the web of life, we are merely strands in it. Whatever we do to the web we do to ourselves” – Chief Seattle.

SHARE:

I first became aware of the concept of “glide paths” in Getting Results the Agile Way. A glide path is an aeronautical term meaning: “the course followed by an aircraft or spacecraft when descending for a landing.” – Dictionary.com

Usually this refers to a low/no power descent which requires little effort.

Applying this concept to the work we do essentially means doing the harder/boring/tougher/difficult/unpleasant things earlier in the week so that towards the end of the week we are “gliding”, with less effort required as we’ve already done the worse tasks.

In addition to applying glide paths to the week, we can apply this to individual days: doing the tougher things at the start so as we get closer to finishing for the day, our tasks get easier.

The same thinking can also be employed by agile teams, for example doing the harder things earlier in the sprint.

The following diagram shows as we get more tired during the week, how the duration of a given task may increase:

This is not always the case obviously, everyone has different energy patterns, but becoming more self-aware we can apply ourselves to different kinds of work at the times where we get get the most output. Also it’s interesting that it may be better to do tasks requiring creativity when we’re tired.

Glide paths assume that we have some autonomy over the prioritisation of our tasks, even when we do have autonomy we my have little choice sometimes about when things get done. Even so, glide paths are a useful concept to have in our productivity toolboxes.

SHARE:

AutoHotkey is a free open source tool that does all kinds of cool things, one of which is hotstrings.

Hotstrings allow us to define shorthand phrases that get expanded into full text. For things we type often, creating hotstrings can save us valuable keystrokes.

Once AutoHotkey is installed, we can edit the script and add our hotstrings.

So, if we typed “dontcodetired.com” often, we could define a hotstring like this:

::dct::dontcodetired.com

Now when we type “dct” followed by an ending key such as space or enter, the “dct” gets auto-replaced with “dontcodetired.com”.

If we want the replacement to happen as soon as the last character is typed (in this case the “t”) and not have to press an ending key we add an asterisk after the first colon:

:*:dct::dontcodetired.com

Now as soon as the “t” key is pressed the replacement happens immediately.

To find out more about hotstrings and the other cool features of AutoHotkey, check out my Pluralsight course: Personal Productivity & Performance Tools for Windows Developers

SHARE:

When working with an MVVM Light sometime we need to “tell” the view that a command’s ability to be executed has changed.

For example, when a user clicks a Start button to start a countdown, the Start button should be disabled and the pause button should then be enabled.

If we’re binding a button to an MVVM Light RelayCommand, the button will automatically disable when then RelayCommand’s CanExecute function returns false.

For this to work, when the user clicks Start, the command will execute, but then we need to tell the Start and Pause commands to raise their CanExecuteChanged events. To do this we can call the RaiseCanExecuteChanged method on each RelayCommand that logically makes sense for our application.

One approach is to put this in each property setter, for example:

public const string IsPlayingPropertyName = "IsPlaying";
protected  bool _isplaying;

public  bool IsPlaying
{
    get
    {
        return _isplaying;
    }

    set
    {
        if (_isplaying == value)
        {
            return;
        }

        RaisePropertyChanging(IsPlayingPropertyName);
        _isplaying = value;
        RaisePropertyChanged(IsPlayingPropertyName);
              
        // RAISE CANEXECUTECHANGED HERE IN PROP SETTER
        PauseCommand.RaiseCanExecuteChanged();
        StartCommand.RaiseCanExecuteChanged();
    }
}

Now when this IsPlaying property changes, the Pause and Start buttons commands can execute will be updated.

A problem with this approach is that the logic to decide which RelayCommands CanExecuteChanged event gets raised in response to which properties are changing is distributed through all the property setters in the ViewModel. This can make it hard to reason about the changes in state of the ViewModel.

One alternative approach is to centralise this logic in a single method.

More...

SHARE:

Sometimes we need one step definition to know about parameter data that was passed to previous steps.

There’s 3 ways main ways to do this, each with various considerations.

Private Field in Binding Class

This is the simplest approach. Simply add a private field to your [Binding] class containing your step definitions.

In a step, just grab the parameter data and store it in this private field.

In later steps, retrieve the data from this private field.

This approach is simple but breaks down when we start to refactor our step definitions into multiple step definition classes; the private field data is not accessible between steps in different binding classes.

ScenarioContext

We can store data for the current executing scenario using the ScenarioContext class.

There's a number of ways to use it, but essentially it’s a dictionary that we can store arbitrary data and retrieve it by a key:

ScenarioContext.Current["age"] = 42;

This approach can be used even if we refactor step definitions out across multiple binding classes. The scenario context is shared between all steps for the lifetime that a scenario is executing.

This approach can start to get a little ugly, we also have to make sure our dictionary keys are correct in all the steps where we set or retrieve data.

By default, it’s also weakly-typed – the dictionary just stores objects so we can end up with casts every time we retrieve data.

Context Injection

The third method (which I wrote about previously) lets us take a dependency injection style approach, and define POCOs to represent the data (in a strongly typed way) that automatically gets injected into each of our binding classes.

Like ScenarioContext, this approach also works across multiple binding classes. Unlike ScenarioContext, we don’t have to worry about dictionary keys or casting.

If you’re new to SpecFlow and Gherkin, check out my Pluralsight course:  Automated Acceptance Testing with SpecFlow and Gherkin or if you understand the basics or have been using it for a while, check out  SpecFlow Tips and Tricks course to learn how to create more maintainable SpecFlow test automation solutions.

If you want to fill in the gaps in your C# knowledge be sure to check out my C# Tips and Traps training course from Pluralsight – get started with a free trial.

SHARE:

In MVVM Light, when we derive our ViewModel from ViewModelBase, we inherit a Cleanup() method.

This method can be overridden, by default it will unregister all messages for the ViewModel, so calling Cleanup() on our view model will prevent multiple subscriptions occurring if we navigate back to the ViewModel and register it again.

But where do we call Cleanup() ?

One method is to get the View to call the ViewModel’s Cleanup() method when it is unloaded.

We could write a codebehind “shim” to cast the View’s DataContext to our ViewModel type then call its Cleanup() method.

Another method is to use the Behaviours SDK (XAML).

Once we add this reference we can add some namespaces in our View XAML:

xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
xmlns:core="using:Microsoft.Xaml.Interactions.Core"

Now in our page, we can add the following XAML:

<interactivity:Interaction.Behaviors>
    <core:EventTriggerBehavior EventName="Unloaded">
        <core:CallMethodAction TargetObject="{Binding}" MethodName="Cleanup" />
    </core:EventTriggerBehavior>
</interactivity:Interaction.Behaviors>

Now every time the Page’s Unloaded event is raised, the Cleanup() method will be called on our ViewModel, which will unregister all messages for the bound ViewModel.

SHARE:

Hi, I thought it would be cool to collate peoples favourite music album to code to.

I created this Excel Web App survey – I would be grateful if you could take 15-seconds to tell me (anonymously) what your fave artist and album are:

http://bit.ly/programmermusicsurvey

Results will be published on the blog once the response sample set is high enough.

Thanks :)

SHARE:

My latest Pluralsight course was released today: SpecFlow Tips and Tricks is a short course to help those who are relatively new to SpecFlow and those who have been using it for a while and want to create more maintainable testing solutions.

The course focuses on 3 main areas:

• Steps and Bindings
• Hooks and Scoped Bindings
• Step Parameters and Data Tables

This course is a loose follow-up to my previous Automated Acceptance Testing with SpecFlow and Gherkin course that covers the Gherkin DSL and other fundamental SpecFlow topics.

You can check out the course on the Pluralsight website or on my author page.

You can start watching with a Pluralsight free trial.

SHARE:

Currently the Timer class is not available when targeting both Windows Phone 8 and Windows 8 Store Apps.

For the app I’m building I want the MVVMLight PCL ViewModel to update a property every second – the databound View then simply updates itself.

One solution is to implement your own Task based Timer as described in this Stack Overflow article.

Another approach could be to make use of Reactive Extensions Observable.Interval method to create a sequence that updates every n-seconds.

First off add the Reactive Extensions NuGet package to your PCL project.

Next, in the ViewModel constructor (or command, etc.) create the interval stream and then tell it to execute a method every second:

var timer = Observable.Interval(TimeSpan.FromSeconds(1)).DistinctUntilChanged();

timer.ObserveOn(SynchronizationContext.Current).Subscribe(TimerTick);

I’m using SynchronizationContext.Current because the TimerTick method (below) updates the ViewModel property, without this there is a thread access problem.

So the TimerTick method ends up being called every second and simply updates the (MVVMLight) TotalTimeLeft property:

private void TimerTick(long l)
{
    TotalTimeLeft = DateTime.Now.Second.ToString();
}

I’m not an expert on Rx so there may be a better way of using it in this instance (or some potential hidden problems) but it’s working in the app so far (and on ARM Surface RT)…

It’s however cool to know that Rx has portable class library support.

Any Rx experts feel free to comment on a better way :)

SHARE: