Devlicio.us - Just the Tasty Bits

Parsing Twitter Date format to .Net DateTime

Derik Whittaker — Thu, 24 May 2012 12:53:17 GMT

Recently when I needed to parse the twitter datetime format into a .Net DateTime I found this post on the web showing how to do it. However, the format string in the post is setup for non-us format so I thought I would share how to do it for US formatted datetime.

const string format = "ddd MMMM dd HH:mm:ss zzzz yyyy";

var d = DateTime.ParseExact("Thu May 24 11:43:52 +0000 2012", format, System.Globalization.CultureInfo.InvariantCulture)

Hope this helps.

Till next time,

EntityCollection or EntityReferece error in EF when using .ToList()

Derik Whittaker — Fri, 18 May 2012 11:38:02 GMT

This is just odd and I am hoping someone can explain it to me. Today when doing a EF query (see below) I received the following error.

Here is the original EF Query which was causing the error

At first I was a bit stumped because this same query worked inside of LINQPad, which I know is using Linq-to-sql not Linq-to-Entities but they are close enough.

After a bit of thinking and staring at the code I thought maybe it was the compiler warning about access to disposed closures when accessing the ‘db’ variable, but that was not the issue either.

For grins I decided to remove the .ToList() from my statement (making it look like below) and it simply worked.

What I don’t understand really is WHY? Does anyone out there know the reason why?

Till next time,

Using TPL to access Async WCF Endpoints in ASP.net MVC

Derik Whittaker — Sun, 13 May 2012 20:07:37 GMT

I am in the process of building out a internal portal/dashboard for our company which will allow us to get a status of what is going on behind the scenes in our application. I want this site to utilize our existing WCF endpoint and as much existing code as possible. When doing this I realized pretty quickly that I needed to create Async Controller actions to hit our async endpoints which was a first for me. Of course the first thing I did was a quick Bing search to see if I could find some existing examples to help me a long. However, every example I found assumed that we were using the automatically generated proxy to access our endpoints rather than spinning up the connection manually via ChannelFactory and the service interface. Because I struggled to get this working I thought I would share my experiances in case others are having the same issue.

Our WCF Endpoint Definition

    [ServiceContract]
    public interface IScheduledEventsService
    {
        [OperationContract(AsyncPattern = true)]
        IAsyncResult BeginScheduledEvents(ScheduledEventsRequest request, AsyncCallback callback, object state);
        Result<IList<ScheduledEvent>> EndScheduledEvents(IAsyncResult result);

    }

One thing to point out about the code above, the actual return value from our endpoint is a Result<T>. The result class is a simple container envelope which provides us back some metadata, this is not something to worry about or to try to find online, you can simply ignore this for your needs

My MVC controller definition

public class ScheduledActivitiesController : AsyncController
{
        public Task<PartialViewResult> Listing()
        {            
            return Task.Factory
                .StartNew(() => GetScheduleActivitiesAsync())
                .ContinueWith(x => PartialView("_Listing", x.Result.ToList()));
        }

        private IList GetScheduleActivitiesAsync()
        {
            var baseUrl = ConfigurationManager.AppSettings["BaseWcfServerUrl"];

            var channel = ChannelHelper.CreateFor<IScheduledEventsService>(baseUrl);

            var myTask = Task.Factory
                .FromAsync(channel.BeginScheduledEvents,
                           new Func<IAsyncResult, Result<IList<ScheduledEvent>>>(channel.EndScheduledEvents),
                           new ScheduledEventsRequest(), 
                           null, 
                           TaskCreationOptions.None);

            var taskResult = myTask.Result;

            return taskResult.ResultItem;            
        }
}

The above code is our entire controller (well at least the important parts her). Please take note of 3 things

Our controller inherits off of AsyncController which is required to do async controller actions in MVC
My return type is a Task<PartialView> for the action, this is required
In the .ContinueWith I am returning the correct PartialView w/ the data

