2010-08-13

Using BDD with SpecFlow, WPF and White

It’s been a while since I blogged. Twitter is taking over. I compensate that with a major blog post.

Background

I written about the project I’m in right now a couple of times before and to make a long story short; we don’t have any requirements! We only have the existing application which we are to “convert” from VB6 to VB.NET. 1:1 is the mantra – which is to be understood as: functional the same.

I have suggested for the team that we work with BDD (or ATDD if you like) to create the requirements as we go. They liked it. A lot!

To not let this post grow totally out of control, I leave the description for that process to another post.

To put my money where my mouth is and show them how it should be accomplished. This blog post is that description.

Solution and tools

SpecFlow

The best BDD-tool I’ve seen for the .NET platform is SpecFlow. It’s a very active open source project that gets more and more attention in the community.

WPF and Prism

We’re going to build a fat client (remember them?) and have decided on building it with WPF and Prism 2 (or 4 was it?) .

Let me right now say that I don’t, yet, know much about Prism and my example in this post is NOT an tutorial on how to build great Prism-applications.

White

The missing part in the solution puzzle was given by the White project. From their website we learn:

White is a framework for automating rich client applications based on Win32, WinForms, WPF, Silverlight and SWT (Java) platforms.

Well – perfect fit, if you ask me. Also – the creators of Prism has used White to acceptance test their own stuff.

Where I learned

I’ve followed the SpecFlow-project for a while now and they have increasingly supplied us with great examples and tutorials. I recommend you check them out. I haven’t seen to much that isn’t web application though.

Likewise the Prism project comes with lot of examples. See their download and learning pages. This description of a Hello World example helped me get started.

White also have some useful examples on their Codeplex-site. I also found this post by Ben Hall useful.

How I did it

Let’s, finally, get down to business. I’ll take this step by step but not supply every detail, for the sake of brevity. The complete code sample can be found here.

The example is very simple calculator. Yes, I know that the example not is a fully fledge application but it proves my point.

Through the example I will use the standards of my current project, which mean VB.NET.

First I downloaded everything I needed:

• SpecFlow 1.3.4 
• Prism 2.2
• White 0.20

I then compiled Prism according to the ReadMe.txt and the “Desktop only - Open Composite Application Library.bat”-file, which put the files in \CAL\Desktop\Composite.UnityExtensions\bin\Debug-folder which puzzled me for a while.
Could not help myself to smile when 431 tests passed. Gotta love TDD!

I now created a empty solution for my application, Marcusoft.BDD.Calculator and in doing so got a root-folder for my application.

In this root project folder I created a lib-folder and copied all the Prism binaries (from CAL\Desktop\Composite.UnityExtensions\bin\Debug)

I then moved all the White binaries to the lib-folder as well. My god – it was many – I will not use all of those…

In my solution I created a lib solution folder and pulled all my binaries into Visual Studio. That’s probably not need but I like to see everything I’m using in the solution.

Writing specs

I now turned to the SpecFlow part of things. As this project will serve as a demonstration for my project I wanted to follow my current customers requirements (VB.NET, MSTest etc).

I therefore created a Test-project called Marcusoft.BDD.Calculator.Specs. DON’T try to create a Class library and convert it into a MSTest-project. You will only fail…

In the project I created a folder called Steps and removed the ubiquitous UnitTest1.vb-file. I also added a reference to TechTalk.SpecFlow.dll from my lib-folder.

One cool feature with SpecFlow is that you can put some rules for how your features are to be written in configuration. That’s stuff like test runner and other technical configuration but also the language used for you features and scenarios. This will give you compilation errors for typos in your requirements! I actually scream of joy when that happened.

So I added an App.config with the following content:

I used sv-SE to enable Swedish for my language setting. But I switched to en-US to get English for this post.

Now I created a .feature-file to get my first SpecFlow-feature. The feature is called: SumTwoPositiveInteger and looks like this:

Please not that I pay homage to the SpecFlow-template :)

Also, on a more serious note, this is a very imperative (vs. declarative) style of writing scenarios. That fit’s our needs very well but maybe not yours…

As the BDD cycle says I could now compile and run my tests to get a Inconclusive result and some help on how to continue. The code I was suggested is in C# but that’s easily translated with this tool. Not to bothered with that. Yet.

So the first version of my steps matched this precisely. That could work for now. I could now start my outside-in development cycle and write some code.

When I now ran my tests they are all pending. Which gives me an opportunity to write some production code.

Writing application code

Here I followed the description in the HelloWorld-post I mentioned before, to get my skeleton code up and running. I will not repeat it here. I called my Shell Marcusoft.BDD.Calculator.Desktop and the module Marcusoft.BDD.Calculator.Module.

On trick was the Application.xaml is called Application and not App. This result in trouble since we’re inheriting from a Prism-class called Application. When you change the name there are 3 places to do it in… or use refactoring…

When you have created your module and got it to run and display an empty form, you’re ready to continue on.

Automating with White

Starting the application

The first thing I started out with was my background:

Background:
    Given that the application is started

To achieve this I had to find a way to start the application via White.

So first I referenced White.Core.dll and put a reference from Marcusoft.BDD.Calculator.Specs to the system under test (Marcusoft.BDD.Calculator.Desktop)

I then used the BeforeFeature-attribute of SpecFlow to start the application (or attach me to it) and the AfterFeature to kill it. That made me write this code:

Writing in textboxes

Now we’re cooking. This actually starts my application and displays the form. On to the next order of business…

The first row in my scenario says:

Given that I write 2 in the textbox Number 1

I need some way to get hold of a textbox and write the specified number in it.

First I cleaned up my step to match all those occurrences. Here is the Given-attribute and method declaration for that:

This will send the number after “that i write” as stringUserEntered and the name of the box after “textbox” as wellKnownNameOfTextbox.

With that in place I could remove the other two givens that was exact matches for specific number.

A problem occurred with the name of the textbox. When writing the specifications we don’t want to write the ID of the textbox (txtNumber1 for example). Instead we want some kind of well known name that the users refers to the box with. Often that will be the name of the label for the control.

In this simplified example I have implemented a convention (over configuration). All textboxes have the same name (in lowercase and without spaces) as their label. That may not hold for ever but works for now.

I could now write a method that returns a control, of a given type, based on the well-known name for that control. Here it is:

I ran my tests again to watch them fail since there was no control on the form called “number1”. Great – no I can write production code.

I updated the user control with a label and textbox called Number 1, and then ran my tests again and … progress! The correct number was filled in.

And the regular expression matches for both textboxes – so I when I get the next error (no textbox for named number2), i can safely add some production code and controls for that.

I had now worked my way outside, from the scenario / requirements, in to the actual implementation.

Love this!

Selecting in Combo-boxes

The final pieces comes together quite easy. I updated the Given-statement that SpecFlow-generated for Calculation Type from this:

<Given("that I choose '\+' in the list Type")>

