If you’re new to the 0.9 alpha version of Duct, I suggest you take a
detour and read Advancing Duct, which covers the new architecture
of Duct more completely.
By contrast, this post won’t cover old ground, but instead focus on
a more specific (but very common) use-case: web services. I’ll also
introduce Ataraxy, a data-driving routing library that integrates
well with Duct.
Duct started life as a project template for writing web
applications in Clojure, based around Stuart Sierra’s Component
micro-framework. The next version of Duct replaces Component
with Integrant, a micro-framework that I developed with Duct in
mind.
Homoiconicity, AKA “code is data”, is a frequently cited benefit of
using a Lisp. When people reference this, the first thing they talk
about is usually macros, and how powerful and transformative they are.
In Paul Graham’s Beating the Averages, for example, he points to
macros as the tool that elevates Lisp above other languages. He goes
on to provide an interesting statistic:
The source code of the Viaweb editor was probably about 20-25%
macros.
As a Clojure programmer, this makes me want to run away screaming.
You might already know about the current proposal to
introduce support for asynchronous handlers in Ring. In this post I’m
going to try to summarise the proposed design, and talk a little about
why it was chosen. I can’t cover everything, but I’ll try to provide
an overview.
There have been a few discussions lately on how to
structure Clojure applications. In one corner there’s reigning
champion Component, and in the other the newcomer Mount.
I come down in favour of Component, but during the discussion I found
that the way I currently use Component has diverged from the way
Component is advocated in Stuart Sierra’s 2014
Just Enough Structure talk. Rather than contrasting Component and
Mount, which has been done by others, I thought I’d instead write
about how I use Component differently to Stuart.
Encapsulation is a mainstay of object orientated programming, but
in Clojure it’s often avoided. Why does Clojure steer clear of a
concept that many programming languages consider to be best practice?
The Clojure web ecosystem doesn’t provide as much guidance to
newcomers as other languages. There are no large frameworks on the
same scale or adoption as Ruby on Rails or Django, and in
their absense, a common question arises: how do I structure a web
application in Clojure?
I haven’t seen a satisfactory answer to this question, but that’s not
because no-one’s bothered to document common wisdom. Rather, I believe
it’s because we’re only now beginning to discover good solutions in
Clojure to this rather thorny set of problems.
With the advent of Github and similar services, it has never been
easier to contribute patches to open source projects. Unfortunately,
it can sometimes be an uphill struggle to get those patches accepted.
As a project maintainer, I receive a lot of good pull requests, but
also many that make common mistakes that need to be fixed before the
code can be merged. In the interests of reducing frustration on both
sides, here’s some advice for writing pull requests that won’t make
the project maintainer hate you.
I recently had cause to investigate serialization options for Clojure
data structures. I came up with four contenders: Carbonite,
Deep Freeze, Nippy and the standard EDN reader from
Clojure 1.5.1. Out of curiosity, I also decided to benchmark
Cheshire’s JSON and SMILE serialization, to see how it
compared.
Compojure operates a little differently to most other routing
libraries, and can seem a little “magical” unless you’re familiar with
how it works behind the scenes. This blog post is designed as a
introduction to Compojure from first principles; starting with
Ring handlers, how do we get to Compojure?