One thing I want to point out here is that when trying to get the .FromAsync logic to work I keep getting compiler warnings telling me about a mismatch. This was because at first I was NOT declaring my two Func<T> and just assumed the compiler knew what I meant (guess not). As soon as I actually defined my 2 Func<T> signatures (I have removed the first one as R# told me it was not needed and sure enough it was not) the compiler was happy.

As you can see, once you make the compiler happy (pesky compiler) this is pretty straight forward. Hope this helps someone.

Till next time,

Caliburn.Micro and MVVM on InfoQ

Rob Eisenberg — Mon, 07 May 2012 17:06:00 GMT

If you are interested to hear some of the back story behind Caliburn.Micro…or just curious about my own conception of MVVM and how it fits in with other popular UI design patterns, I hope you will check out this interview on InfoQ. As always, feedback is much appreciated. Happy Monday and have a blessed week

Using GridView ItemTemplate and ItemTemplateSelector at the same time

Derik Whittaker — Fri, 04 May 2012 17:56:49 GMT

If you are building a XAML based WinRT application which uses a GridView it is very likely you are going to use an ItemTemplate style OR use the ItemTemplateSelector to determine which style to use. This is great and using either of these could not be any easier. HOWEVER, make sure you do not have both of them set at the same time in your XAML. Because if you do use them both you will be left to wonder why your TemplateSelector code is NOT working, but your provided style is.

As far as I can tell the ItemTemplate trumps the ItemTemplateSelector and your selector will NEVER get executed.

You will want to either use just the ItemTemplate OR use the ItemTemplateSelector.

Hope this helps.

Till next time,

Render Action

Christopher Bennage — Mon, 30 Apr 2012 17:55:00 GMT

It’s common for a single web page to include data from many sources. Consider this screen shot from Project Silk. There are four separate items displayed.

The primary concern of the page is displaying a list of vehicles. However it also displays some statistics and a set of reminders. I labeled the stats and reminders as orthogonal because they are (in a sense) independent of the primary concern. Finally, there is the ambient data of the currently logged in user. I call this data ambient because we expect it to be present on all the pages in the application.

It’s a common practice in MVC-style applications to map a single controller action to a view. That is, it is the responsibility of a single action to produce everything that is needed to render a particular web page.

The difficulty with this approach is that other pages often need to render the same orthogonal data. Let’s examine the code for the action invoked by \vehicle\list.

public ActionResult List()
{
    AddCountryListToViewBag();

    var vehicles = Using<GetVehicleListForUser>()
        .Execute(CurrentUserId);

    var imminentReminders = Using<GetImminentRemindersForUser>()
        .Execute(CurrentUserId, DateTime.UtcNow);

    var statistics = Using<GetFleetSummaryStatistics>()
        .Execute(CurrentUserId);

    var model = new DashboardViewModel
                    {
                        User = CurrentUser,
                        VehicleListViewModel = new VehicleListViewModel(vehicles),
                        ImminentReminders = imminentReminders,
                        FleetSummaryStatistics = statistics
                    };

    return View(model);
}

Disregarding how you might feel about the Using<T> method to invoke commands and other such details, I want you to focus on the fact that the controller is composing a model. We generate a number of smaller viewmodels and then compose them into an instance of DashboardViewModel. The class DashboardViewModel only exists to tie together the four, otherwise independent data.

Personally, I prefer to avoid classes like DashboardViewModel and simply rely on dynamic typing in the view. However, others feel strongly about having IntelliSense support in the view.

Project Silk had separate actions just to serve up JSON:

public JsonResult JsonList()
    {
        var list = Using<GetVehicleListForUser>()
            .Execute(CurrentUserId)
            .Select(x => ToJsonVehicleViewModel(x))
            .ToList();

        return Json(list);
    }

You’ll notice that both JsonList and List use the same GetVehicleListForUser command for retrieving their data. JsonList also projected the data to a slightly different viewmodel.

Reducing the Code

While reevaluating this code for Project Liike, we decided to employ content negotiation. That is, we wanted a single endpoint, such as \vehicle\list, to return different representations of the data based upon a requested format. If the browser requested JSON, then \vehicle\list should return a list of the vehicles in JSON. If the browser requested markup, then the same endpoint should return HTML.

First, we needed to eliminate the differences between the JSON viewmodel and the HTML viewmodel. Without going deep into details, this wasn’t hard to do. In fact, it revealed that we had some presentation logic in the view that should not have been there. The real problem was that I wanted the action to look more like this:

public ActionResult List()
{
    var vehicles = Using<GetVehicleListForUser>()
        .Execute(CurrentUserId);

    return new ContentTypeAwareResult(vehicles);
}

Only, the view still needed the additional data of statistics and reminders. How should the view get it?

We decided to use RenderAction. RenderAction allows a view to invoke another action and render the results into the current view.

We needed to break out the other concerns into their own actions. For the sake of example, we’ll assume they are both on the VehicleController and named Reminders and Statistics. Each of these action would be responsible for getting a focused set of data. Then in the (imaginary) view for List we could invoke the actions like so:

// List.cshtml 
<ul>
@foreach (var vehicle in Model)
{
    <li>@vehicle.Name</li>
}
</ul>

<section role="reminders">
@{ Html.RenderAction( "Reminders", "Vehicle") }
</section>

<section role="statistics">
@{ Html.RenderAction( "Statistics", "Vehicle") }
</section>

Note that each action has it’s on associated view.

The value of using RenderAction is that we where able to create very simple actions on our controllers. We were also able to reuse the actions for rendering both markup and JSON.

A secondary benefit is the separation of concerns. For example, because we moved the responsibility of composition from the controller into the view, a designer could now revise the view for the \vehicle\list without needing to touch the code. They could remove any of the orthogonal concerns or even add new ones without introducing any breaking changes.

The Downside

There are a few caveats with this approach.

First, don’t confuse RenderAction with RenderPartial. RenderAction is for invoking a completely independent action, with its own view and model. RenderPartial is simply for renders a view based on a model passed to it (generally derived from the main viewmodel).

Secondly, avoid using RenderAction to render a form. It’s likely won’t work the way you’d expect.This means that any form rendering will need to occur in your primary view.

Thirdly, using RenderAction breaks the model-view-controller pattern. What I mean is that, in MVC, it’s assumed that the view does nothing more than render a model. Controllers invoke a view, and not vice versa. Using RenderAction breaks this rule. Personally, I have no problem breaking the rule when it results in code that is more simple and more easily maintained. Isn’t that the whole point of best practices anyway?

Comment on this post at dev.bennage.com

Incorrect Image Format Error -- x86 vs x64 vs Any CPU

Derik Whittaker — Wed, 25 Apr 2012 15:23:42 GMT

Today I was trying to wrap one of our .dll projects in a wcf endpoint and ran into an odd issue that took 3 hours to resolve and the mad skills of my co-worker James to help resolve.

Long story short, when I would F5 my web project which was hosting our WCF endpoints I would get the following message in the browser.

Of course when I got this I immediately jumped to the referencing project and made sure I had referenced all the needed child assemblies. When this checked out I then jumped to the BIN folder to make sure they were copied correctly, they were. When THIS failed I fired up Just Decompile to ensure that the version of the assemblies were right… All of this lead me NO WHERE.

Now that I have done the typical checks I resorted to firing up the Fusion Log viewer with hopes that this would help… Yea that did nothing….

At this point I was beating my head against the desk, this was also the point that I enlisted the skills and knowledge of James. As we were talking through the problem and looking around we made our way over to the project properties of the dll I was referencing. When looking over the properties James noticed that my target platform was x86 (seen below),

which immediately sent up the red flag for him (it did nothing for me). Of course the question of ‘why is this x86’ was asked to which I answered ‘I don’t know’ but I did know the that project was originally a console app project prior to being switched to a library project…. Ding, Ding, Ding…. Console apps are set to x86 by default not Any CPU.

Once we changed it to Any CPU and recompiled my issues were resolved (seen below)

The moral of the story is that if you get the ‘bad image’ error make sure you are not trying to reference an x86 assembly in your x64 projects.

Till next time,

EF + Overriding Equals == Massive headache

Derik Whittaker — Tue, 24 Apr 2012 09:46:50 GMT

Do you ever have one of those ‘Doh’ days? One of those days where you spend like 6 hours trying to replicate a bug simply so you can debug it. One of those days you wish you could have back? Well I had one of those last week, let me explain.

Recently I was trying to debug an issue where when I would add an instance of an object to the db contenxt sometimes it would take it and sometimes it would not. I tried for hours to replicate the exact steps so I could narrow down the issue but was not able to. Here is what I was essentially doing.

dbContext.MyCollection.Add( instance1 );
dbContext.MyCollection.Add( instance2 );
dbContext.MyCollection.Add( instance3 );
(of course my logic was not like this in the actual code, but it did boil down to this)

At the end of my 3 adds I would do dbContext.MyCollection.Count and expect to see 3, but in almost ALL cases I would get a 1, color me perplexed. To make it even more perplexing for me is that after each .Add I would check .EntityState of the newly added instance and in EVERY case it was NEW. I would also hashcode for each instance to ensure they were different and as you may have guessed they were….. WTF

Fast forward a few more hours of my swearing like a drunk sailor, beating my head on my desk I decided to chat with a co-worker of mine whose knowledge in EF is order of magnitude larger than mine. Although he did not know the direct reason for my pain he did make a magic assertion which lead me to remember something I did a few weeks back. He said,

Well when you add an instance to the collection EF will essentially just check that object for equality versus all the other objects in the collection to make sure they were different.

The minute he finished that sentence the ‘ah F@CK’ bomb went off in my head. See a few weeks prior, during very early development of this feature I had this brilliant idea that I needed to override the .Equals() method on my entity objects (yea I know, that was dumb) so I did. However, as my logic matured over time the .Equals did not keep up because at some point I had realized that I did not need to override that but I was entirely to lazy to delete my overridden method, oh that came back to hurt.

As soon as I realized that this may be the issue I blew away the .Equals() along with my override of GetHashCode() (which actually was simply a pass through to the base implementation) and what do you know, everything simply worked.

The moral of the story here is that when dealing with EF (or any ORM for that matter) I would highly suggest you do not override the .Equals() on your objects, unless you like pain and suffering

till next time,

The Manifold Blunders of Xaml–Part 1: Version and Platform Hell

Rob Eisenberg — Wed, 18 Apr 2012 15:43:00 GMT

I started work with “Xaml-based” platforms in the pre-Beta days of WPF, so I’ve been working with this technology longer than most. Back then I was utterly awed and inspired by it’s capabilities. Today I’m frustrated and sometimes outraged. As I’ve traveled to various conferences, worked with various companies and interacted with the many Caliburn.Micro users, I’ve discovered that I’m not the only one who feels this way. This blog series attempts to catalog a number of the issues, some of which have been there from the very beginning; others creeping in over time. This is an aggregate of my own observations and those of the community.

Versions

Let’s take a brief stroll through the platform timeline:

2006 – WPF 3.0
2007 – Silverlight 1
2007– WPF 3.5
2008 – Silverlight 2
2008 – WPF3.5 sp1
2009 – Silverlight 3
2010 - Silverlight 4
2010 – WP7
2010 – WPF4.0
2011 – Silverlight 5
2011 – WP7 Mango
2011 – Lakeshore¹
2012 – WinRT/Metro²

If we focus on the platforms and ignore their various versions, we have something like this:

2006 – WPF
2007 Silverlight 1.0 (no CLR)
2008 – Silverlight 2.0 (CLR)
2010 – WP7
2011 – Lakeshore
2012 – WinRT/Metro

So, it appears that Microsoft has released a new UI platform at least every two years! Let’s contrast that to the timeline for pre-Xaml UI technologies:

1985?– Win16
1995 – Win32
2001 – WinForms
2006 – WPF

Interesting. We have at least 5 – 6 years between platforms prior to Xaml, but it’s actually about 10yrs due to the fact that WinForms is just making Win32 available to managed languages. It’s just a wrapper around existing APIs. Each of the Xaml platforms is actually a different runtime altogether. So as far as platforms go, we’ve gone from one every 10yrs to one every 2 years. But that’s not all, let’s look at Xaml itself:

2006 – Xaml 2006 Spec
2008 – Silverlight 1 Xaml
2009 – Xaml 2009 Spec
2011 – Silverlight 5 Xaml
2012 – WinRT/Metro Xaml

Aside from the actual platforms released, we have a parallel divergence in Xaml markup capabilities. In 2006 the first version of Xaml was released. It was formally defined and released as a spec shortly after. When Silverlight came along, Microsoft failed to create a Xaml language compatible with their own specification. In fact, even Silverlight 5 doesn’t comply with the Xaml 2006 spec. In 2009 Microsoft released a new version of Xaml that fixed several important shortcomings with the 2006 spec….but not a single platform implemented it. WP7 is still playing catch-up with Silverlight and WPF. WinRT/Metro Xaml has less Xaml features than any platform. Furthermore, it significantly changes some aspects of Xaml altogether, making it compatible with almost nothing. Furthermore, some of the changes they are making will prevent it from ever becoming compatible in the future.

When I step back and try to look at this information objectively, the most natural conclusion I can come to is that Microsoft UI technologies are, and have been for the last five years, in a state of complete instability…and it doesn’t show any signs of change (esp. with the rumors that WP8 will not use Silverlight, but some variant of WinRT). You can’t count on anything. If we forget about app developers for a moment, and think about the ecosystem, imagine the effect this has on third party products, control vendors, open source frameworks and tooling. Every time MS spits out a new platform or Xaml flavor, the entire ecosystem has to start over.

My own Experience

I first wrote Caliburn for WPF when there was no word on anything like Silverlight existing. When Silverlight was first announced, it was branded WPF/e so I thought my framework would port. Unfortunately, when SL2 was made available, there were so many differences that I had no choice but to completely re-write Caliburn. Then, when WP7 was announced, I started porting Caliburn to that, only to discover that it was not possible. So, I did another complete re-write resulting in Caliburn.Micro. Now we have WinRT/Metro. I think I can port it, albeit, with a ton of conditional code. But, I’m not 100% sure yet. If it looks like another re-write…I’m done with this game.

Maintenance and Innovation

There are lots of negative side-effects to this sort of instability. The one that hits me most is that it creates a battle between maintenance and innovation. Again, speaking of my own project, I have plenty of ideas about how to improve Caliburn.Micro. I think some of them are minor niceties, but others are more along the innovative lines. But, you will never see any of them come to fruition. Why? Because the instability of the underlying platform, the constant release of new platforms…has put my project into a state of perpetual maintenance. I can’t innovate because I’m still trying to deal with the differences in WP7.5 and I’ve got developers (who can blame them?) banging down my door wanting to know when WinRT/Metro version will be available. It’s been discussed much in recent years as to why innovation seams to happen in non-Microsoft open source and on other platforms like Mac…while very little happens in Windows software. Could it be because we are spending our time re-writing everything every two years? and don’t have time to develop anything forward thinking?

Careless and Arbitrary

Sadly, many of the API and Xaml differences were completely avoidable. I remember one particular bug I had in Caliburn. It resulted from the fact that List<T>.Remove was implemented differently between WPF and Silverlight. In a particular scenario it would work fine on one platform and crash your app on another. There are hundreds, probably thousands of such issues, from the BCL all the way up through the UI stack. We aren’t talking about missing features here. We are talking about the same features which exhibit different behavior or have altered APIs. Sure, Microsoft worked hard to improve this with successive releases of Silverlight. But then came WP7, which stepped us back in time. Now look at WinRT. There are a number of changes that are completely arbitrary. They serve no technical purpose and don’t improve the API. They just make more work for developers who want to port code. If you want another fine example, just try to write a cross-framework design mode check.

A Lack of Understanding

Sigh. This one perfectly ironic issue really troubles me sometimes. Through all of this, I’ve realized that Microsoft doesn’t understand their own platform. I’ve got more to say on this later, but let’s look at this from an API perspective here. Consider this: every control specific to WP7 development could have been built on top of Silverlight without a need for a modified runtime. Most controls could have been implemented simply by styling an existing control or applying a template. For example, the Pivot control can be implemented using a tab control with a custom template and some attached behaviors. In fact, wouldn’t it have been cool if you could just use a Tab control in WP7 and it just changed it’s appearance to work on the phone?! Wait, wasn’t that the idea behind templating and adaptive layout to begin with? Here’s another example: Behaviors. Perhaps you didn’t know that Microsoft built this twice? In WPF there were Triggers. In fact, in both WPF and the Blend behavior system, there is a class called TriggerBase. They have the same name! They do the same thing! But, you can’t create custom triggers or actions in WPF because the ctor is marked internal. Did it not occur to anyone that they should just remove that instead of re-inventing the wheel? As a result, we now have two methods of doing triggers, and you have to know which to use for what. It’s even true in Silverlight, which has limited support for “traditional” triggers, but does have some. Ridiculous. I could go on and on about the types of internal and cross-platform inconsistencies MS has created by not simply understanding the core capabilities of their own framework.

All of this get’s really interesting if you consider that Mac is the platform that is considered most cutting edge and innovative in terms of UX…and they’ve scarcely had any major breaking changes since 2002. Considering that their phone apps run on their tablet and they are porting a number iOS features back to OSX…it must be nice only having to worry about two platforms and knowing that the OS vendor is making a visible, tangible effort to unify those two platforms…..but I’m getting off topic now.

End of Part One

There are lots of problems with Xaml, but I chose to start this series with one of my particular pain points. Some developers neither care nor are affected (yet) by these sorts of version issues, but they have a big effect on the surrounding ecosystem and are going to be with us for the next decade. Over the next several blog posts, we’ll discuss many other problems, some technical, some not so much, but all have been singled out by multiple members of the community (read: not just me) as problems. It is my hope that Microsoft employees working on these technologies will read this and seriously consider what they can do to improve things going forward or at least not perpetuate the same mistakes again. I also hope that .NET developers will take a long, hard look at this part of the platform and make an honest valuation of its strengths and weaknesses.

Footnotes

1. Lakeshore is the name I’ve been hearing thrown around for the Xaml-runtime for XBox, which sources say is Silverlight-based, but drastically altered. I have no official word from Microsoft on this. It’s just what I heard through the grapevine, though I’m fairly confident in the accuracy of the information. Supposedly this is what is powering the “apps” in the new XBox dashboard which was released around last Thanksgiving. EDIT: Apparently the XBox version is called Lakeview not Lakeshore.

2. I don’t actually know when WinRT/Metro will be released. I imagine that 2012 is a reasonable guess.

Working with Image Paths in WinRT–Something odd here

Derik Whittaker — Mon, 16 Apr 2012 10:25:25 GMT

Over the weekend I was pounding away at my first ‘WinRT’ application which I plan to submit to the marketplace. During this process I ran into some really odd issues with getting images to display in the UI at runtime.

Let me explain my issue:

I had images which were nested inside my Assets folder as below:
/Assets
-> /Category
-> /Animals
-> horse.png

These images were being bound to a view which was not in the root of the solution but rather in a views folder as below:
/Views
-> /Gameboard.xaml

Originally I was trying to use binding to the Image control to a ImageSource property. In my ImageSource property I was doing something like below

public ImageSource Image
{
	get
	{
		var uri = new Uri("ms-appx:///Assets/Category/Animals/horse.png");
		return new Bitmapimage(uri);
	}
}

When I would put a break point in the property everything appeared right, however when I would bind to the UI no image would show up. I then tried to play with the URI path by adding ../ by putting the full ‘pack’ uri in there but nothing seemed to work. To prove that the image was NOT loading I also hooked up the ImageFailed event to the image control and of course that was helpful by providing a ‘network error’ value (that was helpful).

**** Note ****
I knew the logic above was give-or-take valid because when I changed it too use an image in the root of the Assets folder everything worked just fine
**** Note ****

After over an hour and a half of trying everything I could think of I decided to screw binding to an ImageSource and bind directly to the string value for the path.

public string Image
{
	get
	{
		return "../Assets/Category/Animals/horse.png";
	}
}

When I changed my UI to bind to the new property everything magically worked as expected.

I am not sure if I was doing something wrong (likely the case) or if there is some hidden bug in WinRT, but I was able to get everything working.

Till next time,

Last Post

Hadi Hariri — Tue, 10 Apr 2012 18:03:00 GMT

I was invited to join Devlicious a few years ago by Jak and Brendan and very thankful for the opportunity. During this time, I have cross-posted some of my posts on both my personal site as well as here, and have found that as a result, conversations become segregated; somewhat expected.

As grateful as I am of the the privilege of being part of this great community, I value greatly conversations that arise from posts, and prefer to keep them in one place. It is easier for me, as well as you, dear reader. For this reason, I'll no longer be posting on here. If you'd like to continue the conversations, find me at my blog. I'd love for you to join the recent one about Dealing with Too many dependencies.

Once again, thank you to Jak, Brendan, and the entire Devlicious community, including my fellow bloggers. And most importantly, thank you.

GridView SelectedItem Binding Gotcha in WinRT

Derik Whittaker — Tue, 10 Apr 2012 08:32:00 GMT

Last night when I was doing some WinRT hacking I was trying to setup databinding to the selected item in the GridView control and I ran into a gotcha that I thought I would share.

First, I was using the ‘Split Application’ template for my C# project. This is important because this template will create a bunch to boiler plate code for you and I was taking this code and extending it.

When I was setting up my SelectedItem binding had had the following Xaml

When I ran the app everything ran fine but when I selected an item nothing happened. I quickly noticed what I thought was the issue, I had not enabled selection in the grid, aka SelectionMode=Single, so I added that. This made my Xaml look like:

I gave this a spin but nothing…..

Then I had a thought, maybe the bindings which allowed the Item to be clicked was causing this, turns out I was right. The boiler plate code does not use MVVM (a real shame and IMO this needs to be addressed by MS) but rather click events. This meant that the following attributes were set by default for the GridView via the template.

All told my Xaml was both setup to handling SelectedItem binding AND the click event. Turns out this is not allowed and will not allow your binding to work.

To solve my issue I simply removed the IsItemClickEnabled and ItemClick attributes and the now I could get the binding for SelectedItem to work.

Till next time,

Working with Tiles for Windows Metro Applications

Derik Whittaker — Sat, 31 Mar 2012 14:35:06 GMT

When building a Windows Metro (aka Windows 8) application it is important that your application have a nice looking tile. It is also encouraged to enable your tile to be ‘live’, meaning it can update itself with content based on some event, if that is relevant to your application. When you create your tile you can decide to have either a small tile which is 150px x 150px (this takes up one column in the UI) or to have a large tile which is 310px x 150px (this takes up 2 horizontal columns in the UI). It is up to you to decide if you to support only the small, only the large or both. Fortunately for you associating the images used could not be simpler.

Open the Package.appxmanifest
Open the Application UI tab
Provide an image in the correct logo box

If you only provide a small logo you will only have that option on the Start screen. If you only provide a wide logo that will be the one which is used. If you provide both, the wide will be used by default, but the user can switch to the small if they want.

Here are the logo’ used in the image above (remember I am NOT a graphic designer )

Small:

Wide:

Till next time,

CSharp.Target errors when using a Developer Preview version of a Metro Library

Derik Whittaker — Sun, 25 Mar 2012 13:19:02 GMT

When I finally got around to upgrading my Build tablet to run the Consumer Preview of both Windows 8 and VS 11 I immediately ran into an issue when trying to attach a ‘legacy’ VS11 project from the Developer Preview version to a new project using the Consumer preview.

The error I received can be seen below.

Turns out the problem is easy to solve. Open up the offending csproj file and look for the line which looks like:

Replace the line with

Once you replace the line you should be able to add the existing project as expected.

Till next time,

VS11, Silverlight and Ria Services Command line build issue (MSB4006)

Derik Whittaker — Tue, 20 Mar 2012 14:43:22 GMT

I just upgraded my dev laptop to Vs11 and all was great with the world….. Until I ran my command line build script on my Silverlight project. When my script failed with the following error I was perplexed because of course everything ran fine from INSIDE VS

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets(289,9): error
MSB4006: There is a circular dependency in the target dependency graph involving target "CopySilverlightApplications". [C:\
Development\Source\\Main\Website\Thunderbird\ThunderbirdServer\ThunderbirdServer.csproj]

At first I tried to diff the Microsoft.WebApplication.targets file to see what changed there but nothing looked out of place…hum.

Finally when chatting about this issue with a co-worker it dawned on me what my issue was. Our silverlight project uses RIA Services and because of this there is technically a circular dependency between the web project and the client project.

How?

The client knows about the server because the RIA services end points are created inside the web project and post build the client side RIA endpoints are pushed into the Client project.

The server knows about the client because as a silverlight project we had the server setup to copy the .xap file into the ClientBin folder

How did I resolve this?

I removed the Silverlight copy dependency inside my server project as seen below

I added a post build event inside my Silverlight client project do xcopy the .xap into the correct ClientBin folder in the web project.

Once I made this change I was able to do the following

Compile inside of VS with NO issues
Compile via MSBuild on the command line
F5 my application and run the silverlight client

Hope this helps someone else

Till next time,

Magic to my eyes

Derik Whittaker — Tue, 20 Mar 2012 00:58:43 GMT

I know this may be lame but this may simply be the best install feature ever invented…. Enough said J

Till next time,

Remote Work: Placeshift and Stay Highly Collaborative Part 1

Rob Reynolds — Sat, 10 Mar 2012 14:38:57 GMT

The biggest complaint most remote workers have in regards to working on a team? Feeling disconnected. The biggest complaint an office has about remote workers? They forget the remote workers are there and don’t always trust what they are doing. Want to learn how to get past both issues?

Hi, my name is Rob and I have a confession to make. I’m a remote worker four days a week. I’m a placeshift remote worker, and yet I am still highly collaborative with my team. “Placeshifting?” you say. “Highly collaborative?” you say. Over the next series of articles I am going to show you how this can be done.

If you are a business and you have not seriously looked into a technology known as Embodied Social Proxies, you are paying opportunity costs. You are losing money. More on that below. This series is for you so pay attention. I will highlight both business benefits and worker benefits.

If you are a worker and you have considered working from home (or just remotely) but you are not quite sure how you would make it work, this series is for you. Or you are already doing remote work and want to learn how to collaborate better.

Two Types of Remote Work

Timeshift – This is when you perform work at different intervals than the mainstream office may perform the work. Many folks have done this kind of work in one respect or another, even when working a regular full time job. If you ever went home and continued working in the evening, you have done what some might consider timeshift remote work. This series is not geared to this type of remote work.

Placeshift – Placeshifting is when you perform work at the same time as everyone else, but at a different location. This is what most people think of when they hear the term remote workers. If you ever have work from home days, you know what it is like to placeshift. This series is geared to this type of remote work.

The terms placeshifting and timeshifting are borrowed from media industry (television, music, etc) with respect to devices like DVRs. Not quite clear? When you record a TV show and watch it later you are timeshifting the show. Timeshifting dates back to the 1970s with VCRs and Betamax, while placeshifting media is a newer concept made possible by devices like the Slingbox. When you use a Slingbox to watch a show from a device like your phone at the same time the show is playing, you are placeshifting. The difference should be clear when you think of placeshifting as same time, different location and timeshifting as different time, location irrelevant.

This same terminology can be applied to remote work. Although I was hoping to coin the remote work types terminology, Anybots and GigaOm beat me to print with their recent article (How and why robots are placeshifting remote workers). At least this means the terminology is sound.

Bottom Line

Placeshifting remote work is not for everyone and not for every type of business work either. Some jobs have physical requirements or security requirements that negate the ability for remote work. Not every person is able to be productive in a setting outside the office (and the converse is also true). The world is not fair, okay? Get over it. If you are someone who can work by yourself and do so well without being easily distracted (read: there are ways to remove distractions in a work from home situation – I’ll touch on those), then it’s possible you have what it takes to be a remote worker.

Business: We Tried Remote Workers Before, It Didn’t Work

This is the argument I hear the most. The biggest problem with this argument is that it is subjective. Remote work itself is subjective/situational. No two remote workers are going to be alike, no two situations are going to be the same. It’s possible you tried remote work with an individual who was not able to work remotely effectively. It’s highly possible you had an employee who moved away and you wanted to keep them so you allowed them to work remotely. But you may not have set yourself (and the individual) up for success. How much planning and research did you do prior to these remote work situations? How much enabling were you towards your remote worker? Did you attempt to manage your remote worker in the same way as the centrally located folks? Have you even heard of Embodied Social Proxies prior to reading this?

The awareness I am trying to raise with you is that there are situations for businesses to make it work. And you can benefit hugely from remote workers if you do the proper planning, research and understand guidelines for making it work in your situation.

How Do I Benefit as a Business?

Talent Pool

Here’s a hard pill to swallow – you are limited by your talent pool. If you require people to be onsite for work, you are limited by the area in which you do business. I hate to be the one to inform you, but you are not the most awesome place to work. I’m sorry. No matter how awesome you are there is somewhere else that is more awesome and does x better. It’s a losing battle. Get over it already.

In this day and age less and less people will move just to work for you. If you expect the most talented folks in your industry to relocate for you, I have to tell you that 1990 called. I’m sorry to inform you it’s not going to happen in every case. And if it does, it’s borrowed time. Because someone else is going to attract them away.

It’s likely the most talented people in your industry will never work for you if you don’t have a remote option available. There are many reasons, but it boils down to where you expect your talent to live.

Happy Workers Are Superfans (and Productive Workers)

This is so huge I can’t even begin to give it the proper amount of attention. You want your workers to be happy. Tom Preston-Werner, cofounder of GitHub, speaks to this in a presentation called Optimizing For Happiness. Please go there now. The bottom line is that you keep your workers happy, and they are much less likely to leave your organization. Turnover costs are huge to a company. If you are not making your employees happy, they are talking to others about not working for you. They have their ears open to new opportunities. They are likely looking for other jobs as you read this.

If you think you are making your employees happy, I would ask what metric you use for evaluation. I’ll be the first to tell you that you are not doing enough to keep your employees happy. If you give out raises once a year and they are around 3-5% across the board, you might be doing it wrong. Not every employee is created equal, not every employee performs at the same level. Why would you pay them the same? Why would you give them the same raises?

I’m going to make a bold statement here: Your best people outperform your middle of the line folks by ten times. If you are not paying them ten times as much or even five times as much, you might want to re-evaluate how truly happy you are making your employees. If you are not challenging your employees, you are boring them and they will find something more exciting. If you are not doing x you are likely not making your employees happy. You need better metrics into what makes for happy workers.

Facility Costs

Your facility costs are significantly cheaper when it comes to remote workers. A remote worker or semi-remote worker can take up a lot less space than a full time worker. If they come into the office once or twice a week, they will take up some space during that time, but the rest of the week that space could be used by other remote workers when then come into the office. Think of this as space sharing.

Remote workers don’t bring/keep a lot of items in the office. Seriously. Get up and walk around your office. Take a look. Notice how much stuff each worker has surrounding their areas. Notice how much space they take up. Go ask how much it costs for the space of each worker you have in the office per month. If you don’t have this number on hand, you won’t understand what it costs for that worker.

This actually isn’t that hard to calculate if you don’t have it. Just find out the costs of your office space on a monthly basis. Electricity, rent, etc. Now take that number and divide by the number of workers you have on site. This will give you a rough estimate. There are ways to get more accurate estimates, but this is a good start.

For the space of that one onsite worker, you might be able to put 5-10 remote workers in there (if you build and use embodied social proxies which are highly recommended and will be discussed during this series). Imagine that. 5-10 remote workers in that same space. That means for every 10 remote workers you hire, you can only hire one onsite person. Kind of sounds weird to hear it like that, right?

Bigger Staff – More Work In The Pipeline

This is probably the most overlooked opportunity cost when it comes to remote workers. You are limited by the number of folks you have into what you can accomplish. When you open up to remote work, you also open up to the fact that you can take on more work. More work in some terms means more revenue for your business. This is huge.

Final Thoughts For Businesses

Remote work is not without its challenges. I can tell you that the benefits far outweigh the challenges. If you’ve tried remote work in the past and it didn’t work out, don’t let that be a limiter to trying again. If Thomas Edison quit the first time he failed, he may not have been credited with the invention of the light bulb as we know it! Failure is a step on the road to success. Food for thought.

Remote Work Series

Next up I’ll talk about what individuals need to be successful remote workers.
Building an Embodied Social Proxy, aka, the Remote Portal for a practical cost
Possibly other follow ups to come

Alt.Tekpub REST

Rob Eisenberg — Mon, 05 Mar 2012 06:43:00 GMT

Mr. Conery has been working through building a RESTful API over on his blog. He’s tired of theory and has called on the community to submit some concrete examples in order to shed some light on the situation. I’m no expert in this area (I usually stick to UI stuff), but I have some experience, so I thought I’d make a contribution. Here’s some thoughts.

Issuing a GET to http://api.alttekpub.com returns:

<alttekpub>
  <links>
    <link rel="self" href="..." />
    <link rel="rels/productions" href="..." />
    <link rel="rels/new-episodes" href="..." />
    <link rel="rels/productions-by-category" href="...?category={category_name}" />
  </links>
  <categories>
    <category name="Microsoft" />
    <category name="Ruby" />
    <category name="JavaScript" />
    <category name="Mobile" />
  </categories>
</alttekpub>

One of my goals here is that clients only need to know a single uri: http://api.alttekpub.com After that, they should be able to follow links inside the document in order to navigate all the data and exercise all the features of the API. Above, you can see that the alttekpub api exposes links to several other documents: productions, new episodes and productions by category. These are identified by a rel attribute which is used to specify the link’s relationship to the enclosing document. Every document has a link that points to itself at a minimum. The last link in this example is parameterized. The api provides the various options for parameters in its document below. Here’s an alternative way you could represent the same concept, by borrowing some ideas from html:

<alttekpub>
  <links>
    <link rel="self" href="..." />
    <link rel="rels/productions" href="..." />
    <link rel="rels/new-episodes" href="..." />
  </links>
  <form method="GET" action="...">
    <select name="category">
      <option value="Microsoft">Microsoft</option>
      <option value="Ruby">Ruby</option>
      <option value="Javascript">Javascript</option>
      <option value="Mobile">Mobile</option>
    </select>
  </form>
</alttekpub>

I actually like this a little better, but I’ve seen both ideas used here and there. What is neat is that the api is self-documenting and there’s no need for the client to know how to construct uris. Everything is provided by the server. Let’s ay we follow the link for rels/productions. Here’s what we might get back:

<productions>
  <links>
    <link rel="self" href="..." />
    <link rel="next" href="..." />
  </links>
  <production>
    <name>RavenDB</name>
    <author>Oren Eini</author>
    <links>
      <link rel="self" href="..." />
      <link rel="rels/episodes" href="..." />
    </links>
  </production>
  <production>
    <name>Art of Speaking</name>
    <author>Scott Hanselman</author>
    <links>
      <link rel="self" href="..." />
      <link rel="rels/episodes" href="..." />
    </links>
  </production>
  <!--other productions elided-->
</productions>

It’s just a simple list of productions. But, there’s a couple of things to note. First, notice the rel=”next” If there are a lot of productions, the server may choose to paginate them. If that is the case, and there’s a second page, we will have a link with rel=”next” as above. We can handle paging backwards in a similar fashion. In fact, there’s a host of standard rels which you can and should leverage when it make sense. You can find them here: http://www.iana.org/assignments/link-relations/link-relations.xml Another thing to note, is that we’ve represented the collection of episodes in a production with another link. Following the RavenDB production’s rels/episodes link yields:

<episodes>
  <links>
    <link rel="self" href="..." />
  </links>
  <episode>
    <links>
      <link rel="self" href="" />
    </links>
    <name>Why You Should Care About RavenDB</name>
    <description>We've all heard of NoSQL...</description>
    <videos>
      <video type="video/mp4" href="..." />
      <video type="video/ogg" href="..." />
    </videos>
  </episode>
  <episode>
    <links>
      <link rel="self" href="" />
    </links>
    <name>Understanding Document Names</name>
    <description>In this short episode we explain how documents are named with RavenDB - and why.</description>
    <videos>
      <video type="video/mp4" href="..." />
      <video type="video/ogg" href="..." />
    </videos>
  </episode>
</episodes>

There’s not really anything new here. We just have basic xml with links. In the above examples, I’ve only shown a “readonly” api for a custom vendor-specific format. But, these concepts can all be expanded on to model all sorts of things through links, forms, etc. Here’s a couple of ideas you can implement to improve things further:

Use JSON instead of XML :)
Add a “title” attribute to your links. This can be used by clients to display the UI. For example, a client might scan the links in a resource and generate a series of buttons or a toolbar for each link. It could use the title attribute to populate the button’s text. Clicking the button would just activate the link. It’s very similar to the way a browser’s <a /> tag works, and if the client is coded in this way, it allows a lot of flexibility for the service author. They can evolve and extend their service with less changes needed by api consumers.
Embed resources. After recording usage data, you might discover that a request for productions is quickly followed by a request for episodes. Perhaps you can improve the api usage experience by embedding the episodes in the production documents, so only a single request is needed? There are multiple ways you can design your format to handle this situation. But you might want to consider using something that’s already been designed for this scenario, such as HAL.

