The #NoEstimates movement is an interesting thing. If you haven't heard about it, take a look at #NoEstimates hashtag on Twitter, read these articles from Ron Jeffries (article 1, article 2, article 3) or buy (and read) the excellent book written by Vasco Duarte.

Let me make a summary for you: we fail making estimations. A lot. Take a look at famous CHAOS report if you need more evidence. Agile methodologies improved the numbers a bit but not too much (I bet the numbers are going down again because everybody is "agile").

Failing making estimations is not bad per se. The problem is the use we give to estimates:

[caption id="attachment_274" align="alignnone" width="502"]Estimates as deadlines Estimates as deadlines[/caption]

And we usually do that when we know less about the project: before even starting it. Before starting a project maybe we have a good definition of the most important stories, but the others can be vaguely defined (which is good). So we should be able to estimate with some precision the first and most important stories of the backlog (which we already know we must implement), and we will produce very bad estimations for the vast majority of the backlog. Why are we estimating then?

There can be multiple answers to the previous question: we need to know if you will be able to do the job within the budget, we need a release date, etc. And all of them are fair. But the problem is that our answer is just a guess, it is not based on any empirical data. You can claim that you are an expert project manager with more than 15 years of experience, but you have to admit that this is the first time that you're developing this project for this client with this team.

Don't our clients deserve a better answer? Yes, of course. Why don't we use real data from the project to answer these questions? Why don't we talk with our client and ask to work on the project for three or four sprints and use that data to make a projection? Why don't we work on splitting stories in order to make them similar in size and avoid estimating and just count them (and increase our knowledge about them)?.

It sounds quite reasonable to me.

My main conclusions are the following ones:

  • Question all your practices. Estimations, retrospectives, testing, daily meetings... all of them. Are the practices giving value to you and your client?
  • Build trust with your client. If your client trusts you, probably you won't need estimations.
  • Work on slicing stories. Estimate them after doing it if you want, but you'll gain knowledge about them, and about your domain if you do it. You'll be able to deploy them sooner and shrink the feedback loop.
  • Use real data to make predictions. Real data beats guesses. Always.

 

In the first post of this series we've seen a possible implementation for the FizzBuzz kata. In particular, we've finished the article with this code for the fizzBuzz function:

https://gist.github.com/vgaltes/edafb6efc55273543a1d

We've applied a Tuple pattern to match the tuple created in the match part. We've also applied Wildcard matching to discard the values we are not interested in.

In this article we're going to see how we can solve this problem using another flavors of Pattern-Matching.

Active patterns

Using active patterns you can define case names (partitions of your data) so that you can use these names in Pattern-Matching expressions. A typical example could be this one:

https://gist.github.com/vgaltes/ea700e4c7f2334223d0a

So let's use active pattern to resolve FizzBuzz kata. The active pattern could be something like this:

https://gist.github.com/vgaltes/ac693fc6a81885d7eed8

As  you can see we have an active recognizer that defines four cases. Inside the recognizer we're using Pattern-Matching to select the appropriate case as we did in the original implementation of the kata. Now, we just have to use this recognizer in a Pattern-Matching function:

https://gist.github.com/vgaltes/2aa85a0ef5e92d4dfd97

As you can see, we are using a Pattern-Matching function, a convenient shortcut for creating a Pattern-<atching lambda expression. We are just replacing the match...with portion of the match expression with function.

Now, if we would like to print the first 100 numbers we can do something like this:

https://gist.github.com/vgaltes/1bd24d3819c9e6022514

In this case we are using a range expression to create a sequence with numbers from 1 to 100. Using the pipe forward operator we are passing this sequence to the map function of the Seq module that transforms a sequence applying a function (in this case fizzBuzz) to every element in a sequence. Finally, we iterate over the sequence to print the results.

Partial Active Patterns

Active patterns have to limitations:

  • Each input must map to a named case.
  • Are limited to seven named cases.

An alternative to active patterns are partial active patterns. A partial active pattern include only a single case name followed by an underscore. Let's rewrite the FizzBuzz kata using partial active patterns.

