Most Popular Posts

  • There has not been recent blog activity

Most Commented On

  • There has not been recent blog activity

Current Bloggers



  • You have not yet contributed to any pages.

How Passion Saved Windows

Posted by Rob Reynolds, Friday, November 14, 2014 (5,164 views)

“Don’t worry about people stealing your ideas. If your ideas are any good, you’ll have to ram them down people’s throats.” – Howard H. Aiken

Look around today. There is so much that you can do on Windows with respect to automation that just wasn’t possible a few short years ago. It’s hard to see what has changed because our memories are sometimes so short about how it used to be, so let’s go back about 4 years ago to 2010. PowerShell was still young, there was no Chocolatey, and things like Puppet and Chef didn’t work on Windows yet.

Folks were leaving Windows left and right once they got a taste of how easy automation was in other OS platforms. Well versed folks. Loud folks. Folks that were at the top of their game heading out of Windows. Many others have considered it. You’ve all heard the “leaving .NET stories” from some of the best developers on the .NET platform. But what you may not have realized is that these folks were not just leaving .NET, they were leaving Windows entirely. Some of this was in part to limitations they were finding that just were not there in other OSes. What you are also missing are all the folks that were silently leaving. For every one person speaking out about it, there were many more of the silent losses. The system admins, fed up with GUIs and lack of automation, leaving for greener pastures. The developers who didn’t blog leaving the platform.

But a change has occurred more recently that has slowed that process. I believe it is better tools and automation of the Windows platform. Some people have shown such a passion that they’ve saved Windows as a platform for future generations.

So What Saved Windows?

PowerShellPowerShell – Arguably this could be seen as the catalyst that started it all. It came out in 2006 and while v1 was somewhat limited, v2 (Oct 2009) added huge improvements, including performance. PowerShell is prevalent now, but it had humble beginnings. When Jeffrey Snover saw a need for better automation in Windows, no one understood what he was trying to do. Most folks at Microsoft kept asking, why do you need that? But Jeffrey had such a passion for what was needed that he took a demotion to make it happen. And we are thankful for that because it shaped the face of Windows automation for all. Jeffrey’s passion brought us PowerShell, and it is continuing to bring us more things that have come out of his original Monad Manifesto from 2002.

ChocolateyChocolatey – In 2011 Chocolatey furthered the automation story of Windows with package management, something that other platforms have enjoyed for years. Rob Reynolds’ goals for Chocolatey in the beginning were simply to solve a need but it has since grown into so much more and is now making improvements to become a true package manager. It wasn’t the first approach to package management on Windows and it is certainly not the last. But it did many things right, it didn’t try to achieve lofty goals. It started working at the point of the native installers and official distribution points with a simple approach to packaging and very good helpers to achieve many abilities. When Rob first started working on it, most of his longtime technical friends questioned the relevance of it. Rob did not stop because he had a vision, a passion for making things happen. As his vision has been realized by many he is about to change the face of package management on Windows forever.

Puppet LabsPuppet (and other CM tools) – In 2011 Puppet started working on Windows thanks to Josh Cooper. He single-handedly brought Puppet’s excellent desired state configuration management to Windows (Chef also brought Windows support in 2011). Josh saw a need and convinced folks to try an experiment. That experiment has grown and has brought the last bits of what was needed to save Windows as a platform. His passion for bringing Puppet to Windows has grown into so much more than what it originally started out to do. And now it is arguably the best CM tool for any platform, as the Puppet Labs CEO stated at PuppetConf 2014, Puppet is becoming the lingua franca of infrastructure configuration.

The Effects of Passion

All of this passion for automation has really changed Microsoft. They have adopted automation as a strategy. They are moving to a model of openness, recently announcing that the entire .NET platform is going to be Open Source. They are getting behind Chocolatey with OneGet and getting it built into Windows. They announced PowerShell DSC last year and have made huge improvements in it since then. From where we are sitting, it appears Microsoft now gets it. The effects of passion have really turned the company around and has saved Windows. Windows is becoming the platform we all hoped it would be, it’s really bringing many folks to see it as a true platform for automation and that makes Windows a formidable platform for the foreseeable future.

Filed under: , , , , ,
Discuss (1)

Herding Code On Chocolatey

Posted by Rob Reynolds, Saturday, November 08, 2014 (4,049 views)

Recently I talked to Herding Code about the kickstarter, package moderation, OneGet, and where we are going with Chocolatey.

Listen now -

Filed under: ,
Discuss (0)

Chocolatey Kickstarter–Help Me Take Chocolatey to the Next Level

Posted by Rob Reynolds, Friday, October 17, 2014 (7,738 views)

I’m really excited to tell you about The Chocolatey Experience! We are taking Chocolatey to the next level and ensuring the longevity of the platform. But we can’t get there without your help! Please help me support Chocolatey and all of the improvements we need to make!
Filed under: ,
Discuss (0)