The takeaway here is that a key concept in REST is hypermedia controls, which I’ve represented mostly with links (and a form). These allow the API to document itself, alleviating the need for the client to be coded with specific knowledge of link construction. It also allows the service to evolve more easily by adding additional controls over time or by completely changing uri’s or even whether or not certain related documents are embedded.

Oh..and just a reminder that I’m not a REST expert. But hopefully this example sheds some light, however dim :)

WebApi and Json Deserialization into an object model

Derik Whittaker — Thu, 01 Mar 2012 22:22:31 GMT

If you use WebApi with the Asp.Net MVC framework you may not realize that there is some ‘magic’ that takes place under the hood to convert the over the wire data from Json into an object. You may not realize this because by default it ‘just works’, which is exactly what I want and what a framework should do.

However, if you are not using MVC and you are going to use WebApi endpoints from any other application you will have to handle this deserialization or transformation your self and we will find out that this is actually very easy.

If you are not familiar with the WebApi you can bounce over to a few of my prior posts about this topic:

When you set out to convert your Json data into an object you will want to do the following.

1) Include a reference to the System.Runtime.Serialization assembly in order to use the JsonValueExtension class.

2) Add a using statement for System.Runtime.Serialization.Json

3) Run the following in order to use the extension classes to turn your Json result into an object

