Developmentor Instructor's Blog Posts

Llewellyn Falco (Approval Tests): Testing Views in Asp.Mvc

Sat, 19 May 2012 18:15:00 -0700

For many years, the views (the html returned from an rendered MVC controller) were an extremely difficult thing to test. Like many unreachable things, they were declared “not worth it” and ignored.

Until now,
with ApprovalTests we have created a “simple” way to test the rendered output of a view. I say “simple” because there is a fair amount of overhead for the 1st test, which means we wanted to give you some resources to get it working for yourself.

I created a short video tutorial, and Jim Counts put together a fabulous 3 part blog + Sample Code.

Now you can decide for yourself how important it is to test the views.

Video :

Blog :

Part 1 – Getting Started
Part 2 – Working with Data
Part 3 – Tackling the Build Server

Code:

https://bitbucket.org/magnifico/mvctestsite

Lynn Langit: AWS RDS SQL Server vs. SQL Azure Smackdown – Importing Data

Thu, 17 May 2012 13:39:06 -0700

This is first in a series of comparisons between Amazon Web Services RDS SQL Server and SQL Azure. It is useful for me to understand exactly which features and tools work with cloud-deployed instances of SQL Server. In this screencast … Continue reading →

Pinku Surana: Ubuntu is too much work

Thu, 17 May 2012 07:56:11 -0700

I’m returning my laptop’s SSD for a replacement drive. In the meantime, I loaded Ubuntu Precise on my Sony Z. I usually run Windows w/ Linux in a VM. The installation actually went just fine. It looked good, it appeared to work and all was well. Unfortunately, my laptop has a switch to manually choose [...]

Lynn Langit: Hadoop on Azure – Deck and Screencasts

Wed, 16 May 2012 10:54:27 -0700

Enjoy this deck (and linked screencasts) covering Hadoop on Azure.

Allan Kelly: 10 Things to make you Agile adoption successfull

Mon, 14 May 2012 12:50:00 -0700

One of the closing slides in my Agile Foundations course includes a quote from Ken Schwaber saying that only 30% of teams who attempt Scrum will be successful. What I find interesting about this quote is that it aligns with many other change management studies. Researchers like Harvard Professor John Kotter regularly say 70% of major change efforts fail.

On his blog Ken Schwaber says he doesn’t remember this and instead suggests only 30% will become “excellent development organizations.”

Either way, the prognosis isn’t optimistic. A few months ago, at the end of the course, someone asked the obvious question, a question so obvious I wonder why nobody has asked it before: “What can we do to ensure that we are in the 30% who make it?”

Given that I had the Managing Director, the Director of Technology and most of the technology team in the room it was an excellent opportunity to set the change agenda. And I fluffed it, despite having written a book on the subject I didn’t have a quick answer to hand. But it set me thinking: “What are the 10 things a team can do to make Agile (any flavour) stick?”

Here then is that list, the team in the room will recognise the first three, it was after that that I had to think.

1) Use a physical board: over the last year I have become convinced that the single biggest difference between teams which successfully adopt Agile working and those who try, fail, or end up stuck is the use of an actual physical board.

I know some teams find this difficult, I know some teams are distributed, I know there is technology out there to do this for you but I stand by my point. If you can make it physical, in a place where many, if not all, can see, then you are more likely to succeed.

2) Start collecting and using statistics and other data: velocity, burn-down, bugs identified, bugs logged, etc. etc. Metrics have a bad name in software development - rightly in most cases. But that only means that have been badly collected, managed and used, it doesn’t mean they aren’t useful. At the very least measure your velocity and create a burn-down chart or cumulative flow diagram of the work to do or arising.

3) Engage a coach/consultant: at the risk of being accused of trying to make work for myself I should say you can adopt Agile all by yourself. You can read the books, you can experiment, you can go on courses. But doing it without help makes the whole process slower and increases the risk that you won’t make it to the 30%.

Personally, I find it difficult to know just how an Agile Coach differs from an Agile Consultant. What ever you call the role you want someone who can:

Provide advice on which practices and process to adopt, and how to best adopt them
Offer examples of what they have seen work, and not work, elsewhere, and how other team tackle similar issues
Observe, examine, query and challenge your thinking on what you are doing
Challenge your thinking and point out opportunities and idea that you haven’t seen yet

You may need to work with multiple advisors since few will be able to cover all process, practice, technology, product and strategy bases. On very large team it might be worth having full-time consultants although the model I have had most success with is light-touch coaching in tandem with a pull-change model (below).

I don’t believe such an advisor needs to be full time. I practise, and have written before about, light-touch Agile coaching, in this model I return to companies at intervals, perhaps monthly, perhaps more frequently, sometimes less frequently and continue the discussion.

4) Action over talking: action speaks louder than words, until you start trying to do Agile you can’t foresee all the issues and questions which will arise. The longer you spend talking about doing it, and not actually doing it, the more it anticipation will build up, the more more it will look like jus another management fad.

By all means talk about it, plan a bit but there is no real substitute for just getting stuck in and doing it. In particular do not spend your time agonising over whether to do XP or Scrum, or Lean or FDD, or DSDM or Kanban. They are all pretty much of a muchness and you will end you up crafting your own hybrid anyway.

Likewise, discusses a few weeks ago: don’t waste your time looking for evidence, make your own.

Planning your way to Agile is anathema, just do it - JFDI.

5) Give everyone training and start group wide discussions: teams don’t get to be Agile by management deeming “thou shalt be Agile” - although plenty of managers and team leaders have tried the approach. Reading books works for some people but most books go unread, or the words go in one eye and out the other.

If you want to be Agile then invest in taking the time to explain to people what it is. But don’t stop there, make time for people to talk about what Agile is to them, what they like, don’t like, will do, won’t do. Agile is a team sport and unless the team have a shared understanding they will be playing different games.

6) Enthuse, Pull, don’t Push: Anyone who has worked around companies for a few years will have seen management pushing the latest change initiative: ISO 9000, Sig Sigma, CRM, ERP, etc. etc. Someone dreams up these ideas and then a change machine sets about pushing them out.

Apply a lean principle: Pull, don’t push. Forbid the words “change management.” Enthuse individuals and teams, have them ask for Agile. And when they ask give them the help and support they need. This works at the individual level, at the team level, at the company level.

If you are in management this means you need to engineer a pincer movement: you want enthusiasm for change coming from the bottom up to meet your support coming top down. Introducing Agile top-down alone is, in my opinion, as quite likely to kill it - employees are, rationally, skeptical of top-down management change. We live in a post-modern, post-BRP, post-layoffs, post-recession, post-everything world. Employees aren’t children they’ve heard what happens.

Rather than impose change from the top down managers need to build, kindle people’s curiosity, get people asking questions and for help, create bottom-up change initiative and support it. Do everything build the fire without extinguishing it.

The good news is the Agile marketing machine may already have got there ahead of you. People may already be curious about Agile, or even keen to try it - they may even be doing it when you are not looking. If not then find ways to stir interest. When they come asking for support - for budget for speaker, trainers or coaches - or time to go to conferences, give it, give it generously. Offer more, ask when else they need, and above all else: learn to change your own behaviours to match.

7) Be clear on Why you are going Agile: what ever level you are, engineer, tester, project manager, director, look beyond the Agile hype. What is the problem you want “Agile” to fix for you? Understand why you want change and what you expect from it.

Don’t just “get Agile” because it is this month’s fashion, get “Agile” to achieve something more important.

8) Process and technical, Adopt technical side as well as process side: don’t think you can just change the process and it will all be all right. You need to address the technical side too, you need to improve quality, you need to support the engineers, testers and others who are at the code face doing the work.

I’ve come across big companies who view the technical side as somehow dirty: the attitude seems to be “thats technical” or “ they get their hands dirty” or “we can ship it to [Low cost country of choice this week]”.