Durandal 2.0.1 Released. How You Can Help...

Posted by Rob Eisenberg, Wednesday, October 23, 2013 (7,167 views)

Durandal 2.0.1 is a patch release containing a number of bug fixes and improvements applied after the release of 2.0.0. There are no breaking API changes in this release and no new features; only fixes. You can find the full list of changes and their related issues in the Changes.txt file found here. With this release we've updated the following assets: all Nuget packages, the Bower package, the VSIX, the Mimosa Skeleton, the HTML and Raw zip downloads and the TypeScript definition file.

Additionally, we've updated the web site with fixes and improvements to existing articles. We've also added some new topics such as testing, SEO and localization. All these articles are now located in the repository under docs/2.x. So, if you want to make corrections, additions or create completely new topics, all you have to do is submit a pull request.

Next, we begin work on 2.1.0. This minor version will continue to incorporate fixes to bugs as we find them, but will also include some new functionality. We will also be upgrading our dependencies to their latest versions. There are some pretty neat things planned, so keep a look out :)

If you are wondering how you can help out the Durandal project, here's a list of things you might consider doing:

  • Blog about Durandal: How To's, Tutorials, etc.
  • Make some instructional videos and post them to YouTube or Vimeo.
  • Speak about Durandal at user groups and conferences.
  • Help answer questions in the google group.
  • Follow the official Durandal twitter account: @durandaljs.
  • Star the Durandal project on GitHub.
  • Tweet about Durandal.
  • Consider donating or purchasing commercial support during your project.
  • Build awesome apps and tell everyone about it!

If you blog, speak publicly or make videos, please let me know and I will be glad to help get the word out. Thanks to everyone who contributed pull requests, reported bugs and made suggestions. This release wouldn't have happened without you!

Durandal’s Edge

Posted by Rob Eisenberg, Monday, October 21, 2013 (8,787 views)

With so many SPA-style frameworks emerging in the last couple years, you may wonder what makes Durandal unique or different. Why would you want to choose it for your next project?  I’d like to share a few key points to that end…

A Natural Alliance

Rather than re-invent the wheel, Durandal starts by combining and building on top of three existing libraries. Each of these libraries is very mature, has a large, active community and was strategically chosen because it meets one specific need very well. First we start with jQuery. In some ways you can think of it as a better DOM or the “missing JavaScript core library”. Next, we add in RequireJS, which gives us rich, declarative JavaScript modules. Finally, Knockout provides us with powerful two-way data-binding.

With these three libraries as a foundation, Durandal constructs a thin integration layer and transforms them into a powerful SPA framework. In addition to strategically connecting these libraries, Durandal adds new functionality. Some things Durandal adds are:  a client-side router, rich view composition, screen state management, pub/sub, simple conventions, modals/message boxes and more…

Maximum Skill Reuse

If you’ve worked with any of the three libraries listed above, then you already have skills you can leverage on a Durandal project. You already know part of the framework. This makes it relatively easy for existing web developers to get started. The time you’ve invested learning the three core libraries on prior traditional web projects translates directly to Durandal apps. Choosing Durandal is almost a “no brainer”.

Suppose you’ve never worked with jQuery, RequireJS or Knockout. Is Durandal worth your time to learn? Why not pick a different SPA framework that is “all inclusive”? The simple answer is YES, it is well worth your time. Here’s the longer answer: Almost every major SPA framework has a way to work with the DOM, create modules and declare data bindings. No matter what framework you pick, you are going to have to make the effort to learn these things both conceptually and in terms of the chosen library’s API. The difference with Durandal is that we get those capabilities from other libraries which were originally designed for traditional web development. That means that when you learn those things in the context of Durandal, you are also learning things you can directly apply to traditional web development too. It’s a huge return on investment.

Powerful Modularization

All Durandal code is modularized based on the AMD standard, which is supported by our use of RequireJS.  To my knowledge, Durandal is the only SPA framework based on this de-facto standard for JavaScript modularization. As a result, Durandal’s capabilities in this department far outshine everything. Because we use the AMD standard, there is no presentation-framework-specific code required to create modules. This not only keeps your own code clean, but also makes it more portable: You can write a Durandal module for use both in a SPA and in a traditional web application where Durandal itself is not even used.

But that’s only the beginning of the advantages…

The AMD spec is pluggable via the notion of loader plugins. These plugins can acquire and transform any resource in any way and supply it as a module dependency. Want to load some JSON data? You can do that declaratively. Want to load CoffeeScript? You can use a loader to compile it on the fly if you want. You can write loaders to do just about anything. Most of Durandal’s view engine is in fact supplied by the text loader plugin. What’s the really awesome thing about loaders? They can execute code both at runtime and at build time. This means you can have a loader optimize content as part of a build process, but not have to change your application code at all. It’s extremely powerful.