response.Content
    .ReadAsAsync()
    .ContinueWith( readResult =>
                        {
                            var array = readResult.Result;

                            // How to transform the entire result from Json to an object
                            var episodes = array.ReadAsType<IList<Episode>>();
                                                                  
                            foreach ( var element in array )
                            {
                                // how to transform a single Json element to an object
                                var asEpisode = element.ReadAsType<Episode>();                                                                    
                            }

                        } );

The magic in the code above is the usage of the ReadAsType extension method. This method will hide any of the complexities of turning the Json value into an object.

As you can see manually converting your Json into an object is simple and very straight forward.

Till next time,

Consuming WebApi endpoints in your application

Derik Whittaker — Tue, 28 Feb 2012 14:35:46 GMT

In my prior post I walked you though how to setup WebApi in a self hosted environment. In this post we will take a look at how to consume a WebApi endpoint. We will do this by using the code from the prior example as well as by creating a new console application.

Before we get started you are going to want to create our console application and add references to the following assemblies.

System.Json
System.Net.Http
System.Net.Http.Formatting

Step 1: Creating our HttpClient

When connecting to any remote endpoint there are many ways to do this, in our post we are going to use the HttpClient which is part of the System.Net.Http namespace.

var httpClient = new HttpClient();

Step 2: Connecting to our endpoint and consuming our data

