Friday, January 31, 2014

MOOCs: A Brief History of Humankind in Coursera

Two weeks ago I finished this great Coursera course by Dr. Yuval Noah Harari from Hebrew University of Jerusalem:

"This course surveys the entire length of human history, from the evolution of various human species in the Stone Age up to the political and technological revolutions of the twenty-first century to present a panoramic study on the history of Humankind; following the Cognitive, Agricultural and Scientific Revolutions, and the Unification of Humankind. Its aim was to give a brief but complete overview of the history of Homo sapiens."

You can watch this video where Dr. Harari introduces its course.

It's been the longest course I've finished in Coursera (17 weeks). It has changed my perspective on many different historical processes and human phenomena such as religion, economy or politics. The contents are very critical and sometimes even controversial but I think it's been worth it to be exposed to these ideas in order to reflect on the past and the present of humankind from a different angle.

There's also a book which discusses the contents of this course in greater depth: From Animals into Gods: A Brief History of Humankind

Thank you very much to Coursera and Dr. Harari for offering this wonderful course.

Interesting Talk: "Deconstructing Functional Programming"

I've just watched this interesting talk by Gilad Bracha:
As it's summarized by InfoQ, he "explains how to distinguish FP hype from reality and to apply key ideas of FP in non-FP languages, separating the good parts of FP from its unnecessary cultural baggage."

This is the summary slide:

Interesting Talk: "Does anybody remember design patterns?"

I've just watched this interesting talk by Robert C. Martin:

Strategy pattern and higher-order functions?

As a practice, I'm implementing different design patterns in different languages.

I'm using the examples in the great Head First Design Patterns book as the basis for this implementations.
The book examples are written in Java, so I'll use other languages.

I've started with the Strategy pattern.
"The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it."
The first implementation is written in C++:
I modified the book example to make it shorter. In this case the Duck class has only one configurable behavior: quacking.

This behavior is injected through its constructor but can also be modified afterwards using a setter: changeHowToQuack.

Since C++ is statically typed like Java, we need to create a base type for all the different behaviors or strategies. In this case the QuackBehavior abstract class (this would work as a Java interface).

The Duck class has a field, howToQuack, which is a pointer to an object that implements the QuackBehavior interface. When Duck's quack() method is called, it delegates the quacking responsibility to its howToQuack collaborator.

This is one of the implementations of QuackBehavior:

You can find the rest of them in this Bitbucket repository: StrategyPatternExampleCpp.
This is an example of how this code can be used:

And this would be its result:
<< Silence >>
Using this pattern we've encapsulated the quacking behavior and made it possible to change how the duck quacks without changing its code just by injecting new variants of the behavior. The code respects the Open-Closed Principle for the quack behavior because it's Open to extension (by creating new types of QuackBehavior) and Closed to variation (we don't need to change the Duck class).

This way of implementing the Strategy pattern in C++ or Java has to do with two facts:
  1. They are both statically typed languages. 
  2. Functions are not first-class citizens in any of them.
In languages like Ruby or Python we wouldn't need to use an interface like QuackBehavior. We'd just need to make the different behaviors (Quack, Squeak and MuteQuack) have a common interface: quack().

Moreover, since functions are first-class citizens in these languages, we wouldn't even need classes for the different types of behaviors. In this case, functions would suffice, as you can see in this other example of the Strategy pattern in Ruby (much less verbose than the C++ or Java ones):

The Strategy pattern relies on composition. I can't avoid thinking that it's a way to compose behavior that is very similar to what you do when you're using higher-order functions in functional programming.

This last example in Racket has the same functionality as the previous two:

Even though there are no objects here, you can notice some similarities.
It's also applying the Open/Closed principle because it's injecting a behavior as a function parameter, how-to-quack, that has several variations inside a higher-order function, quack, in order to change the function behavior without having to change its code. To get a new behavior, you just need to create a new type of quack function (a different quack behavior) and pass it to quack as a parameter.

Well I hope this makes you see the Strategy pattern from a little bit different perspective.

PS: If you're interested in JavaScript, check this implementation of the Strategy pattern by Tomás Corral.


A functional JavaScript version (very similar to Racket's one):

Tuesday, January 28, 2014

Interesting Talk: "OO Design for Testability"

I've just watched this interesting talk by Miško Hevery:
According to Miško Hevery the biggest enemies of testability are:
  1. Location of the new Operators. 
  2. Work in constructors. 
  3. Global State. 
  4. Law of Demeter violations.
In this talk he explains why and shows ways to avoid them.

Interesting Talk: "The Magic Tricks of Testing"

I've just watched this great talk by Sandi Metz:
This slide summarizes the testing rules from the talk:

Check also the rest of slides.