Interesting Talk: "Functional programming patterns for the non-mathematician"

I've just watched this interesting talk by Brian Lonsdorf

• Functional programming patterns for the non-mathematician

Interesting Talk: "Functional Programming in 40 Minutes"

I've just watched this interesting talk by Russ Olsen

• Functional Programming in 40 Minutes

Interesting Talk: "The Best OO Language is a Functional One"

I've just watched this great talk by Dave Thomas

• The Best OO Language is a Functional One

Interesting Talk: "Transforming Programming"

I've just watched this great talk by Dave Thomas

• Transforming Programming

Interesting Talk: "Solving Problems the Clojure Way"

I've just watched this wonderful talk by Rafal Dittwald

• Solving Problems the Clojure Way

Interesting Talk: "Acercándonos a la programación funcional a través de la arquitectura hexagonal"

I've just watched this wonderful talk by Juan Manuel Serrano and Javier Ferrer

• Acercándonos a la programación funcional a través de la arquitectura hexagonal

Interesting Talk: "Refactoring to Immutability"

I've just watched this very interesting talk by Kevlin Henney

• Refactoring to Immutability

Interesting Talk: "Poetry of Programming"

I've just watched this wonderful talk by Attila Egri-Nagy

• Poetry of Programming

Interesting Talk: "Rich Hickey on Clojure Spec"

I've just watched this wonderful talk by Rich Hickey

• Rich Hickey on Clojure Spec

Interesting Talk: "Functional Programming with Effects"

I've just watched this wonderful talk by Rob Norris

• Functional Programming with Effects

Interesting Talk: "Side Effects are a Public API"

I've just watched this very interesting talk by Christopher Armstrong

• Side Effects are a Public API

Interesting Talk: "Lean and Functional Programming"

I've just watched this interesting talk by Bryan Hunter

• Lean and Functional Programming

Course: Purely functional Scala

Last June I attended the amazing Habla Computing's Purely functional Scala course in Madrid.

It's a challenging course in which we learned about type classes, functors, monadic APIs and composition of effects. It's tough but very interesting, and I discovered a very flexible and robust way of designing software which goes beyond what you can achieve using ports and adapters in OO.

Habla Computing's team explains these concepts in a very creative and accessible way that gently takes you from what you already know from OO (separations of concerns, ports and adapters,...), into the monadic APIs, so that you can see the need for the new patterns and how they come to be, without losing yourself in too much mathematical jargon.