to this:

<Given("that I choose '(.*)' in the list (.*)")>

And then implemented a generic method that selects a value from a combo box like follows:

That drove me to put the a Combo-box on the view. And got another part of my feature passing.

We’re getting there. One step at the time.

Clicking buttons

To click a button it’s as simple as:

And the following method to check the content of a textbox:

With these two methods I could bring the whole feature together. And it fails and tells me that 5 is expected but it got an empty string. I can now implement the functionality for the feature.

Conclusion

This blog post is getting ridiculously long already so I better wrap it.

From now on I continued on driving my implementation from the scenarios. I took very small steps as described above, so I always knew where I was.

It took quite some time before I could get my first feature flying, but by then I had a real nice set of step’s that could be reused by the next feature. Which led to that the subsequent features were really fast to implement. I added scenarios for subtraction, division and multiplication. Which didn’t force me to write anything but production code!

What didn’t I do

I haven’t included anything on TDD in this post. And I didn’t do any. That doesn’t mean that I don’t think it’s needed, but I didn’t wanted to mix any of that into this example.

I will sure have to work more on the handling of names and references to them. There is an article on that in the White functional testing documentation, that talks about screen objects. Also I recommend watching this video on how to test the GUI in a web application. It gave me some valuable insights on how ATDD might influence your code and naming etc.

The code

The code be downloaded here. I will sure work on it – so it might update from time to time.

Final thoughts

This has been a very technical post with lots of code. But remember – it’s not in the tool!

For me the biggest take away when working like this is the way you can collaborate with customer, analysist and tester when writing your features and scenarios.

That’s so much more important than any tool.

If you read all of this – thank you. You have been an awesome audience ;)

Postad av Marcus Hammarberg

2010-06-14

Resovling policy enabled objects with Unity 2.0

I had the opportunity to use Unity and Enterprise Libarary in my current project. On of the really cool features of Enterprise Library (and most Dependency Injection frameworks) is the support for Aspect Oriented Programming. It’s a really neat way of handling the cross-cutting concerns in your application.

I was therefore very surprised when I had a really hard time to get, what I thought was simple, the following scenario to work:

I want the objects that I resolve to be “policy enabled” – i.e. configured in such a way that I can add policies in the configuration that can be picked up later and applied to the resolved objects.

That is, it was hard in Enterprise Library 4.1 and Unity 1.2. I had to scan the net and put together a solution of my own. It was a mix of extension methods, wrappers and some low-level enterprise library tweaking. You know, the kind of code that doesn’t make you feel proud after you wrote it.

And then Unity 2.0 and Enterprise Library was released. All my problems gone! Everything is simple and the sun is always shining. … Not quite – the scenario I was looking for was a bit tricky still. But the solution a lot cleaner.

I asked a question about in on both StackOverflow and in the Unity Community and soon got an answer. In the unity thread I’ve posted a complete code example of the solution.

In short the answer was to add an extension called EnterpriseLibraryCoreExtension, like this:

_container.AddNewExtension<EnterpriseLibraryCoreExtension>();

Using this extension will instruct Unity to pick up my configuration with, in this example, the policies and apply them to the resolved object.

Postad av Marcus Hammarberg

2010-05-28

TF203007: Cannot create the label because the version controlled item […] already exists or has been specified more than once

OK – I just broke my old “longest blog post title” but this was a problem we ran into today.

As I understand the message some kind of duplication has taken place, but I don’t know what to do about it. Well I found this on a msdn-forum:

This error is cause by one of your developer was deleted file and added exactly same file back in instead using undeleted feature, and in the backend database, TFS give this file new file id which has exactly same server path; therefore, when you are trying to label, it throws an exception which complaining file already existed. To work around this issue, you have to manually open label and remove […] Then you should be able to label again.

OK. One of those - “That’s strange, but it works”. Thank you AndyPham.

Postad av Marcus Hammarberg

2010-05-11

Scaling Scrum in the Enterprise with Kanban

I have had the pleasure to hold a lightning talk for the Agila Sverige conference i Stockholm about "Scaling Scrum in the Enterprise with Kanban".
The talk went well but the format (10 minutes) made it more like an elevator pitch.
You can find an enhanced - somewhat longer - version of the slides used during presentation on slideshare.
I will venture deeper in the subject on a comming blog post.

Postad av Christophe Achouiantz

2010-05-11

WCF, MVVM and good client design

Up to now most of my assignments has not been client-related. Often the project description and main focus is on the layers beneath the GUI. But lately I have seen a shift in the industry and more so in my own interest. Client-side stuff is coming on strong.

And it’s hard work to design a well structured client application. There are a lot of patterns but the frameworks and “recommended” ways up to now often doesn’t lend themselves well to those patterns. Ever tried to do proper MVC with WebForms or WinForms – it’s not easy.

But that has also shifted. I have written a lot on ASP.NET MVC – that of course supports the mother of all client patterns, MVC, in a great way. So enough said there.

But for “fat clients” such as windows clients there’s been a hazy mystery for me. I know OF WPF but I don’t know WPF. And they seems to talk a lot about the MVVM (Model-View-ViewModel) pattern.

To the extent of my knowledge now the MVVM pattern is an adaptation of Martin Fowlers Presentation Model pattern. An adaptation that make full use of the WPF DataBinding capabilities.

I’ve found some great resources on this – starting with this excellent presentation on the pattern, by Jason Dolinger. Here is his source code

After that I thought that there must be frameworks that helps me with this. And there are. About as many as there are WPF developers… Here is a great StackOverflow post that helps you choose one.

And following one of those links (to the MVVM Foundation) I finally found and read this great MSDN Magazine article by Josh Smith.

Postad av Marcus Hammarberg

2010-05-11

Ny sorts kortlek för planeringspoker

Avega Group har nyligen tagit fram en ny kortlek för planeringspoker som bygger på lärdomar vi samlat på oss från våra många medarbetares mångåriga erfarenhet av agil programvaruutveckling i olika former.

Foto: Ola Dusegård

Denna kortlek skiljer sig något från den vanliga, traditionella leken och vi har fått en del frågor om hur den är tänkt att användas. Jag vill därför beskriva bakgrunden och våra tankar om hur den kan användas.

Låt oss ta det från början. Planeringspoker är en populär metod för att estimera storleken på user stories (eller use cases, wireframes, etc - välj ditt gift) i agila metoder som Scrum eller XP. Den går i korthet ut på att teammedlemmarna oberoende av varandra med var sitt kort visar hur stor de anser att en user story är i relation till andra user stories. Om man inte är överens diskuterar man skillnaden i estimaten, gärna genom att dem som avviker åt ena eller andra hållet motiverar sin bedömning. Sedan visar man kort igen o.s.v. Man brukar använda valörer som löst följer Fibonaccis sekvens: 1, 2, 3, 5, 8, 13, 20, 40 och 100. Tanken med att utesluta siffrorna däremellan är att man inte ska lura sig själv och andra att estimaten är mer än gissningar, måhända mer eller mindre kvalificerade sådana. Ju större saker stories desto svårare att korrekt estimera och därför passar fibonaccitalen bra.

