• This idea that constraints are something heavy and unwanted, an enemy for the creative, is just not true. Constraints have an enormous creativity power.

  • Pattern Matching is a beautiful way to specify the different behaviours a function has depending on its arguments.

  • The responsibility for your education is not of your employer. In a pragmatic perspective, you are a product that your employer is investing in, looking for a profit.

  • In the blink of an eye, one year working remotely has passed.

  • Monads were not the easiest concept for me to fully understand. There are endless QAs and tutorials about Monads and each one adds something more. And then I released that Monad is actually a design pattern and it all made sense.

  • One of the main words to retain about lambda expressions is anonymous. A lambda expression is, basically, an anonymous function. Lambdas Expressions are a normal feature in functional languages but just few time ago arrived into the Java world. Better late than never though!

  • What if your functions would only, actually, take a single argument? Currying is a very nice feature that Haskell offers that allows cleaner code to be written and leverages composition.

  • When I think of referential transparency, I think that one reference to something is transparent, this is, there are no hidden parts involved.

  • null returning and checking is everywhere and it developed deep roots in the imperative programming world. It’s more than time to stop using it and to look into better ways to deal with fallible computation.

  • A while ago, when I started to learn Haskell more seriously, I found this beautiful piece of history. 15 years ago Dijkstra saw the Budget Council of his University giving steps to replace the CS introductory language Haskell by Java.

  • “To try” is an often used expression in the most different contexts. In some, it might make sense and have a useful presence but in other, it might be a dangerous tool.

  • “But it works!” is a small big excuse to avoid excellence and to show our attitude towards code: either we just don’t think it deserves all that much care or we think of if as a mystery box - so lucky we are that it is working!

  • I wanted to write a little grep program that prints the lines of a given file that contain a given term.
    I choose to write it in Haskell, Ruby, Java, Scala and Python and see how different the thinking process and the result would be.

  • When programming we are using some programming language to describe a solution for a problem, to define behaviour or the flow of a computation. And we do it using a language that is not human, and it’s not our mother language, therefore we inevitably feel the need to leave comments and make it as readable as possible. By other words, most of the times we comment to balance the unreadability of our code.

  • To some people programming languages are no more than mere tools. We can say the same about Mathematics but we would be missing a lot.

  • This pattern is really a good choice to extend behavior without the drawbacks of inheritance. The example given in the Heads First Design Patterns is of a Coffee Shop, on how to design a flexible beverage selling system.

  • The difference between BDD and TDD is that BDD begins with a B and TDD begins with a T. But seriously, the gotcha with TDD is that too many developers focused on the “How” when writing their unit tests, so they ended up with very brittle tests that did nothing more than confirm that the system does what it does.
    BDD provides a new vocabulary and thus focus for writing a unit test. Basically it is a feature driven approach to TDD.

  • I’ve used this pattern in a iOS project where a web page was to be loaded and the native app should handle javascript events. I encapsulated the “web page” into an EmbeddedWebApp object where the javascript<>native bridge was set. I had a factory class (client) where were defined the handled events/commands and their action upon the native side of the app. One of the events (command) was to request a camera capture, that needed to delegate the request to another object (receiver). Note the Single Responsibility principle and how important it is.

  • Let’s abstract this class, let’s play with generics, inherithance, abstract classes and interfaces and make this code reusable in some other context or problem. Oh but wait… this is not quite well placed. Ok, let’s make an exception here or instead add an attribute to configure the behaviour of this particular case. Tadam, it works!

  • Sometimes we get to feel this desperate need of getting into the zone. We know how of a geniuses we are and we are fully conscious that if we are let in our own world and dive in to the zone, oh boy, it will be incredible! Well… most of times it’s not true. I’m not confusing the preference for (enough) silence, a quite office and relaxed enviromnet with this need of getting into the zone. The zone most of the times leads us to go off-scope, to write more and think less and to be more an individual than a teammate.

  • David West wrote Object Thinking where the main stressed point is that objects must be designed in terms of behaviour and not data.

  • Martin Fowler published this useful and interesting guide on microservices: Microservices Guide

  • Consider that we need to work with a list of numbers and find the need to encapsulate some methods to help us out.

  • A Ball and A Dog In true object-oriented programming, objects are living creatures, like you and me. They are living organisms, with their own behavior, properties and a life cycle.

  • Can we make the code that simple? It turns out that we can. We can change the ExpenseReportDAO so that it always returns a MealExpense object. If there are no meal expenses, it returns a MealExpense object that returns the per diem as its total: