Conway's Game of Life - my take on it in Clojure

If the board is represented as a vector of strings, where a string represents a row. E.g

The solution takes the board and returns the it in the next state.

On Scala

This will be a short one. Having been earning my bread and butter with Scala for 3 months now, I've come to realize: you can write beautiful code with Scala on both small and large scale. It has all the tools you need to do that. The same tools will enable undisciplined developers to make a terrible mess. Thank God we are a small team.

OO and FP

Shameless re-post, but great content!

http://somethingdoneright.net/2015/07/30/when-object-orientation-works-a-rule-of-thumb.html

My book list

Everyone has to come up with a booklist. That's a fact. This year is the 10th of my professional life and I use the annual to look back over this decade and pick the books that taught or inspired me most. I try to structure the following list respecting chronology (subjective chronology, though - based on when I came across these items), level and theme, sometimes sacrificing one for the the sake of the others.

Head First Design Patterns

An epitome of beginners' books, requiring only basic programming knowledge, funnily written and accessible. Even though Java and OO is not as hip as they used to be, it's a worthy read. Must read even, if you are a young, aspiring Java programmer.

Robert C. Martin: Clean Code

One of my all-time favourites. As much as I dislike Robert C Martin as a speaker - he has apparently irredeemably fallen in love with his own voice - I respect him as a superb writer. Clean Code covers a broad swathe of programming must-knows, its arguments are crystal clear, the style is witty and entertaining. It also introduces, IMHO, one of the greatest practical set of guidelines in programming, the SOLID principles. I think they really capture the essence of good code, and DDD, Hexagonal Architecture,  microservices and many other good things can almost completely be derived from them.

Martin Fowler: Refactoring: Improving the Design of Existing Code

Another iconic book. We owe much to Mr Fowler and this book is one of his greatest contributions. Introduced the concept of "refactoring", changing the code in small, controlled steps for the better whilst keeping the functionality intact.

Joshua Block: Effective Java, Second Edition

I don't really know what sets it apart from the first edition, but this is the only way I have seen this referred to. This is a bit more advanced stuff than the previous ones, and more specific to Java. Not too specific, though, to prevent users of other languages to draw some good lessons. Akin to Clean Code, it concentrates on small-scale stuff you meet in your everyday job - builders, classes, exception handling, ... - and does it very well.

Java Concurrency in Practice

You cannot regard yourself a senior Java developer if you haven't read this book. This sounds smug, but has more than a grain of truth. Concurrency is a bit like uncomfortable truth. One usually procrastinate accepting the pain and dealing with it, but if you do that, sooner or later it will come and bite you. The book addresses this difficult and complex topic and does it in a structured and readable style.

Martin Fowler: Patterns of Enterprise Application Architecture

A book targeting the large-scale. It offers a plethora of patterns and time-honoured insights in Fowler's usual engaging style. Very classic.

Martin Fowler: UML Distilled

Far away the days are when we had to generate code from models. Thank God. Although UML has lost much of its charm in the last decade (for the better), it's still a ubiquitous and not-yet-superseded tool in software engineering. Martin Fowler treats it fair in this concise little book, presenting it as a useful tool for thinking and communication between humans as opposed to the "visual programming language" some of its proponents promised it to be and it's failed to live up to.

Michael Feathers: Working Effectively with Legacy Code

This is a truly wonderful book for developers with a couple of years behind their back. Also is one that is a bit too heavy to read from cover to cover in one go, but full of interesting chapters that can stand alone on their own. Although the theme is eponymously about problems and solutions around interacting with legacy code - mostly how one can incrementally carve out chunks of the legacy codebase and plug in something new and well tested in their place -, Mr Feathers offers some very valuable general insights on coding and especially on testing.

Kirk Knoernschild: Java Application Architecture: Modularity Patterns with Examples Using OSGi

The best book I've read about modularity and I have to admit I only skimmed through the second, OSGi-specific part. But the first part about the general principles, challenges and solutions of modularity is awesome. Lots of other books touches this very important topic, but none of them in this depth and clarity.

Robert C. Martin: Agile Software Development, Principles, Patterns, and Practices

This books deserves much more attention than it enjoys. I consider it the big brother of Clean Code, aiming at larger scale problems. Among other things it introduces principles of Package and Component Design, mirroring SOLID principles on a coarser granularity level. Although some static code analyser tools - including my own humble excuse for one, Principle - use some of them to calculate metrics, they are not widely known and appreciated enough.

Steve Freeman, Nat Pryce: Growing Object-Oriented Software Guided by Tests

With so many books and blog posts and rants on TDD it's very hard to imagine that someone can still come up with something fresh and insightful in the topic. Yet Freeman and Pryce delivers that and much more. Through a realistic example they show how to do what the title says and tell a lot about testing and design along the way.

Vaughn Vernon: Implementing Domain-Driven Design

The Red Book. This is a big and heavy volume, full of theory and practical examples, and almost indispensable if you want to grok DDD. Much more down to earth than its predecessor (the Blue Book by Eric Evans). Very-very useful.

Martin Fowler: NoSQL Distilled