First, we have to write the active patterns we are going to use:

https://gist.github.com/vgaltes/06f0e841f0a82d9d7d8c

And after that, we are ready to use them in a Pattern-Matching expression:

https://gist.github.com/vgaltes/ba40cc99e15118b81301

Parameterized Active Patterns

It's possible to use a function that accepts more than the match value. Let's define a Parameterized partial active pattern (remember to include additional parameters before the match input argument.

https://gist.github.com/vgaltes/e453ddd088beac84791f

And now, let's use this partial active pattern:

https://gist.github.com/vgaltes/8c1c7b58c07df88bfd3a

And that's all for today. All these samples are extracted from the excellent book The book of F#, so I can't recommend it enough if you want to learn F#.

As usual, I'm just learning F#. If you see something incorrect or you want to add an alternative solution, please leave a comment.

Last week I continued learning F# with my friends Samir and Pedro. The first week we learned some of the F# basics and this week we learned some of the functional characteristics of F#. To do that we started doing a custom interpretation of the Bank kata from Sandro Mancuso. You can find the code here: https://github.com/vgaltes/FSharpByExample/tree/master/BankKata

As usual, let's start with a test an its implementation:

https://gist.github.com/vgaltes/a9c109919fe7e5555c27

In this piece of code we can see some of the functional characteristics of F# we are going to see in this post. The first one is Discriminated Unions. Discriminated unions are types whose value are restricted to a known set of values called union cases. These cases are the only valid values. In our case we are defining Currency as a discriminated union. One of the most used discriminated unions is the Option type, present in the F# core library:

https://gist.github.com/vgaltes/ad0eaab4d86ce2677b86

Option is a type with two possible values: Some and None. None is an empty union case (doesn't contain any associated data). Some has an associated instance of 'T. It's something similar to Maybe pattern in C#.

Using Option type is quite simple:

https://gist.github.com/vgaltes/d1dda90150ff380166ac

We will an example of how to retrieve the value of an Option, but it's as simple as:

https://gist.github.com/vgaltes/5da2202b0dfd5e833a2c

The second functional characteristic of F# we can see in our little piece of code is a record type. In our case, we used a record type to define what is an account. A record represent a simple aggregates of named values. It's a kind of type between a tuple and a class. To define a record type enclose between braces a list of labels with type annotations. A simple record type can be something like this:

https://gist.github.com/vgaltes/ee0e0e0260b4cecd53b1

So, in our example we are defining an Account as a record type that has a label called Amount that is a tuple of int and Currency.

Let's take a look at the deposit function's code after another test and a refactor:

https://gist.github.com/vgaltes/7297d59862b4007c980e

Here we can see how type inference and pattern matching (tuple pattern) helps us to have a more compact code. First of all, instead of defining the last parameter of the function as an Account, we can use definition of the record type. Doing this, we can use tuple pattern to extract the values of the tuple and use them inside the function. In our case, we don't care about the second value of the tuple, so we can use the wildcard pattern (_).

Let's take a look now at the final implementation of the withdraw function:

https://gist.github.com/vgaltes/eea502a4bc3b2ce9475a

In this piece of code we can see another flavor of pattern matching. In contrast with the one used in the previous article, here we can't use directly the values calculated in the match part to define our cases. We have to use the values to compare with another value, in this case 0. To do that, we use the keyword when, specifying the condition after it. In the second part (when the first case is false) we get the calculated value and use it in the return.

And finally, let's take a look at the codification of a global operator we use to chain withdrawals:

https://gist.github.com/vgaltes/c9b2b5cd166c2babcf31

As you can see, you define an operator just like another function but with the name of the operator enclosed in parenthesis. In our case, the operator |>> takes two parameters called result and f. You can annotate the type if you want but there's no need to. In the body of the function we use pattern matching to determine if the first parameter is a Success or a Failure. If it's a Success we called the function f with value as its first parameter and if it's a Failure we return the failure.

And that's all folks! We are just learning F# so, if you find something that is not correct in the article, please, leave a comment!

 

Last Tuesday I started a book club with my friends Samir Talwar and Pedro Moreira Santos (both of them working at Codurance). The book we've choseen is "The book of F#", because we want to learn F#.

After reading the first three chapters we decided to make the FizzBuzz kata to start practicing. In this article I'm going to explain you how we solved the kata trying to explain all the F# syntax we use. So, let's start!

First of all let's install NUnit as our testing framework. In future articles we are going to take a look to other testing frameworks and libraries, but right now NUnit is a good choice.

install-package NUnit

No F# magic, just NuGet.

Let's write our first F# line of code:

https://gist.github.com/vgaltes/8900b49681c56d0c792b

In this line we have declared a new module. In F#, unless you have only one single file in your project, every file must begin with a namespace or module definition. Both are ways we have to organize our code. The main difference is that inside a module you can define other modules, type definitions, values and functions but inside a namespace only modules and type definitions.

Now we need to include NUnit in the project. To reference a package in F# (a using in C#) we use the open keyword:

https://gist.github.com/vgaltes/c1ae19b0ab531ca3ba69

As we are working in a module, we can directly write the first test:

https://gist.github.com/vgaltes/58750e89636880cda7b8

In the line 1 of this gist we can see how we use an attribute in F#, in this case the Test attribute from NUnit.

In the line 2 we are defining a new function, in this case a function without any parameter. To do that, we use the let binding to identify the function. We are not going to see any example in this article, but it's worth mentioning that let bindings are immutable.

The next interesting thing is how we name the function. In F# we can use any type of string to identify a value or a function, we just need to change what we use to wrap it. In this case we are using a quoted identifier to use a string with blank spaces, just enclosing it in backtick characters (``).

Instead of using brackets to define the body of a function in F# we use an equal after the parameter definition and we indent the body. It's no important how many whitespaces we use as long as we are consistent in the indentation level we use.

And finally, in the line 3, we are making the assertion of our test. In this case we are asserting that "1" is equals than the result of calling a function called fizzBuzz with the number 1 as a parameter. In F# we don't use parenthesis to pass parameters to a function.

Not bad for three lines of code. But this code don't compile. We need to declare the fizzBuzz function in order to be able to run the tests. Let's do it:

https://gist.github.com/vgaltes/00a56221ddaa38423688

Here we are defining a function with one argument that returns an empty string. In F#, unless we are defining a function with more that one argument and with type annotations in the arguments (we'll see type annotations later), we don't need to use parenthesis to declare a function.

In F# all expressions (and therefore all functions) returns a value, so the last expression of a function is the return value. So, in this case, the expression "" is the return value of our function.

If we now run the test, the test will fail. To make this test pass, you just only have to return "1"

https://gist.github.com/vgaltes/96c45ef56e8d2008dab9

As you can imagine, the second test will be just as the first test but changing 1 with 2. Let's see how we have to implement the function to pass it:

https://gist.github.com/vgaltes/10bd928d5d1224c8540d

Here you can see our first flow control expression, in this case an if. In F# ifs are defined with the expression if...then...else. To compare to values we use the single equal operator.

In the third test we are going to test that the fizzBuzz function returns "Fizz" when the parameter is a 3. Let's see the changes we must do in the function:

https://gist.github.com/vgaltes/6816297abd63b6f60e4f

In this case we've introduced an elif (a shortcut for else if) to specify the second condition.

After the next test ("4" = fizzBuzz 4) we have enough duplication to do a little refactor. The result of the refactor can be something like this:

https://gist.github.com/vgaltes/62018983f630c98a26b8

As you can see we can use the standard .Net ToString function here.

The next important bit is after writing tests for 6 and 9. The code of the fizzBuzz function could be something like this:

https://gist.github.com/vgaltes/cbd9ba33f5039ffb2c4e

If you follow the rule of three, it's time to refactor. Our firs refactor could be something like this:

https://gist.github.com/vgaltes/39d4f39e3dab86555200

We are using the exists function from the List module. This function takes a predicate (a function) as a first argument and the list of elements as the second one. We are checking that the input is one of the elements of the list.

We can rewrite this piece of code in a more compact way taking advantage of currying. You can read more information about currying in this post.

https://gist.github.com/vgaltes/310108e02557af31750e

With the use of the parenthesis, we are converting the = operator into a function. So, when the List.exists supplies the current list item to our predicate, we can apply the function to compare it with the input parameter.

If we continue working we will end up with something like this:

https://gist.github.com/vgaltes/651a0c64d5f4aa04b511

Now it's time to apply a typical functional feature: pattern matching. Pattern matching is F# primary branching mechanism. So, we can remove these nested ifs with a pattern matching. Pattern matching is a quite big concept (we'll explore it deeply in the future) but here we are going to apply some concepts. Let's start with the simplest refactor we can do:

https://gist.github.com/vgaltes/edafb6efc55273543a1d

Here we are matching a tuple. The underscore character (_) is the Wildcard pattern that match any value and doesn't bind it to anything.

Finally we are going to apply a couple of refactorings more to reach our final implementation:

https://gist.github.com/vgaltes/b9dc646c7a403606af46

The first refactor we made is take advantage of the NUnit's test cases to simplify the test code and remove duplication.

The second refactor is to organize the code in different modules (nested modules), one for the production code and other for the test code. In F#, the order of the modules is important because F# code is evaluated from top to bottom. So, if we need to reference module Prod from module Tests, we need to declare it before.

And that's all. I hope you liked this little F# introduction. I'll keep the blog updated with the new things we'll be learning.

 

What object references this in JavaScript is always a tricky question. Let me try to explain you how the value of this is determined.

The value of this is based on the context in which the function is being called. Let's consider this piece of code:

<script>
 
var hello = 'Hello from the outer space';
var aObject = {
	hello : 'Hello from the earth'
}
 
var sayHello = function(){
	console.log(this.hello);
}
 
aObject.sayHello = sayHello;
 
aObject.sayHello();
sayHello();
 
</script>

The output of this code is this:

[caption id="attachment_244" align="alignnone" width="1024"]First example First example[/caption]

As you can see, in the first line we are calling the sayHello function inside the object, so this is referencing aObject. In the second line, we are calling the sayHello function of the global scope.

Nested functions

Things get a little more complicated when you have nested functions. Imagine this piece of code:

<script>
 
var aObject = {
	aFunction: function(){
		console.log(this);
		var anotherFunction = function(){
			console.log(this);
			var yetAnotherFunction = function(){
				console.log(this);
			}();
		}();
	}
}
 
aObject.aFunction();
 
</script>

The output of this code is:

[caption id="attachment_245" align="alignnone" width="1024"]Nested functions Nested functions[/caption]

As you can see, only the first call this refers to the object. On the other calls, this refers to the head object. This will be fixed soon, but in the meantime you should workaround this problem storing this in a variable:

<script>
 
var aObject = {
	aFunction: function(){
		console.log(this);
		var that = this;
		var anotherFunction = function(){
			console.log(that);
			var yetAnotherFunction = function(){
				console.log(that);
			}();
		}();
	}
}
 
aObject.aFunction();
 
</script>

 

Constructors

When you invoke a function with the new keyword this refers to the instance.

Imagine this piece of code:

<script>
 
var Elf = function(name){
	this.name = name;
}
 
var aegnor = new Elf('Aegnor');
 
console.log(agnor.name);
 
</script>

The output will be:

Be careful because if you don't use the new keyword, this will refer to the context in which Country is invoked. So, if we remove the keyword new of the previous example, the output will be undefined.

The same logic applies if you add a function to the object prototype. If you new an instance of this function and you call the added function which uses this, this will refer to the instance.

Using call or apply

You can overwrite the value of this using apply() or call(). When using these functions you specify which object will be used as this. Let's see an example:

 

<script>
 
var monica = {};

var setLocation = function(location){
    this.location = location;
}

setLocation.apply(monica, ['London']);

console.log(monica);
 
</script>

The output is:

[caption id="attachment_248" align="alignnone" width="725"]Using apply Using apply[/caption]

 

As you can see, determine the value of this is a little bit tricky but not so complicated.