Speaking of the build process….RequireJS supplies a build tool called r.js. It essentially takes a list of modules as inputs and spits out 1-n optimized files. For a small or medium-sized application, you might choose to build to one optimized file. For larger apps, you might choose to build a shell with each feature area optimized into its own file…and download features on the fly based on live user usage. That and many more deployment scenarios are what this tool was designed for. On top of that, there are many higher level build tools that work with RequireJS. You can use Grunt, Mimosa or even Durandal’s Weyland to automate the process.

Language support for AMD is also great. If you are using CoffeeScript, you’ll quickly notice that it’s function and block syntax makes defining modules really clean. But an even better  experience is had when using TypeScript because it has direct language support for the concept of modules. When you compile your TypeScript code you just tell it that you want AMD modules and it will spit out JavaScript ready to work with RequireJS. But that’s not the end of it. The work on TypeScript modules, RequireJS and the AMD spec has been influencing the next version of JavaScript directly. RequireJS is already planning to provide a direct migration path for code written with it today to the native module implementation of the JavaScript of the future.

Beyond Unobtrusive

Because Durandal relies on AMD modules and a lite set of conventions, you actually don’t see Durandal itself in your code very much. Yes, you use its APIs to configure the framework and set up your application’s router, but beyond that you don’t invoke Durandal much at all. You won’t be calling into Durandal to create modules, controllers, models or anything else. You don’t need to inherit or extend from any special classes or objects. Most code in a Durandal application is vanilla JavaScript and you could take it out and use it without the framework at all. It’s particularly powerful when used in combination with the observable module, which allows you to also remove all traces of Knockout from your code as well.

Flexible Composition

Not only do you need the ability to break down complex applications into small modules, but you need to be able to “compose” these small pieces together again at runtime. The declarative features of the AMD specification enable you to do this with your JavaScript objects in much the same way that you would leverage IoC and even simple name-spacing in other languages. The result is powerful and flexible object composition right out of the box.

But you don’t just need to compose objects, you need to compose views. Fortunately, Durandal has the most powerful, declarative view composition engine available in any framework today. Here’s a short list of some things you can do declaratively:

  • Statically/Dynamically compose a child view into a parent, allowing the binding context of the parent to be applied to the child.
  • Statically/Dynamically compose a child view with it’s own binding context into a parent view.
  • Statically compose a model with a dynamically changing view.
  • Statically compose a view with a dynamically changing model.
  • Statically/Dynamically compose in a view while overriding parts of the view with custom HTML on a case-by-case basis in the parent. It can have it’s own binding context or inherit its parent’s.

This is just a few examples of what can be done. Keep in mind that in all these cases the composition can be configured with transition animations, optimized per composition site to cache views or be driven entirely by static or dynamically changing data.

Elegant Asynchronicity

Building rich clients usually involves asynchronous requests for data or other resources. Durandal was designed to handle this with elegance from the very beginning. To that point, Durandal uses promises throughout. Durandal’s own API exposes all potentially asynchronous commands via promises. Internally, Durandal also understands when you use promises and it can therefor cause the binding system, router and other key features to respond appropriately. Out of the box, our promise implementation is provided by jQuery. However, existing site documentation explains how you can switch that out in favor of your favorite promise library, such as Q.

If you are targeting an ES5 browser, you can then enable the observable module. When this module is active, it teaches the binding system to data-bind directly to promises. The result is that you can set up a foreach binding over a promise for an array of data. In your own code, you don’t have to handle the promise yourself at all.

Navigation & Screen State Management

Durandal’s router is perhaps the most powerful router available today. It is configured with simple route-to-module mappings but can also be configured for convention-based routing. It automatically handles bad routes, supports hash and push state navigation and provides a lot of capabilities around data driven routes such as parameters, optional parameters, splats and query strings. Additionally, we support the notion of “child routers” allowing you to structure and encapsulate entire areas of your application, reducing the overall complexity of the navigation structure.

In real applications you need more than just routing though. You need something which is occasionally called “screen state management.” What is that? Imagine you’ve got a customer filling out a form in your application. Before they save, they attempt to navigate to a new screen. The current screen is in a “dirty” state and the application may want to prevent the user from navigating away…or at least temporarily halt the process and ask the user what it should do with the data. In Durandal, the router supports something we call the “screen activation lifecycle” which allows any screen to synchronously or asynchronously control flow into and out of screens. But this functionality is implemented so that it’s decoupled from the router itself, thus Durandal also uses it to handle the lifecycle of its modal dialogs. In fact, you can use it anywhere in your app, even controlling fragments of a screen and individual component activations. This is a complex bit of functionality to get right but it is critical in real applications. Most frameworks just ignore it entirely, but not Durandal.

