DotNed podcast: Marcel Meijer over Windows Azure

In deze podcast spreekt Maurice de Beijer met Marcel Meijer over huidige stand van zaken bij Windows Azure. Ze blikken even terug op de eerste versie van Azure en wat je toen allemaal wel en niet kon. Het grootste deel van de podcast gaat over hoe Azure veranderd is en wat je tegenwoordig allemaal kan doen. Windows Azure is een dynamisch platform en er is dus veel nieuws te melden. Daarom komt niet alles aan bod en gaan we binnenkort een vervolg podcast opnemen.

Links:

 

Met dank aan onze sponsor RedGate.


Tips for optional parameters to ASP.NET MVC action methods

Here’s a quick ASP.NET MVC tip to help you be more productive and write cleaner code. We will see how to leverage C# 4′s optional and default parameters in our action methods for greatly simplifying our code while keeping it fully functional and error free.

Often you want to pass data to your controllers based on URL parameters. This can either be part of the URL itself in the case of route data or it can be part of the query string. In fact, this tip even works for input forms.

Let’s take a basic method which shows some census data, potentially filtered and sorted if that information is passed along, otherwise we’ll just show everything with a default sort.

value-types

This looks great, right? If you had a URL such as

    /census/detailsvaltype/1?sortAscending=false

It would work perfectly. But what if we omit sortAscending? Well, bool is a value type and doesn’t like missing data much:

crash

I’m just guessing, but most users don’t love this page.

So we can make the parameters strings (no MVC conversion required, missing data can be detected, etc.) like this. But notice how ugly and complex the code becomesnullables-with-convert

Yikes, we went from 1 line of code to many! However, (here’s the point of this post), let’s try that again with optional parameters:

optinoal-params

Almost as simple as the naive version. However, you see making the request with and without data works perfectly! In fact, the data passed to GetDataAndResult are the same here as for the complex variant.

With Data (filtered and ordered):
/census/detailsoptionaldefault/1?sortAscending=false

filtered-data

Without Data (unfiltered and default order):
/census/detailsoptionaldefault

with-no-data

How about that? Hope you find that useful! You can download the code and try it for yourself here: OptionalParamsKennedy.zip

Using RavenDB with Azure websites

In a previous post I explored various options of hosting RavenDB. While using RavenDB as a Windows Service or hosted in IIS is probably the best way to go in most cases there are a number of cases where the embedded option is great. And one of the places where I really like the embedded option of hosting RavenDB is when doing simple standalone websites. And with the new Azure website option that is a great way to host them.

The code is real straightforward and just like before. I am using a DataDirectory option when creating the EmbeddableDocumentStore here but that does the same thing as I did before using the connection string.

 1: public static DocumentStore DocumentStore { get; private set; }

 2:  

 3: private void CreateRavenDB()

 4: {

 5:     DocumentStore = new EmbeddableDocumentStore()

 6:     {

 7:         DataDirectory = @"~App_Datadb"

 8:     };

 9:     DocumentStore.Initialize();

 10: }

RavenDB Configuration

The example code from my previous blog posts will just work except for one gotcha. By default RavenDB will search for a post to use by itself. However that means scanning the available posts and that isn’t permitted by default. The result is an exception:

System.Net.NetworkInformation.NetworkInformationException: Access is denied

With a stack trace like this:

[NetworkInformationException (0x5): Access is denied]
System.Net.NetworkInformation.SystemIPGlobalProperties.GetAllTcpConnections() +1570717
System.Net.NetworkInformation.SystemIPGlobalProperties.GetActiveTcpListeners() +74
Raven.Database.Util.PortUtil.FindPort() +79
Raven.Database.Util.PortUtil.GetPort(String portStr) +133
Raven.Database.Config.InMemoryRavenConfiguration.Initialize() +4355
Raven.Database.Config.RavenConfiguration.LoadConfigurationAndInitialize(IEnumerable`1 values) +307
Raven.Database.Config.RavenConfiguration..ctor() +196
Raven.Client.Embedded.EmbeddableDocumentStore.get_Configuration() +87
Raven.Client.Embedded.EmbeddableDocumentStore.set_DataDirectory(String value) +40
MvcApplication3.MvcApplication.CreateRavenDB() +57
MvcApplication3.MvcApplication.Application_Start() +169

The fix is simple. Instead of letting RavenDB search for a port by itself just specify one in the web.config. The setting required is “Raven/Port”.

 1: <configuration>

 2:   <appSettings>

 3:     <add key="Raven/Port"

 4:          value="9090"/>

 5:     ....

 6:   </appSettings>

 7: ....

That is all there is to it :-)

Want to see for yourself?

I have a simple page using RavenDB as the backend store hosted on Azure right here.

Enjoy!


Querying RavenDB databases

As we have seen in previous blog posts getting data from a RavenDB database is easy. Either use the IDocumentSession.Query<T>() function to load a series of documents or the IDocumentSession..Load<T>() function to load a document using its identity. However sometimes we want more control over what we want to load. It turns out this is rather easy as the IDocumentSession.Query<T>() function returns an IQueryable<T>, actually it returns a IRavenQueryable<T> to be exact but more about that another time.

Querying the database

As IDocumentSession.Query<T>() return an IQueryable<T> we can just start composing queries just as we can with EntityFramework or another ORM. In my original online example you might have noticed that the books aren’t ordered. As with any query this is easy to correct. All we need to do is add an order by clause.

 1: public ActionResult Index()

 2: {

 3:     using (var session = MvcApplication.DocumentStore.OpenSession())

 4:     {

 5:         var books = session.Query<Book>()

 6:             .OrderBy(b => b.Title)

 7:             .ToList();

 8:         

 9:         return View(books);

 10:     }

 11: }

If you prefer the full LINQ syntax that is no problem as it produced exactly the same result±

 1: public ActionResult Index()

 2: {

 3:     using (var session = MvcApplication.DocumentStore.OpenSession())

 4:     {

 5:         var books = from book in  session.Query<Book>()

 6:                     orderby book.Title

 7:                     select book;

 8:             

 9:         return View(books.ToList());

 10:     }

 11: }

Filtering data

In this case I am only ordering the result set but you can also use other operators if you like. Just want books from an author starting with “A”? No problem, just add the filter and it works. The following view search for books where the title or author starts with the passed string.

 1: public ActionResult BooksByAuthor(string author)

 2: {

 3:     using (var session = MvcApplication.DocumentStore.OpenSession())

 4:     {

 5:         var books = session.Query<Book>()

 6:             .Where(b => b.Author.StartsWith(author) || b.Title.StartsWith(author))

 7:             .OrderBy(b => b.Title)

 8:             .ToList();

 9:  

 10:         return View("Index", books);

 11:     }

 12: }

Lucene.Net indexes

If you try this you might notice one big difference from EntityFramework or in memory LINQ queries. If you search for books starting with a lowercase “the” both “The Hitchhiker’s Guide to the Galaxy” and “The RavenDB Book” are returned. And in the query I am not doing anything about making this a case insensitive search. It turns out RavenDB does so by default as it uses Lucene.Net to create indexes. As we didn’t create any indexes you might be wondering where this comes from. It turns out that RavenDB always uses an index when you do a query. You can explicitly create them if you want to. However if you do not, as is the case here, RavenDB will try to find a matching index or create a temporary index if a marching one isn’t found. If the same temporary index is used frequently RavenDB will automatically promote it to a permanent index. That might sound like a bad idea, after all in SQL Server index help with querying but can also slow updates down. In RavenDB this isn’t the case as indexes are update asynchronously so we get the query benefits without the update penalties. Of course there is no such thing as a free lunch and in the case of RavenDB this can mean we use a stale index for the query. That might sounds bad but isn’t quite as bad as it sounds as the data is never stale, just the index, and we can easily control when we want to wait for a non stale index.

Want to try? I have this example running on Windows Azure here.


Use NuGet package restore to simplify code sharing

Here’s a quick post on how and why you want to consider using NuGet package restore.

First, if you’re unfamiliar with NuGet, it’s basically “add reference” to external software projects (typically open source ones such as jQuery, but also for Microsoft ones such as Entity Framework). You definitely need to check out David Ebbo’s post introducing it. NuGet will change the way you develop.

Now when using NuGet it maintains a packages folder near your solution file. For things like ASP.NET MVC that heavily leverage NuGet, you’ll see this folder is very large. It’s usually much larger than your project itself in the beginning.

If you write small projects and share them out as compressed files (e.g. zip’s), and size matters to you, you might want to consider enabling NuGet package restore (off by default) for those projects and delete the packages folder before zipping and sending it out.

As an example, with a typical MVC 4 project, the “raw” content is 680 KB. After doing a build and counting the packages folder you’ll see it jumps to 16.9 MB. If that helps you significantly, then it’s probably a good idea to use package restore.

Three things have to happen to use NuGet package restore.

First, you’ll need to make sure everyone who downloads your zip file has “Allow NuGet to download packages during build” enabled in Visual Studio under Tools>Options>Package Manager.

enable-global

The next set of steps are only done by the you – the one sharing the code. Right-click on the solution file and choose enable package restore:

enable

After doing this, you’ll see 3 new files in your solution:

sol2

Finally, when you zip and share your code, be sure to include the .nuget folder but not the packages folder (and maybe not the bin and obj either).

Now I did say at the beginning why to consider this, not just you should use it as a blanket statement. This whole workflow was introduced for simplifying source code management. Two reasons that come to mind right away to not use package restore are:

  1. If not many of your users / readers / downloaders have package restore enabled globally it might be more effort than its worth.
  2. In the source code scenario, you are dependent on NuGet keeping the right version around forever. Suppose you want to roll-back to the way the code was 2 years ago (some time in the future). It might be safer to have the packages folder just checked in so you’re sure it gets versioned and labeled exactly right.

Hope that’s useful to you!

Cheers,
@mkennedy

DotNed Podcast: Willem Meints over Mono for Android

In deze podcast spreekt Maurice de Beijer met Willem Meints over wat je precies kan met Mono for Android. Verder hebben ze het over de geschiedenis van het open source Mono framework.

Link:

Met dank aan onze sponsor RedGate.

What is the right size for a User Story?

A question that comes up again and again from teams is “What is the right size for a User Story?” – a day? a week? three weeks? – 1 point? 5 points? 10 points? 37? 100? 5 words? 20 words?

Short answer: there isn’t a universal right size for a User Story, it depends on your team, their skills and their level of domain knowledge.

Long answer: for some teams a User Story is Big, several days or weeks of work. On other teams they are small – maybe a day’s work. Both are possible, both are the right answer. Although, as a general rule smaller is better.

For me there are criteria that a User Story should meet:

  • It should be small enough for the technical team to understand it and create in in a short time period

  • It is small enough to move on the board sometime soon

  • It should be big enough to represent business value in its own right – it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity)

  • It is big enough to be deliverable in its own right – you might not want to do so but if you needed to you could

In an ideal environment: the story would be developed in a few days, would be released on its own right and the business value measured directly. (For those who know about Minimally Marketable Features (MMFs), also sometimes called Business Value Increments (BVI) or Quantum of Value (QoV), I casually consider a User Story to be a MMF.)

When a team are dedicated to a particular product, and have worked on it for several years, and have learned about the domain – as I would expect in for in-house development operations – I expect to see larger stories. Conversely, when a team don’t know the domain – as is common with outsourced development – I expect to see small stories, and more knowledge pull from the client.

Taking a step back, a few basics:

  • A User Story is not in and of itself a requirement; I like to call them “Tokens for Work to be Done”, others like to say they are “A placeholder for a conversation” both are true

  • Don’t feel that you must use User Stories: if the format doesn’t fit your need then don’t use it! You can still have a “token for work to be done” and a “placeholder for a conversation” using any words you like, they don’t have to be “As a… I can … So that…”

  • The User Story format does capture three very important elements: Who, What, Why so they make a good starting point and are easy to understand but if they don’t work for a particular need then don’t force it into the format

Small stories are better – they can be developed more quickly, delivered more quickly and return value more quickly. But there comes a point were stories become too small to return any business value at which point they, well, loose value. Plus, when you have a lot of small stories they become a headache to manage.

One common problem I see is teams who create really small stories in order to get them to fit within one sprint. These means large stories don’t get scheduled or teams split large stories into many small ones which have no business value themselves.

People say this is a Scrum thing, I’m not sure. Scrum doesn’t mandate User Stories, the story format came along after Scrum. True the format is widely used they has become part of Common Scrum.

What Hard Core Scrum does say is that all the work the team commit to should be done by the end of the Sprint. Which would imply a story has to be small enough to fit I the Sprint. The problem then comes: what else do you put in the Sprint? If one story is going to take more than half the Sprint you need one or more stories to use the rest of it up. Plus you hit the commitment problem – developers have an incentive to under commit and the business/custom has an incentive to over demand.

My solution – one which I’m baking into my description of Xanpan – is:

  • Stories are split into Tasks during the planning meeting

  • Tasks do not follow any particular format, nor do tasks have any business value

  • Tasks are for the team – the developers, testers, analysts and anyone else

  • Tasks should be small, a day or two at most.

  • A story is not done until all the tasks are done. Stories can therefore flow across iterations, the chances of tasks flowing across iterations is low (because they are small) but they can and do.

However – and this is the key point – in counting the points (velocity) of a team only the completed Tasks are counted. Partially done tasks are not. The only states that matter are Done and Not Done.

As I’ve written before, the breakdown of stories to tasks fills (at least) three purposes:

  • It is superficially an estimation exercise

  • It is also a requirements elicitation process (I like the Requirements Engineer, BA, Product Owner/Manager to be present)

  • It is a design activity.

You know a task is too big because it is difficult to finish. If it is difficult to finish it needed more thought up front, to define and understand it, to bound it, to understand it. (See the mini-series on Story Points earlier this year, and specifically the Story Breakdown entry.)

So there you have it: there is no right size of a User Story.

That said, they may still be “too big” or “too small”. But what constitutes right it dependent on you, your team and how you play the game.


Attend my sessions at DevWeek 2013 in London

Want to see some of the topics covered in my blog presented live and in-person? Make your way to London in March 2013 to DevWeek! I’ll be presenting 4 sessions covering NoSQL, ASP.NET MVC, and Cloud (Auzre and AWS mostly). Details below.

Sessions:

Building Rich Input Forms in ASP.NET MVC

ASP.NET MVC has gained broad adoption over the last year. This is in part due to it’s clean and simple design. However, one aspect that new-comers typically get hung up on is building pages that accept user input in various manners. In this talk we will explore the powerful features of ASP.NET MVC that allow us to build rich forms that accept user input. We’ll begin by discussing the built-in HTML Helpers and Model Binding. Next we’ll add validation and show how we can do both client- and server-side validation using DataAnnotations. We’ll see that sometimes using domain models as our form-bound objects doesn’t make sense and so we will cover more advanced scenarios using View Models. Finally, time permitting, we’ll see how client-side programming with JavaScript and jQuery can take this even farther.

Applied NoSQL in .NET

Perhaps you’ve heard about the next generation of databases roughly classified as NoSQL databases? These databases are generally much better than RDBMS at scaling, performance, and easy-of-development (i.e. in NoSQL the object-relational impedance mismatch usually disappears). Unfortunately, many talks on NoSQL are very academic and general. Not this one.

In this talk, we’ll explore the NoSQL landscape and look at the the various options out there. Then we’ll learn how to leverage MongoDB (a popular NoSQL DB) to build .NET applications using LINQ as the data access language. From there we will build out a .NET application using LINQ and MongoDB in a series of interactive demos using Visual Studio 2012 and C#.

Getting Serious About The Cloud – For Developers

You’ve been hearing all about “the cloud” for several years now. Maybe now is the time to take the leap and get started developing for this next-generation platform. That’s what this talk is all about. Learn what options you have for cloud hosting (and the related trade-offs). See how to create and host applications in the cloud. And learn about the tricks the pros use to achieve the scalability and durability promised by all the hype.


(At Least) 9 Ways Your Brand New ASP.NET MVC Project Can Be Better

So you’re ready to start that new and ambitious ASP.NET MVC project. Maybe you’re kicking off a new startup or just finally moving that old-and-crusty webforms project into modern development world. Either way, this talk will give you some easy things you can do immediately after creating that new MVC project that you will thank yourself for as your project grows in complexity.

Cheers,
@mkennedy