Get your hands dirty, talk to engineers, adopt Test Driven Development, refactoring, shun big up front design architecture, learn to live with rough designs and evolving architecture. There are real feedback loops here.

9) Get Product Management/Owner flow to developers clear and clean: it isn’t just about fixing the coding side, the requirements side needs to be addressed to. Specifically there needs to be a clear path from someone who represents requirements - typically called a Product Owner or Product Manager and frequently staffed with a Business Analyst - and the development team. Far more negotiation is going to happen over “what” then “when”. Someone needs to represent - and have authority - over that side of things.

10) Structural changes - Functional groups: Staff your teams to do the work for which they are responsible, end functional groups - i.e. database developers and UI developers in separate teams. This is just the first of more structural changes you will need to make. But if you fail at this you won’t get to play again.

There you go, each of those items could be an entry in its own right, maybe one day they will be. Thats enough to get you started. If there was an eleventh is would be: let go of the past, things change, Agile isn’t purely additive. If you don’t stop doing some of your current things you will never see the full benefit. But 11 can wait, those 10 will get your a long way.

Brock Allen: HTTP status codes for REST

Mon, 14 May 2012 10:38:03 -0700

While developing the upcoming Essential REST course for DevelopMentor, I thought it would be useful to put together a chart illustrating the common HTTP status codes used for each of the common HTTP methods. This isn’t exhaustive and many of the status codes below might be issued by the infrastructure and not directly by your application [...]

Maurice de Beijer: DotNed Podcast: Tom Verhoeff over geld verdienen met Windows Phone 7 applicaties

Thu, 10 May 2012 03:12:00 -0700

In deze podcast spreekt Maurice de Beijer met Tom Verhoeff over zijn sessies op de TechDays. Tom presenteerde een sessie over hoe je geld kan verdienen met Windows Phone 7 applicaties. Het lijkt op het eerste gezicht zo eenvoudig, je maakt een app en het geld stroomt binnen. Maar in de praktijk blijkt het toch iets lastiger te zijn en zijn er best wel veel details waar je op moet letten.

Links:

Blog: http://blog.tomverhoeff.nl/
Blogpost nav TechDays sessie: http://blog.tomverhoeff.nl/2012/02/24/making-money-with-windows-phone-applications-at-techdays-2012/
Mark Monster zijn Unified Ad oplossing: http://mark.mymonster.nl/2012/02/07/windows-phone-unified-ad-part-1-introduction/
Verschillende posts over Tom zijn review reader tool: http://blog.tomverhoeff.nl/tag/wp7rr/
AddDuplex: http://www.adduplex.com/
Managing Trial Applications for Windows Phone: http://www.slickthought.net/post/2010/08/30/Managing-Trial-Applications-for-Windows-Phone-7.aspx

Je kan hem hier afluisteren.

Met dank aan onze sponsor RedGate.
http://www.red-gate.com/

Enjoy!

Lynn Langit: First Look – ASP.NET on Amazon Web Service Elastic Beanstalk

Wed, 09 May 2012 22:47:21 -0700

Here’s part two of my look at the big AWS announcement yesterday – full support for ASP.NET and SQL Server on AWS Elastic Beanstalk and AWS RDS. I found it remarkably easy to get up and going with ASP.NET on … Continue reading →

Lynn Langit: First Look – SQL Server on Amazon Web Services RDS

Tue, 08 May 2012 16:58:13 -0700

Of course I had to try it out! Here’s the announcement from @Werner – and the documentation from the AWS site on the new support for SQL Server in AWS RDS. There is a free usage tier as follows: “If you … Continue reading →

Allan Kelly: Points based contracts? Just Say No.

Tue, 08 May 2012 06:02:00 -0700

With the points-mini-series still fresh in the mind now seems a good time to say publicly something which I’ve been saying privately for a long time.

Avoid points based contracts. i.e. don’t outsource work, or undertake work, on the basis of points - be they story points, abstract points, nebulous units of time or any other name you give them.

I have one client at the moment who wants their software supplier to sign a points based contract, I’ve advised against it. Another client is trying to sell points based contracts to their clients, while they are having some success - I think they rushed in before they had enough data to understand the implications.

Why do I say this? Well three reasons

First is Goodhart’s Law: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” Put it another way: any measurement metric will change behaviour once it is used for control.

In this context it means: points are very good at measuring story size and team velocity, they can be accurate at predicting when a piece of work will be done. But, if you use them for other purposes - like regulating a contract and making payments - they will change their behaviour. They won’t be so useful for predicting end dates, or for controlling contracts for that matter.

This is a problem many readers will be familiar with from traditional time estimation. Estimates are nominally sought to determine how long a piece or work will take, and thus how much it will cost. But they are also used as a means of targeting and for control. They are used as a proxy for commitment and they are gamed (i.e. changed for specific ends) when they don’t give the time/cost numbers desired. (This is something Esther Derby discusses recently in her blog, Estimating is often helpful, estimates are not.)

In fact, time estimates show the same range of problems present in the corporate budgeting processes and which has given rise to the beyond budgeting movement.

One direct result of Goodhart’s Law in this context is...

Inflation, the second reason to avoid points based contracts: points are subjective, they are not grounded in time, complexity, function point analysis, lines of code or any other objective measurement. They are in fact like a fiat currency: they are worth what you can buy with it. If people don’t believe in it, or believe the value will change then it will change. Check out rational expectations theory if you want to understand why.

Overtime points can devalue with the result that point scores increase. Actually, I believe the free floating nature of points is one of the strongest reasons for using them but in terms of signing a contract it makes them useless.

Most teams I see work in low points: 1, 2, maybe a 5, rarely an 8, they score 10, 12 or maybe 20 an iteration. One team I saw worked in tens, and scored hundreds each iteration. It was like one of those old Space Invaders machines were the last digit was a hard coded “0”.

The team’s project manager finished planning meetings with an call for the team to work harder next iteration, to reclaim the lost time. Iteration on iteration velocity increased. Inflation was rampant.

Finally there is practicality. As the recent posts from myself and Vasco Duarte demonstrate points, there is still a lot of debate over points. Personally I have come to the conclusion that exactly how you run iterations and count points makes a big difference. While if you agree with Duarte you might as well dispense with points and sign story based contracts.

Then there is the team: only the team which will do the work can accurately say how many points a piece of work will, or did, take; and then only when they have experience of doing the work. So you shouldn’t sign a points based contract unless you have the team in place and they have done some of the work.

Even a relaxed interpretation of that last point should lead you to conclude you should only sign a points based contract when the team is experienced in using points and you have historical data. If you feel you must sign a points based contract then only do it when you have data.

Still, I’d rather you didn’t do it in the first place.

Llewellyn Falco (Approval Tests): The Testing Circle

Sat, 05 May 2012 16:14:00 -0700

This is the pattern I find myself in day after day while practicing TDD or BDD.

Step 1?

Usually I start at the whiteboard. It is the easiest place to start as I sketch out the scenario I want to program, but not always. Sometimes a mockup file (image, html, or xml) is provided and I start at the result, sometimes I’m give a scenario already in English, and sometimes I have to fiddle with the code first to see what’s happening.

No Beginning, No Ending

The great thing about the circle is no matter where a start, the flow should always be there in the end. If it isn’t, I take this as a smell that I am neglecting something. Also, while I wrote the arrows going clockwise (the normal way I view this process) they can equally go in reverse.

Smell 1: No Result –> Whiteboard

If the result does trigger the original image on the whiteboard (usually long erased by the time I revisit the code), then this will be a maintenance problem when I try to remember why the code looks the way it does when it changes.

Smell 2: No Code –> English

If the resulting code doesn’t make the comments so easy that they should be deleted for not adding any value, then my intention (so clear when I’m writing the original code) will not be there when my fellow programmers, or myself even a few days later, what the understand the code later.