Svårigheten med att estimera stora saker korrekt driver också många team att försöka dela upp stora stories i mindre som är lättare att estimera. Det finns också andra fördelar med att ha små stories, inte minst att man kan leverera nytta snabbare, men också att man får tätare återkoppling, lättare att få ihop lagom mängd stories för en iteration m.m. Det anses därför vara god praxis att jobba med så små stories som möjligt, men som fortfarande ger nytta för användaren, när man jobbar agilt. Många team använder därför sällan eller aldrig de högre valörerna eller så använder man dem för att indikera att storyn är för stor och bör brytas ned i mindre.

Om man tar det här tänket tillräckligt långt kanske man inte har mer än tre olika storlekar: normalstor, något mindre och något större. Eller small, medium, large; t-shirtstorlekar helt enkelt. Just t-shirtstorlekar är något som blivit populärt i många Kanban-team, dels därför att man då ofta anger estimat i dagar baserat på faktiska data för de olika storlekarna, kanske i form av SLA:er, dels därför att Kanban tydligt visar på fördelarna med jämnstora arbetsenheter för att underlätta snabbare och jämnare flöde. Andra gillar t-shirtstorlekar därför att de ytterligare förstärker ovissheten i estimat och inte inbjuder till sifferexercis som kan missbrukas i för detaljerade och långtgående prognoser.

De här lärdomarna från våra erfarna agilister och scrummare är något vi tagit fasta på i vår kortlek och därför har vi helt enkelt tagit bort de högre valörerna och dessutom lagt till t-shirtstorlekar på korten. Det innebär att kortleken innehåller något fler kort med valörerna 3/Small, 5/Medium och 8/Large, vilket gör att ett team som bara använder dessa storlekar kan få en kortlek att räcka till åtta personer istället för fyra. I ett Kanban-team jag jobbade med använde man även XS och XL (för att indikera att storyn är för stor) och lät då kortlekens XS och XXS representera XS, samtidigt som XL och XXL fick representera XL. På så sätt kan man fortfarande få leken att räcka till åtta personer även med ett bredare spann.

Foto: Ola Dusegård

Har du andra idéer eller erfarenheter kring planeringspoker, t-shirtstorlekar eller kortlekar? Dela med dig!

Postad av Joakim Sundén

2010-05-06

Configure WCF in IIS for anonymous access

This case may sound strange and I have seen loads of post that describes how to get out of this behavior. But we have a case where we want to allow anonymous access and the let a external component manage the security validation.

This turned out to be very hard to figure out and required some wizard-like skills of Anders Granåker amongst others.

OK – the case is very simple. I have a WCF Service that I want to allow anonymous access to. I don’t care about message and transport security (for now). Just allow anonymous access – I’ll take care of the authorization in code.

Here is what I had to do to get it to work on Windows 2003 R2:

1. Create a account on the server
2. Put that account into the IIS_WPG group
3. Create a virtual directory for my WCF service
4. Create an application in that virtual directory
5. Set the account as Identity on the application pool that the virtual directory is using (DefaultAppPool for example)
6. Set the account as the anonymous account the virtual directory is running under (Directory Security)
7. IISReset to get the settings to take

The last step is a bit interesting… In this time and age you could think that a simple recycling of the application pool would be enough but … no. Do an IISReset to be sure.

Another gotcha that confused us a lot was that when you set an account to be the anonymous account for the virtual directory, you’re prompted to set the password. And retype it to be sure. But that password is not check if it’s the right password! Beware – I locked out our administrator account due to this.

Now it works – and we have a build script that is doing regressions tests via SOAPUI.

Postad av Marcus Hammarberg

2010-04-22

Specification by example – the missing link?

I’ve been thinking. That statement alone will be sure to put fear in the heart of a lot of you… But if you have continued on this far, here we go.

Learning programming stuff

During the last year or so I have been reading a lot. I have read stuff on XP, on good design DDD and TDD. This reading has affected me and my coding style way much more than I first thought. I simply cannot write code anymore without the test first, interface first, thinking of SOLID etc..

Learning lean stuff

At the same time I have change role at Avega. I am now an AvegaCoach. This means that my time is divided between my regular (often coaching) assignments with customers and Avega and Elevate. Since my fellow AvegaCoaches (Joakim and Christophe) and me are interested in agile and lean stuff we have focused our joint efforts on that.

This has led that I have learned a lot from them about lean and Kanban. And this has expanded my understanding of Scrum and how to work agile.

Frustrations

But around here the frustration started to kick in. I felt that these two areas; technology and process stuff could marry in a great way. But how? And how much does the it affect each other?

Also, a specific thing that I have been really frustrated in is how to include test in an agile world. Testing are left out in planning, are left to try to keep up with development and the regression stuff will eventually kill them. So “testing sprints” are introduced, “we’re running a sprint behind the rest of the team” and other solutions like that is used to try to get around it.

Surely – this cannot be the best case? So I started read about agile testing. I loved the book by Gjoko Adzic. This book introduced me to the term agile acceptance testing and specification by example.

The solution?

I have heard and learned quite a lot about BDD. I knew that BDD and “outside-in” thinking can help me design my application in a maintainable way. But BDD can be applied at any level. It could be used to spec out your unit test. Another way to do TDD (AAA becomes GWT)

But I had missed the fact that the specifications and features should could be written in collaboration with customer or business analysists. This will turn the specs into executable specifications. (Those words still gives me the shivers. It’s so cool!)

That’s the thing! With executable specifications you have a living specification to code against, and the moment you’re done (as in done done) with the story the specification is “magically” turned into an acceptance test.

And the specifications finally reflects what the code is doing. I can never forget a quote by a customer how very proudly showed me the folder with all the specifications (use cases in this case) and then told me:

“And the best thing… they are almost up to date with what the system does”.

The really scary part about that is that it was actually the best I ever seen. Most documentation and specifications are a violation to the DRY principle. But with executable specifications you’re as close as it gets.

But it doesn’t stop there: since the specification with any current tool is written in plain English you can workshop around it to get everybody's (business analysis, testing, coding, deploy etc) views on the matter. And you minimize the misconceptions by using real world examples.

And that in turn closes the gap for me; agile testing is hard since I am still viewing testing as something separate from coding. And the same goes for specifying… But it’s not! You can do this in agile way, a little slice of functionality at the time. A way to do that is specification by example.

Recommended watching and reading

Read Gojkos book – Bridging the communication gap. Stop reading whatever you reading now and start reading this. It was a eye-opener for me.

Watch (anything you can get your hands on) this webcast by Dan North. There are lots of great stuff in here on BDD and design.