Once we have our httpClient created we need to do something useful with it. The code below is what is needed in order to do exactly this.

httpClient.GetAsync( "http://localhost:8080/endpoints/episode/" )
    .ContinueWith( result =>
                        {
                            var response = result.Result;

                            response.EnsureSuccessStatusCode();

                            response.Content
                                .ReadAsAsync<JsonArray>()
                                .ContinueWith( readResult =>
                                                    {
                                                        var array = readResult.Result;

                                                        foreach ( var element in array )
                                                        {
                                                            Console.WriteLine(element);
                                                        }

                                                    } );

                        } );

The code above is a bit much so lets take a few to break it down and take a closer look at its parts

The first thing we are doing is using the HttpClient to connect to the our endpoint. As you can see we are doing this Async via the Task Parallel library.
Next you should see that once we get a response from the remote endpoint we are going to handle the results via the .Result property. We will also want to ensure that the connection as valid so we should call response.EnsureSuccesStatusCode. If any status but success (200) is returned an exception will be thrown.
Once we know we have a good connection we need to read in the content. we will read the content via the ReasAsAsync method and provide it the type of JsonArray, this tells the code how to format/deserialize the result content stream. of course you could read this as a raw stream or string but that is no fun.
Once we have our formatted content we can do something useful with it. Of course in this example I am not converting my content into an object, I am leaving it as raw Json, but if need an object you can use the JsonSerializer to get an object.