Maurice de Beijer: HTML5 Background tasks using Web Workers

Wed, 02 May 2012 03:26:36 -0700

One of the problems with running JavaScript in the browser is that everything usually executes on the same thread as the UI. With most scripts this is fine because they are short executing however if you start doing more complex calculations you might run into the vase where the UI becomes non responsive because of the JavaScript executing. And when that happens you will see one of these dialogs popup and you are at the mercy of the end user, not the best of places to be.

Update: Check out these live Simple Web Worker and Chunked Web Worker demos.

Fortunately there is a fix for this in the form of the new HTML5 Web Workers specification

Web workers are relatively well supported, IE9 being the big exception, as you can see from caniuse.com. Getting started with them is quite straightforward, basically you create a Worker object and pass it the URL of the script you want to execute. This has to be a URL, you can’t just pass a function, something that would have been handy.

The following HTML page contains all the code required.

        1: <!DOCTYPE html>

       2: <html>

       3: <head>

       4:     <title></title>

       5: </head>

       6: <body>

       7:     <button id='btnStart'>

       8:         Start</button>

       9:     <button id='btnStop'>

      10:         Stop</button>

      11:     <button id='btnPause'>

      12:         Pause</button>

      13:     <button id='btnResume'>

      14:         Resume</button>

      15:     <ul id='primes'>

      16:     </ul>

      17:     <script src="Scripts/jquery-1.7.2.js" type="text/javascript"></script>   1:     2:     <script>   3:         $(function () {   4:             var worker = null;   5:             $('#btnStart').click(function () {   6:                 if (!worker) {   7:                     $('#primes').empty();   8:                     if (!!window.Worker) {   9:                         worker = new Worker('Scripts/Primes.js');  10:                         worker.onmessage = function (e) {  11:                             $('<li>').text(e.data).prependTo('#primes');  12:                         };  13:                     } else {  14:                         $('<li>').text('Web Worker is not supported :-(').prependTo('#primes');  15:                     }  16:                 }  17:             });  18:    19:             $('#btnStop').click(function () {  20:                 if (worker) {  21:                     worker.terminate();  22:                     worker = null;  23:                     $('<li>').text('Terminated').prependTo('#primes');  24:                 }  25:             });  26:    27:             $('#btnPause').click(function () {  28:                 if (worker) {  29:                     $('<li>').text('Pause').prependTo('#primes');  30:                     worker.postMessage('pause');  31:                 }  32:             });  33:    34:             $('#btnResume').click(function () {  35:                 if (worker) {  36:                     $('<li>').text('Resume').prependTo('#primes');  37:                     worker.postMessage('resume');  38:                 }  39:             });  40:         });  41:    42:     </script>

      18: </body>

      19: </html>

The important part is the start button:

   1: worker = new Worker('Scripts/Primes.js');

   2: worker.onmessage = function (e) {

   3:     $('<li>').text(e.data).prependTo('#primes');

   4: };

This code creates a Worker object and points it to the JavaScript file to start executing. In this case we are going to calculate prime numbers.

As soon as the Worker has loaded the JavaScript file it will start executing, no need to do anything special.

Communicating with Web Workers

The code executing as part of the Worker is completely isolated from the UI document. You can send messages between the two using the postMessage() function but all data will be cloned, no shared references exist. When a message has been posted the other party can specify the onmessage callback and react to the message. The worker has restrictions to the data being passed, the most important one is that nothing related to the DOM can be passed to the worker object and everything that can be is cloned first.

A simple implementation of the worker to calculate prime numbers looks something like this. Note the postMessage being used to pass the computed prime numbers back to the user interface,

   1: for (var i = 2; i < 1000000; i++) {

   2:     var isPrime = true;

   3:     for (var d = 2; d < i; d++) {

   4:         if (i % d === 0) {

   5:             isPrime = false;

   6:             break;

   7:         }

   8:     }

9:

  10:     if (isPrime) {

  11:         postMessage(i);

  12:     }

  13: }

Controlling the workers execution

Suppose we want to stop the workers execution there is a terminate() function on the worker which is used in the Stop button.

   1: $('#btnStop').click(function () {

   2:     if (worker) {

   3:         worker.terminate();

   4:         worker = null;

   5:         $('<li>').text('Terminated').prependTo('#primes');

   6:     }

   7: });

This will kill the worker process and that is the end of it, there is no way to restart it. Nice, simple and effective however sometimes that is not quite what we want and we want to restart the worker.

Suspending and resuming a worker

Given the fact that we can send messages between the UI and the worker the code below might look like a valid approach. Unfortunately this doesn’t quite work

   1: var isPaused = false;

2:

   3: onmessage = function (e) {

   4:     if (e.data == 'pause') {

   5:         isPaused = true;

   6:     }

   7: };

8:

   9: for (var i = 2; i < 1000000; i++) {

  10:     var isPrime = true;

  11:     for (var d = 2; d < i; d++) {

  12:         if (i % d === 0) {

  13:             isPrime = false;

  14:             break;

  15:         }

  16:     }

17:

  18:     if (isPrime) {

  19:         postMessage(i);

  20:     }

21:

  22:     if (isPaused) {

  23:         break;

  24:     }

  25: }

The problem here is that the postMessage()/onmessage pair works using the event loop and as long as the Web Worker is busy calculating it will never receive the message, instead it will be queued and remain queued until the worker is idle, something that doesn’t happen until all primes have been calculated.

Using a chunking algorithm

The solution is to use a chunking algorithm. This algorithm brakes the calculation into different groups and use the setTimeout() API to execute the next chunk after a small delay. The result of using setTimeout() is that the message posted can be read and we can actually pause and resume the worker execution. Using a chunking algorithm out background worker JavaScript looks like this:

   1: var isPaused = false;

2:

   3: onmessage = function (e) {

   4:     if (e.data == 'pause') {

   5:         isPaused = true;

   6:     } else if (e.data == 'resume') {

   7:         isPaused = false;

   8:         testPrime();

   9:     }

  10: };

11:

  12: var i = 2;

  13: testPrime();

14:

  15: function testPrime() {

  16:     var isPrime = true;

  17:     for (var d = 2; d < i; d++) {

  18:         if (i % d === 0) {

  19:             isPrime = false;

  20:             break;

  21:         }

  22:     }

23:

  24:     if (isPrime) {

  25:         postMessage(i);

  26:     }

27:

  28:     if (!isPaused) {

  29:         if (i < 1000000) {

  30:             i++;

  31:             setTimeout(testPrime, 0);

  32:         }

  33:     }

  34: }

With this in place we can pause and resume our prime number calculation

The only problem with this approach is that, in some browsers, it slows down calculations a lot. So instead of doing a setTimeout() after every prime you might want to do so once after a series of numbers has been checked. For example with the code below:

   1: var i = 2;

   2: testPrime();

3:

   4: function testPrime() {

   5:     var isPrime = true;

   6:     for (var d = 2; d < i; d++) {

   7:         if (i % d === 0) {

   8:             isPrime = false;

   9:             break;

  10:         }

  11:     }

12:

  13:     if (isPrime) {

  14:         postMessage(i);

  15:     }

16:

  17:     if (!isPaused) {

  18:         if (i < 1000000) {

  19:             i++;

  20:             if (i % 100 === 0) {

  21:                 setTimeout(testPrime, 0);

  22:             } else {

  23:                 testPrime();

  24:             }

  25:         }

  26:     }

  27: }

How about browsers that don’t support Web Workers?

It turns out that using this chunking approach in the UI is a very decent alternative to using a Web Worker as it prevents the user interface from completely blocking. It will still be somewhat slower to respond but is the best you can do in the circumstances.

Update: Check out these live Simple Web Worker and Chunked Web Worker demos.

Enjoy!