I’m reading Agile Testing right now. That has really showed me that testing is something that any agile person (developer, tester, business analysist etc.) should care about. Or as Deming put it:

“Quality is everyone's responsibility.”

Postad av Marcus Hammarberg

2010-04-14

Calling SOAPUi Testscript from MSBuild

Yes, I know that I have written about this before, with several updates. But I have now solved some issues with setting different endpoints for different services and thought that I might need to update the MSBuild-script to be able to call with those parameters also.

Again – the script I am starting off is written by Todd of the Tar Pit. I’ve just tweaked it to take project property as input. That was the recommended way to change the endpoint for one service, to set the endpoint to a projectwide parameter.

So, here is what the new MSBuild targets looks like.

And here is a DOS-command that runs the MSBuild-target TestAll with the project property set to a endpoint.

Please note that I was running this on a 64-bit Windows 7 and got some strange paths (Framework64) that you want to change..

You can download my complete (now updated) project from here.

Postad av Marcus Hammarberg

2010-03-30

Changing endpoint from the command line when testing services with SOAPUi

I have been singing SOAPUi’s praises lately and it’s really great for testing services. In this post I describe how I made the whole thing work for testing WCF Services.

But, as stated in this post, there was still one more thing to be solved… The endpoints from the command line. You want to use different endpoints in different environments. And in my specific customer case I want one of them to stay the same all of the time, since that endpoint points (sorry, could not resist myself) to a “singleton” kind of service.

Luckily the SOAPUi team also have some great support (Thanks Ole, who replied in Swedish!). So here you have it – how to change the endpoint for one of your services under test from the command line – which in my case means the build script.

1. I first created a sample WCF service project (very vanilla, i didn’t touch the code just the default generated code).
   By the way; really cool hosting and test client stuff in Visual Studio 2010
2. I changed the binding to basicHttpBinding since that’s the only thing that work with SOAPUi. I used the WCF Service Configuration tool in Visual Studio of course.
3. I then created a normal SOAPUi project and let SOAPUi create testcases for me. I added asserts just to make sure that the I didn’t get an error back.
4. I started my service and ran the testcases – It worked!
5. I then, and here is the trick, created a project-wide property (Click project file and chose Custom properties in the lower part of the project window) to hold the endpoint value.
   1. I named the project wide property DemoServiceEndpoint
   2. I gave it the address of the service I was testing as value
6. I then opened the tree down to the test request in question and then chose the Test Property-tab in the lower part of the project tree
7. Here I entered this expression that reads the value from my project wide property:
       ${#Project#DemoServiceEndpoint}
8. I repeated for my other test request and tested. It still worked!
9. OK – we’re closing in now. Now I used the Test Runner to create my command (nifty stuff SOAPUi dudes!). Here I got the opportunity to set my parameter ${#Project#DemoServiceEndpoint}.
10. After some tweaking I managed to “harvest” the command into a .bat-file.
    

    "C:\Program Files (x86)\eviware\soapUI-3.5\bin\testrunner.bat" -sDemoTestSuite -PDemoServiceEndpoint=http://localhost:8732/Design_Time_Addresses/Marcusoft.SOAPUiDemo.WCFService/Service1/ C:\Dev\Marcusoft.SOAPUiDemo\EndPointOverrideDemo-soapui-project.xml 

11. And it worked!

So now I can change the endpoint from the command line! In my build script when I have deployed the service to the testing environment for example! Yeah!

You can download my example here.

Postad av Marcus Hammarberg

2010-03-30

Status of work items – where to keep it

This is a question that arises very soon or sometime even before you start doing work with a board; Scrum, Kanban or Scrumbut.

Where should the status be? Or more often – “let’s use TFS” (and keep the work items in TFS/SharePoint/Excel and then make copies of them to use on the wall).

A variant of the question is; “we are a distributed team – can we still use the same board?”

Well of course there is not a yes or no answer to that but here is my take on it:

Low tech rules!

First I think that no electronic system will ever beat the flexibility, simplicity and agileness of a board. See this for some examples. There are some that have come close but a low tech board communicates so much information with the added flexibility to move things around very easy.

Also using a board promotes face-to-face communication which is always good. I have been in teams where the status of the electronic system should be updated before the daily standup – what use is the meeting then?

Master data problem

Secondly this problem is a master-data problem; who is the master of the status?

There are places, big companies, distributed team etc. where electronic systems are the only way (or so they say ;)). Then you’ll have to use them. But be sure to know where your master status is – on the board or in the system?

When I did my military service I learned: “if the map and reality mismatch then the map is correct” (or master). That shows how master data problems is handled in a bad way, I think. Know where your master status is and treat all other sources as non-masters or copies.

Use the tool not the other way around

Finally – it’s not in the tool. Or put differently these are just tools. Tools are meant to be used by people to get task done easier. Not to add load to the burden.

If you ever find yourself complaining (as I have… a lot…) of having to update TFS with the status of the board – then the tool is using you. Not a very clever way to use your time. Waste – in Lean terms.

How I would do it

If I ever got the chance to decide on stuff like this (Hey, I sometimes do!) I would do it like this:

• Keep your work items and their status on the physical board
• Let the physical board be the master of status for the work items
• Use the electronic system to keep reference data that doesn’t need to be on the physical board.
• Do not keep status of the work item in the electronic system, or rather not all of them. You could keep a simplified status chain (Not started/Started/Done for example)
• Put a reference on the work item on the board to the ID inside the electronic system
• “Stamp” work items with the dates they enter a new stage of your workflow. You can then use these data to find bottlenecks in your workflow, make predictions (search for Disneyland) and get some really nice follow-up-data
• Keep in synch within distributed teams by using any means possible; web cams, digital photos, telephone, IPhone video calls, travel; are some of the ways I have tried to solve this.
• Use the board to get your work to flow smoother – don’t add more work to keep the board and any system up-to-date.

That’s a few thoughts on the subject.

Postad av Marcus Hammarberg

2010-03-28

Practical Kanban – some Kanban boards in practices

Together with Joakim Sundén and Christophe Achouiantz I’ve been doing some talks on Kanban. We have included some practicality in the talk – Build your own Kanban-board sort of.

For the first few talks I tried to draw as fast as Joakim (in that case) talked. Not an easy task – try it. And also my drawings were not always optimal.

So Joakim and I did some stop-motion-action and created slides for this part instead. It took the better part of a complete day… But the result was alright I think.

Here are the slides with some short comments to illustrate what we talk about. 

Postad av Marcus Hammarberg

2010-03-18

Persisting Rich Domain Models with NHibernate – Torkel Ödegaard

Kvällens tema var NHibernate och vi fick redan från början veta att vi skulle bli Jedis inom området – Torkel Ödegaard hade nämligen valt Star Wars som exempeldomän.

Torkel jobbar på Avega och har diger erfarenhet av NHibernate genom att ha jobbat med det dagligen under ca 4 år. Dock lär han sig, enligt egen utsago, nya saker i NHibernate. Vilket är både uppmuntrande och lite skrämmande – hur stort är det egentligen.

Kvällen började med en historik och en snabb genomgång av de beståndsdelar som NHibernate består av. Men publiken var mycket kunnig och rätt snart fick vi både djup och bredd. Och rätt snart kom vi också till en mängd av kodexempel.

Dessa kodexempel sträckte sig från de mest basic till avancerat men hela tiden guidade Torkel oss och visade på små nyttiga saker och features i ramverket.

Torkel tog upp en hel del av de vanliga fel som man springer in i när man först börjar jobba med NHibernate (har något sett detta t.ex.) vilket var rätt skönt att se – jag är inte själv. Detta lärde jag mig mycket av under kvällen.

En funktonalitet som jag inte har använt tidigare var detattachade objekt och hur NHibernates funktioner Merge() och Lock() kan hjälpa dig att koppla ihop ett deattachat objekt med en annan session.

Hanteringen av arv kände jag till men jag visste inte om de olika typer av arvshantering som stöds av NHibernate

.Vi lärde oss också en hel del om performance t.ex. genom batchning, eager loading och future queries.

Torkel pratade lite grann om session management, som t.ex. i WCF eller ASP.NET.

Slutligen pratade Torkel om en del vaniga problem som man springer in i. Läs mer om det i kodexemplen.

Torkels kunskaper i NHibernate är mycket imponerande. Kvällen innehöll mängder av kodexempel (50+) och demos. Det blev inte många fel – och de få gånger fel uppstod visste Torkel snart vad de berodde på. Det är verkligen inte lätt att koda inför publik – prova det själv någon gång, får du se.

Möjligtvis behöver Torkel se Star Wars filmerna – Han Solo skulle aldrig flyga en Tie Fighter. Men det kanske bara är jag som är nördig ;)