As you can see consuming a WebApi is pretty straight forward and does involve a ton of coding or effort.

Till next time,

Zero to Self Hosting AspNet WebAPI in a few short steps

Derik Whittaker — Mon, 27 Feb 2012 10:42:40 GMT

So #AspNetWebAPI has finally reach beta and I finally have gotten off my a$$ and starting playing around with it. Sure I have read the info on line, I have sat through numerous sessions where it was being taught and all along I have been telling myself ‘this stuff kicks ass’ but I just not have not found the time to actually use it or learn it. That all changed today, and in typically fashion Glenn Block and team have delivered a kick ass, easy as pie solution to a tough issue. They have managed to take WCF and all of its glory and complication and made it dead simple to use.

This is going to be the first of 2 posts where I will walk you though step by step on how to setup and use the AspNetWebApi in a self hosted situation . This post will be how to self host the routes/services and the second post will be how to consume the services from a external (non-MVC) application.

Step 1: Create a windows console application

The simplest way to show how to do this is to create a console app, but of course you could have created a winform, wpf or Windows Service but console apps work just great.

One thing to not though is you will want to open up the Properties for your console app and make sure it is using the Full .net 4 framework, not the client profile. See blow:

Step 2: Getting the bits from Nuget to allow self hosting

The simplest way to get and register the bits needed is to fire up Nuget and download them. If you have not already installed the Nuget bits head over to Nuget.org and download them.

Once you Nuget up and running type in ‘Install-Package' AspNetWebApi.Selfhost’ as shown below.

When this is done running you should have the following assemblies added to your solution:

Step 3: Setting up a basic route and Setup Self Hosting

In order for your application to be able to host WebApi you will need to setup a basic route and the Self hosting Server. You will want to open up your Program.cs file and add the code below.