Michael Kennedy: How Are You Scaling ASP.NET?

Tue, 01 May 2012 11:13:23 -0700

There are some interesting debates out there around scaling ASP.NET. How do you do it? Please fill out this poll and tell the world: Interested in a blog post on this? Take it to the comments section. Cheers, @mkennedy Filed … Continue reading →

Mark Blomsma: String literals and ‘==’ versus Equals(…)

Mon, 30 Apr 2012 09:51:50 -0700

I had a little fun today playing with ‘==’ vs. the Equals(…) method. I knew that somewhere in .NET 2.0 (I believe) there had been some improvements in String.Empty versus “”, but I didn’t quite realize that this affected all string literals.

In the code below you can see how value types and reference types may behave differently when using ‘==’ versus the Equals method.
My surprise came when I discovered that line 39 and 41 both return TRUE. Apparently the string literals in an assembly get put in a master list of string constants and then reused where the same string literal gets used. Nice!
The way to force the reference comparison of the string against object to actually be different is to delay the creation of the string until runtime, like in line 52.

 1: static void Main(string[]
args)

 2: {

3:

 4:  // value types

5:

 6:  int x = 10;

7:

 8:  int y = 10;

9:

 10:  Console.WriteLine( x == y ); //
compare by value -> return true

11:

 12:  Console.WriteLine( x.Equals( y ) ); //
compare by value -> return true

13:

 14:  Console.WriteLine( object.ReferenceEquals(
x, y ) ); // compare by reference -> return false

15:

16:

 17:  Console.ReadLine();

18:

 19:  // Reference types

20:

 21:  StringBuilder s1 = new StringBuilder( "yes" );

22:

 23:  StringBuilder s2 = new StringBuilder( "yes" );

24:

 25:  Console.WriteLine( s1 == s2 ); //
compare by reference -> return false

26:

 27:  Console.WriteLine( s1.Equals( s2
) ); // compare by value -> return true

28:

 29:  Console.WriteLine( object.ReferenceEquals(
s1, s2 ) ); // compare by reference -> return false

30:

 31:  Console.ReadLine();

32:

 33:  // object and string

34:

 35:  object o1
= GetName();

36:

 37:  string o2
= "Mark";

38:

 39:  Console.WriteLine( o1 == o2 ); //
compare by reference -> return true

40:

 41:  Console.WriteLine( o1.Equals( o2
) ); // compare by value -> return true

42:

 43:  Console.WriteLine( object.ReferenceEquals(
o1, o2 ) ); // compare by reference -> return true

44:

 45:  Console.ReadLine();

46:

47:

 48:  // object and string

49:

 50:  object ss1 = "Mark";

51:

 52:  string ss2 = "Markx".Substring(
0, 4 );

53:

 54:  Console.WriteLine( ss1 == ss2 ); //
compare by reference -> return false

55:

 56:  Console.WriteLine( ss1.Equals( ss2 ) ); //
compare by value -> return true

57:

 58:  Console.WriteLine( object.ReferenceEquals(
ss1, ss2 ) ); // compare by reference -> return false

59:

 60:  Console.ReadLine();

 61: }

62:

 63: static object GetName()

 64: {

 65:  return "Mark";

 66: }

Lynn Langit: Using Variety to get schema info for MongoDB

Sun, 29 Apr 2012 15:30:14 -0700

I tried out a utility on GitHub called Variety for MongoDB. As the creator (@JamesCropcho) says of Variety: “This lightweight tool helps you get a sense of your application’s schema, as well as any outliers to that schema. Particularly useful … Continue reading →

Andy Clymer: How much packaging

Sat, 28 Apr 2012 08:40:00 -0700

Richard and myself receive a batch of Microsoft Windows Embedded licence keys. Having only ordered four we were a bit amused by the size of the box they came in .

http://www.youtube.com/watch?v=M47ZbefpQbY&feature=plcp

Llewellyn Falco (Approval Tests): What’s new in ApprovalTests.Net v.19?

Fri, 27 Apr 2012 22:43:00 -0700

This is a relatively small release, only 2 real changes.

EmailApprovals
Better Rdlc Syntax

Email Verification

Almost every site sends some sort of email. These have been hard to test, usually requiring some sort of email to be actually sent. Now you can simply say:

EmailApprovals.Verify(new MailMessage())

This is particularly nice with a

[UseReporter(typeof(FileLauncherReporter))]

As it will open in your desktop email client (like outlook, not gmail) making it very easy to see the results. If you’ve given up on desktop clients, you can grab one from www.ninite.com
I made a video about it here:

Verifying Email

Better Rdlc Support

Previously, if you wanted to approve a Rdlc report with multiple data sources you had to use Tuples, which got a bit annoying. In this release I am taking advantage of the anonymous enumerator syntax. The result is

   1:  RdlcApprovals.VerifyReport(reportname, assembly,

   2:        new DataPairs() { { "DataSet1", model1 }, {"CompanyAddress",model2} });

