Interesting links

Updated on


Deliver Working Software Frequently

Before you can run, you need to learn how to walk. This is a good primer on agility. Focus first on delivery.

Until you can deliver, work on delivery. Work on nothing else until then. The rest will come in due time.

I reckon your message broker might be a bad idea.

Message brokers can be a bad idea if treated like "infallible gods", because they aren't. Think about three good design principles for realiable systems:

  • Fail fast
  • Process supervision
  • End-to-End principle

In the end, it isn’t so much about message brokers, but treating them as infallible gods. By using acknowledgements, back-pressure and other techniques you can move responsibility out of the brokers and into the edges. What was once a central point of failure becomes an effectively stateless server, no-longer hiding failures from your components. Your system works because it knows that it can fail.

PostgreSQL 9.4 - Looking Up (With JSONB and Logical Decoding)

PostgreSQL 9.4 is going to be exciting with JSONB support. As David Lesches says:

JSONB has been committed to Postgres 9.4, making Postgres the first RDBMS with rock-solid support for schemaless data

Horizontal divider

On "Enlightenment"


The more I think about it, the more I see it. They say that you should expose yourself to different kind of programming languages, and more specifically to different kind of paradigms. The key of that advice is to get exposure (and hopefully proficiency) with different ways of thinking. The more high-level thinking tools you have at your disposal, the more effective and efficient you are at identifying and solving problems.

You become able to really see the problem and build a general solution. You start to deconstruct what you know, the constraints and the problem at hand, and you become able to build general solutions by composing simple things. Systematically. When you start to think in terms of data transformations via map, filter, reduce, juxt, etc. you realize that you are operating on a higher level. You start to really see what the single resposibility principle is all about. And then, you start to see all the accidental complexity that used to slow you down and hide the essence of the solution behind reams of low level details (syntactical or otherwise). When your mind is not distracted by accidental complexity, you can step back and think clearly about what you have and what is really needed.

Unfortunately, this kind of "enlightenment" has some downsides:

  • You become painfully aware that you could do much better and much faster when you develop with less advanced languages (for example: Java). Here starts the frustration.
  • Your "yet-to-reach-enlightenment" colleagues don't see the way you do. They don't understand (yet). This is the blub paradox at work.

Combine both factors, and you have a recipe for misery. It's depressing seeing friends (and yourself) wasting time with unnecessary complexity.

Square wheels

However, even if it requires work, practice and dedication to reach a master level, I think that it's worth it. I'm certainly not a master, and yet I'm seeing benefits of this learning journey even when I'm not writing LISP code. Eric Raymond was right:

LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot.

So go ahead and learn some Clojure, Haskell and Factor (for example). You don't need to spend a lot of time to get a feel of what's out there. You will be a better programmer anyway, and I think this is a worthwhile goal.

Horizontal divider

On frameworks

Updated on


Frameworks remove your ability to solve your specific problems from first principles. They opt you out of innovation, simplicity & elegance — Steve Purcell

Horizontal divider

How to programmatically manage a Light Table-aware nREPL server

Updated on


Starting an nREPL server for a Clojure application is trivial if you use Leiningen:

lein repl

# or:

lein repl :headless

But what if you have an application deployed as a JAR (or WAR in an application server) and you want to have remote access to an nREPL server? Fortunately, it's easy to start one programmatically:

(require '[ :refer (start-server stop-server)])

; Starting an nREPL server is trivial:
(defonce nrepl-server (start-server :port 12345))

; So is stopping it:
(stop-server nrepl-server)

It works out of the box if you use Emacs with Cider to connect to it, but if you use Light Table, you need to add an additional nREPL middleware to support some functionality that LT needs to work properly. Again, this is easy if you use Leiningen: you just need to declare the dependency to the middleware and add some :repl-options:

(defproject some-awesome-thing "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [lein-light-nrepl "0.0.13"]] 
  :repl-options {:nrepl-middleware [lighttable.nrepl.handler/lighttable-ops]})

Using the lighttable-ops nREPL middleware programmatically is also quite easy, but you have to know how to compose nREPL middlewares. First, you need to add the dependency to the LT middleware in your project.clj as before:

(defproject some-awesome-thing "0.1.0-SNAPSHOT"
  :description "FIXME: write description"
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [lein-light-nrepl "0.0.13"]])

Then you can add it to the middlewares chain in your code:

(require '[ :refer (start-server stop-server)])
(require '[lighttable.nrepl.handler :refer [lighttable-ops]])

; Starting a server with custom middlewares is trivial:
(defonce nrepl-server 
         (start-server :port 12345
                       :handler (default-handler #'lighttable-ops)))

; So is stopping it:
(stop-server nrepl-server)

Notice that we passed lighttable-ops to the default-handler as a var (in fact, #'lighttable-ops is a reader macro that expands to (var lighttable-ops)).

Now you can connect to your project remotely using Light Table and inspect, modify and control it live. Enjoy :)

Horizontal divider


Updated on


This is one of the most terrifying technical books I've ever read (not an affiliated link):

Release It!

I haven't finished it yet, and I already think it's a foundamental read for every professional software developer. Along with, for example:

Horizontal divider



Recently I'm working quite heavily with straight JDBC and I'm learning some things from best practices and some others the hard way. One tool that I've found useful is JDBC Lint: it's a tool that acts as a dynamic proxy for Connection objects (so that it can be used transparently) and reports errors at runtime on the standard error channel.

For a primer on some JDBC best practices, see this post.

Horizontal divider

Fainting Goat Systems

Updated on


Paraphrasing Robert Heinlein, reality is a harsh mistress. Have you ever designed or worked on a system which was finally declared "done" (the mythical 1.0 release): it passed all QA tests, all was green, all the checks in place... but that failed miserably when deployed in production? Unfortunately, a real system lives in a harsh reality made of unreliable networks, crashing subsystems, crazy users and Elbonian hackers.

Architecture is extremely important: flexibility, rapid development, modularity. All technically cool and necessary (I'm all for it!), but you need to take into account and design for the real world. You don't want to design a cool system on paper only to be constantly in emergency mode, struggling and working frantically just to keep the system live (still, with 80% availability, or worse). When you are in survival-mode you can't spend time learning, practicing and developing new systems (that generates revenue). I call those "Fainting Goat Systems": they are beautiful, functional, but when they are under stress, they just crash and fall to the ground. Here is an informative slide of a Fainting Goat System just deployed to production for the first time:

A fainting goat

The first thing is stability. The system should be stable, built for cheap and easy operations and ready to make contact with the real world and real users. It's important to release early and often, in production, and adapt to reality. Certain lessons can only be learned in production, with real users and real deployments.

A good book on the subject is Release It! by the Cognitect Michael T. Nygard.

Horizontal divider

(JAR) Hell is here

Updated on


From Gorging on Java frameworks and dependencies:

I can't remember who said it, but I think one of my colleagues at Comoyo said something along the lines of: "we obsess over our own code with code reviews and such, but we happily depend on any piece of shit some crazy monkey on the net has cobbled together in his spare time".

Think about that. Because it is true.

Right now your Java application probably contains a dozen version conflicts that you have not noticed. The more common variety being the same library occurring in your transitive dependency graph more than once and in different versions. It is sheer dumb luck that your application works at all. If you don't know what I am talking about I suggest you have a close look at your transitive dependency graph.

There has to be a better way to manage dependencies. One that is not necessarily a one-level dependency tree (which isn't an unreasonable thing given a suitable language/ecosystem). Well, maybe there is.

Horizontal divider

Power comes from Emergence

Updated on


I've been thinking a lot about the intersection of OOP and FP, and I've come to realise one thing: there is real power on the composition of simple things.

It's more general than the objects VS functions debacle, and I won't talk about immutability right now. The point I want to make is that when you have a small set of simple concepts/abstractions that you can compose at will, you get a great deal of expressivity and power that you can build on. Just look at LISP or Smalltalk.


Maybe you are among the ones that consider git difficult. Well, at its core git is quite simple: it's a set of simple concepts at your disposal that give you a lot of power and flexibility.

Understanding them in isolation is easy, because they are simple. However, there are a lot of ways to compose simple things and it isn't equally easy to grok all the ways you can combine them. The real power and expressiveness emerge from the interactions between the foundational concepts. In other words: it's more than the sum of their parts.

Git it's a perfect example of the concept of emergence at work. Quoting Wikipedia:

In philosophy, systems theory, science, and art, emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions.


Another example is Pedestal. It's difficult to get it: in part because it's different from the "standard" Rails-esque web framework, and in part because it's designed as a set of simple concepts. Taken one by one they are quite simple, but the real power and perceived complexity is on the number of ways you can compose them.

Contrast this with the average framework: usually there is THE way to do things and you only have to plug your code here and there and BAM! It works. A blog engine in 15 minutes, cool uh? It's certainly easy, but not simple and by a large degree not nearly as powerful.

BTW, yes I know that Pedestal has been designed with real-time collaboration in mind :)

Horizontal divider

Ninja Framework

Updated on


Segnalo un recente web framework basato su Java molto interessante: Ninja Framework.

E' un nuovo web framework full-stack basato su Java, molto ispirato a Play 1.x, realizzato, mantenuto e reso open-source da un’azienda tedesca con sede a Berlino: FinalFrontierLabs.

Vantaggi e differenze rispetto Play 1.x

  • E’ attivamente mantenuto (Play 1.x è decisamente abbandonato).
  • Maggiore supporto al testing! Citando il sito ufficiale:

Testing is THE MOST IMPORTANT THING of Ninja. We put a huge effort into making testing your apps as simple and quick as possible. The developers of Ninja all had experiences with different web frameworks that were really hard to test, or where tests were not reliable and slow.

  • Cosa molto interessante relativamente al testing è che ci sono diverse facility in più rispetto a Play (anche 2.x), di particolare interesse il testing delle API (NinjaApiDocTest) che consente di testare facilmente l'interfaccia HTTP e scrivere contemporaneamente la documentazione. In pratica questo significa che si possono scrivere test automatici per l'interfaccia HTTP (tramite JSON e altro) e da questi si può generare automaticamente la documentazione della stessa tramite Doctest (alcuni esempi della documentazione generata sono visibili qui, vedere in particolare l'ultimo).
  • Basato su standand: Maven, Freemarker, Google Guice, Jackson, Google Guava, JPA/Hibernate, FlywayDB per le migrations (molto interessante), Memcached/Ehcache.
    • Da notare: i moduli di Ninja sono semplici JAR mavenizzati. Inoltre, persino le dipendenze lato frontend possono essere gestite con Maven grazie ai WebJars (cosa che facilita ulteriormente la modularizzazione anche lato frontend).
  • Niente smandruppamenti col bytecode, che impedisce certi approcci e strumenti, ed in certi casi rende difficile il debugging con errori di difficile comprensione.
Il fatto che sia basato su standard senza "magie" facilita la comprensione, il debugging e non preclude diversi approcci che con Play non sono possibili e più complicati del necessario.

Specialmente la gestione delle dipendenze standard tramite Maven faciliterebbe l'applicazione di alcuni dei pattern del JAA:M (per esempio Levelized Build e Manage Relationships) per modularizzare i progetti che al momento con Play sono più complessi del necessario da usare (se non proibitivi).

Nonostante questo è abbastanza simile a Play 1.x e convertire i progetti a Ninja da questo framework non richiede una riscrittura (la cosa è ulteriormente facilitata se la business logic è isolata dal meccanismo di delivery come dovrebbe essere).

Vantaggi rispetto a Play 2.x

  • NON si deve estendere qualche classe del framework per utilizzarlo, il che è necessario con Play (Controller, Plugin, Model, ecc ecc) ma è anche un anti-pattern che complica il testing e lega troppo strettamente al framework di turno limitando certe scelte in queste aree.
    • Possibilità di utilizzare la Dependecy Injection standard di Guice senza legarsi al meccanismo dei plugin di Play.
  • Il testing è un cittadino di prima classe ed è fornito un supporto a tutti i livelli.
  • Niente "magie" col bytecode.
  • Build standard tramite Maven (in contrasto a SBT + Ivy + Scala)


Sulla carta sembra molto interessante e pare valga la pena provarlo su strada e vedere come si comporta nel "real world".

Update 2013-10-17

Oltre alla possibilità di pacchettizzare una app sotto forma di WAR per il deploy in un qualsiasi application server, è anche prevista la possibilità di creare un uberjar con Jetty embedded. In questo modo è ulteriormente facilitato il deploy ed è abilitante per l'implementazione di micro-servizi.

Update: 2013-12-02

E' stata rilasciata oggi la versione 2.3.0, con una interessante novità: il SuperDevMode, che è molto simile alla modalità standard di sviluppo di Ninja con l'hot-reload di Jetty, con la differenza che non ci sono problemi di PermGen che di solito ci sono con l'hot-reload in ambito JVM.

Horizontal divider