Enterprise Ready

Consistent Testability

SPA’s can be complex code-bases and such projects need to be tested. Durandal has this area covered well. Because we’ve built on RequireJS and all of your code is built as AMD modules, you can easily fake, mock, or stub any part of the system. This applies both to your code as well as all of Durandal’s modules. The test strategy is consistent.  In fact, if you want to see how to write unit tests for your application, all you have to do is fork the Durandal test suite, change some file paths and you are up and running with a test setup for yourself. If you are interested in testability, keep an eye on the site. Our upcoming release will contain additional documentation showing multiple strategies for testing.

SEO Optimization

From the beginning of work on Durandal 2.0, SEO was considered. Interestingly, much of this work has to be handled on the server for a SPA. That said, Durandal supports all the necessary client-side hooks and configuration options to enable full Google crawling of your application. Our next site release, coming this week, will show you how to do it.

Globalization and Localization

Modern applications need to be made available to diverse people groups. Today Durandal is being used by companies all over the world who are rolling out apps to multiple cultures. Since Durandal was designed to be pluggable, it actually only takes a few minutes to plug a localization solution into the binder. With just a few lines of code centralized in one part of your code-base, you can ensure that everything displayed on the screen is properly localized; no hassle, no fuss. As part of our release this week, you’ll see some new documentation showing you just that.

Responsible Versioning

The Durandal project follows Sematic Versioning with great rigor. APIs do not break on minor or patch releases. Minor releases contain only additions and patches contain only bug fixes. Only major version changes signal potential breakage. Those aren’t going to happen very often. When you depend on Durandal, you know exactly what the version numbers mean and what you can expect when updating. The docs from previous versions are made available perpetually and conversion guides are provided for major version changes. We handle integration of the dependent libraries for you as well.

Commercial Support and Training

Durandal has an active community that is happy to help you learn the framework as you work through your application’s unique challenges. Much discussion is taking place already in our Google Group as well as on Stack Overflow. However, if that is not enough for you, or if you or your business need a safety net, Durandal has a few options available to you.  First, we have commercial support. This is a monthly subscription you can cancel any time and is priced based on the team size. We usually have clients purchase the commercial support for the few months they are working on the project and then discontinue after a successful rollout. It’s a great bargain compared to traditional consulting prices and turnaround time is very good. Additionally, my company provides customized training either delivered in person at your place of business or virtually through a series of web meetings. Pricing is usually negotiated on a case by case basis depending on the depth, time length and number of students. Finally, in the next couple of months you are going to start seeing official video training become available. Some of this will be free and some of it will be available for a reasonable price, providing you not only with a way to learn directly from me, but also to financially support the project.


While there are several SPA frameworks available today, only Durandal has all the benefits and characteristics listed above. But not only is it one of the most powerful and flexible options today, it also provides you with a great return on investment for your non-SPA web work. On top of all that, it’s enterprise ready and the kind of training and support you would expect is readily available. And this is just the beginning. Wait until you see what’s next…

Leveraging your XAML MVVM Skills in HTML – Changing Binding Context

Posted by Derik Whittaker, Monday, October 14, 2013 (6,009 views)

This is a multi-part excerpt series from my PluralSight course Knockout for the XAML Developer 


Knockout for the XAML Developer

The Knockout for the XAML developer course helps XAML developers, whether you’re a WPF or Silverlight developer, take their existing MVVM skills and transition them to the exciting world of HTML development.

This series is going to be broken down into 6 parts and should be enough show you show you can leverage your existing MVVM Skills you acquired while building XAML based and apply those to building HTML application with Knockout JS

Series Table of Context

  1. Setting up the Data Context
  2. Working with Observable Properties
  3. Working with Observable Arrays
  4. Handling User Click Events
  5. Handling Binding Context Changes (this post)
  6. Changing UI Appearances based on Bindings


When building applications which use the MVVM pattern it is common to have deep view model.  Working with a deep view model is not difficult but it becomes easier if we change change our binding context to remove some of the property chaining.

Take a look at the XAML below and notice how I am chaining the properties in my binding setup


In XAML this can be accomplished by setting the DataContext property on a given control as seen below:


Once you set the DataContext all child controls will have this set as their root context.

When working with Knockout you can accomplish the EXACT same result by utilizing the ‘with’ binder.

How to change Context Binding in Knockout

Take a look at the HTML markup below and notice who I am still using property chaining.


Now by using the ‘with’ binding in Knockout I can update my markup to look like below


If you want to learn more about how your XAML MVVM skills transfer to HTML Development watch my Pluralsight Course – Knockout for the XAML Developer

Till next time,

