April 18, 2013

Finally... Google+ Comments in a blog post

I didn't realize I was waiting for this, but now that it's live, it makes me wonder why it hadn't happened earlier.

Reading and responding to comments can be one of the most rewarding aspects of blogging. Not only do they help you connect with your readers, they can also inspire later blog entries. The challenge, oftentimes, is following all the conversations around your contenton Google+, for instance, as well as on your website. So we're making things a lot simpler.

Starting today, you can bring Google+ Comments to your Blogger blog.

This post is for trying it out.

January 28, 2012

WP7 Series Part 2: Ensuring Blendability with Dependency Injection

Starting with MVVM

In WP7 Series Part 1 I explained that I wanted to build a Windows Phone application using some basic MVVM principles to maintain 'Blendability'. After tinkering with some options, I've decided to use the MVVM Light Toolkit as the basic framework. It provides some good tools for the toolbox but doesn't otherwise drastically change how I code.

After installing the toolkit and creating a new MVVMLight phone application, open the App.xaml file and you'll find an entry in the Application.Resources section that looks like this:

    <!--Global View Model Locator-->
    <ViewModel:ViewModelLocator x:Key="Locator" 
                                d:IsDataSource="True" />

This 'ViewModelLocator' is the heart of the MVVM Light framework and is meant to be used by every page to find its data context. It does so by assigning a property of the Locator resource to the page's context, like so (at the top of MainPage.xaml):

DataContext="{Binding Main, Source={StaticResource Locator}}"

This line basically says "bind my DataContext to the 'Main' property of the 'Locator' resource". Everything so far is great, and pretty straightforward. A quick look inside the ViewModelLocator.cs file shows that the 'Main' property is a static instance of the MainViewModel.cs class. I'm not going to go into the details of how the ViewModelLocator instanciates the ViewModels, though, because I don't particularly like how it works. I'll show my variation a bit farther down.

Meanwhile, let's glance inside the MainViewModel.cs class. One of the first things I notice is the way DesignTime vs RunTime data is decided.

public MainViewModel()
    if (IsInDesignMode)
        // Code runs in Blend --> create design time data.
        // Code runs "for real"

With this method, every ViewModel is going to have the same (or very similar) logic duplicated in its constructor. I'd rather have that logic centralized some place else, and have the ViewModel ignorant of its source of data (DesignTime or RunTime). It just uses whatever data it gets.

Enter Dependency Injection

Back to the ViewModelLocator. Since the ViewModelLocator is where the ViewModel classes get instanciated, it seems an appropriate place to decide where to get the data for the ViewModels. I understand that the MVVM Light Toolkit may eventually include a small Inversion of Control container (called SimpleIoc), but I'm comfortable with Ninject, so that's what I ended up using. It takes just a few seconds to install Ninject using NuGet.

In 'Blendable' apps, the concepts of design-time data and run-time data are equally important, so I decided to treat design-time data as an integral part of my data access layer. I like using the Repository pattern, even though its popularity may be waning in some circles, so it makes sense that I should have both design-time and run-time data repositories available.

After creating the repositories (as shown on the right, each implementing the IExampleRepository interface), I created Ninject modules for each of them. You'll notice I created a ViewModelModule; I use that in the ViewModelLocator also.

Now, returning to the ViewModelLocator, I can create a Ninject kernel, and add either the DesignTimeModule or the RunTimeModule depending on the same IsInDesignMode property that the MainViewModel was using. You can see that below in the BuildKernel() method.

My ViewModelLocator now looks like this:

public class ViewModelLocator
    private static StandardKernel _kernel;
    public ViewModelLocator()
    public IMainViewModel Main
        get { return _kernel.Get<IMainViewModel>(); }
    private static void BuildKernel()
        _kernel = new StandardKernel(new ViewModelModule());
        if (ViewModelBase.IsInDesignModeStatic)
            _kernel.Load(new DesignTimeDataModule());
            _kernel.Load(new RunTimeDataModule());

