Introduction

When it comes to Clojure (when I say Clojure, I am usually referring to both Clojure and ClojureScript. Sometimes I am referring only to JVM Clojure, but context should make it clear), there are many tutorials, websites, and books about how to get started (giving information on the language syntax, how to set up a project, how to configure your IDE, and so on). There are also many tutorials, websites, and books about how language features work (protocols, transducers, core.async, and more). There are precious few tutorials, websites, and books about when and how to use Clojure's features.

This book is not a getting-started tutorial. Neither is it a deep dive on a particular Clojure feature. It is more like a class in comparative architecture. I assume that you are familiar with Clojure and even a bit proficient at it. I will pick a theme and talk about the tools Clojure provides in that theme. I will use some example problems, solve them with different tools, and then pick them apart for what is good and what is bad. There will not be one right answer. There will be principles that apply in certain contexts.

Who am I? I'm Paul Stadig, and I have been using Clojure since 2008. I took a job writing Clojure full time (actually writing Clojure every day) in 2010. Since then, I have worked at two other companies writing Clojure code full time, and I still do!

I have worked on large, distributed, cloud-based applications that ran Clojure services on hundreds of Amazon Web Services instances, processing jobs from RabbitMQ. I have worked on Clojure services that served front-page ad carousels to 1,000,000 visitors per day. I have worked on distributed Clojure systems that process graph algorithms across billions of observations about network activity.

I have patches that have been applied to Clojure. I have been an administrator for Clojure's Jira ticketing system, and for the Clojure developer Google Group. I have been actively involved in Clojure user groups. I have created and contributed to many Clojure open-source projects. I have spoken at Clojure conferences. I have been a technical reviewer on several Clojure books.

I also have a life outside of Clojure. I live in central Virginia in the foothills of the Blue Ridge Mountains with my wife and four children.

This is not a cookbook. This is me conveying my experience of writing large Clojure systems. If I am successful, then I am not teaching you recipes; instead, I am helping you develop a taste for good Clojure design. Partly, this will be up to you. I will help as much as I can, but you must see through the examples to perceive the design principles underneath, then take the design principles and use them in your own work.

The principles I am sharing are based on my own experience, so they may not be the best advice or the most beautiful design principles. I am writing this in a very personal style, as though we were chatting in a coffee shop. Just like any other advice you may receive, you must judge it for yourself. Do not throw out everything because you found one thing that is wrong or does not make sense. Take the good. Leave the bad. Use discernment.

Finally, I cannot claim to have invented all of these principles, but I will attribute where I can. Many of these principles I learned working with amazing people on amazing teams, and—if I learned my lessons right—you will get to benefit from that experience.

I hope I can help you develop a taste for good Clojure design.

If you have any questions or feedback, send me an email (paul@stadig.name). You can also, find me at Real World Clojure (http://realworldclojure.com/).