P.S. – Check out any one of my other Pluralsight courses

    1. InDepth Knockout Validation - Online Training Course for Developers
    2. HTML for the XAML Developer - Online Training Course for .NET Developers
Discuss (1)

Leveraging your XAML MVVM Skills in HTML – Handling Click Events

Posted by Derik Whittaker, Thursday, October 10, 2013 (7,083 views)

This is a multi-part excerpt series from my PluralSight course Knockout for the XAML Developer 


Knockout for the XAML Developer

The Knockout for the XAML developer course helps XAML developers, whether you’re a WPF or Silverlight developer, take their existing MVVM skills and transition them to the exciting world of HTML development.

This series is going to be broken down into 6 parts and should be enough show you show you can leverage your existing MVVM Skills you acquired while building XAML based and apply those to building HTML application with Knockout JS

Series Table of Context

  1. Setting up the Data Context
  2. Working with Observable Properties
  3. Working with Observable Arrays
  4. Handling User Click Events (this post)
  5. Handling Binding Context Changes
  6. Changing UI Appearances based on Bindings


Once we understand how to setup our Data Context along w/ Observables we should learn how to handle user click events.  When following the MVVM pattern in XAML you would create a property in your bound view model which implements the ICommand interface and bind your button to this property as seen below.


Using this pattern is simple and easy.  One really great feature of the ICommand interface is the implementation of the CanExcute method.  This will enable or disable the user control based on the evaluation of a method in your view model.

Although Knockout does NOT have a direct 1 to 1 mapping for ICommand, we are able to achieve the exact same functionality within Knockout.

Knockout Bindings to handle user click events


The code above is pretty straight forward.  We are using ‘click’ bind and binding it to a method called ‘save’ in our underlying view model

Now, I mentioned that we do not have the 1 to 1 match for CanExecute in Knockout, this is true.  However, we can use the click binder in conjunction with the enable binder to achieve the exact same results

Knockout Bindings to enable/disable the User Control


As you can see from the code above we are still using the ‘click’ binder to bind to our save method but we are also using the ‘enable’ binder to bind to and evaluate the IsValid method.  If the evaluation returns true the control will be enabled, if it returns false, disabled.

If you want to learn more about how your XAML MVVM skills transfer to HTML Development watch my Pluralsight Course – Knockout for the XAML Developer

Till next time,

P.S. – Check out any one of my other Pluralsight courses

    1. InDepth Knockout Validation - Online Training Course for Developers
    2. HTML for the XAML Developer - Online Training Course for .NET Developers
Discuss (1)

Durandal vs. Framework “X”

Posted by Rob Eisenberg, Monday, October 07, 2013 (10,878 views)

Sometimes I am contacted by consultants or businesses regarding Durandal as it compares to other frameworks. And sometimes the questions that are asked take the form of “So and so says Durandal isn’t as good as Framework X because of Y. Is this true?” Frequently the people making the original statements aren’t basing them on correct information. Other times, they ignore the imperfections in their “framework of choice.” Below is a list I was asked to address recently for a customer who was very happy with Durandal, but who was receiving some pressures from a 3rd party who wanted them to switch to Angular.

1. Angular supports large scale applications better.

Durandal supports large apps at least as well as any other framework. I would say it supports them better because it is built from the ground up on RequireJS, which is a stronger and more flexible module system than Angular's. If you choose Angular for a large project, you will likely have to go through the process of building infrastructure and integration with a solution like RequireJS anyways. With Durandal, it's supported out of the box. Additionally, Durandal's module system, being based on AMD, doesn't introduce any presentation-library-specific code into your app modules. Even if you integrate RequireJS with Angular, you will still have to deal with Angular modules, thus ending up with two module systems in your app. With Durandal, you just build standard modules, as apposed to Angular modules. What is important about that is that RequireJS is forward looking, with a planned path to ES6 native modules and will provide a smooth transition when the time comes. Additionally, if you choose TypeScript as your language, you will find the experience to be gorgeous, since TypeScripts's language support for modules compiles directly into AMD modules. If you are using Angular with TS, you are always going to have the second layer of modules, not supported by the language and the generated code will have those two module systems as well. In actuality, I think it’s fair to say that Durandal is the best framework available today for large app development. It scales linearly from the smallest of apps to the largest with ease.

2. Angular has better community support and Google backs it.

I can't argue with Google financially backing Angular. If having a big company backing a JS library is a concern, that's an honest +1 for Angular. I can tell you that if you look at my personal open source project history, you will find that I've been more consistent than Google has with their developer projects. Currently, Google has multiple internal presentation tier libraries that are competing with one another. They aren't all going to be supported going forward. Furthermore, large initiatives such as Dart, have not chosen Angular as their library. (The Dart team chose Polymer, another Google initiative, after they had dumped a 3rd Google library.) If you look across Google's developer projects, you will also find that they are not shy to frequently break APIs and even kill products without much  notice. You can't choose a Google product thinking it has Microsoft's "10 year" support promise. It doesn't. I’m not sure you really get much advantage from Google’s backing at all, if any. It might even be worse.