verses

   1:   RdlcApprovals.VerifyReport(reportname, assembly,

   2:        new Tuple<string,object>( "DataSet1", model1), new Tuple<string,object>("CompanyAddress", model2);

Again, there is a video of this here:

Verifying Rdlc Reports

Happy Testing!

Michael Kennedy: Michael’s .NET Suggested Reading List

Fri, 27 Apr 2012 16:32:57 -0700

With Guerrilla .NET from DevelopMentor coming up on May 7th, it’s time to refresh my .NET reading list. Want to get ready for this class or a class like it or just get a quick-start on .NET? Here’s what I would recommend. … Continue reading →

Brock Allen: Change FireFox’s default Accept header to prefer JSON over XML

Fri, 27 Apr 2012 11:12:38 -0700

I prefer to use FireFox as my browser, but one downside is that it doesn’t display XML very well (and it seems this is a problem due to some conflict with Firebug). Now that I’m looking into WebApi more, the default content negotiation prefers to render XML due to the default “Accept” HTTP header that [...]

Brock Allen: WIF on Windows XP and Cassini

Thu, 26 Apr 2012 18:48:18 -0700

WIF isn’t officially supported on XP (and it won’t even install), but you can ~/bin deploy it (you need to for Azure deployment). So this means you can basically develop with WIF on XP, but if you’re using Cassini as your web server then you’ll run into this bizarre exception (with a lousy stack trace [...]

Tony Sneed: Roll Your Own REST-ful WCF Router

Tue, 24 Apr 2012 08:05:16 -0700

Download the code for this post here. Recently I’ve been tasked with building a WCF routing service and faced the choice of whether to go with the built-in router that ships with WCF 4.0, or to build one from scratch. … Continue reading →

Lynn Langit: New 1-day Class ‘NoSQL for the SQL Server Pro’

Mon, 23 Apr 2012 09:51:59 -0700

Because I’ve had several requests to build a short class after delivering my talk ‘NoSQL for the SQL Server DBA’ at #SQLSaturday120 last month in Huntington Beach, CA, I’ve decided to write and teach a one-day class around this topic. … Continue reading →

Allan Kelly: Points: conclusions and hypothesis

Fri, 20 Apr 2012 09:16:00 -0700

As anyone with time to spare will know I’ve recently spent a lot of time thinking, and writing about story points. This was in response to Vasco Duarte’s Story Points Considered Harmful blog from a month or two back. For completeness here are the links:

Some conclusions I draw from this:

There is far more work to do on Abstract/Story Points than we, as a community have done to date
There are many more nuances to the assignment of points, the breakdown of work and the management of the outcomes than I think I previously realised
I must go and see what Mike Cohn actually says about Story Points before I say any more about his approach
Stable teams are crucial - but then I’ve been saying this all along

Given all this I’d like to pose a few questions and hypothesis of my own

Q1: When does the correlation between story points and number of cards become stable?

Hypothesis: I would expect a team new to “Agile”, stories and points to start off with erratic point scores and number of stories complete per sprint. Thus I would not expect the correlation to be stable. As a team settles down I would expect points to become stable, then stories completed and thus establish a correlation.

Q2: Is there any serious research into story points out there?

In the same line as my recent post “Agile: Where’s the Evidence?” it would be interesting to know if anyone has examined the use and accuracy of story points. Again, I should seclude myself in an academic library and review the data. But again, I have to find time.

More problematic, I suspect, OK another hypothesis, that some of the reason why story points work - which I listed in part 3 of my posts - will make it very difficult to determine if they are accurate because the thing story points are measuring will change.

Allan Kelly: Points 4 of 4 - Breakdown

Thu, 19 Apr 2012 03:39:00 -0700

This entry directly continues from three earlier ones:

Duarte’s analysis, and my response, has got me thinking. And I think it would be useful - to me at least, maybe to some readers! - to explain why I think story points, or rather the “Abstract Points” that I prefer, are still useful, and why I advise teams to break down Blues - stories, possibly User Stories.

Why do I advise teams to break down Blues/Stories?

My background is as a C++ programmer, I worked on financial, telecom, and other systems. A business story, a Blue, would frequently be bigger than a developer could manage in an iteration - particularly if you have a legacy system. Thus I would break Blues down to Whites. (See Blue-White-Red (PDF) if you want to know more about this approach.)

Blues mean something to the business, Whites mean something to developers. I think this situation still holds for many developers in many environments. This has several advantages:

Whites are smaller pieces of work, they flow through a system more easily. Progress can be seen, tasks tracked, velocity calculated.
“The Business” aka Product Owner/Manager/BA are not always good at delivering small stories, breaking a blue down gives the developer a chance.
On some teams the business have been beaten up by development to request really small stories. However these stories lack business value. Because Blues are going to be broken down they can be large enough to have value even if that means that can’t be completed in one iteration/sprint.
(Yes, you heard that right) Whites are completed during the iteration, when all the Whites, or the essential ones, are completed then the Blue is completed.
Breaking Blues down to Whites is as much a design exercise as it is an estimation and scheduling one. This allows teams to engage in design and create a shared understanding.
Breaking Blues down to Whites frequently reveals functionality or assumptions about the Blue requirement which can be removed or postponed.
Having the Product Manager/Owner/BA in the room during this break down allows for requirements elaboration and knowledge mining.
Work can be rolled from one iteration to the next. I’m very relaxed about carry over work and I think for a new team its almost unavoidable. However doing it this way allows some points to be counted and illustrates what is happening.

(Of course the break down does create some problems: a Blue can only be done when all the Whites, or some done and other cancelled, which mean tracking becomes more complex. It might also break the Lean idea of “single piece flow” but I’m not sure.)

Next, why, given Duarte’s analysis, do I still advise teams to estimate their work?

I have seen the breakdown and estimate approach. As detailed previously in one case it allowed a team to forecast to the day.
Estimating work allows teams, and individual team members, to raise a warning when work is not understood, defined or involves a lot of risk. For example, a team estimating with planning poker will normally settle on an “average size” of task, e.g. 3 or 5 points. When they suddenly assign 13 or 20 points to a task something is wrong.
And just in case the warning is ignored the team, the people at the code face, the people doing the work, have a control mechanism. No matter how much the business or a manager bully a team they can still assign a high point score.
Equally, when differences in estimation appears it is a trigger to discussion, to learning, to understanding. This is desirable.

Finally, there is one more reason why I will continue to advise to point their work, and its one I don’t normally admit to but, well Vasco, you win.....

Placebo effect.

Managers, particularly trained project managers, find it alien to not estimate. Actually they are not alone, I’ve seen plenty of developers and testers who think the Kanban craze of not estimating work is nutty. Going through the rituals of pointing and planning poker provides at least the appearance of doing “the right thing.”

Asking these folk to go cold turkey on planning and estimation is tough.

Likewise, asking them to give up Gantt charts can be tough, so we offer them burn down charts. To be honest I find intra-sprint burn-down charts useless. Even the efficacy of pan-iteration burn-down charts surprised me at first. I now see they can be very useful and recommend their use. (Intellectually I prefer Cumulative Flow Diagrams but they are more difficult to get your head around and more difficult for the casual viewer to understand.)

A mature team is, almost by definition, beyond needing placebos. In a mature team I would expect the business to be requesting small stories which do represent value and do fit within an iteration. Thus I would expect Duarte’s analysis to hold up and a mature team might well decide to go without points and use cards.

However, for team at the beginning of its Agile journey I don’t expect these conditions hold.

Finally, for this instalment, I’ve started to wonder about Blue-White-Red again. I’ve long regarded Blue-White-Red as a Scrum/XP hybrid - closer to XP than Scrum if I’m honest. While I’ve been asked to write more about it in the past never have. Over time I have refined my thinking about it. I’m now wondering if Blue-White-Red is actually something more different than I’ve ever appreciated.

Maybe someone who has used Blue-White-Red can answer than one.

Allan Kelly: Story points 3 of 4 - An example

Wed, 18 Apr 2012 02:44:00 -0700

This entry continues from two earlier ones:

I’ve got some (abstract) points data of my own. Not as much as Duarte’s but some. One team in particular is interesting. The development manage said a few months ago “We can deliver to the day.” But actually, when you look at the data the velocity looks quite variable. Whats going on?

Well two things, at least. First, when you average the data out it is no where near as variable - thats what averages do. I’m reminded of the old economists warning: “Do not pay to much attention to one month’s figures [GDP/GNP/Inflaction/etc]. Look at the trend.”

So yes, velocity iteration to iteration changes but over a longer period it is meaningful.

Second, this is a team I regard as stable. I learned a long time ago that if you don’t have a stable team your velocity data is meaningless. The velocity is delivered by the team members, if you change the team you can’t get a meaningful velocity.

While I regard this team as stable when I looked close, looked at the data and dredged my memory, this was not a stable team. One member retired, one member joined, the team was joined by another person to tackle a specific sub-set of work, the team adopted TDD a few months after moving to iterations, later still they tried doing pair-programming.

Somewhere along the line the hardware team joined the iterations, added to the velocity, then, after a while left. It didn’t work as well as hoped. When you look at the data you can see this: alone the software team can have a standard deviation as low as 3.6 on an average velocity of 62 (over 5 iterations) , with the hardware team added that goes to over 17 on a velocity of 60.

(Velocity falls after team expansion is a phenomenon I’ve seen in two other data sets I’ve got. Brooks’ Law doesn’t completely explain this, other factors are at work which I will discuss another day (i.e. when I understand them more fully!))

In other words, the team wasn’t stable. In fact, given all that change I’m surprised velocity was as stable as it was!

I think a third factor was at work. Once a team have put a point score on a card, say they point it to 5. Then there is a mild incentive to finish the card in something that feels like 5 points. Not the strong commitment of Scrum mythology, more a pride in ones own skills, and perhaps, a desire to score points at the end of the iteration.

Fourth: its not just development estimates that are helping the team hit dates. Armed with this data scope can be fine tuned, teams can take decisions on when to do refactorings and so on.

Fifth: once a team has velocity data and can forecast dates it it can negotiate on features and deliveries. This echo’s Duarte’s story but is more fine grained. Of course this won’t help if the end customers/users/clients/stakeholders aren’t prepared to engage.

Given all this I believe abstract points and graphs are helpful, not harmful.

Perhaps one day I’ll be able to publish this data. Its just one team but it shows that velocity and point scoring can work.

Allan Kelly: Story points 2 of 4 - Duarte's arguments

Tue, 17 Apr 2012 06:14:00 -0700

This blog entry follow directly from the previous Story Points - Journey’s Start.

Key to Duarte argument, and something I didn’t originally appreciate from his initial Tweets is: he is not saying story points are rubbish, forget about them. What he is saying is: it is simpler and equally accurate to just count the stories as atomic items. This is equivalent to saying “All stories are 1 point” and having done with it.

For a mature team with a good relationship with its stakeholders I could see this working well. However, for less mature teams (who have difficulty agreeing among themselves) or a team with bully-boy stakeholders (or bully boy anyone else for that matter) then I think being able to put a higher point score on the card serves as a useful warning mechanism.

Duarte says in his blog “the best predictor of the future is your past performance!” On this I couldn’t agree more. He then poses three questions - and answers - which I think are worth reviewing.

Q1: Is there sufficient difference between what Story Points and ’number of items’ measure to say that they don’t measure the same thing?

Here he finds there is a close correlation. I’m not surprised here, in fact I would expect this to be the case. Teams are encouraged to write small stories, in fact Scrum almost mandates this because work should be completely done at the end of a sprint. In effect there is an upper bound placed on the size of a story.

Actually, I’m not so keen on this rule. I allow work to be carried from iteration to iteration but I only allow points to be scored when the work is done. Thus I encourage stories to be completed in an iteration but I don’t mandate it. One of the exercises I do with teams on my courses actually sets out to illustrate this point.

At the very least I would expect teams to settle on an “average story size” implicitly. Notice also that the correlation applies whether all stories are of size 1 or of size 2, 3 or any other number. Its a correlation between two series of numbers.

However, given all this Duarte has a point: if your stories are clustered around an average size then you might as well count the stories.

Q2: Which one of the two metrics is more stable? And what does that mean?

Duarte’s analysis says that both stories and story points have similar standard deviation. Thus they are of similar stability. Since these two are closely correlated this isn’t a surprise. In fact, given the correlation, it would be a surprise if one was notably more stable.

Q3: Are both metrics close enough so that measuring one (number of items) is equivalent to measuring the other (Story Points)?

Duarte’s data seems to measure the same thing - again, if they are closely correlated then this is exactly what you would expect. You can write out the equation:
Story Points ~= (Correlation Co-efficient) x (Number of Stories)

(The ~= is supposed to mean approximately equal.)

With this out of the way Duarte moves on to consider Mike Cohn’s claims for story points.

Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story
Duarte says: Story Points offer no advantage over just simply counting the number of items left to be Done.

I agree here. I’ve long encouraged teams to move away from story pointing work in the distant future. Yes I encourage them to story point some stories in the backlog - say a few months work - and story point tasks - for the next iteration. But for stuff that is “out there” or has just arisen my advice is usually: just assign it your average story point value.

In other words, assume your average story point value is your Correlation Co-efficient. When work gets close then estimate it traditionally, you might find the value changes. When it gets really close break it down into tasks.

Claim 2: The use of Story points works for both epics and smaller stories
Duarte says: there is no significant added information by classifying a story in a 100 SP category

Again I agree. To be honest I’m not a fan of Epics and while some of the teams I work with use them I often encourage teams to dump them. To me an epic is just a collection of stories around a theme.

Actually, what Cohn and Duarte are saying are not at odds here. Cohn doesn’t (seem to) make any additional claims. Its just a scaling question.

Claim 3: The use of Story points doesn’t take a lot of time
Duarte says: In fact, as anybody that has tried a nontrivial project knows it can take days of work to estimate the initial backlog for a reasonable size project.

Here I have issues with both Cohn and Duarte.
If you are estimating stories then it does take time. Fast as it is, even planning poker takes time. However there is also a lot of design and requirements discussion going on in that activity. Therefore I don’t see this as a problem. In fact I see it as an important learning exercise.

True, on a none trivial project it will take time to estimate a large backlog. But a) that is valuable learning and b) I won’t try. I’d either estimate it in chunks or I’d apply an average estimate to work which wasn’t going to happen anytime soon - see claim #2.