Tack för en mycket bra kväll – jag och många andra lärde oss massor.

Torkels kod exempel kan du hitta här: http://tlo.googlecode.com/svn/trunk/presentations/nhibernate_elevate/

/Marcus Hammarberg

Postad av Elevate

2010-03-16

Testing with Unity, Policy injection and solving “Ambiguous match found. (Strategy type Instance Interception Strategy” problem

I have been chasing this for quite some time now, about 4 days on and off. But now I have nailed it, thanks to Christer Cederborg – my Unity beacon in the dependency injection mist.

OK – the problem is as follows; I have an object factory that encapsulates the calls to Unity for registration and resolving. This is done because I want to control if the resolved objects should be wrapped with PolicyInjection or not.

However I ran into problem when I created test for my code. In the top most layer an resolved started to fail for the layers beneath them. I started to get an error which basically said:

Ambiguous match found. (Strategy type Instance Interception Strategy…

As often, I didn’t understand the error message and started to chase down the wrong things. I first thought that this had to do with the fact that I was mocking (with Moq) the object that I was resolving. And since Moq creates a type on the fly I could not possible create a policy match for it.

But that was not it. In fact it was simple and of course my own doing.

My ObjektFactory is a singleton – I want to resolve against the same container. But the reference to the UnityContainer was done inline right where variable was declared. Ugly and it jumped up and bit me…

OK – the solution was to have a Init-method that creates a new UnityContainer. And to call it in the test-setup (before each test) and in the application before the ObjektFactory is configured.

Easy – when you looked at the right place.

Postad av Marcus Hammarberg

2010-03-12

Short and sweet introduction to RESTful services

I have heard a lot about REST and RESTful services but never have had the opportunity to work in project that uses that architectural style of working. So sadly I haven’t learned it.

Here is a short and sweet introduction to the subject that explains REST in a good way.

So – as I understand it – it’s just HTTP. The way HTTP is meant to be (URL to each resource, stateless, hyperlinks between resources and usages of the HTTP verbs). I like the simplicity.

Postad av Marcus Hammarberg

2010-03-06

BDD with SpecFlow – some thoughts after a workshop at Elevate

Last Thursday I facilitated a Elevate-workshop, Avega on BDD with SpecFlow. It was, as always, a very nice learning experience for me, and hopefully also for the participants.

I wanted to take some time to put down my thoughts and findings about the framework, BDD in general and some other stuff I have ran into.

BDD – Behaviour driven design

I don’t want to go into explaining BDD since it's been done several times before (I can really recommend the last Steven Sanderson post – excellent!) in a much better ways than I could ever do. Go on and read them if you want – I’ll wait right here.

But I can share some aha-moments and experiences that has surfaced for me when preparing and doing the workshop.

It’s not in the tool

First, as a colleague told me yesterday: “It’s not in the tool”. First and foremost I think that BDD is a great way to discus and formalize the requirements together with your customer. I know that Gojko Adzic has formalized this into workshops where you flesh out the acceptance criteria together and I really like that idea.

That promotes an ubiquitous language and helps you to preserve that language when turning requirements into code.

A great way to get hold of behavior is to ask for example scenarios. These fit very well as the scenarios we’re writing when doing our features and scenarios in BDD. That is so much clearer and crisper than sending documents back and forth.

Implementing outside in

Finally when it comes down to implementing the scenarios you get a nice outside-in approach to your testing. Of course this was where I started. Being a programmer I was eager to see how to use this to write code. And as you might know that was where I started glancing on SpecFlow and BDD.

Starting from the acceptance criteria's or scenarios I was amazed how a design was pulled from the text and turned into code. Just-in-time so to speak

Gherkin

SpecFlow is supporting Gherkin 100 %. Gherkin is the language that is used in the Ruby BDD framework Cucumber. And SpecFlow is a great way to use standard Cucumber/Gherkin BDD-style on the .NET platform. That mean that you can read and understand any Cucumber literature be if for the Ruby, Java or the .NET platform.

Gherkin is a DSL (Domain Specfic Language) for writing user stories and scenarios, with the well know trio of: Given/When/Then. And as it is a formal language it has it’s own best practices and trick that you’ll need to pick up before being productive. Here is a great article series that take you from basic to advanced:

• Basic syntax and usage
• A bit more advanced features
• 15 Best practices in Gherkin

SpecFlow

Earlier on I said “It’s not in the tool” but of course you will need one. The tool I have used is SpecFlow. The thing that I like with SpecFlow is that is 100% Gherkin  compatible and doesn’t introduce any funky syntax to go to code. Ok, it’s cool – but come on: “= () => “ – who reads stuff like that?

Just as in standard Cucumber you also get stub code for your steps, when you run the scenarios the first time. I love that feature since it helps you along in a very nice way.

The binding between your scenarios and the code is done in a class with step definitions. The methods are decorated with attributes (Given/When/Then) that instructs SpecFlow which method to run for a certain step.

Here we found out some problems and opportunities:

• The steps can be located in any class with the Binding-attribute. There is no connection between the scenario and the binding. It just a bunch of steps. If more than one attribute match a step in a scenario SpecFlow will throw and exception and inform you about it.
• SpecFlow supports that you can have more than one attributes (two different [When]’s for example) on the same method. Using this technique you could have very specific strings in the attributes and still have them call the same method.
• In the attributes for the steps you can use regular expressions to be able to send different data to the same step. This could also be a bit confusing since some regular expressions will match a “bigger” portion of a string than you first might have guessed. This feature is standard Gherkin.
• Another, and maybe better way, to send data is the table construct in Gherkin. I found this a much better way to keep your scenarios clean and less sensitive for change.
  The syntax for tables are a bit special though:
  • You need to have space after the pipe (|) sign.
  • The table (of course) need headers, so that you can reference different columns in your code. The first line is the header.
• A thing that confused me, but is the way it has to work, is that a pending step will stop the execution of the rest of the scenario.

All in all I think SpecFlow is an excellent choice when doing BDD on the .NET platform.

A bumpy ride – bugs and embarrassing moments

As me and Måns Sandström created the code and lab for the workshop we ran into more bugs in tools and frameworks than I ever seen… None of them had to do with SpecFlow and some of them had to do with me…

• We used Resharper 5.0 Beta (different versions). I cannot imagining Visual Studio without Resharper, but this time I started to soon. Thanks to some great support some of the issues were solved during the weeks we developed the code.
• I still cannot get Resharper to run the test from the .feature-file. “No test found in file” is the response that I get from Resharper for that… That worked for a while but has disappeared now. I haven’t reported a bug for that yet – not sure if it’s in Resharper or in SpecFlow.
• I also reported a bug in Moq – but that was completely my fault. And I have to endure the embarrassing “user fault” in the report…
  That had to do with me using an overload and forgetting do an Verify for the overload.

So all in all – I’m hooked. I will sure try to get some more BDD approach to the project I’m in. I up to now I haven’t seen a better tool than SpecFlow for the job.

Postad av Marcus Hammarberg

2010-03-03

SOAPUi and MSBuild

After my last post I cannot withhold you from this nugget. It’s a guy (Todd) that have created some MSBuild targets to call SOAPUi from a build script.

I am about to try it out… I’ll get back to you if I run into problems.

Postad av Marcus Hammarberg

2010-03-03

SOAPUi and testing WCF Services – how I made it work

I have already blogged about SOAPUi but then it was more me thinking and seeing it was a good idea to use SOAPUi to do testing of service.

Now I have actually done this – and I love it so far. In the last project where we our deliverable was a service I think we spent about 30% of our time creating and maintaining the test client.

Not to speak about all the time we had to spend explaining for the client that “no this is NOT the GUI you will see later on”.

So the thought of a general test client for SOAP services is very compelling. And SOAPUi has done a great job making your job easy and fun… Almost all of the time.

They have an amazing amount of documentation. I guarantee that everything I am about to tell you is in there somewhere… This is my short story for our case.

So the case is as follows – I have a quite simple WCF service. One trick is that we need to call a common security service (let’s call it SECI) to get a token that we have pass into our operations.

We have worked contract first and started with a WSDL-file. I used WSCF.blue (great tool) to generate the service stub. And then…

• I downloaded SOAPUi. Go on - do it now- it’s free!
• I created a new project by pointing the wizard to my WSDL-file. I also asked the tool to create a starter testcase for me.
  Beware of the location or endpoint address – it’s read from the WSDL-file and most likely you will need to change that to your computer or the server where your service is deployed.
• I then added a new WSDL to the SECI service to the project. This is needed to be able to call

I was now ready to create my test case with the test steps I need to call the SECI service and insert the token into the request I wanted to test.

• First I created some parameters for my test suite. This is actually hidden away a bit.
  • Open the test suite editor by right clicking it and chose “Show TestSuite Editor”
  • In the lower section of the editor you’ll find a “tab” that is named Properties

 

• Here you can add properties that will be visible for the whole test suite
• I added some inparameters to the SECI service and the token I will pass on
• I then called the SECI service, passing it values from the parameters I created in the earlier step.
• To get the values from the response of the SECI service into the request to my service I used a Property Transfer. In it I transferred the value of the token node into a variable that holds the property for the token.
  It’s a quite deep structure with dropdown boxes and namespaces in the UI here but it’s not to hard to understand.
• Finally I could easily insert the value of the token variable into my request, as before.

It wasn’t to hard after I got understanding about the variables for the testsuite. I sure beats having to code your test client manually…

Great work SOAPUi!

Postad av Marcus Hammarberg

2010-03-02

Scandinavian Developer Conference 2010

In a couple of weeks it is time for Scandinavian Developer Conference in Gothenburg again. I had a really fun time last year when I was invited to present about ALT.NET. This year I've been fortunate enough to do two talks: "Flow Where You Can, Pull Where You Must: A Practitioner's Guide To Kanban" and "Drinking From The Source: A Report From a Lean Enthusiast's Pilgrimage To Toyota".

I basically only had one complaint last year and that was the length of the conference: only one day. It seems they listened to my criticism because this year the conference goes on for two days and is packed with interesting Swedish and international speakers, e.g., Michael Feathers, Diana Larsen, Kent Beck, Douglas Crockford, Brian Marick, Chris Hedgate, Roy Osherove, Marcus Ahnve, Ola Ellnestam, Bill Wake, Neal Ford, Jimmy Nilsson and Henrik Kniberg. With so many good speakers and interesting topics, presented in the nice Svenska Mässan convention centre, it will be almost guaranteed to be a great conference.

I hope to see you there!

Postad av Joakim Sundén

2010-02-19

Great Git-reference for non-commandliners

I have started to take a look at git. It looks great and all, but I am not a command line guy…

This quick reference made my life a bit easier.

Postad av Marcus Hammarberg

2010-02-17

SOAPUi and others – regression testing services

I been looking around for some way of (regression)testing the WCF service we will build in my current project. I will not write another client and be forced to maintain it during the project. This took loads of time the last time I tried it.

The thing I will settle on is SOAPUi, which seems just awesome. I have already written about it – but didn’t get the time to try it for real. I sure will now!

But there are others – many of the free. Just see for yourself.

A nice complement is WSDLDisco that creates a portal for your. This is a way to open up for ad-hoc testing for project members that not is comfortable with XML or concepts as requests/responses.

Postad av Marcus Hammarberg

2010-02-17

Resolving with Unity and Policy Injection using extension methods

I actually thought that this was going to be a small thing. The Unity application block is Microsoft’s IoC-container, part of the Enterprise Library. The Policy Injection application block (PIAB) is Microsoft’s AOP framework, also part of the Enterprise Library.

You’d think that it would be easy to integrate the two… But it’s not… that simple. Actually that is stranger than it first sound because apparently they are calling each other internally.

OK – I want it to be easy to combine them, so I have written two extension methods of UnityContainer that make it easer.

Here is the extension methods.

And here is some tests showing the usage.

Of course I haven’t thought this out by myself. That takes time. I want things fast. So I steal ;). Thanks goes to this blogpost that helped me on the way and Christer and Anders who supplied me with some great input on the way.

Yeah that’s right here is the complete code example. And here is a services that translates C# to VB.NET if that’s your preference, mr Scott. :)

Postad av Marcus Hammarberg

2010-02-16

ALT.NET Workshop Day

This weekend ALT.NET organized a full day of workshops at Informator in Stockholm. About 30 to 40 participants could choose among workshops with topics such as Fluent NHibernate, JavaScript, CSS, Introduction to Python, Parallel Programming in VS2010 and Acceptance Test Driven Development with Selenium. After the workshops a bunch of us ended up at Vapiano (as usual!) having interesting discussions and generating great ideas over food and drinks. Ideas man Carl Kenne delivered, as expected, a few good ones: ALT.NET Incubator to help people get started on stuff, a 24 hour business camp for Open Source projects, and more that maybe will be revealed (i.e., remembered) in time on the ALT.NET Discussion Group. Someone wanted to invite professors from his university to come meet developers in the field, and so on so forth.

What I like about these participatory ALT.NET events is how easy they are to organize. One guy (new colleague at Avega Group Anders Jönsson this time) suggests that it's time for another unconference, workshop day or whatever, on the discussion group and the thread catches on with people chiming in what kind of workshops they want or are able to run. Another guy (Tibi Covaci) suggests a venue (Informator), there's some voting about a suitable date and suddenly all you have to do is show up wanting to learn!

If you haven't been to any of the ALT.NET gatherings yet you should definitely come next time - it's always fun and you always learn a lot! Meanwhile, be sure to partake in the discussions and why not post your own idea for the next event?

Postad av Joakim Sundén

2010-02-11

System.BadImageFormatException: Could not load file or assembly 'System.Data.SQLite'

I ran into this problem when I tried to re-open a solution I did a while back when labbing with Fluent NHibernate and SQLite.

Behind the cryptic error message lies and easy solution; I was running the 32-bit version of the SQLite-driver and runtime. That' doesn’t fly on my Windows 7 64-bit machine.

Here is a more through description and here is a link to the latest version of SQLite that will get you all the version (32 and 64 bits) of the SQLite.

Postad av Marcus Hammarberg

2010-02-10

Applied probability and statistics

Speaking of probability and statistics, there is the story of a statistician who told a friend that he never took airplanes: "I have computed the probability that there will be a bomb on the plane,” he explained, "and although this probability is low, it is still too high for my comfort." Two weeks later, the friend met the statistician on a plane. "How come you changed your theory?" he asked. "Oh, I didn't change my theory; it's just that I subsequently computed the probability that there would simultaneously be two bombs on a plane. This probability is low enough for my comfort. So now I simply carry my own bomb."

- Excerpt from Raymond Smullyan, To Mock a Mockingbird and Other Logic Puzzles (1st edition), Knopf, June 1985

Postad av Martin Kaarup

2010-02-07

Lean Software Architecture med James Coplien

Härom veckan talade James Coplien om Lean Software Architecture på Elevate, Avega Groups föreläsningsserie för medarbetare. Coplien har gjort sig känd som något av en ikonoklast inom agile-världen, inte minst med sitt provocerande ifrågasättande av, för många centrala, praktiker som TDD och onsite customer. Provokationer som han inte drog sig för att upprepa inför det dryga femtiotal åhörare som samlats på Avega Group denna kväll.

Ämnet för den här kvällen var emellertid Lean Software Architecture:

"Agile has long shunned up-front design. When Agilists force themselves to do up-front work, it usually is limited to a symbolic use of User Stories for requirements and metaphor for architecture, with much of the rest left to refactoring. Experience and formal studies have shown that incremental approaches to architecture can possibly lead to poor structure in the long term. This talk shows how to use domain analysis in a Lean way to build an architecture of form that avoids the mass of structure that usually accompanies big up-front design, using only judicious documentation. It will also show how architecture can accommodate incremental addition of features using Trygve Reenskaug's new DCI (Data, Context and Interaction) approach, and how it maps elegantly onto C++ implementations. The talk is based on the forthcoming Wiley book of the same title."

Läs mer om Copliens bok.

Läs mer om DCI Architecture.

Postad av Elevate

2010-02-07

Red Bead Experiment at Limited WIP Society Stockholm

In December we organised a second meeting with the Limited WIP Society user group in Stockholm, this time at Crisp. David J Anderson honoured us with a visit and an interesting talk on Kanban and organisational maturity.

Inspired by Benjamin Mitchell and David Joyce, my colleague Marcus Hammarberg and I ran a version of W. Edwards Demings Red Bead Experiment, a tool to teach how slogans and management yelling at workers to “motivate” them won’t affect results - only process improvements will. Marcus did a great job as the nefarious project manager whose only “help” to the team consisted in slogans, threats of punishments and promises of rewards, reassurances about how perfect the process is etc. We had fun running the experiment, but since our prepared Excel sheets couldn’t easily be altered to work with a smaller number of workers it took too much time. As a result we had to replace the group discussions about what happened with an unprepared, and therefore not so good, lessons learned.

If you attended the experiment and want more or if you just want to learn more about the lessons it teaches, check out the recording with Mitchell and Joyce at Skillsmatter. Or why not the one where I (that’s me in the green sweater) and colleague Christophe Achouiantz (the tall guy next to me) participated?

Postad av Joakim Sundén

2010-02-03

PowerCommands for Visual Studio 2008

I’m back with Visual Studio 2008 after a few months only doing Visual Studio 2010 stuff. And… you miss some stuff. Things get old so fast. Sad.

Here’s some nifty tools that get you a bit closer; PowerCommands for Visual Studio 2008.

Aaah – now it feels a bit better.

Postad av Marcus Hammarberg

2010-02-01

AutoMapper – get rid of your tedious mapping code

One thing that I really love being on a contract is that you’re almost immediately is forced to find solutions, whereas on a leisure project you rather do something else…

Here is another great tool; AutoMapper. It’s a framework that do all of that tedious mapping code you’re doing in for ViewModels or Messages in services etc.. Boring and tedious to write and test. AutoMapper takes care of that – using a lot of Conventions.

Be sure to see the screencast that introduce a lot of the possibilities.

Postad av Marcus Hammarberg

2010-02-01

SpecFlow: BDD .NET-style

As you could read in my latest post I have be a bit frustrated with TDD and where to start, lately. BDD is of course the answer to that. But I must say that the frameworks are available to the .NET crowd is a bit weird. Either you have some really funky syntax (hey Anders, a new colleague and great guy) or it’s build on top on other stuff and where hard to work with.

I simply cannot see myself introduce any ordinary programmers to any of that.

But here is something that looks more like it… a bit at least; SpecFlow. It’s also built with an eye too RSpec, Cucumber and Ruby but build in the style of .NET and C#.

Here is a (silent) screencast, something about syntax and workflow and some great resources.

From this it even looks that they support Swedish… Great work guys!

I’ll be sure to look into this a bit more. Later. New assignment today.

Postad av Marcus Hammarberg

2010-01-28

ASP.NET MVC, StructureMap and … TDD?

I’ve been playing around a bit with ASP.NET MVC and StructureMap (an IOC container). It all looks very nice and works wonder. During this I ran into an excellent blog post by Elija Manor on wiring StructureMap and ASP.NET MVC together. Beware of the favicon-problem though.

Again – i use NHibernate and Fluent NHibernate which so much nicer than the XML-stuff. The critics to Fluent NHibernate says that you cannot reach all functionality from Fluent NHibernate, but here is an example on how to set specific properties in your configuration. Helped me through this example.

Also found some great code examples from the TekPub NHibnernate series here.

OK – I've added “TDD?” in the title. I love TDD and it’s my preferred way of doing code, but I have a problem (to quote a thinker). I think TDD doesn’t help my through the broader strokes of my application.

Where do I start? How do I use the test to know that it’s time to add an repository, or an IOC Container? Do I TDD the IOC-code?

I asked the Swedish ALT.NET group a question and got some great tips, mostly they pointed me to BDD and those ideas. I also liked the idea of the Walking skeleton.

But I’m still confused. Can TDD really help you to design a system from the bottom up, or top-down (BDD) for that matter? Will the design be improved by the TDD-design technique? I’m not sure.

For now, my thinking is that it’s better to create a very simple design (MVC + repositories + IOC) to get your “skeleton to walk”, maybe with a functional/integration test that verify the functionality.

With that foundation in place it becomes easier to add some meat to the bones (is this skeleton metaphor taken too far yet?) with the normal TDD techniques and patterns.

Postad av Marcus Hammarberg

2010-01-22

Visual Studio 2010 web.config transformation

I happened to run into a feature I didn’t know of… Visual Studio 2010 (beta still… soon RC) includes a function for managing different .config-files for different environments. And support for transforming them on build/publish.

Here is a MSDN-article that introduces the concept and use it. And here is an article on the subject.

Pretty cool since up to now you’ve had to do it manually with build-tasks… Not so trivial.

Postad av Marcus Hammarberg

2010-01-19

C# 3.0 och 4.0, SOLID och den funktionella revolutionen med Magnus Lidbom

Ikväll hade drog Elevate igång för säsongen för .NET området. Det var Avegas egna Magnus Lidbom som höll i seminariet. Och ämnet var C# 3.0, 4.0, SOLID och den funktionella revolutionen.

Sammanfattningsvis kan man säga att Magnus visade hur funktionell programmering numera är implementerat i C#, och varför det är intressant för hur vi skriver vår kod.

C#3.0

Först pratade Magnus Lidbom kring vad funktionell programmering är och att det faktiskt numera (sedan C#3.0) är implementerat i C#, genom LINQ.

Därefter visade Magnus på hur vi med hjälp av funktionell programmering kan uppfylla SOLID-principerna. Det är ju lätt att förstå för objekt orientering programmering, där vi ju vet hur man följer SOLID för klasser och objekt.

Men hur gör man med funktioner. De kan bli SOLID med hjälp av funktionell programmering eller stödet som vi har i C#. Magnus menar att för att bli riktigt SOLID så behöver man ta med både OOP och funktionell programmering i beräkningen.

Med ett antal kodexempel visade Magnus på hur man kan använda de nya features som C# 3 och framåt har för att lösa detta.

Magnus visade bl.a. på:  

• var - type inference. Intressant här var att genom att använda var så får du automatiskt Interface Segreration principle, från klientsidan, eftersom det är ditt användande av variabeln som styr “typningen”.
• partiella metoder
• auto properties
• Object and Collection Initializers
• anonyma typer
• extension methods
• Action<T> and Func<T>
• lambda expressions
• expression trees och Expression<T>, vilket nästan är magi eftersom man kan analysera koden i kod… Det är bara Magnus som verkligen fattar det där, tror jag ;)
• LINQ. Magnus stannade länge vid LINQ men det hinner jag inte få med här, eftersom jag skriver medan jag lyssnar…

Efter maten gick Magnus vidare och visade på hur alla dessa möjligheter kan kombineras ihop till användbara patterns som ger dig bättre kod som följer SOLID-principerna.

Jag lärde mig en ny term “Coding by wishful thinking”, vilket påminner mycket om Coding by Intention som man talar om i TDD. Rätt kul term som går ut på att man skriver koden som om alla metoder som man kommer att behöva skriva redan fanns, trots att du måste skriva dem sen.

“Vad kul det vore om någon hade skrivit HämtaAllaFilerRekursivt()… Oj – det är ju jag som ska göra det” – ja ni förstår.

C#4.0

Fram till dess hade vi bara talat om C#3. Magnus gick nu vidare och berättade om andra nyheter som kommit i C#4.

Magnus pratade om:

• Covariance och ContraVariance
• Parameter förändringar; named och optional (vilket gör att du t.ex. slipper skriva massor med överlagrade konstruktor. Yes!)
• Nyckelordet Dynamic

Slutligen visade Magnus hur man kunde använda dessa nya språkfeatures för att komma ytterligare vidare i SOLID-tankarna.

Kvällen var mycket lärorik och väldigt ödmjukande för undertecknad… C# lever verkligen och blir inte mindre direkt. Mycket nyttigt dock för att verkligen komma långt i hur väldesignad din kod är.

Magnus har lovat att göra kodexempel tillgängligt. Du kan nå den här.

Tack så mycket Magnus. Bra gjort och väldigt imponerande kunskaper och presenterat på en mycket avancerad nivå. Jag är officiellt impad!

Postad av Elevate

2010-01-18

Branching Guide for Team Foundation Server 2010

Here is a great resource on how to handle branching in Team Foundation Server 2010.

The best part is that you can get this very short and sweet picture of it. Here is the description of it.

Postad av Marcus Hammarberg

2010-01-18

Inbox zero

First, admit that the title alone is very tempting… You want it, you need it… but how to get it?

How do you manage the steady flow of mail and requests during a day? How do you stay afloat? That’s what you can learn from picking up on the inbox zero concept.

I first learned about this concept at a presentation by Scott Hanselmann at ÖreDev. You can see this presentation here. Mr Hanselmann has put out some other advices that are well worth reading as well.

I then realized that the concept is older than that presentation and was invented by Merlin Mann. He even has a site on the subject; InboxZero.com. But he looks so crazy on that video that I didn’t dare watch it ;)

Here is a great presentation Merlin Mann did at Google. It will take you through the basic rules and improve your mail management – I promise. Spend 58:38 minutes and save years of boring mail reading:

Postad av Marcus Hammarberg