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:

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:

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

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:

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:

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:

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

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.

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

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:

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

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:

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:

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

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:

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:

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:

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:

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:

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:

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

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:

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"

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:

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:

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:

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:

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

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.

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:

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:

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:

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:

var hello = 'Hello from the outer space';
var aObject = {
	hello : 'Hello from the earth'
var sayHello = function(){
aObject.sayHello = sayHello;

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:

var aObject = {
	aFunction: function(){
		var anotherFunction = function(){
			var yetAnotherFunction = function(){

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:

var aObject = {
	aFunction: function(){
		var that = this;
		var anotherFunction = function(){
			var yetAnotherFunction = function(){



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

Imagine this piece of code:

var Elf = function(name){ = name;
var aegnor = new Elf('Aegnor');

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:


var monica = {};

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

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


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.

Last Wednesday was my last day in the project I worked on the last six months. I've spent a great time working there, learning a lot of things and improving as a professional.

One of the members of the team, Mark, has the role of technical architect. If you have an agile mindset when you listen the word architect is not unusual that a look of disgust appears on your face. Concepts as Big Upfront Design appears on your mind and you start sweating.

But Mark is a great architect. His duties in the team are:

  • He goes to the pre-planning, UX/UI meetings.
  • He goes to technical meetings with other companies involved in the project.
  • He starts thinking in the technical solution of every feature, but he always discuss it with the team and never imposes his vision.
  • He's accessible to resolve any question the team (development and non development people) has.
  • He reviews some of the commits we make.
  • And he writes code!

I think that the architecture responsibility should be shared among the team. Actually, I think that it was in my team. But if your team doesn't have an uniform technical capability it's not bad to have someone who makes the first step.

What do you think? Do you have architects in your team? What are their duties?