I wanted to do this course since I met Juan Manuel Serrano in the first Lambda World in Cádiz two years ago, and when I finally had the chance to attend it, I loved it. Juan Manuel is the CTO of Habla Computing and he is doing a great work in making functional programming more accessible (I've posted several of his talks in this blog). I really recommend Habla Computing's course to anyone that would like to enter the world of functional programming.

Thanks a lot to Habla Computing's team for this great course!

Interesting Talk: "Effects as Data"

I've just watched this wonderful talk by Richard Feldman

• Effects as Data

Notes on OCP from Agile Principles, Practices and Patterns book

This post continues with the series of posts publishing my notes about SOLID principles taken from Robert C. Martin's wonderful Agile Principles, Practices and Patterns in C# book.

• OCP -> "Software entities (classes, modules, functions, etc) should be open for extension but closed for modification <- [Martin's definition. The origin of the principle comes from Bertrand Meyer that gave it a slightly different definition]"
• "When a single change to a program results in a cascade of changes to dependent modules, the design smells of fragility" <- [related with violating Beck's Local Consequences principle from Implementation Patterns] OCP advises us to refactor the system so that further changes of that kind will not cause more modifications. <- [related with Cockburn's & Larman's Protected Variations] If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works"
• "It's possible to create abstractions that are fixed and yet represent an unbounded group of possible behaviors"
• "[A module that uses such abstractions] can be closed for modification, since it depends on an abstraction that is fixed. Yet the behavior of the module can be extended by creating new derivatives of the abstraction"
• "Abstract classes are more closely associated to their clients than to the classes that implement them" <- [related with Separated Interface from Fowler's P of EAA book]
• "[Strategy and Template Method patterns] are the most common ways to satisfy OCP. They represent a clear separation of generic functionality from the detailed implementation of that functionality"
• Anticipation
  • "[When a] program conforms to OCP. It is changed by adding code rather than by changing existing code"
  • "In general no matter how "closed" a module is, there will always be some kind of change against which it is not closed"
  • "Since closure can't be complete, it must be strategic. That is the designer must choose the kinds of changes against which to close the design, must guess at the kinds of changes that are most likely, and then construct abstractions to protect against those changes."
  • "This is not easy. It amounts to making educated guesses about the likely kinds of changes that the application will suffer over time."
  • "Also conforming to OCP is expensive. It takes development time and money to create the appropriate abstractions. These abstractions also increase the complexity of the software design"
  • "We want to limit the application of OCP to changes that are likely"
  • "How do we know which changes are likely? We do the appropriate research, we ask the appropriate questions, and we use or experience and common sense. And after all that, we wait until the changes happen!" <- [relates with Yagni, also talking about learning about your domain] "We don't want to load the design with lots of unnecessary abstractions. <- [related with Metz's The Wrong Abstraction] Rather we want to wait until we need the abstraction and then put them in"
• "Fool me once"
  • "... we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind."
  • "If we decide to take the first bullet, it is to our advantage to get the bullets flying early and frequently. We want to know what changes are likely before we are very far down the development path. The longer we wait to find out what kind of changes are likely, the more difficult it will be to create the appropriate abstractions."
  • "Therefore, we need to stimulate changes"
    • "We write test first" -> "testing is one kind of usage of the system. By writing tests first, we force the system to be testable. Therefore, changes in testability will not surprise us later. We will have built the abstractions that make the system testable. We are likely to find that many of these abstractions will protect us from other kinds of changes later <- [related with Feather's The Deep Synergy Between Testability and Good Design]."
    • "We use short development cycles"
    • "We develop features before infrastructure and frequently show those features to stake-holders"
    • "We develop the most important features first"
    • "We release the software early and often"
• "Closure is based on abstraction"
• "Using a data-driven approach to achieve closure"
• "If we must close the derivatives [...] from knowledge of one another, we can use a table-driven approach"
• "The only item that is not closed against [the rule that involves] the various derivatives is the table itself. An that table can be placed in its own module, separated from all the other modules, so that changes to it do not affect any of the other modules"
• "In many ways the OCP is at the heart of OOD."
• "Yet conformance to [OCP] is not achieved by using and OOP language. Nor is it a good idea to apply rampant abstraction to every part of the application. Rather it requires a dedication on the part of the developers to apply abstraction only to those parts of the program that exhibit frequent change."
• "Resisting premature abstraction is as important as abstraction itself <- [related with Metz's The Wrong Abstraction]"

Other posts in this series:

• Notes on SRP from Agile Principles, Practices and Patterns book

Notes on SRP from Agile Principles, Practices and Patterns book

I think that if you rely only on talks, community events, tweets and posts to learn about a concept, you can sometimes end up with diluted (or even completely wrong) versions of the concept due to broken telephone game effects. For this reason, I think it's important to try instead to get closer to the sources of the concepts you want to learn.

Lately I've been doing some study on object-oriented concepts doing an effort to get closer to the sources. These are the resulting notes on Single Responsibility Principle I've taken from the chapter devoted to it in Robert C. Martin's wonderful Agile Principles, Practices and Patterns in C# book:

• "This principle was described in the work of [Larry Constantine, Ed Yourdon,] Tom DeMarco and Meilir Page-Jones. They called it cohesion, which they defined as the functional relatedness of the elements of a module" <- [!!!]
• "... we modify that meaning a bit and relate cohesion to the forces that cause a module, or a class, to change"
• [SRP definition] -> "A class should have only one reason to change"
• "Why was important to separate [...] responsibilities [...]? The reason is that each responsibility is an axis of change" <- [related with Mateu Adsuara's complexity dimensions]
• "If a class has more than one responsibility the responsibilities become coupled" <- [related with Long Method, Large Class, etc.] <- [It also eliminates the possibility of using composition at every level (functions, classes, modules, etc.)] "Changes to one responsibility may impair or inhibit the class ability to meet the others. This kind of coupling leads to fragile designs" <- [For R. C. Martin, fragility is a design smell, a design is fragile when it's easy to break]
• [Defining what responsibility means]
  • "In the context of the SRP, we define a responsibility to be a reason for change"
  • "If you can think of more than one motive for changing a class, that class has more than one responsibility. This is sometimes difficult to see"
• "Should [...] responsibilities be separated? That depends on how the application is changing. If the application is not changing in ways that cause the [...] responsibilities to change at different times, there is no need to separate them." <- [applying Beck's Rate of Change principle from Implementation Patterns] "Indeed separating them would smell of needless complexity" <- [Needless Complexity is a design smell for R. C. Martin. It's equivalent to Speculative Generality from Refactoring book]
• "An axis of change is an axis of change only if the changes occur" <- [relate with Speculative Generality and Yagni] "It's not wise to apply SRP, or any other principle if there's no symptom" <- [I think this applies at class and module level, but it's still worth it to always try to apply SRP at method level, as a responsibility identification and learning process]
• "There are often reasons, having to do with the details of hardware and the OS [example with a Modem implementing two interfaces DateChannel and Connection], that force us to couple things that we'd rather not couple. However by separating their interfaces, we [...] decouple[..] the concepts as far as the rest of the application is concerned" <- [Great example of using ISP and DIP to hide complexity to the clients] "We may view [Modem] as a kludge, however, note that all dependencies flow away from it." <- [thanks to DIP] "Nobody needs to depend on this class [Modem]. Nobody except main needs to know it exists" <- [main is the entry point where the application is configured using dependency injection] "Thus we've put the ugly bit behind a fence. It's ugliness need not leak out and pollute the rest of the app"
• "SRP is one of the simplest of the principles but one of the most difficult to get right"
• "Conjoining responsibilities is something that we do naturally"
• "Finding and separating those responsibilities is much of what software design is really about. Indeed the rest of the principles we discuss come back to this issue in one way or another"

Agile Principles, Practices and Patterns in C# is a great book that I recommend to read. For me getting closer to the sources of SOLID principles has been a great experience that has helped me to remove illusions of knowledge I had developed due to the telephone game effect of having learned it through blogs and talks.

Other posts in this series:

• Notes on OCP from Agile Principles, Practices and Patterns book

Interesting Talk: "Functional architecture. The pits of success"

I've just watched this great talk by Mark Seemann

• Functional architecture. The pits of success

Recorded talk about sequence comprehensions in Clojure (in Spanish)

Today we did our fourth remote talk about Clojure as part of our small Clojure/ClojureScript study group.

This time we talked about sequence comprehensions and we recorded it as well.

This is the resulting video:

You'll find the examples we used here.

Again I'd like to especially thank Ángel for his help and patience.

I hope you'll find it useful.

Recorded talk about functions in Clojure (in Spanish)

Last Wednesday we did our third remote talk about Clojure as part of our small Clojure/ClojureScript study group.

This time we talked a bit about functions and we recorded it as well.

This is the resulting video:

You'll find the examples we used here.

Again I'd like to especially thank Ángel and Magento Barcelona for letting me do the talk from their office.

I hope you find it useful.

Recorded talk about destructuring in Clojure (in Spanish)

I recently started to work at Codesai.

Some members of the team wanted to learn Clojure, so we started a small Clojure/ClojureScript study group.

We created a slack called clojuresai where I'm posting some readings (we're reading Clojure for the Brave and True) and exercises (we're working through a selection of exercises from 4Clojure) each week and where they can ask doubts about the exercises and readings, and comment things they find interesting.

Some colleagues from the Clojure Developers Barcelona meetup that are beginning to learn clojure have also joined the study group.

Now and then, we do introductory talks using Google Hangouts (Codesai's team is distributed) to go deeper in some of the topics they've just read in the book.

So far we've done two talks. The first one was about Clojure collections. Unfortunately, we didn't record it, but you can find the examples we used here.

Today we did a second remote talk. This time it was about destructuring in Clojure, and since some of the members of the study group members weren't able to make it, we decided to record it.

This is the resulting video:

You'll find the examples we used in this previous post.

I'd like to especially thank Ángel and Magento Barcelona for letting me do the talk today from their office (their internet connection is much better than mine).

Recently, Miguel de la Cruz (thanks a million Miguel!!) has joined our study group as a tutor. He knows a lot of Clojure so he will help answering doubts and giving some talks that we'll hopefully share with you soon, as well.