Yet another great book of Fowler, exhibiting all the good traits of his other work. Exploring a fundamental topic, engaging style and clarity.

That's it.
What is missing? Probably 1-2 books I forgot, but mostly huge amount of on-line resources. I can't say there is any book about FP that fundamentally influenced me, although FP in general has in the last 2 years. The same could be said specifically about Clojure.

Clojure's Protocol - when to use it?

Coming from an OO-background I instinctively turned to protocols during my early Clojure explorations. Need to model an Aggregate? Complex internal structure, should be hidden, small set of functions operating on it? Protocol, what else?
Eventually I've learnt a bit of FP and started moving towards pure functions, feeling less and less the need to resort to the OO-ish features of the language. However recently I've been spending some time writing a Twitter-reader application and had some trouble with functions with side-effects. Long story short, I've come up with a simple rule of thumb (don't expect anything earth-shattering)

Use protocols when state is involved!

When is 'state' involved?

1. when the program maintains stateful entitites (either in DB or just in memory)
2. communicating with an external system (e.g. Twitter)

The two cases are not that different, actually. If you can abstract away from the communication details, is operating on the DB really much different from operating on Twitter? Twitter could run on your local machine on your DB after all, in theory.

So what's the benefit?

1. you can group functions together. Usually if you manage state, there are multiple operations around it. Save/Delete/Get/Update for DB, StartListeningToStream/StopListeningToStream for Twitter. Having separate methods only grouped by namespace seems somewhat off to me. Maybe a matter of taste.
2. Easier to provide new implementations. You want to replace your Mongo with Reddis, just give a new implementation. I think the cognitive load is much less if all the functions you need to change are bound together by the language itself, so you don't have to hold all those independent functions in your head.
3. Ordinary functions should be pure. If you hide your state behind a protocol, all the rest can be

An example

So the new, all-encompassing, completely universal principle you should absolutely start all your projects with, absolutely without exceptions

1. identify the moving parts in your model
2. hide them behind protocols by having a namespace for each where only the protocol itself and the factory method is public

Still a bit OO-ish? Maybe. But no-one said OO is without merits.

Creating Clojure "actors" with core.async

A plain vanilla "actor" built with core.async. Can wrap any type of logic as long as it can be described with a function with the given - very general - signature.

Improving existing code - imaginary checklist - 3

Eliminate cyclic dependencies

Almost forgot about this one, despite being the most obvious (and challenging, possibly).

Decrease ACD (Acyclic Component Dependency)

Related to the previous point, but a quite vague target. I don't know what the proper value is for relative ACD, it possibly depends on the size of the application and other traits of it. STAN is a great tool to help you in that, however.

Improving existing code - imaginary checklist - 2

Continuing the completely random and unprioritized checklist. Some of them are easy to fix, some are heavy.

Eliminate mutable state where possible

Immutability has many advantages over mutable objects, none of them will I mention here. For an example see the Query class in the previous post. Avoid setters, use final keyword and defensive copies.

Thread safety

Quite self-explanatory.

Separation of concurrency and domain logic

Multi-threading logic should be separated from the rest of the code. It's quite complex on its own, even more when is intertwined with other things.

Invariants and UnitOfWork-s

Check what are the units of work, and what are the invariants. The formers should encapsulate the latter. This is quite an important point. And a not so low hanging fruit, probably.

Push third-party code to the outer layers

This might be a big one. Practically I think almost all application should follow the Hexagonal Architecture style. This can be achieved iteratively, but could take a long time to get there if the code hasn't been written that way.

To be continued...

Binary Tree implementation in Haskell, Clojure and Scala - 2

And thanks to @Kaloz, here is the Scala implementation with a slightly altered/extended functionality.

Improving existing code - imaginary checklist - 1

I endeavour to prepare a checklist I would go through if I had to start to work on a brownfield project. Small things to improve, hunt for the low hanging fruits. Don't expect any enlightenment here, these are just pearls of blue-collar wisdom.

Handling unrecoverable exceptions

In my current project we use messaging via ActiveMQ. Should an exception occur, the message is bounced back to the queue, then retried. It's fine, as long as there is a chance of recovery and sometimes - for example when the message is invalid in some way - there is none. In this case bouncing the message back is a waste of time and resource, plus the message can and up in the Dead Letter Queue leading to memory loss. So instead we should catch these exceptions as close to the entry point as possible and simply log them.

Validating input

Related to the previous point. To adhere the fail-fast principle, the inputs of the system should be validated. Validation is usually against some domain criteria, so I would put the logic in the Domain layer, just as the input passed the ACL. Should the input fail to comply, throw an unrecoverable exception.

Validate domain objects

I wouldn't stop at the inputs. I'd validate every domain object upon creation. Design by contract is a very good practice.

The validation should throw an unrecoverable exception. See the first point.

To be continued...

Binary Tree implementation in Haskell, Clojure and Scala

I've embarked on learning Haskell recently. I only start to suspect the power of this language, but I'm already impressed with its beautifully succinct and readable, no-nonsense syntax. Nuff' said, let's do a demonstration!

Haskell


Clojure


Scala - I've failed with this one. Maybe @Kaloz can help me out.