Regarding better support, I'm not sure that's true at all. For example, Durandal has commercial support options available, with SLAs of course, and Angular does not. We have an active community communicating in our Google group and plenty of activity on SO as well. How big do you need your community to be? From what I can tell, most people are getting great help from our community and those that want even more have opted for commercial support.  I can tell you that every single support customer I have has been very happy.

3. Angular binding is easier than Knockout/Durandal.

This complaint usually refers to the need to use ko.observable et al instead of normal JS object attributes. However, Durandal 2.0 eliminates this need for ES5 browsers. That said, I believe this is not an entirely sincere complaint. The reason is that you still need to manually interact with the binding machinery in Angular. You need to really understand how scopes work in Angular and you need to work with those directly in many cases. You also need to understand the "digest cycle" and in certain cases, manually interact with it. Those concepts can be a significant learning hurdle in Angular, but they don't exist at all in Durandal. Some people may also like the html binding syntax in Angular better, but if you use Knockout 3.0 and Knockout Punches with Durandal 2.0’s observable module you will find that Durandal's experience is actually superior to Angular's. We can use normal properties, have more efficient and scalable data binding due to no digest cycle and we have a nice, rich declarative (and extensible) syntax. Finally, I'd like to point out that it's much easier to learn how to build custom binding handlers on top of Knockout's system than Angular's. Building custom bindings in Angular is a bit cryptic. There are usually lots of ways to do "similar" things but with subtle differences between them. You really need to understand the process very well, understanding how scopes, digest and even parsing work sometimes.

4. Angular has better support for existing UI control libraries like Kendo or Ignite.

I'm not sure what this statement is based on. We have people using Durandal with all sorts of libraries, including Kendo and Ignite. We even have documentation on Kendo integration as part of our official Docs and Infragistics has even blogged about using Ignite with Durandal. We also have great support for libraries like Breeze. I've personally used Durandal with tons of 3rd party libraries without issues and have seen the community do the same.

5. Angular is easier to get started with.

I'm having a hard time understanding this one. If you are using Visual Studio, just install the VSIX, then do New Project => ASP.NET MVC 4 Web Application =>Durandal SPA Template. That's it. You have a runnable, pre-configured navigation application. Just start adding pages. You can also use Mimosa, which has a single command line statement to generate a new Durandal project with the same capabilities. Alternatively, you can grab the HTML starter kit, unzip it and you are ready to go with the same setup. I'm not sure how to make it easier than unzipping a file or doing a "File => New Project". If the criticism is referring to Angular's ability to just add the library and then immediately start writing binding expressions in the page without a model or project structure….sure that's pretty simple, but nobody builds a real application like that. That's demo code and falsely represents the real app building experience. If you want to build a real app with Angular, you have to go through all the steps of setting up a project structure, creating modules and controllers, configuring routing, etc. I think if you go through those steps you will see that the Durandal equivalents are actually simpler and more standards-based. But, you don't have to do that because we provide you with great starter kits.

6. Angular has more free training.

It’s possible. Angular has been around longer. However, Durandal is growing pretty rapidly and is being spoken about at tons of conferences and code camps around the world. There are plans in the works to expand training options too. That said, there are pay training options with Durandal. I realize this is about "quantity" and "price" but if you want quality training, there are pay options for Durandal that can easily be afforded by most companies and individuals. I think a better question might be about quality of training materials, in which case I’d say that the frameworks are roughly equal. That said, we’ve got some big plans in this area that will be surfacing in the near future.

7. Angular has better documentation.

I'd just have to flat out disagree with this. Personally, I don't like Angular's docs. We've also had a number of people contact us directly to say that they specifically chose Durandal because it had better, more useful documentation than Angular. It is a big matter of opinion, I guess, depending on what your expectations are. Here's what Durandal has: a getting started guide, lots of "targeted" how tos, docs on integrating with other popular libraries, docs on how to build native apps, docs on build processes, docs on customizing the framework and in-depth references docs. In the next couple of weeks, we are releasing more docs. I take a lot of feedback from the community on the documentation and treat those requests the same as requests for bug fixes and features in the framework. We've also taken plenty of community contributions.

This should put to rest a few common objections which are frequently based on misinformation. This isn't an attempt to cut down Angular, but rather to show that Durandal is as capable. In many cases, Durandal does actually excel beyond other frameworks. I could go into detail concerning some of it’s unique benefits beyond what is mentioned here. It has many. But I wanted to focus on common, incorrect arguments that I have heard. Hopefully this helps to clear things up a bit.

