Category Archives: Uncategorized

Introduction to F#

Just found this very nice video by Luca Bolognese introducing F#.

The video is already from some time ago (PDC 2008) but it nicely shows the difference between the declarative and imperative programming paradigm in some real-live examples.

I very much liked how Luca used the barista analogy to explain that distinction. He said it would be like asking for coffee in a bar or telling the bar tender to grind some beans, to heat some water and in parallel pressure cook some foam.

I remember three basic functions from F#:

The ‘et’ oporator to bind a value to a function and not an assignment
The ‘>’ pipeline operator to push the output from one operation to the next
The ‘et functionName’ to define functions on the fly

I was pretty amazed how F# deals with asynchronous and parallel programming. A simple ”et!’ allows you to free up a thread.

More info about F# you can find on Microsoft’s F# Developer Center webiste.

Junior Developers need a DoD-y!

Leave a reply

Junior developers have a hard time to answer the question whether something is done. They need DoD-y!

It contains two elements they have not a lot of experience with: estimating the remaining time to complete (ETC) and knowing when something is completed according to the company’s standards.

Both will come with time and often they are not experienced enough to understand all aspects of the work yet. Scrum solves this by requesting the team to create a Definition of Done (DoD).

Below an example of what this could look like;

A DoD focusses on task decomposition. “How to eat elephant” … “bit by bit”!

If you get an understanding on what to do, the estimation of the time needed will become easier as well.

Branching Strategy Explained In One Picture

Leave a reply

Normally you would start from a main TFS project called Trunk and immediately branch this into Dev. All development is done on Dev: developers check-in/check-out content.

After a certain period, groups of finished functionalities are merged into Trunk from Dev. This is done by the quality gate keepers i.e. architects, team leads, release managers after checking everything is ok.

When everything is ready to go into production a version branch, for example 1.0, is split off from Trunk and production hot fixes can be done on branches of these version branches, for example 1.0HF1 for 1.0. This to guarantee at any time, we can build and recreate any production version.

Nightly builds are run on Dev to create the latest build and on Trunk to create a latest stable build output. Normally only latest stables can be deployed in environments other than development i.e. test, quality and production.

TechEd 2010, looking for the latest on Azure

Leave a reply

A bit to my surprise I got an invitation to attend TechEd Berlin. So to ‘please’ (*blink*) my employer I will join you all in the Messe.

I’m looking forward to see the latest evolutions in Azure.

Azure is something that will become big and to my opinion is the first real step of Microsoft in the direction of hardware solutions that have to do with hosting and serving capabilities. Are they outgrowing their software market share and now looking for strategic investments in the hardware market? Who knows and the future will tell but for the moment I like what I see related with Azure.

Google Wave development stopped

Leave a reply

In 2009 I was completely blown away by Google Wave.

I was particularly interested in the new ways of collaborating and communicating. Some real time features, that are available in Google Wave, I never saw before on other platforms.

Recently I heard that the development was stopped and Google would only continue using it their own products but as a platform.

It is a pity but apparently people were not ready for these new ways of communication. I still hope to see features like side-by-side typing appearing future products. May-be they get accepted when released at a slower pace. On the other hand I still need to convince my parents to use text messaging and chat. For some people adapting to new ways of communicating will always be hard.