static void Main(string[] args)
{

    var selfHostConfiguraiton = new HttpSelfHostConfiguration( "http://localhost:8080" );
            
    selfHostConfiguraiton.Routes.MapHttpRoute(
        name: "DefaultApiRoute",
        routeTemplate: "endpoints/{controller}",
        defaults: null
        );

    using (var server = new HttpSelfHostServer(selfHostConfiguraiton))
    {

        server.OpenAsync().Wait();

        Console.WriteLine("Hosting at http://localhost:8080/endpoints/{controller}");

        Console.ReadLine();
    }

}

Breaking down the code above.

The first line is where you setup the configuration for the WebApiSelfHost Server. When setting this up you will need to make sure to put in a valid URL w/ port, if needed. You may need to use Netsh.exe to register the port if the port you are using is not already setup.
We are creating our default route. If you have done any Asp.net MVC work this should be confortable for you. The one difference here is we are using MapHttpRoute rather than MapRoute. The MapHttproute can be found in System.web.Http namespace
Lastly we are creating and starting our Self host Server. This is the magic goo.

Step 4: Creating your first controller

Like Asp.net MVC WebApi users a controller to handle inbound requests. However, we now use ApiController as our base class. The code below is my basic controller for handing the route I defined above.

public class EpisodeController : ApiController
{
    public IList GetAllEpisodes()
    {
        return new List
                    {
                        new Episode {Id = 1, Name = "Episode 1", ReleasedOn = DateTime.Now.AddDays( -10 )},
                        new Episode {Id = 2, Name = "Episode 2", ReleasedOn = DateTime.Now.AddDays( -5 )},
                        new Episode {Id = 3, Name = "Episode 3", ReleasedOn = DateTime.Now.AddDays( -3 )},
                        new Episode {Id = 4, Name = "Episode 4", ReleasedOn = DateTime.Now.AddDays( 0 )},
                    };
    }
}

Breaking down the code above.

We must inherit from ApiController
If you have done ANY WCF work you will notice that there are ServiceContrace or OperationContract attributes anyplace to be found on the controller….

Step 5: Creating the model to be used by your controller

So we have our controller, now it is time to create the Episode model which is being used by our controller.

public class Episode
{
    public int Id { get; set; }

    public string Name { get; set; }

    public DateTime ReleasedOn { get; set; }
}

Above is our model and if you have done any type of work with WCF you should notice straight away there is NO attributes. This is awesome

Step 6: Hit F5 and take WebApi For a spin

So we have created the SelfHosting service, we have created our route, we have created our controller and finally we have created out model. It appears to me we are ready to give this puppy a test ride.

Hit F5 in your project and open up a browser. Once your browser is up and running navigate to http://localhost:8080/endpoints/episode.

If all goes well you should see something like

You may notice this is use XML formatting by default. If you don’t want xml follow Glenn’s post on how to disable XML formatting.

Till next time,

Chocolatey - Guidance on Packaging Apps with Both an Install and Executable/Zip Option

Rob Reynolds — Sat, 25 Feb 2012 17:35:00 GMT

One of the thoughts I've been considering recently with chocolatey is consistency with packages and naming conventions as chocolatey continues to grow. It's fine to name packages by the app/tool name, that's both intuitive and expected. What I am more interested in is when an application has multiple installation options (ie. an MSI and a ZIP). It can become confusing for people to install these when they don't know what they are getting if they call a package that has both. If you start with one that has a .zip and later they release an MSI (nodejs anyone?), what do you call the package that installs the MSI? Do you keep around the executable? Do you rename the original package in response to the other option? Is there a third option?

One Option

If there is only one option available, you are fine to make the package name the same as the application/tool. This makes it intuitive and reduces confusion.

Multiple Options

To start putting together guidance on this and alleviate confusion, I see that we would move forward in these cases with three packages. One with no suffix, one with ".install" suffix, and one with ".commandline" suffix.