The final piece of the puzzle comes into place by changing the MainViewModel so that it's constructor asks for an IExampleRepository to be injected. The ViewModel itself doesn't care whether it's design-time data or run-time data.

The MainViewModel now looks like this:

public class MainViewModel : ViewModelBaseIMainViewModel
    private readonly IExampleRepository _repository;
    public MainViewModel(IExampleRepository repository)
        _repository = repository;
    public string ApplicationTitle
        get { return "MVVM LIGHT"; }
    public string PageName
        get { return "My page:"; }
    public string Welcome
        get { return _repository.GetWelcomeMessage(); }

The 'Welcome' message (displayed in the middle of the MainPage) is now retrieved through the injected repository, which may be either run-time or design-time data. The end result, in the emulator:

In Visual Studio, design view :

And, finally, in Expression Blend :

So there you have it: one way of injecting design-time and run-time data into a ViewModel using the ViewModelLocator and Dependency Injection, with just a few changes to the out-of-the-box MVVM Light template.

The code for this sample can be found at https://bitbucket.org/devadept/mvvmlightsample/

Read all posts in the WP7-Series

January 26, 2012

WP7 Series Part 1: To build a Windows Phone 7 app

And suddenly it's 2012... Where has the time gone? 

It's a new year, and I've decided to take on a new challenge by building a Windows Phone 7 app. I've had my Windows phone (an HTC HD7) for over a year, and I absolutely love it. I've not written a XAML app yet, nor a mobile app, but I saw mention of the 30 to Launch challenge a week or so ago, and have decided to give it a try.

I've done the File -> New Windows Phone Project a few times in the past year, but have never felt inspired enough to really delve into creating an app 'for realz', but one thing I do know: I don't want to use the standard out-of-the-box code-behind process. I really want to try to keep to an MVVM model and maintain good 'blendability'.

To that extent, I've tried to do a little research up front to look at some options. I could go the route that @kellabyte had taken during her learning experience and write much of the framework myself. Or, I could try to leverage as much as possible a framework somebody else has written, like Caliburn Micro or MVVM Light

I watched several of the training videos on Pluralsight, followed by all of the Full Stack series of videos, plus a few others like Laurent Bugnion's Deep Dive MVVM video on Channel 9. I've read through several tutorials, and browsed a bunch of open source code. I figure it's time to get off my butt and write some code.

So, after playing around with a few options, I've settled on a basic app structure that I'm happy with, that uses MVVM Light and Ninject at the core, along with a repository pattern wrapped around SQL CE for data. It allows for easy display of design-time-data in Blend, and adheres to MVVM very well. I'll explain more about the structure in my next post.

August 06, 2011

The organizational mindshift of Agile

Quite often, adopting Agile requires organizations to change more than expected, and sometimes more than the organizations are willing. I don't think that organizational leaders understand that Agile is not a set of practices or tools from which they can pick and choose, instantly transforming them into an 'Agile Organization'.

Instead, Agile is a set of values; often the values are foreign to those the organization has long held. Embracing these values requires adopting some new practices and tools, for certain, but it must be the values driving the change, not the tools.

I listened to an episode of the Agile Toolkit Podcast the other day, in which host Bob Payne and Kelly Allan discuss Agile and its relationship to W. Edwards Deming's management teachings. At about the 12:00 minute mark, this exchange discusses how much change an Agile transition demands from a traditional, conservative organization:
Kelly - Agile, I think, will help drive even more of Deming's thinking into, and I hope will drive out a lot of the prevailing notions of management as it's practiced. 
Bob - Yep. 
Kelly - So, what do I mean by that? In part, certain practices like pay for performance and performance appraisals, incentives and rewards and driving in fear and management by quota and management by results and these kinds of things, have no place in the Agile world. Agile rejects that.
Bob - We try.