I deliberately delay estimation as long as possible to allow more information to arrive and because work will change. It might be changed out of all recognition or it might go away completely.

Claim 4: The use of Story points provides useful information about our progress and the work remaining
Duarte says: This claim holds true if, and only if you have estimated all of your stories in the Backlog and go through the same process for each new story added to the Backlog.

Again I agree. However I doubt the usefulness of the concept of “work remaining”. Its only work remaining if you think you have a lump of work to do. In my experience work is always negotiable. Its just that people don’t want to negotiate until they accept that they won’t get everything.

One of my clients has gone through the very expensive exercise of estimating all the work they might do. Earlier this year they realised they had 3000 points to do by Christmas. They also realised they had capacity to do less than 1000. This brought home to fact that they couldn’t do everything - something many people on the project had long known or suspected. The company are still working through this issue but at they are having the discussion now, in March and April not September and October.

Claim 5: The use of Story points is tolerant of imprecision in the estimates
Duarte says: there's no data [in Cohn’s book] to justify the belief that Story Points do this better than merely counting the number of Stories Done. In fact, we can argue that counting the number of stories is even more tolerant of imprecisions

Again I agree. But then, if there is a high correlation between story points and stories then this is self-evident. And again, as I said before: we need to work with aggregates and averages.

Claim 6: Story points can be used to plan releases
Duarte says: Fair enough. On the other hand we can use any estimation technique to do this, so how would Story Points [be better than counting the number of stories]

Again, agreement, and with correlation its self evident.

Duarte goes on to give a worked examples in which a project does not achieve the desire velocity and gets cancelled. His story makes no use of story points, simply stories. To be honest I’m missing something here. True the stories in his story have no points, but I don’t see where that makes a difference. What he describes is exactly the way I would play the scenario although I would have story points in the mix.

His conclusion: “Don't estimate the size of a story further than this: when doing Backlog Grooming or Sprint Planning just ask: can this Story be completed in a Sprint by one person? If not, break the story down!”

This is interesting because while Duarte is working at the story level this pretty closely models the way I advise teams to work. I always tell teams:

“I’d like a story to be small, to fit in one iteration but that isn’t always the way.”
“In my experience stories need to be broken down, both so they can get done but also so you get flow and as part of a design exercise.”

I then have teams break down stories - which I call blues - into (developer) tasks - whites - this follows my Blue-White-Red process from a few years back. I then put points on whites - at this point you probably start to see why I prefer the term Abstract Points not Story Points because Whites aren’t stories.

When a team have a feel for points then I will have them put points - the same units, just bigger - on Blues. For Blues that won’t be done for a while then I’m happy to assign averages, and for Blues that are further out then I’m happy to leave them unpointed.

So, thank you for reading my analysis of here and staying all the way.

My conclusion? I think I agree with Duarte but I don’t agree with him. I think I actually disagree with Mike Cohn but I’d have to go back and look at what he says himself.

I think the way I estimate with teams, the way I used to do it when I ran teams and the way I teach clients to estimate is more different than perhaps I appreciated. My method grew from my interpretation of Kent Beck’s XP planning game and velocity. However I now think my approach has drifted from this. The result of my experience, seeing what works and what doesn’t has refined my approach.

The approach I’ve ended up with has similarities with what Duarte describes but is also different.

Despite lots of authors attempts to describe Scrum/XP planning and estimating I still find myriads of minor variations. Some improve things, some not. Until this moment I’ve always believed my approach only differed in minor ways. Now I’m thinking....

And what of the Duarte’s harmful claim? Actually, although he uses the word in the title I don’t see any discussion of the harm they cause.

Story points might be pointless but do they do any harm? I don’t really see it, they may be a waste of time, there might be more effective ways of doing the same thing but that’s not the same as harmful. Story points might mislead, there is little evidence here so I’ll hold judgement on that one.

To be continued....

Maurice de Beijer: HTML5 and Device API’s

Mon, 16 Apr 2012 07:40:19 -0700

Last week the question of HTML5 and sensors came up. This wasn’t really strange as we where talking about the HTML5 GeoLocation features and using the, optional, GPS is just one device or sensor you might want to use.