If you would take a quick look at 7zip (http://chocolatey.org/packages?q=7zip), you will notice there are three packages here.

7zip is what will ultimately be a virtual package
7zip.install is the package name for a package that uses a native installer (i.e. MSI, exe)
7zip.commandline is the package name for a package that has an executable / downloads & unpacks an archive / etc

7Zip right now is taking a dependency on 7zip.install (which makes it a meta package). When virtual packages (see Virtual Packages below) are ready, that dependency will be removed and the chocolateyinstall.ps1 file will look something like the following (this is not definitive of what it will look like though):

Install-VirtualPackage '7zip.commandline' '7zip.install'

You will notice I put the ".commandline" ahead of ".install". In the end, I think the behavior of a virtual package should default to a command line version. Why? There are folks that do not have administrative access to their machines. Chocolatey is really nice for them because they can install and use chocolatey without ever needing to assert administrative privileges. Marcel Hoyer (https://twitter.com/pixelplastic) first proposed the idea of being able to use chocolatey without administrative privileges. Him and I took pains to make chocolatey work for these scenarios. This did complicate chocolatey a little bit for the package maker, but in the end I think it is a really good thing. As a person inspecting a package to decide whether to install or not, they can see every point that the package maker mentioned they needed administrative privileges.

That said, the default will be the one on the leftmost side. You are beholden to the community in justifying why you didn't put the command line version first if you decide not to in the virtual package. But chocolatey won't constrain you on that because you may have a really good reason.

App Now has Multiple Options

When an application/tool moves to where it has multiple options, like an installer it didn't used to have, that's when it is time to break the package out to a virtual (meta for now until virtual is available) and create the other two packages with the correct suffixes as outlined in the guidance above.

Virtual Packages

For those confused about the idea of a virtual package, it allows folks to say I need to take a dependency on a PDFReader. PDFReader becomes a virtual package that does nothing other than point to all of the different pdf readers available. When someone installs the package that has a dependency on PDFReader, chocolatey looks at the virtual options and sees you have adobereader installed (one of the options in the list). So it moves on because you have met the virtual package requirements. If you have foxitreader installed, it moves on. Otherwise it picks the first item in the virtual tree and installs it as the default. More information? https://github.com/chocolatey/chocolatey/issues/7

Virtual Packages vs Meta Packages

A meta package is one that points to other packages. If you think of a package that does nothing more than take on dependencies to other packages, that is a meta package. A virtual package is like a meta package, except it has the concept of optional dependencies.

Ending Thoughts

This seems to be on the surface the best way to provide an intuitive user experience. There may be some things we learn along the way and adjust this as we go. If you are a package owner and you have packages that have both options, you may want to start getting them into this format. I myself have some work to do in this aspect.

Thoughts?

Original Discussion: http://groups.google.com/group/chocolatey/browse_thread/thread/a1d208b022dfc30f

Avoiding Prescriptive Requirements

Jak Charlton — Thu, 09 Feb 2012 03:50:00 GMT

Core Requirements

Requirements should be given as the Core Requirement, and avoid the common pitfall of providing Prescriptive Requirements

As an example, a core requirement in an insurance system may be:

As a user of the Broker system, I want to create a Settlement Batch of Eligible Documents across Insurance Policies

This is eminently testable, is clear and unambiguous, and has real business value, and it meets the general INVEST principle of good user stories (which is also a good maxim for any form of requirements):

It is Independent of other stories
It is easily Negotiated as to priority and value
It has real business Value
It is small enough to easily Estimate with some degree of certainty
It is of an appropriate Size for easy estimation, planning and prioritisation
It is able to be Tested both manually and in an automated fashion with clear and unambiguous pass or fail criteria, you can either do it or not

The stated requirement is not prescriptive, it does not specify how the user triggers this action, what data they need to provide, how they select the documents, nor does it specify what a "user of the Broker System" is within this context, nor what a Settlement Batch is, nor what an Eligible Document is. This means the requirement can be documented very early on, with little analysis work needed, allowing very quick comparison with other requirements, and very quick verification from the business as to the validity of the story.

Later this placeholder can be expanded in discussions between the technical teams and the business to include the actual definitions and scenarios that define its acceptance criteria:

The user must have the “Batch Creation” permission
Eligible Documents are those which are awaiting Settlement
A Settlement Batch is a group of Documents that will be dealt with together by the Claims Settlement system, so as to save managing on an individual policy level

This would lead to a requirement with maybe a dozen test scenarios giving all the variations of user and statuses that would allow or not allow the story to pass the test. All of these stories and scenarios are now easily tested with automated and repeatable testing.

At this point it would probably be obvious where within the UI this functionality should surface, and the design of the UI interaction can be worked out. This UI work is actually a very specific development skill within its own right - there is significant complexity in designing UI interactions that mirror both the technical system and the user’s mental model.

Through all of these steps, the original core requirement has not been changed, though its implementation and business logic may have evolved, changed and adapted to line up with other functionality.

Good requirements are merely a placeholder for a later conversation. Their level of completeness or accuracy only dictates your certainty in implementing them accurately and efficiently, but does not preclude moving forwards, and does not hold development up waiting on “complete requirements”.

As granularity increases, so does complexity required to understand, verify and implement, but oddly so does instability. By starting with core stories, you maintain a fairly stable set of requirements, and only deal with complexity when you need to, and suffer the instability only on individual scenarios.

Which brings us neatly to development

It is fairly well established now that development must be iterative within short cycles to increase its chance of being successful. Early feedback and revision saves massive amounts of time and effort correcting incorrect assumptions and poor translation.

The sooner a story enters development, the sooner a basic version of it can be demonstrated to business users, to verify against their assumptions, the faster it can be revised and the more accurately it will reflect the actual requirements. In addition it will expose underlying technical constraints and limitations earlier on.

Finding Out When Something Happened in Your Git Repo

Christopher Bennage — Wed, 08 Feb 2012 15:14:00 GMT

Acknowledgment: This is meant to be the Windows equivalent of Anders Janmyr’s excellent post on the subject of finding stuff with Git. Essentially, I’m translating some of Anders’ examples to Powershell and providing explanations for things that many Windows devs might not be familiar with.

This is the third in a series of posts providing a set of recipes for locating sundry and diverse thingies in a Git repository.

Determining when a file was added, deleted, modified, or renamed

You can include the --diff-filter argument with git log to find commits that include specific operations. For example:

git log --diff-filter=D # delete

git log --diff-filter=A # add

git log --diff-filter=M # modified

git log --diff-filter=R # rename

There are additional flags as well. Check the documentation. By default, git log just returns the commit id, author, date, and message. When using these filters I like to include --summary so that the list of operations in the commit are included as well.

N.B. If you run a git log command and your prompt turns into a : simply press q to exit.

I don’t think that you would ever want to return all of the operations of a specific type in the log however. Instead, you will probably want to find out when a specific file was operated on.

Let’s say that something was deleted and you need to find out when and by whom. You can pass a path to git log, though you’ll need to preced it with -- and a space to disambiguate it from other arguments. Armed with this and following Ander’s post you would expect to be able to do this:

git log --diff-filter=D --summary -- /path/to/deleted/file

And if you aren’t using Powershell this works as expected. I tested it with Git Bash (included with msysgit) and good ol’ cmd as well. Both work as expected.

However, when you attempt this in Powershell, git complains that the path is an ambiguous arugment. I was able to, um, “work around” it by creating an empty placeholder file at the location. Fortunately, Jay Hill heard my anguish on Twitter and dug up this post from Ethan Brown. In a nutshell, Powershell strips out the --. You can force it to be recognized by wrapping the argument in double qoutes:

git log --diff-filter=D --summary "--" /path/to/deleted/file

That works!

I’m guessing that Powershell considers -- to be an empty arugment and therefore something to be ignored. I also assume that when the file actually exists at the path that git is smart enough to recognize the argument as a path. (Indeed, the official documentations says that “paths may need to be prefixed”).

While we’re here, I also want to point out that you can use wild cards in the path. Perhaps you don’t know the exact path to the file, but you know that it was named monkey.js:

git log --diff-filter=D --summary -- **/monkey.js

Happy hunting!

Comment on this post at dev.bennage.com

Submit a patch

Hadi Hariri — Mon, 06 Feb 2012 16:56:08 GMT

We love to complain, and Twitter has just made is so much easier. By merely including a handle or keyword of some company or product, we can attract the attention of those we’re moaning about and have them run to try and solve our problem. The speed at which they run is proportionally direct to the number of followers we have or the ‘people we know’ (I have 10 followers but my best friend is a celebrity with 300K followers and RT’s anything I ask him to). Apparently it’s called Social Media Damage Control.

When it comes to software products, we’re quite good at it too. After all, that’s why we pay for software, to have someone to hear our roar on the other end of a phone, a forum or a twitter handle.

But that only applies to commercial software.

When it comes to OSS however, it seems different rules apply. Specially when it's free. Complaining about OSS is often viewed as ungrateful behavior. Numerous times I’ve seen reactions from OSS developers, contributors or merely a simple passer by, responding to a complaint with: submit a patch or well if you can do better, write your own framework. In other words, put up or shut up.

We’re not all Einstein's

It’s not always a patch they are after. At times, when you find a bug, an OSS team member can ask you for a failing unit test. Now granted that we all strive to unit test and promote unit testing, feeling that every developer should know, understand and practice unit testing, the reality of the matter is that it’s not all green pastures out there. For one reason or another, not everyone has that knowledge, the ability or the opportunity to. So often, sending a failing unit test can seem daunting.

Of course, coming back to patches, there’s the added issue of figuring out how to work with the given source control the project is using, get the right unit testing frameworks to run, creating new unit tests, making the necessary changes, submit them and wait for your pull request to be accepted. And that’s if the project is using a DVCS and you can figure out what Pull, Push, Clone, Fork and Checkout mean. All this doesn’t even take into account that you need to figure out how the actual code-base works. And we all know understanding other people’s code isn’t easy.

For someone that is merely using an OSS project, all this can be overwhelming, not to mention intimidating at times.

Lowering the barrier to adoption

The OSS community often complain how big “Enterprise” and “Microsoft” shops don’t buy into OSS. It seems they go for commercial software in order for their legal departments to have someone to sue in case things go wrong. A little far-fetched of course, but nonetheless something you hear often. These shops also go for commercial software because it provides them with someone to call, someone that won’t tell them to submit a patch or provide a unit test. Someone they can call when they need support and not be judged (or at least not humiliated publicly on a forum or mailing list). Of course, the somewhat sad irony of this is that often, the support provided on OSS projects outdoes commercial products by a long shot, and that’s not to mention OSS projects that offer the possibility of commercial support.

However, we need to look at ourselves and see how much of this low adoption of OSS that we’re so passionately fighting for is our fault. If we expect all the users of our projects to know how to work with our source control or compile the source and deal with dependencies, submit patches or work with our testing framework, all we’re doing is raising the entry barrier to OSS.

Before shouting that I’m stereotyping OSS projects, I’m not. I’m well aware that there are amazing projects out there with beautiful and thoughtful teams and communities around them that make many commercial support alternative envious. However, I’ve seen the submit a patch attitude often enough, over the many years I’ve been involved in OSS to warrant mentioning it.

What about me? What about my time?

Now there is the opposite side to all this. You. The Project Lead. The Core Contributor. The guy that has spent several years of his life giving to the community, contributing to OSS projects, helping others. Why should you, despite having given so much, take more of your time to help others. The minimum, that someone that is using your project (for free might you add), owes you, is a failing unit test. No? Not just some lousy steps to reproduce…

Here’s the thing. If you’re working on OSS, you’re doing it because you are benefiting from it. You benefit because you enjoy it. You benefit because you learn. You benefit because you potentially can rise to fame (albeit a micro-celebrity), and you benefit because it can ultimately provide you with potential consulting and training opportunities.

Nobody owes you anything for working on OSS!