In the previous article we've seen how to parse a git log file. We ended up having an array of commits:

TODO: Raw content of a Gist file.

Let's start extracting some useful statistics from it.

The first thing that can come into our mind is to know how many commits we have done to the repository. That's pretty easy to do:

As you can see, we are using the pipe forward operator (|>) and the Array.length function to extract this information.

I've recently read the excellent book Your Code as Crime Scene by Adam Tornhill. In this book, Adam explain several techniques to extract very useful information from the commits in the code repository to help you to understand your code, your dependencies and your organisation. If you haven't read the book, please do yourself a favor and get a copy as a Christmas present. On the othe hand, this week I've attended the fantastic Progressive F# Tutorials at Skills Matter.

In the era of JavaScript it's a good idea to support users that aren't getting JavaScript enhancements, specially if you work for UK's goverment. If you are using simple forms you don't have any problems, but as long as you start adding complexity to your page supporting this scenario can be a bit tricky. Obviously your first thought should be: "Can I provide a similar experience using a less complex view?

Yesterday I attended XPDay 2015, an event organized by the people of the eXtreme Tuesday club. It was the first time I was there and it was great to share a day with such a bunch of talented people like Allan Kelly, Nat Pryce, Steve Freeman, Giovanni Asproni or Liz Keogh among others. In this time where a lot of people talk about agile hangover and say that agile doesn't work it's good to return to the origins and talk about eXtreme Programming.

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 "

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.

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.

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.

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.

When we write unit tests we usually try to apply our great object oriented knowledge, so we try to apply the well known DRY principle (Don't Repeat Yourself). One visible consequence of this effort is that the test code is considerably shorter than the previous version. A less visible consequence, but much more important, is that is harder to understand what the hell the test is trying to do. For that reason, when writing tests, I'm more inclined to apply a non so well know principle called DAMP (Descriptive And Maintainable Procedures).