It turns out the W3C has a Device APIs Working Group working on this problem. They are working on a whole range of interesting devices like:

Battery Status API
Contacts API
HTML Media Capture
Media Capture API
Network Information API
Sensor API
Vibration API
Calendar API
MediaStream Capture Scenarios
And more..

The Sensor API covers a group of others

AmbientTemperature
A ambient temperature
AtmPressure
A pressure sensor
RelHumidity
A releative humidity sensor
AmbientLight
A light sensor
AmbientNoise
A ambient noise sensor
DevMagneticField
A magnetic field sensor
DevProximity
A proximity sensor

Sweet, this should open up some nice capabilities in the future. The problem is that for now this is just one of may standards out there and it seems it will be some time before these standards are actually usable. Guess we have to stick to native clients, or something like PhoneGap, for now.

Enjoy!

TheProblemSolver
DotNetEvents

Allan Kelly: Story points considered harmful? 1 of 4 - Journey's start

Mon, 16 Apr 2012 07:40:00 -0700

A few months ago Vasco Duarte, with a little help from Joseph Pelrine started a discussion entitled “Story Points considered harmful.” They, or at least Vasco, has given this as a conference keynote and has blogged about it.

(Warning: this is the first of 4 blog entires, its quite a long post. Plus I think there are two appendix blog entries to follow up.)

Now I’ll admit, when I first heard this argument I thought “Well I can guess where they are coming from” - I have sympathy with the argument, I’ve always considered story points as suspect myself. I also thought “But I don’t think they are right”. Specifically I know a team who use story points and claim to be able to schedule delivery “to the day.”

I’ve collected some data of my own from teams I’ve worked with, am working with or at least in contact with and done a bit of amateur analysis. I’m also taking time to go over Vasco and Joseph’s arguments.

This is a big topic and its going to take me a while to get to the bottom of the data, what I think and the pro and con arguments. So please forgive me, this is going to take a few, possibly long blog articles to go through.

Lets get a couple of things on the table to start with.

Firstly I don’t believe Story points are a Scrum technique. Yes they have been subsumed into Common Scrum but I believe they originally originated with Extreme Programming. Where they originated isn’t really important because I believe story point estimation and tasking (i.e. estimating work to do with story points and then scheduling a number of story points) is at odds with Scrum Commitment.

I’ve blogged about this before, Two Ways to Fill and Iteration, so I won’t repeat myself. Just say, in my book commitment and story pointing are alternatives.

By the way, the name Story Points comes from Mike Cohn, I prefer to call them Abstract Points, and I’ve heard others call them “Nebulous Units of Time”.

Second, I don’t believe story points can ever be stable if you don’t have a stable team. If you remove people from a team I expect it to slow down, if you add people to the team I expect it to slow down too - at least in the short term. In the longer term you might increase capacity but frankly I don’t know how long that will take.

I few years ago I worked with one team which had story/abstract points which appeared to be random. When I adjusted form changes in team staffing they average was constant. That said, I don’t expect points to remain constant, they might do for a while but I expect them to fluctuate at the very least.

It goes without saying that I expect sprint/iteration length to be stable too.

Which brings us to the third thing: with points, stories and projections, they only work at the average and aggregate level. They are a good predictor over several sprints but they offer no guarantees for the next sprint/iteration.

Finally, for now, something I do agree with Duarte on: we can’t estimate. By “we” I mean humans. Last year I devoted several blog entries to the subject, Humans Can’t Estimate.

Lynn Langit: Java vs. SmallBasic for Teaching Kids Programming

Sun, 15 Apr 2012 17:11:01 -0700

We’ve been experimenting with porting our TKP (Teaching Kids Programming) recipe library over to Java (from SmallBasic). We recorded a short video showing a comparison between using the SmallBasic language and editor as it compares to using Java with Eclipse … Continue reading →

Lynn Langit: MongoDB for the .NET developer – Zero to Go in 9 minutes

Fri, 13 Apr 2012 12:02:55 -0700

As I explore NoSQL options, I am more and more impressed with both the ease-of-use and the power of MongoDB. Here are two short videos to get you started. In the first video (< 5 minutes), I show you where … Continue reading →

Maurice de Beijer: The browser landscape is changing

Fri, 13 Apr 2012 05:55:58 -0700

I hadn’t really been paying attention to the popularity of browsers a whole lot for the last few months until this week as I was teaching HTML5 and the usage stats influence what is usable and what not. Sure I heard some time ago that Chrome was larger then IE but as most of these statistics are more about politics then anything else I tend to ignore them and just check some sites I know are producing real numbers for me. And the best I know way is to compare Google Analytics on some large sites.

And was I surprised this week when I checked.

These are the stats I collected last December for an HTML5 presentation I did back then:

As you can see there are three big players and Internet Explorer was the biggest with a 42% market share. Now your stats may vary slightly but I would be very surprised they where very different for a general purpose website.

However when I checked this week things where very different.

The total number of visits may be down quite a bit but we arte still looking at more than half a million visits here. And not only did Google Chrome pass Internet Explorer but so did Firefox. And even with the overall traffic being down more than 25% Chrome still manages to get more visits in now then it did in December.

Didn’t see that one coming, it sure seems we are living in a very interesting time as HTML5 developers.

Enjoy!

TheProblemSolver
DotNetEvents

Michael Kennedy: Downloads from Building Rich Input Forms in ASP.NET MVC Webcast

Wed, 11 Apr 2012 22:27:46 -0700

Thanks to all who attended my webcast yesterday. Here is the recorded video, slides, and demo application. Slides: Kennedy-Rich-Forms-with-ASP.NET-MVC-Slides.zip Demo Application: Kennedy-MVC-Forms-Demo.zip Video Recording: Remember, you’ll need to run MongoDB to make the web app work. Read the readme in the zip … Continue reading →

Pinku Surana: Ubuntu Software Center UI issues

Wed, 11 Apr 2012 13:30:20 -0700

I’ve loaded Precise into VMware (2GB, 2 cores). In 30 minutes I’ve run across so many UI idiosyncrasies in Software Center that I can’t remember them all. Here’s a short list: When I installed git, it didn’t change it’s status to installed until I moved to another screen and back. When I went back to see [...]

Maurice de Beijer: Using jQuery from an HTML5 Web Worker

Tue, 10 Apr 2012 01:57:00 -0700

jQuery is one of the most useful frameworks out there for web development. And while most of jQuery is very much about working with the browser DOM there is also another side to it that makes doing networking real easy and that is all based around the $.ajax() and related, like the $.getJSON(), functions. Now HTML5 contains a real useful part in Web Workers for doing work that should not block the background thread. And using the XMLHttpRequest for network IO is fine in a Web Worker.

Unfortunately however working with the DOM is not ok in the Web Worker, which makes total sense, but as a result using jQuery, which has lots of DOM related code is not fine in a Web Worker. And that is a shame because using jQuery for just network IO would be much easier that the XMLHttpRequest and totally fine if it would load.

So removing the DOM code from jQuery should solve the problem right?

Enter the jQuery - No DOM Edition

It turns out Konstantin Pozin did just that with the jQuery - No DOM Edition

You can find it here or download a test version here.

Enjoy!

TheProblemSolver
DotNetEvents

Llewellyn Falco (Approval Tests): What’s New in ApprovalTests .Net v.18?

Tue, 10 Apr 2012 01:44:00 -0700

FrontLoadedReporter
IEnviromentAwareReport Upgrades
CodeCompareReporter
DictionarySupport
EF and Mvc3 additions
Bug Fixes

FrontLoadedReporter Attribute (For Build Systems)

You can now add the following code to your assembly.

[assembly: FrontLoadedReporter(typeof(NCrunchReporter))]