Kelly - Yes. The rest of the organization, of course, is still stuck in that old management model. So Agile picked up all those things by - so, for example, Deming calls the annual performance appraisal one of the 'deadly diseases' that he lists. His eighth point is 'drive out fear from the organization'. Because if there's fear in the organization, you tamp down innovation, you tamp down experimentation, you tamp down new product development.
Those words, "they have no place in the Agile world", are pretty strong. And I agree with them. But I don't think many business leaders understand how strong the Agile values are when they say they're ready to transition to Agile. What they are wanting is to change a few things here and there, holding their core (often anti-Agile) values steady, and claim victory. They expect software to somehow get built better and faster, as if through some sort of magic applied with the Agile label.

In reality, the management practices of the past are simply dressed up to look like Agile, and continue to be applied as before. See, change is not so hard!

In his book The Art of Agile Development, author James Shore has this to say about the common practice of reporting time usage to management:
If the project is under time pressure - and projects usually are - stakeholders may want to know that the team is using its time wisely. Often, when the team mentions its velocity, stakeholders question it. "Why does it take 6 programmers a week to finish 12 days worth of work? Shouldn't they finish 30 days of work in that time?"
Although I prefer that stakeholders trust the team to schedule its tasks wisely, that trust takes time to develop. In the beginning, I often produce a report that shows how the programmers are using there time. This report requires that programmers track their time in detail, so I stop producing it as soon as possible, typically after a month or two.
In other words, this report, which has probably been a staple report for the organization over the years, is foreign to Agile, which values trusting your team over requiring the team to track time.

To the Agile mind, this time-tracking is waste, as it doesn't lead to working software; in fact it delays the working software. In the Agile point of view, this waste shows that the organization's Agile implementation is broken, and Agile itself demands that it get fixed.

An organization that isn't ready to consider that these practices and processes are broken, that isn't ready to consider rejecting them as Agile does, is simply not ready for Agile.

July 21, 2011

Agile and the Power of Feedback Loops

Last month I came across a great article on Wired Magazine titled "Harnessing the Power of Feedback Loops". It reminded me of the importance of one of the basic tenets of Agile programming methodologies, extremely short feedback loops.
The potential of the feedback loop to affect behavior was explored in the 1960s, most notably in the work of Albert Bandura, a Stanford University psychologist and pioneer in the study of behavior change and motivation. Drawing on several education experiments involving children, Bandura observed that giving individuals a clear goal and a means to evaluate their progress toward that goal greatly increased the likelihood that they would achieve it. He later expanded this notion into the concept of self-efficacy, which holds that the more we believe we can meet a goal, the more likely we will do so.
Many times I've seen 'agility' (as it pertains to software development) defined in terms of implementing certain processes and disciplines, or sometimes the lack of disciplines altogether. If you institute a two-week 'sprint', you must be Agile, right? Got a burndown chart? Agile. Don't like documentation? Skip it, and be more Agile!

That misses the point. The way I see it, the single most important aspect of software development agility is feedback. In a truly agile environment, we see feedback loops everywhere. The point of a short work cycle, whether you call them sprints or iterations, or forego them completely with the continuous pull of kanban, is to keep the feedback coming. Daily stand-up? All about meaningful feedback. Pair programming provides the ultimate real-time collaborative feedback between two programmers. Fast running automated unit tests? Feedback.
Why does putting our own data in front of us somehow compel us to act? In part, it’s that feedback taps into something core to the human experience, even to our biological origins. Like any organism, humans are self-regulating creatures, with a multitude of systems working to achieve homeostasis. Evolution itself, after all, is a feedback loop, albeit one so elongated as to be imperceptible by an individual. Feedback loops are how we learn, whether we call it trial and error or course correction. In so many areas of life, we succeed when we have some sense of where we stand and some evaluation of our progress. Indeed, we tend to crave this sort of information; it’s something we viscerally want to know, good or bad. As Stanford’s Bandura put it, “People are proactive, aspiring organisms.” Feedback taps into those aspirations.
It's important to remember, as we put in place all of these processes and tools and practices and policies to become 'agile', that the point of them all is to provide the feedback that we as humans are hard-wired to respond to. Feedback is the secret sauce of agile.