Honored to be award the MVP for C# for the 6th year in a row

Posted by Derik Whittaker, Saturday, October 05, 2013 (4,583 views)

This post is a few days late but on October 1st I was honored to be awarded the MVP in C# for the 6th year in a row.  I am always honored to be renewed with this because of the company it keeps.

Sadly I will have to miss my first MVP summit later next month, although in fairness this is the 2nd one of 2013.

Thanks again Microsoft for the recognition.

Till next time,


P.S. – Check out any one of my 3 Pluralsight courses

    1. InDepth Knockout Validation - Online Training Course for Developers
    2. Knockout For the XAML Developer - Online Training Course for Developers
    3. HTML for the XAML Developer - Online Training Course for .NET Developers
Filed under:
Discuss (0)

DevReach Sessions (WebApi, TypeScript & Knockout)

Posted by Derik Whittaker, Friday, October 04, 2013 (6,332 views)

This year I was giving the honor of speaking at DevReach 2013 and I had a blast.  Telerik really puts on a world class event and treats their speakers and attendees to an amazing event.

If you attended my sessions or just want to take a look at the content you can download each session below.


Thanks again for Telerik for allowing me to come out and speak at this great event.

Till next time,

Discuss (0)

Injecting dependencies into AngularJS routeProvider's resolve

Posted by Billy McCafferty, Saturday, September 28, 2013 (7,196 views)

Now I'm not sayin' I wasted half of my Saturday to discover that you cannot inject dependencies into an AngularJS module's config function directly, but that you can, instead, inject dependencies into routeProvider's resolve within config.  But hypothetically speaking...completely hypothetically...if I did waste half my Saturday doing that, finding these two links 3 1/2 hours earlier would have been really really

Just sayin'

Billy McCafferty
Discuss (11)

InDepth Knockout Validation PluralSight Course is Live

Posted by Derik Whittaker, Thursday, September 26, 2013 (9,534 views)

I am happy to announce that my latest Pluralsight course has gone live.  This course is an InDepth look at how to use the Knockout Js Validation Library.


InDepth Knockout Validation

he In-depth Knockout Validation course will show you how to use every nook and cranny of the Knockout Validation library. You will see not only how to setup basic validation, but learn how to create your own rules. We will even go over how to tweak the configuration of the library to meet your particular needs.

This course is broken down into 4 different modules

Module 1 – Getting Started

This module is designed to provide you with an overview of the Knockout Validation library as well as get you up and running using the framework.

Module 2 – Basic Validation

In this module we review basic validation scenarios when using the library.  We will review each of the built in validators to ensure you have a clear understanding of what comes in the box

Module 3 – Advanced Validation

In this module we will learn how to create custom inline and custom shared validators.  We will also explore concepts such as conditional validation and HTML 5 validation techniques.

Module 4 – Advanced Configuration

In this module we will take a look at some of the advanced configuration scenarios that you may encounter when using this library.  These include items like changing the way messages are displayed to the user as well as how to provide custom styling for the validation.

Please take this course for a spin and let me know what you think

Till next time,

P.S. If you want to learn more about Knockout watch my Pluralsight Course on Knockout JS

P.S.S. If you want to learn how to transition your XAML skills to HTML you can watch my course on Html for the XAML Developer

Discuss (1)

Windows Phone HTTP Proxy Caching Issue

Posted by Derik Whittaker, Tuesday, September 17, 2013 (5,221 views)

Recently I noticed that when I did a http get to one of my API endpoints at work the request would come back with the same data no matter what.  I knew the data should be coming back differently because I would make a change to the backend data and it was not be reflected in the response.  To ensure that my API was working as expected I was able to verify that the response was coming back correctly in Postman as well as directly from the URL in Chrome.

I suspected my issue had something to do w/ request caching coming from the same client because I was making my get requests back to back, within 5 seconds.  To test my theory I added both a ‘Cache-Control’ and ‘Pragma’ request header to my request and set them both to ‘no-cache’ but that did not help.

Being a bit stumped here I reached out to our API developers to enlist their help.  The first thing they did was start watching the incoming traffic and noticed that my request was never actually leaving the device so there was no way it would ever return the new data.  To ensure this was just an emulator issue I deployed to my actual phone to see if the issue persisted there and sure enough it did.

We now knew that something inside of the Windows Phone was doing Http Get request caching… but how to fix it.

We figured we could solve the problem the simple, non-elegant way which is to take on a random query string to each request thus forcing each request to be unique.  This did work, but man did that feel dirty.

After doing a bit of research I came across the ‘If-Modified-Since’ request header.  The specs on this state the following:

The If-Modified-Since request-header field is used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.