This is only allowed at the assembly level, and must be a IEnvironmentAwareReporter. If the reporter is allowed in the current environment, it will circumvent all other reporters. This is very useful for Build Systems where you want to override the behavior of the reporters.

IEnvironmentAwareReporter is file specific (better composition)

The IEnvironmentAwareReporter interface has changed from

bool IsWorkingInThisEnvironment();

bool IsWorkingInThisEnvironment(string forFile);

this allows for better composition of reporters. For example I can now combine DiffReporters that only do text with DiffReporters that do images. If you have an Image it will fall thru to the ImageReporter even if the TextDiff Program is on your system.

This is especially nice for…

CodeCompareReporter

My new favorite text diff tool is Code Compare, mainly because it integrates directly into Visual Studio 2010. You can download it here (it’s free)

Dictionary Support

var map = new Dictionary<string, string>(){
{"Caption", "Mal"},
{"Pilot", "Wash"},
{"Companion", "Inara"}  };
Approvals.VerifyAll(map);

This will now create the expected approval result. I don’t know how this didn’t exist from the very start. It is worth noting that keys will be presented in their natural ordering (to allow consistency.)

EF and Mvc3

I added a Mock Saver, LambdaLoader & SingleLambdaLoader to the Enitity Framework support.
I also added .Explict to the Mvc3 Toolkit. I will make videos about this approach soon.

Bug Fixes

There were 2 bugs that got fixed this round.
64-bit machines didn’t launch 32-bit Reporters.
XUnit Reporter didn’t invoke the right Equals Method.

Both are fixed now.

Tony Sneed: Ninject WCF Extensions for RESTful Services

Sun, 08 Apr 2012 07:53:58 -0700

Download the code for this post. A while ago I blogged about using Ninject for dependency injection with WCF Services. The advantage of using DI is that it allows you to achieve loose coupling in your application architecture, so that … Continue reading →

Brock Allen: Cookieless session considered dangerous

Sat, 07 Apr 2012 21:31:13 -0700

Another question came up: “What if users disable cookies – won’t session break?”. Yes. So will Forms Authentication and the Anonymous Identification Module. And so will half the web. But wait — session state, forms authentication and the anonymous identification modules all have cookieless modes. Surely if that’s an option it’s fine to use, right? [...]

Brock Allen: Think twice about using session state

Fri, 06 Apr 2012 21:31:32 -0700

So this question comes up all the time: “Where should I keep my shopping cart data for my application?” The common knee-jerk response is “use session state”. I find this to typically be the wrong answer if you want to build a resilient and scalable application. Session state was originally meant for this kind of [...]

Michael Kennedy: Webcast: Building Rich Input Forms in ASP.NET MVC Tuesday April 10

Fri, 06 Apr 2012 12:42:41 -0700

[Update: View the recordings and downloads.] Want to learn more about building great forms in MVC? Attend my free DevelopMentor webcast this Tuesday. Webcast: Building Rich Input Forms in ASP.NET MVC https://www3.gotomeeting.com/register/559059054 In this webcast we will explore the powerful … Continue reading →

Maurice de Beijer: DotNed podcast: Patriek van Dorp over NuGet packages voor Windows Azure

Fri, 06 Apr 2012 02:43:00 -0700

In deze podcast spreekt Maurice de Beijer met Patriek van Dorp over zijn TechDays presentatie over NuGet packages voor Windows Azure.

Links:

Blog: http://patriekvandorp.net
TechDays presentaties: http://www.techdays.nl/AgendaDetail.aspx?cid=2271
Wazug: http://www.wazug.nl/
NuGet: http://nuget.org/
Presentatie met links naar de NuGet packages: http://static.techdays.nl/Speakers/Presentations/2012/Patriek van Dorp - NuGet For Windows Azure.pdf

Met dank aan onze sponsor RedGate.

Andy Clymer: Pet USB Keys

Thu, 05 Apr 2012 12:19:00 -0700

A friend of mine has designed some dog USB keys. I'm sure they will be a hit with dog lovers and kids alike

You can buy them online

http://www.petstar-tech.com/
"Designed in Farnham assembled in China"

Brock Allen: Ajax with HTML or JSON

Wed, 04 Apr 2012 22:27:30 -0700

Recently a poster on the asp.net forums asked about the difference between returning HTML or JSON from Ajax calls. Here was my answer: airic82 Well, ya. But working doesn’t always mean its following best practices. Sinful term! “Best practice” requires context. Usually the answer is “it depends” and thus there’s rarely “the one and only [...]

Michael Kennedy: No, You Don’t Need A Windows App

Wed, 04 Apr 2012 08:03:33 -0700

Do you think you need a Window’s app for your next project? Here’s a thought: No you don’t. Let me give you one less reason choose the rocky-road of desktop apps today. You’ll hear people tell you that if you … Continue reading →

Maurice de Beijer: Slides from my security and REST services session at Engineering World 2012

Wed, 04 Apr 2012 02:32:00 -0700

Here are the slides from my securing REST services session I did at Engineering World 2012.

Beveiliging en REST services

View more PowerPoint from Maurice Beijer

Enjoy!

TheProblemSolver
DotNetEvents

Andy Clymer: Double check locking

Tue, 03 Apr 2012 05:26:00 -0700

At my recent Async talk at DevWeek I built an Asynchronous queue that enables the consumers to take advantage of async and await keywords available in C# 5. You can download the code here, the final step in that implementation was to make use of double check locking. A delegate came up to me afterwards and said my code wasn’t thread safe, in that I could end up with a partially completed object. This was due to the fact that the CPU can re-order write operations to optimise memory bus, and that is true of some processors. In that the reference to the object could be flushed out to main memory before the data associated with the object constructor. This certainly was the case in .NET 1.1 with certain chip sets not true for your classic x86 and x64 but the Itanium I-A64 family of processor. The work around was to make the pointer to the constructed object volatile forcing the compiler to place the appropriate memory barrier instructions.

However in .NET 2.0 the CLR team enforced a more strong memory model since they didn’t like the idea of managed code behaving so differently on the final target hardware. Here is a link to the write up from MSDN mag by Vance Morrison the compiler architect of the .NET runtime explaining why you don’t need to use volatile from .NET 2.0 onwards.

Andy Clymer: DevWeek 2012 Demos

Tue, 03 Apr 2012 05:08:00 -0700

Just to say my demos from DevWeek 2012 are now available for download here

Maurice de Beijer: Demos and slides from my HTML5 and REST presentation in Belgium last week

Tue, 03 Apr 2012 01:29:00 -0700

HTML5 & rest services

View more PowerPoint from Maurice Beijer

You can download the ASP.NET WebAPI demo here and the SignalR demo here.

Enjoy!

TheProblemSolver
DotNetEvents

Tony Sneed: SSD + SATA = Best of Both Worlds

Mon, 02 Apr 2012 07:00:07 -0700

Every once and a while I pull something off that makes me smile. I experienced this sensation last week when I swapped out the DVD drive in my MacBook Pro and replaced it with the 500 GB SATA hard drive … Continue reading →

Andy Clymer: Devweek 2012

Mon, 02 Apr 2012 01:10:00 -0700

Had a great conference as ever. Thanks to everyone who attended the RSK talks. I literally left the conference and went on holiday. Will be back tomorrow so will upload the demos to the website on Tuesday 3rd

If you want a refresher on the asynchronous talk we have screencasts on the site that cover some of the aspects

Lynn Langit: Hadoop on Azure – JavaScript MapReduce using AWS S3 data

Sun, 01 Apr 2012 19:01:27 -0700

What? Use a Microsoft Azure product (Hadoop on Azure) to run a MapReduce job (using JavaScript) on data stored on AWS S3? Seems like a great blog topic for April 1, doesn’t it? Enjoy the video. Here’s Microsoft’s Denny Lee’s … Continue reading →