It’s increasingly common for web applications to incorporate real-time elements. More and more, users expect the page to be updated instantly, without the need to refresh. Unfortunately, this is often implemented as an afterthought. The dominant paradigm for the web is still request-response. This is well suited to fetching data on some client-side event (e.g. page loads, button clicks), but not for receiving real-time updates from the server. To work around this limitation, developers often resort to polling, or “sprinkle on” ad-hoc real-time events using a websocket.

It may surprise you, given the title of this post, that I’m not absolutely against hooks. I actually think that they’re mostly an improvement over the old class API. What concerns me is how they’ve affected how React is used in practice. React is now perceived as a full framework, rather than just a library for UI rendering. It’s claimed that hooks have enabled this shift. I’ve been told that hooks solve fundamental problems like state management, controlling side effects, and writing testable code.

In this blog post, I’ll recount my experience building a CLI application in Elixir . I needed to build a CLI for Intention , a web app for goal tracking that I wrote last year. The CLI wasn’t very complicated - it just needed to authenticate, then call a couple of HTTP endpoints in Intention’s backend API and show the results. This will be a fairly high level overview, if you’d prefer a more detailed step by step guide, I’ve linked to a couple at the bottom of the page.

Whenever I speak to other Clojure developers, whether they’re seasoned pros or brand new to the language, one question that always comes up is “how do you debug your code?”. Most of us have heard the rhetoric around REPL driven development - “develop your program interactively in the REPL, debugging as you go!”. This sounds straightforward, but it’s often not quite that easy in practice. Say you’re writing a REST API using Compojure, and you notice one of your endpoints is returning an incorrect response.

In life, you don’t always get what you want. As developers, we may want all our data in a nice format like EDN or Transit , but alas this isn’t always possible. Sometimes marketing send you data in a .docx file (containing a scan of a photocopy of a screenshot of an HTML table), or perhaps you receive a 5 megabyte Excel spreadsheet from a 3rd party. It’s an unfortunate fact of developer life that you have to spend a lot of time massaging data into a usable format.

(a.k.a how to generate a static site using Clojure) As many of you are no doubt aware, during these troubling times many young people are showing their support for the NHS and other key workers by displaying paintings of rainbows in their windows . Since I’m supposedly a grown-up, I thought I’d try to go one better - displaying a computer-generated rainbow. Naturally, I turned to Clojure to do this. My basic plan was this:

I recently encountered a slight difficulty with updating cardinality many attributes in Datomic, so I thought I would make a short walkthrough post about it. The Problem In Datomic each attribute has a “cardinality”, signifying how many values an attribute is allowed. Cardinality can be either “one” or “many”. Adding values for a cardinality many attribute is fairly straightforward, but updating them to a specific set is more difficult. Let’s take the example of a simple Todo list, where each todo has a title and multiple tags.

In this blog post, I’ll walk you through how to create a Kafka Streams application in an idiomatic Clojure style. I won’t assume any knowledge of Kafka or Kafka Streams, but if you’ve never heard of them before this post may be a bit overwhelming - I’d check out Confluent’s introduction to Kafka Streams , and also the Kafka Streams docs . Kafka can be thought of as a persistent, highly scalable, distributed message queue.

First off, welcome to my brand new blog. I’m a Clojure programmer by day, so this blog will focus pretty much entirely on Clojure (as you probably guessed from the name). My main aim with this blog is to document step-by-step solutions for any difficult, or rare, problems I come across. I was inspired to start the blog by a post on Medium . The post talks about how Clojure can be hard for beginners, due to the lack of step-by-step guides for common problems.