This should work great all I needed to do was use this with the current date time.  Sure enough I added this request header along with DateTime.Now() and my get request made it to the server and I was able to get my updated data as expected.

Hope this helps,

Till next time,

Discuss (0)

Leveraging your XAML MVVM Skills in HTML – Working with Observable Arrays

Posted by Derik Whittaker, Tuesday, September 03, 2013 (8,084 views)

This is a multi-part excerpt series from my PluralSight course Knockout for the XAML Developer 


Knockout for the XAML Developer

The Knockout for the XAML developer course helps XAML developers, whether you’re a WPF or Silverlight developer, take their existing MVVM skills and transition them to the exciting world of HTML development.

This series is going to be broken down into 6 parts and should be enough show you show you can leverage your existing MVVM Skills you acquired while building XAML based and apply those to building HTML application with Knockout JS

Series Table of Context

  1. Setting up the Data Context
  2. Working with Observable Properties
  3. Working with Observable Arrays (this post)
  4. Handling User Click Events
  5. Handling Binding Context Changes
  6. Changing UI Appearances based on Bindings


After we have setup our view model and bound it to our markup thing we would typically do is start setting up our observables.  In my prior post we took a look at how to work with Observable Properties but what about working with an array of items? 

When working in XAML applications you would setup your observable collections as seen below.

How to setup an Observable Collection in XAML


The code above is pretty straight forward.  We have a property which is of type ObservableCollection.  When we setup our property we setup our backing field along with raising property change messages each time the array is populated.  One thing not illustrated here is what happens when an item is added or removed from the collection.  That is because this is handled by the ObservableCollection class.  Each time something is added or removed the underlying collection type will raise the notifications for us.

Now that we remember how to setup an observable collection in XAML how would we accomplish the same using KnockoutJS?

How to setup an Observable Array in Knockout Js


The image above is a 1 to 1 match for setting up an Observable Collection Knockout vs XAML.

If we break down our code (this code is written in Typescript)

  1. We first declare our property, in our case ReminderGuests
  2. We tell the Typescript Complier this is an ObservableArray of type UpcomingReminderModel (not needed if not using Typescript)
  3. We initialize our property via Knockout using ko.observableArray([]) (I like to init the array as empty out of convention)

We now have an observable array declared how do we use it in our Markup?


To use an Observable Array in Knockout as we need to do is use the ‘foreach’ binder and away we go.

If you want to learn more about how your XAML MVVM skills transfer to HTML Development watch my Pluralsight Course – Knockout for the XAML Developer

Till next time,

Discuss (2)

PuppetConf 2013

Posted by Rob Reynolds, Monday, August 26, 2013 (5,236 views)

I recently attended PuppetConf 2013 (the 3rd annual event) and all I can say coming away from that is wow. It was an amazing event with quite a few amazing speakers and sessions out there. There were over 100 speakers and more than 1200 attendees. And we had live streaming for quite a few sessions and keynotes that had a huge attendance (I don’t remember the number off the top of my head). With seven tracks going at a time, not including demos or hands on labs, it was quite an event.

Disclaimer: I work for Puppet Labs but my opinions are my own.

The venue was awesome (San Francisco at the Fairmont Hotel) and I wished that I had a little more time outside of the conference to go exploring. Being there as an attendee, speaker, employee, and volunteer, I saw all sides of the conference. Everything was well prepared and I saw no hiccups from any side. Walking around at some of the events I could hear a buzz in the air about Windows and I happened to overhear a few folks mention the word chocolatey, which was definitely cool considering the majority of folks that are at PuppetConf are mainly Linux with some mixing of environments. I’m hoping to see that start to tip next year.

There were 4 talks on Windows and I was able to make it to almost all of them (5 talks if you consider my hands on lab a talk). Only two of those were given by puppets, so it was nice to see some talks considering there were none last year (I need to verify this).

My Hands On Lab – Getting Chocolatey (Windows Package Provider) with Puppet


The hands on lab did not go so well. Apologies to the attendees of the lab, but there was an issue with the virtual machine that I had provided. It was corrupted somewhere between copying it from my box to all of the USB sticks that we gave to lab attendees. Since it was only a 40 minute lab, we had to switch to a quick demo.

I did promise those folks that I would get them a functional hands on lab and here it is: (You can take advantage of it as well for free!).

My Talk – Puppet On Windows: Now You’re Getting Chocolatey!


My talk went very smoothly. It was almost night and day having given a failing lab a little over an hour prior to a talk that had quite a bit of energy in the room. I enjoyed the feedback coming from the audience and the session went (I felt) very well. Sessions were recorded so be on the lookout for that to show up soon.  Until then you can check out the slides here: – and if you came to the session, I’d appreciate feedback on how I did and where I can improve. You can do that here:

Filed under: , , ,
Discuss (0)
More Posts Next page »

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)