DEV Community: ivan.gavlik

Leiningen — Complete Tutorial & Best Practices

ivan.gavlik — Sun, 12 Apr 2026 11:23:33 +0000

Leiningen is the build tool and project manager for Clojure. Think of it
like npm (Node), Maven (Java), or pip (Python) — but designed around
Clojure's philosophy.

What Leiningen Does

Creates and scaffolds projects
Manages dependencies (from Clojars + Maven Central)
Runs REPLs, tests, and builds
Compiles and packages your app (JAR/uberjar)
Runs custom tasks via plugins
Manages profiles (dev/test/prod configs)

Project Structure
my-app/
├── project.clj ← The heart: dependencies, config, build
├── src/
│ └── my_app/
│ └── core.clj ← Main namespace (note: _ not - in folders)
├── test/
│ └── my_app/
│ └── core_test.clj
├── resources/ ← Static files, config, assets
├── target/ ← Compiled output (git-ignore this)
└── README.md

Note: Clojure namespaces use - (hyphens), but folder/file names use _ (underscores). my-app.core → src/my_app/core.clj

project.clj

  (defproject my-app "0.1.0-SNAPSHOT"
    :description "What this project does"
    :url "https://github.com/you/my-app"
    :license {:name "MIT"}

    ;; Dependencies: [group/artifact "version"]
    :dependencies [[org.clojure/clojure "1.12.0"]
                   [ring/ring-core "1.12.0"]
                   [hiccup "2.0.0-RC3"]]

    ;; Entry point for `lein run`
    :main my-app.core

    ;; Source paths
    :source-paths ["src"]
    :test-paths   ["test"]
    :resource-paths ["resources"]

    ;; AOT compile specific namespaces (needed for uberjar)
    :aot [my-app.core]

    ;; Profiles: override config per environment
    :profiles
    {:dev  {:dependencies [[ring/ring-mock "0.4.0"]]}
     :prod {:aot :all}
     :uberjar {:aot :all :omit-source true}})

Real world Example

Shows how do declare dependencies, plugins on project and profil level plus advanced usages of aliases

(defproject ebp-be "0.1.0-SNAPSHOT"
  :description "Backend project for Event Booking Platform."
  :url "https://github.com/IvanGavlik/ebp"
  :license {:name "MIT"}

  :dependencies [[org.clojure/clojure "1.11.3"]
                 [ring/ring-core "1.12.1"]
                 [ring/ring-jetty-adapter "1.12.1"]
                 [ring/ring-json "0.5.1"]
                 [compojure "1.7.1"]]

  ;; project level plugins
  :plugins [[lein-ring "0.12.6"]
            [lein-shell "0.5.0"]]

  ;; lein-ring plugin config - points to handler
  :ring {:handler ebp.handler/app
         :port 3000
         :auto-reload? true
         :reload-paths ["src"]
         :init ebp.handler/app-init
         :destroy ebp.handler/app-destroy
         :open-browser? true
         :war {:name "ebp-be"}}

  ;; entry point
  :main ebp.core

  :source-paths ["src"]
  :test-paths ["test"]
  :resource-paths ["resources"]

  :uberjar-name "ebp-be.jar"
  :profiles {:dev {:dependencies [[ring/ring-mock "0.6.2"]]
                   :plugins [[lein-ancient "0.7.0"]
                             [lein-cljfmt "0.9.2"]
                             [lein-kibit "0.1.11"]
                             [jonase/eastwood "1.4.3"]
                             [com.jakemccrary/lein-test-refresh "0.26.0"]]
                   ;; lein-ancient plugin config
                   :ancient {:check-clojure? true
                             :allow-snapshots? false
                             :allow-qualified? false}
                   :cljfmt {:indentation? true
                            :remove-trailing-whitespace? true
                            :insert-missing-whitespace? true
                            :remove-surrounding-whitespace? true}
                   :eastwood {:linters [:all]}
                   :test-refresh {:changes-only false}}
             ;; production build
             :uberjar {:aot :all :omit-source true}}
  :aliases {"dev" ["do"
                   ["shell" "cmd" "/c" "start" "cmd" "/k" "lein" "with-profile"
                    "dev" "ring" "server-headless"]
                   ["shell" "cmd" "/c" "start" "cmd" "/k" "lein" "with-profile"
                    "dev" "test-refresh"]
                   ["with-profile" "dev" "repl"]]
            "code-quality" ["with-profile" "dev" "do"
                            "cljfmt"  "fix,"
                            "eastwood,"
                            "kibit,"
                            "test,"
                            ;"ancient" ":all" ":profiles" does not work on windows
                            ]
            "ci"      ["do"
                       "clean,"
                       "cljfmt"  "check,"
                       "eastwood,"
                       "test,"
                       "uberjar"]})

Full source code here

Explanation of each of the sections

Profiles

You can put inside a profile almost anything that goes in project.clj at the top level:

  :profiles
  {:dev
    {:dependencies   [...]   ; extra deps for this profile
     :plugins        [...]   ; extra plugins
     :source-paths   [...]   ; extra source dirs
     :resource-paths [...]   ; extra resource dirs
     :env            {...]   ; env vars (needs lein-environ)
     :jvm-opts       [...]   ; JVM flags
     :main           ...     ; override entry point
     :aot            [...]}} ; override AOT

Activate a profile:
lein with-profile prod run
lein with-profile dev,test test # multiple profiles

Profiles merge, with later ones winning. :dev is active by default in most commands.

Common Patterns

Separate DB per environment

  :profiles
  {:dev  {:env {:db "jdbc:postgresql://localhost/app_dev"}}
   :test {:env {:db "jdbc:postgresql://localhost/app_test"}}}

Dev-only tools that don't ship

  :profiles
  {:dev {:dependencies [[clj-reload "0.7.0"]
                        [eftest "0.6.0"]]
         :plugins [[lein-cljfmt "0.9.2"]]}}

Different JVM memory per task

  :profiles
  {:dev     {:jvm-opts ["-Xmx512m"]}
   :uberjar {:jvm-opts ["-Xmx2g" "-server"]}}

Extra source dir for dev utilities

  :profiles
  {:dev {:source-paths ["dev"]}}

dev/user.clj — good place for REPL helper functions and startup code.

Plugins

Plugins extend what lein can do.

Where to Put Them

Global — your personal machine only
Good for personal tools you want in every project.

  ;; ~/.lein/profiles.clj  (not in the project repo)
  {:user
    {:plugins [[lein-ancient "0.7.0"]
               [lein-pprint "1.3.2"]]}}

Top-level — for everyone on the project
Committed to git. Every developer gets these when they clone.

  (defproject my-app "0.1.0-SNAPSHOT"
    :plugins [[lein-ring "0.12.6"]
              [lein-ancient "0.7.0"]])

Inside a profile — conditional
Only active when that profile is active.

  :profiles
  {:dev
    {:plugins [[lein-test-refresh "0.25.0"]
               [lein-cljfmt "0.9.2"]]}

   :uberjar
    {:plugins [[lein-shell "0.5.0"]]}}

Most Useful Plugins

Web Development

  ;; Run Ring/Compojure apps with auto-reload
  [lein-ring "0.12.6"]
  lein ring server        ; open browser automatically
  lein ring server-headless
  lein ring uberjar       ; build deployable war

  ;; ring config in project.clj
  :ring
  {;; Required: your main handler function
   :handler my-app.core/app

   ;; Port (default 3000, overridden by $PORT env var)
   :port 3000

   ;; Auto-reload namespaces on file change
   :auto-reload? true

   ;; Which namespaces to watch for reload
   :reload-paths ["src"]

   ;; Run this function before server starts
   :init my-app.core/init

   ;; Run this function when server stops
   :destroy my-app.core/destroy

   ;; Open browser on start (default true with `lein ring server`)
   :open-browser? true

   ;; For WAR packaging: servlet name
   :war {:name "my-app"}}

Testing Ring Handlers

Use ring-mock — no server needed:

  :profiles {:dev {:dependencies [[ring/ring-mock "0.4.0"]]}}

  (ns my-app.core-test
    (:require [clojure.test :refer :all]
              [ring.mock.request :as mock]
              [my-app.core :refer [app]]))

  (deftest test-home
    (let [response (app (mock/request :get "/"))]
      (is (= 200 (:status response)))))

  (deftest test-not-found
    (let [response (app (mock/request :get "/missing"))]
      (is (= 404 (:status response)))))

  (deftest test-post
    (let [response (app (-> (mock/request :post "/users")
                            (mock/json-body {:name "Alice"})))]
      (is (= 201 (:status response)))))

Testing

  ;; Auto-run tests on file save
  [lein-test-refresh "0.25.0"]
  lein test-refresh

  ;; Test coverage report
  [lein-cloverage "1.2.4"]
  lein cloverage
  ;; generates target/coverage/index.html

Code Quality

  ;; Format code (like Prettier)
  [lein-cljfmt "0.9.2"]
  lein cljfmt check       ; show formatting issues
  lein cljfmt fix         ; auto-fix them

  ;; Linter — catches common bugs
  [jonase/eastwood "1.4.3"]
  lein eastwood

  ;; Suggest more idiomatic Clojure
  [lein-kibit "0.1.8"]
  lein kibit

Dependency Management

  ;; Check for outdated dependencies
  [lein-ancient "0.7.0"]
  lein ancient            ; check deps
  lein ancient :all       ; check deps + plugins
  lein ancient upgrade    ; auto-update versions

Finding Plugins

https://clojars.org — search for lein-*
https://github.com/technomancy/leiningen/wiki/Plugins — official plugin list

Aliases

Shortcuts that let you define custom lein commands in project.clj. Instead of typing long commands repeatedly, you define them once and run them with a short name.

Simple Aliases

Single task shortcut

  :aliases
  {"fmt"   ["cljfmt" "fix"]
   "lint"  ["eastwood"]
   "hints" ["kibit"]
   "dev"   ["ring" "server"]}

Example of call
lein fmt

Chaining Tasks with do

Run multiple tasks sequentially — use commas to separate task+args groups:

  :aliases
  {"ci" ["do"
         "clean,"
         "eastwood,"
         "kibit,"
         "test,"
         "uberjar"]}

lein ci ; clean → lint → analyze → test → build

Note: The commas are part of the syntax — they tell do where one task ends and the next begins.

Profile + Task Combos

  :aliases
  {"dev"      ["with-profile" "dev"     "ring" "server"]
   "prod-run" ["with-profile" "prod"    "run"]
   "ci-test"  ["with-profile" "test"    "test"]
   "build"    ["with-profile" "uberjar" "uberjar"]}

lein dev ; start dev server with :dev profile
lein build ; build production jar with :uberjar profil

Why AOT Compilation?

AOT = Ahead-Of-Time compilation

Normally Clojure compiles at runtime (when the JVM starts). AOT means
compiling to .class files before runtime, at build time.

The Problem It Solves
When you run a JAR, the JVM needs a standard Java entry point:
public static void main(String[] args)

Clojure's -main function is not that. It's a Clojure function that gets compiled on the fly when the JVM starts.

Without AOT, the JVM has no idea where to start. It can't find a main
method.

AOT compiles your -main namespace into real .class files with a proper Java main method the JVM can call directly.

What Happens With vs Without AOT ?

Without AOT (lein run):
JVM starts
→ loads Clojure runtime
→ Clojure compiles your namespaces on the fly
→ calls -main
(works fine because lein handles the startup)

With AOT (java -jar my-app.jar):
JVM starts
→ looks for main class in MANIFEST.MF
→ finds compiled .class file ← AOT produced this
→ calls -main
(works because the class file exists)

Concrete Example

(ns my-app.core
    (:gen-class))          ; ← this is also required! tells AOT to generate a
   class

  (defn -main [& args]
    (println "Hello!"))

Without :gen-class in the namespace declaration, even with :aot, the JVM won't find the entry point.

Why Only in the Uberjar Profile?

  :profiles
  {:uberjar {:aot :all}}   ; ← AOT everything for production jar

AOT has downsides in development:

Slower build — compiling everything takes time
Stale classes — if you change code, old .class files can cause confusing bugs
Bigger output — more files in target/

Clojure core.async: A Question & Answer Journey on Channels

ivan.gavlik — Fri, 13 Mar 2026 14:29:49 +0000

Introduction

core.async is Clojure's library for writing concurrent code without dealing with locks, callbacks, or complex threading.

Write asynchronous code that looks synchronous. Your code reads top-to-bottom, even though operations happen concurrently.

Components

Channels: queues that connect producers and consumers. They hold data temporarily and coordinate when to send and receive values
Operations: Non-blocking and blocking put and take operations for sending and receiving data
Go block: Place where you write sequential-looking async code

This post focuses exclusively on Channels. We'll explore Operations (>!, <!, >!!, <!!) and Go blocks in the next posts.

Channels

What exactly is a channel?

A channel is much more than a simple queue—it's a coordination mechanism that manages communication between independent processes

Internal Structure:

Every channel maintains four key components:

Buffer: Optional fixed-size queue holding values in transit. Can be:

nil (unbuffered - rendezvous semantics)
Fixed buffer (bounded queue)
Sliding buffer (drops oldest when full)
Dropping buffer (drops newest when full)

Take Queue: List of consumers waiting to receive values (when buffer is empty)

Put Queue: List of producers waiting to send values (when buffer is full)

Closed Flag + Lock: Thread-safe state management for the channel lifecycle

How data flow in the channel internal structure?

When you put a value on a channel, the implementation checks if any consumers are waiting. If so, the value is handed directly to a waiting consumer. If not, the value goes into the buffer (if there's space), or the producer joins the put queue to wait.

(require '[clojure.core.async :as a :refer [<! >! <!! >!! go go-loop chan close!]])

;; Unbuffered channel - producers and consumers must rendezvous
(def unbuffered-ch (chan))

;; Fixed buffer - can hold up to 10 values before blocking producers
(def buffered-ch (chan 10))

;; Sliding buffer - drops oldest values when full
(def sliding-ch (chan (a/sliding-buffer 5)))

;; Dropping buffer - drops newest values when full
(def dropping-ch (chan (a/dropping-buffer 5)))

;; Demonstration of buffer behavior
(let [ch (chan 2)]  ; Buffer size 2
  (go
    (>! ch 1)  ; Goes into buffer immediately
    (>! ch 2)  ; Goes into buffer immediately
    (println "Put two values")
    (>! ch 3)  ; Blocks here - buffer full, no consumer
    (println "Put third value"))

  (Thread/sleep 100)  ; Let producer run
  (go
    (println "First value:" (<! ch))   ; 1
    (println "Second value:" (<! ch))  ; 2
    (println "Third value:" (<! ch)))) ; 3 - now producer can complete

;; Output:
;; Put two values
;; First value: 1
;; Second value: 2
;; Put third value
;; Third value: 3

What is diff between buffered vs unbuffered channels?

Buffered channel = A mailbox where you can drop letters (items stored until someone picks them up).

Unbuffered channel = Handing something directly to someone (requires both people present at the same time).

Unbuffered channels have no storage capacity. They cannot hold any items at all.
When you do (chan) with no buffer size, you create a channel with a buffer size of 0. This means:

A producer trying to put a value must wait until a consumer is ready to take it
A consumer trying to take a value must wait until a producer is ready to give it
The value passes directly from producer to consumer in a "handshake" (No values are ever stored in the channel itself)

Important Note:
Both buffered and unbuffered channels work with all four operations: >!, <!, >!!, <!!
The difference is in when blocking/parking happens:

Buffered: Only blocks/parks when buffer is full (for puts) or empty (for takes)
Unbuffered: Always blocks/parks until handoff completes

What are use cases for buffered and unbuffered channels?

Buffered Channels Use case

I'm putting this in the queue for you to get to it when you can.

When producers generate data in bursts but consumers process steadily (e.g., user clicking buttons rapidly, but backend processes one request at a time).
When you want to queue up work without blocking the producer (e.g., logging system that accepts messages quickly while writing to disk happens in background)
Email Queue: Marketing system generates 10,000 emails instantly when campaign launches, but email server can only send 100 per minute. Buffer stores the emails while they're sent gradually.
Restaurant Order System: Kitchen receives orders in bursts during lunch rush (10 orders in 2 minutes, then nothing for 5 minutes). Buffer holds the orders so they're not lost, and kitchen processes them steadily.

Unbuffered Channels Use case

When you need confirmation that data was received before continuing (e.g., a worker acknowledging it accepted a task)

Worker Task Assignment: A manager hands work to a team member and waits until they confirm "I've got it" before walking away. You don't want to assume they took the task—you need to see them accept it.
Database Transaction Coordination: Service A completes a database write and must wait for Service B to acknowledge it read the data before A can proceed. Both must be synchronized at that exact moment.
Checkout Process: Customer submits payment, and the system must wait for payment gateway to confirm receipt before showing "Order Placed." Can't just fire-and-forget.
Handshake Protocols: Two systems establishing a connection—client sends "hello," waits for server to respond "hello back" before proceeding. Each step requires mutual acknowledgment.

What happens when a channel closes?

Closing a channel signals "no more values will ever be sent." This is the standard way to communicate completion in core.async pipelines.

Semantics:

Closed channels immediately return nil to all consumers
Attempts to put on a closed channel return false (or throw in blocking operations)
You can still drain values that were buffered before the close
Closing is idempotent—closing an already-closed channel is safe

(def ch (chan 5))

;; Producer sends values then closes
(go
  (>! ch 1)
  (>! ch 2)
  (>! ch 3)
  (close! ch)
  (println "Channel closed")

  ;; Attempting to put on closed channel
  (let [result (>! ch 4)]
    (println "Put after close returned:" result)))  ; false

;; Consumer loops until channel closes
(go-loop []
  (if-some [val (<! ch)]
    (do
      (println "Received:" val)
      (recur))
    (println "Channel closed, exiting")))

;; Output:
;; Received: 1
;; Received: 2
;; Received: 3
;; Channel closed
;; Put after close returned: false
;; Channel closed, exiting

Critical pattern: Use if-some or when-some to distinguish between:

nil because channel closed
nil as an actual value (though sending nil is discouraged)

;; Proper close detection
(go-loop []
  (when-some [val (<! ch)]  ; Continues only if val is non-nil
    (process val)
    (recur))
  ;; Loop exits when channel returns nil (closed)
  (println "Cleanup and shutdown"))

Key Takeaways

Channels are coordination mechanisms, not just queues. They manage the flow of data between independent processes.
Choose your buffer type wisely:
- Unbuffered: When you need rendezvous/handshake semantics
- Fixed buffer: For backpressure and controlled queuing
- Sliding buffer: When newest data matters most (like sensor readings)
- Dropping buffer: When you can afford to lose data under load
Always close channels when production is complete. This is how consumers know to stop waiting.
Use if-some/when-some to properly detect channel closure versus nil values.
Buffered channels decouple producers and consumers in time, while unbuffered channels force synchronization.

What's Next?

Now that you understand how channels work internally and when to use different buffer types, the next post will dive into Operations:

The difference between parking (>!, <!) and blocking (>!!, <!!) operations
When to use each operation type
How go blocks enable efficient concurrent programming
Composing channels with alts!, mult, pub/sub, and pipelines

(Clojure Managing-User-Permissions)

ivan.gavlik — Sun, 30 Mar 2025 19:28:08 +0000

Clojure practice task:

Managing User Permissions with Sets

You are developing a role-based access control system for a web application. Each user has a set of permissions (e.g., :read, :write, :delete). Your goal is to implement a permission management system using Clojure sets.

User {:user-name :email :permission}

The set of all available permissions in the system is :read :write :delete.

Tasks

Create a function to assign a set of permissions to a user.

(defn valid-user-permission? [permission]
  (subset? permission #{:read :write :delete}))

(defn valid-user? [user]
  (and (some? (:user-name user))
       (some? (:email user))))

(defn assign-user-permissions [user permissions]
  (when (and (valid-user? user) (valid-user-permission? permissions))
    (assoc user :permissions permissions)))

Write a function to check if a user has a specific permission.

(defn has-user-permission? [user permission]
  (when (and (valid-user? user) (valid-user-permission? #{permission}))
    (contains? (:permissions user) permission)))

Write a function to revoke a specific permission from a user.

(defn revoke-user-permissions [user permission]
  (when (and (valid-user? user) (valid-user-permission? #{permission}))
    (let [current-p (:permissions user)
          remove-p (disj current-p permission)]
      (assoc user :permissions remove-p)
      )))

Find users who have at least one common permission from a given permission set.

(defn find-users-common-permissions [users permissions]
  (filter #(subset? permissions (:permissions %)) users))

Find users who have all required permissions from a given permission set.

(defn find-users-all-permissions [users permissions]
  (filter #(= permissions (:permissions %)) users))

Compute the difference between two users permissions.

(defn diff-users-permissions [user-1 user-2]
  (difference (:permissions user-1) (:permissions user-2)))

Generate a report of all users and their permissions.
Example Alice -> #{:read :write}

(defn users-permissions-report [users]
  (map #(let [user (:user-name %)
              permissions (:permissions %) ]
          (cond
            (some? permissions) (str user " -> " permissions)
            :else (str user)
            ))
       users))

Practice working with Clojure vectors

ivan.gavlik — Sun, 23 Mar 2025 20:39:23 +0000

Vector

A vector in Clojure is an ordered, indexed, immutable collection that allows efficient random access and fast additions at the end. They are immutable.

Vectors are defined using square brackets [] or by using the vector function:

;; Creating vectors
[1 2 3 4]          ;; Literal syntax
(vector 1 2 3 4)   ;; Using vector function

Key Characteristics of Vectors:

Indexed (O(1) access time): You can retrieve elements using their index.
Ordered: Elements maintain the order in which they were inserted.
Immutable: Any modification creates a new vector instead of mutating the original.
Efficient addition/removal at the end: Adding elements to the end is fast (conj).

Usage & Operations:

Access Elements by Index

(def v [10 20 30 40])
(nth v 2)      ;; => 30
(get v 1)      ;; => 20
(v 3)          ;; => 40 (Vectors can be used as functions for indexing)

Adding Elements

(conj [1 2 3] 4) ;; => [1 2 3 4] (adds to the end)

Updating Elements

(assoc [1 2 3] 1 99) ;; => [1 99 3] (Replaces index 1 with 99)

Removing Elements

Vectors do not have direct remove operations, but you can filter or use subvec:

(vec (remove #(= % 2) [1 2 3])) ;; => [1 3] (Removes 2)
(subvec [1 2 3 4] 1 3)          ;; => [2 3] (Slices vector from index 1 to 2)

Iterating Over a Vector

(map inc [1 2 3]) ;; => (2 3 4)
(filter even? [1 2 3 4]) ;; => (2 4)

Sorting a Vector

(sort [3 1 4 2])  ;; => (1 2 3 4)
(sort-by count ["apple" "kiwi" "banana"]) ;; => ("kiwi" "apple" "banana") (Sort by length)

Task: Managing a Task List with Vector

Scenario:

You are building a simple task management system that stores tasks in a vector. Each task is represented as a map with the following keys:

:id (unique task identifier)
:title (task description)
:priority (one of :low, :medium, :high)
:completed? (boolean indicating if the task is done)

Goal:
Implement functions that allow you to manage tasks in the system:

Initialize Task List – Create a vector of sample tasks.
Add a Task – Insert a new task into the task list.
Remove a Task – Remove a task by its :id.
Mark a Task as Completed – Update a task’s :completed? status to true.
List All Pending Tasks – Return only tasks where :completed? is false.
Find Tasks by Priority – Retrieve all tasks with a specific priority (:low, :medium, or :high).
Sort Tasks by Priority – Sort the vector so :high priority tasks come first, followed by :medium, then :low.
Get Next Task – Return the highest-priority pending task that has not been completed.

Solution

;; Managing a Task

;; Initialize Task List
(defn init-task-list []
  (hash-map {})
  )

(defn valid-priority [priority]
  (or (= :low priority) (= :medium priority) (= :high priority))
  )


(defn create-task [id title desc priority]
  (when (valid-priority priority)
    {:id id :title title :description desc :priority priority :completed? false}
    )
  )

(defn task-not-exist? [task-list title]
  (= 0 (count (filter #(= (:title %)  title) task-list))
  ))

;; Add a Task
(defn add-task [task-list title desc priority]
  (when (task-not-exist? task-list title)
    (let [last-task-id (:id (last task-list) 0)
          next-task-id (inc last-task-id)
          task (create-task next-task-id title desc priority)]
      (conj task-list task)
      )
    )
  )

;; Remove a Task
(defn remove-task [task-list task-id]
  (remove #(= (:id %) task-id) task-list)
  )

;; Mark a Task as Completed
(defn mark-as-completed [task-list task-id]
  (let [task (first (filter #(= (% :id) task-id) task-list))
        index-of-task (index-of task-list task)]
    (when (not (nil? task))
      (assoc task-list index-of-task (assoc task :completed? true))
      )
    )
  )

;; List All Pending Tasks
(defn pending-tasks [task-list]
  (filter #(not (:completed? %)) task-list)
  )


;; Find Tasks by Priority
(defn filter-by-priority [task-list priority]
  (when (valid-priority priority)
    (filter #(= (:priority %) priority) task-list)
    )
  )

(defn priority-count [priority]
  (cond
    (= priority :high) 3
    (= priority :medium) 2
    (= priority :low) 1
    :else 0
    )
  )

(defn priority-higher-comparator [el1 el2] ()
  (let [priority1 (priority-count (el1 :priority))
        priority2 (priority-count (el2 :priority))]
    (compare priority2 priority1)
    )
  )

;; Sort Tasks by Priority
(defn sort-by-priority [task-list]
  (sort priority-higher-comparator task-list)
  )

;; Get Next Task
(defn next-task [task-list]
  (sort-by-priority (pending-tasks task-list))
  )

Clojure Vectors: A Deep Dive into the Data Structure

ivan.gavlik — Fri, 07 Feb 2025 22:13:34 +0000

Why Vectors Matter in Clojure

Vectors are one of the most commonly used data structures in Clojure. They provide fast lookup, efficient updates, and structural sharing for immutability, making them a crucial tool in functional programming. In this article, we'll explore how vectors work, when to use them, and best practices for leveraging their full potential.

How Vectors Differ from Lists

Clojure provides multiple sequential collections, but vectors and lists have different performance characteristics.

Vector

Access by index: O(1)
Adding elements: O(1) (append)
Immutability strategy: Structural sharing
Best suited for: Random access, iteration

List

Access by index: O(n)
Adding elements: O(1) (prepend)
Immutability strategy: Linked list
Best suited for: Recursion, sequential processing

Vectors are optimized for fast random access and updates, while lists excel in sequential processing and recursion.

Creating and Using Vectors

Vectors in Clojure are created using literal syntax ([]) or the vector function.

(def my-vec [1 2 3 4])
(def my-vec-alt (vector 1 2 3 4))

Retrieving elements by index is constant time:

(nth my-vec 2)  ; => 3
(get my-vec 2)  ; => 3

Modifying Vectors Efficiently

Although vectors are immutable, Clojure provides efficient ways to "modify" them by creating new versions.

Adding Elements

Appending elements to a vector is fast (O(1) amortized):

(conj my-vec 5)  ; => [1 2 3 4 5]

Updating Elements

Clojure's assoc function allows updating elements efficiently:

(assoc my-vec 1 99)  ; => [1 99 3 4]

Removing Elements

Vectors do not have a built-in function for removing elements by index, but you can achieve it using subvec:

(vec (concat (subvec my-vec 0 2) (subvec my-vec 3)))
; => [1 2 4]

Performance Considerations: When to Use Vectors

Vectors are ideal when:

You need fast index-based lookups
Appending elements at the end is frequent
Immutability with efficient memory usage is important

However, if you frequently remove elements from the front, consider other data structures like clojure.lang.PersistentQueue or list.

Best Practices for Working with Vectors

Use mapv for Efficient Vector Transformations.

Clojure's map function produces a lazy sequence, which may not always be ideal when working with vectors. Using map on a vector returns a lazy sequence, which requires conversion back to a vector if you need indexed access.

Example: The Issue with map

(map inc [1 2 3 4])
; => (2 3 4 5)  ; Returns a lazy sequence, not a vector

Since the result is a lazy sequence, functions expecting a vector (e.g., assoc) may not work efficiently. Instead, using mapv ensures the result remains a vector:

Example: Using mapv

(mapv inc [1 2 3 4])
; => [2 3 4 5]  ; Maintains vector type

Using mapv eliminates the need for explicit conversion (vec (map ...)), making the code cleaner and more performant.

Prefer conj for adding elements unless inserting at a specific index.

Use subvec for Efficient Slicing

When working with large vectors, extracting a portion using subvec is more efficient than converting to sequences. The subvec function provides a constant-time way to create a view of the original vector without copying data.

Example: Using subvec

(def my-vec [1 2 3 4 5 6 7 8 9])
(subvec my-vec 2 5)  ; => [3 4 5]

Unlike converting to sequences and filtering, subvec does not create an entirely new vector but instead references the existing structure efficiently.

Avoid frequent use of vec on sequences; favor transients if performance is critical.

Using vec on sequences repeatedly can be inefficient because it creates a new vector from a sequence every time, leading to unnecessary allocations. Instead, when building large vectors incrementally, consider using transient vectors for improved performance.

Example: Using Transients for Efficient Construction

(reduce conj! (transient []) (range 1000000))
; Returns a transient vector efficiently

You can finalize a transient vector using persistent! to make it immutable again:

(persistent! (reduce conj! (transient []) (range 1000000)))

This approach significantly improves performance for large data transformations.

Summary

Vectors are a powerful and efficient choice for most collection-based operations in Clojure. They offer fast lookup, efficient immutability, and excellent performance for most use cases.

Key Takeaways:
✅ Use vectors for random access and iteration
✅ Prefer conj for appending and assoc for updating
✅ Optimize performance with mapv, subvec and transient

Clojure's map data type

ivan.gavlik — Sun, 02 Feb 2025 17:33:31 +0000

Definition

A map in Clojure is a key-value data structure that stores associations between keys and values.

Keys are unique (no duplicate keys)
Maps are unordered by default (unless you use a sorted map)
Maps are immutable (modifications return a new map instead of modifying the original)

Clojure supports two main types of maps:

HashMap ({}) – Unordered, optimized for fast lookup.
SortedMap (sorted-map) – Ordered by key, useful when ordering matters.

Syntax

A Clojure map is represented using curly braces {} with key-value pairs:

{:key1 value1, :key2 value2, :key3 value3}

Keys are often keywords (:name), but they can also be strings, symbols, or numbers.
Values can be anything, even map.

Common Use Cases

Clojure maps are used for:

Data Representation – Storing structured information like user profiles, configurations, etc
Associative Lookup – Fast key-based retrieval of values
Transformations – Using functions like assoc, dissoc, merge, map, reduce on maps
Sorting & Grouping – Organizing data using sorted-map or group-by

Practicing:

Create and Manipulate Maps
Create a map representing a student with keys :name, :age, and :grade. Add a new key :hobby with a value, and update the :grade to a new value.

(def student {:name "Johnny" :age "30" :grade "A"})
(def studentWithHobby (assoc student :hobby "Clojure"))
(def studentGotB (assoc studentWithHobby :grade "B"))

Access Map Values
Given a map of product prices (e.g., {:apple 1.2 :banana 0.5 :cherry 2.5}), retrieve the price of :banana and handle the case where a key does not exist (e.g., :orange).

(def productPrice {:apple 1.2 :banana 0.5 :cherry 2.5})
(productPrice :banana)
(productPrice :orange 0)

Filter Map Entries
Write a function that takes a map of people’s names and ages (e.g., {:Alice 30 :Bob 25 :Charlie 35}) and returns a new map with only people aged 30 or older.

(def people {:Alice 30 :Bob 25 :Charlie 35})
(defn filter30Above [people]
    (filter (fn [map-item] (> (val map-item) 30)), people)
  )

Merge Maps
Merge two maps: one containing a user's personal details and another containing their contact information. Handle any key conflicts by prioritizing the second map.

(def user {:id 123456 :fNmae "Ivan" :lName "Gavlik" :age 30 })
(def contact {:id 123456 :email "ivangavlik963@gmail.com" :tel "+385912266016"})
(def user-contact (merge user contact))

Map Keys and Values Transformation
Given a map of temperatures in Celsius for different cities (e.g., {:Berlin 20 :Paris 25 :Rome 30}), transform the values to Fahrenheit.

def city-temp-celsius {:Berlin 20 :Paris 25 :Rome 30})
(defn cel-to-feh
  [[key val-cel]] [key (+ (* val-cel 9/5) 32)]
  )
(def city-temp-fahrenheit
  (into {} (map cel-to-feh city-temp-celsius))
  )

Group by Key Values
Create a function that groups a sequence of maps (e.g., {:name "Alice" :department "IT"}) by the :department key.

(def employers [ {:name "Alice" :department "IT" }
                { :name "Marko" :department "HR" }
                {:name "Pero" :department "HR"}
                ])

(def bySector (group-by :department employers))

Remove Entries by Condition
Remove all entries from a map of products and their stock quantities (e.g., {:apples 5 :oranges 0 :pears 10}) where the stock is 0.

(def fruit-stock-quantities {:apples 5 :orange 0 :pears 10})
(defn exist-fruit-stock? [[fruit stock]]
  (> stock 0)
  )
(defn fruit-stock-good [fruit-stock]
  (filter exist-fruit-stock? fruit-stock-quantities)
  )
(def fruit-stock-report (into {} (fruit-stock-good fruit-stock-quantities)))

Nested Maps
Work with a nested map representing a school (e.g., {:class1 {:students ["Alice" "Bob"] :teacher "Ms. Smith"} :class2 {:students ["Charlie" "Dana"] :teacher "Mr. Johnson"}}). Add a new student to :class2.

(def school-class {
            :class1 {:students ["Alice" "Bob"] :teacher "Ms. Smith" }
            :class2 {:students ["Charlie" "Dana"] :teacher "Mr. Johnson"}
            }
  )

(defn new-student-class2 [student school-class]
  (let [class2-students (get-in school-class [:class2 :students])
        add-new-student (conj class2-students student)
        class-new-student (assoc-in school-class [:class2 :students] add-new-student)
        ]
    class-new-student
    )
  )

Count Map Entries
Write a function to count how many keys in a map have values greater than a given number. For example, in {:a 5 :b 10 :c 15}, count how many values are greater than 8.

(def letter-occurrence {:a 5 :b 10 :c 15})
(defn letter-occurrence-gt [n letter-occurrence]
  (let [filter-map (filter #(> (second %) n) letter-occurrence)
         ]
     (count filter-map)
    )
  ;;  (count (into [] (keys (filter #(> (second %) n)  letter-occurrence))))
  )

Sort Maps by Values
Sort a map of items and their prices (e.g., {:item1 20 :item2 10 :item3 30}) in ascending order of prices.

(def item-price-data {:item1 20 :item2 10 :item3 30 :item4 10})
(defn sorted-item-price [item-price] (into (sorted-map-by (fn [k1 k2]
                                          (compare [(get item-price k1) k1] [(get item-price k2) k2]))) item-price))

Task: Managing a Library System Using Maps

Scenario:

You are developing a simple library system to manage books and their availability. The system stores book records as maps, where each book has attributes like :id, :title, :author, :year, and :available?.

Your goal is to implement functions that:

Initialize the Library – Create a collection of book records using maps
Check Out a Book – Update a book’s availability status when a user borrows it
Return a Book – Update the book’s availability when a user returns it
Find Books by Author – Retrieve all books written by a specific author
List Available Books – Return a list of books that are currently available
Add a New Book – Insert a new book record into the collection.
Remove a Book – Delete a book from the collection based on its :id

Solution

(def library
  [{:id 1 :title "Clojure for the Brave" :author "Daniel Higginbotham" :year 2015 :available? true}
   {:id 2 :title "The Joy of Clojure" :author "Michael Fogus" :year 2014 :available? true}
   {:id 3 :title "Programming Clojure" :author "Stuart Halloway" :year 2018 :available? false}])


(defn check-out-book [library book-id]
  (map #(if (= (:id %) book-id)
          (assoc % :available? false)
          %)
       library))

(defn return-book [library book-id]
  (map #(if (= (:id %) book-id)
          (assoc % :available? true)
          %)
       library))

(defn find-books-by-author [library author]
  (filter #(= (:author %) author) library))

(defn list-available-books [library]
  (filter :available? library))

(defn add-book [library new-book]
  (conj library new-book))

(defn remove-book [library book-id]
  (filter #(not= (:id %) book-id) library))


;; Example Usage
(def updated-library (check-out-book library 2))
(def returned-library (return-book updated-library 3))
(def books-by-author (find-books-by-author library "Michael Fogus"))
(def available-books (list-available-books library))
(def expanded-library (add-book library {:id 4 :title "New Book" :author "Some Author" :year 2023 :available? true}))
(def reduced-library (remove-book library 1))

Difference Between Clojure, Kotlin and Scala

ivan.gavlik — Sun, 26 Jan 2025 20:25:29 +0000

Intro

The JVM (Java Virtual Machine) ecosystem is home to several powerful languages, each bringing unique features and paradigms. Clojure, Kotlin, and Scala stand out as prominent options for developers working within the JVM environment. Here's a comparison of these languages, focusing on their integration with the JVM and JDK.

Clojure

Clojure is a dynamic, functional programming language inspired by Lisp. It emphasizes immutability, concurrency, and simplicity.

JVM:

generates bytecode that runs on the JVM
can call Java classes and methods making it ideal for integrating Java libraries, but it does not go well with Java Frameworks because they are written for OOP where Clojure is pure functional language
compilation is dynamic, but it supports ahead-of-time (AOT) compilation for creating standalone
has a REPL (Read-Eval-Print Loop)

JDK:

it relies heavily on the JDK for standard functionalities like I/O, collections, and threading
doesn’t impose a specific type system, it provides mechanisms to interoperate with Java’s static types when needed

Strengths:

ideal for rapid prototyping and data-driven applications
exceptional support for concurrency via immutable data structures and software transactional memory

Drawbacks:

not statically typed, which can be a disadvantage for some use cases
less suitable for complex object-oriented designs typical in Java-heavy environments.

Kotlin

Kotlin is a statically-typed, modern programming language developed by JetBrains. It was designed to improve upon Java by enhancing developer productivity while maintaining 100% interoperability with Java.

JVM:

compiles directly to JVM bytecode
allows mixing Kotlin and Java code within the same project - supports scripting and can even compile to JavaScript or native code (using Kotlin/Native)

JDK:

fully compatible with the JDK
simplifies Java’s verbose APIs by introducing features like extension functions, null safety, concise syntax and coroutines

Strengths:

null safety at the language level reduces the likelihood of NullPointerException
a shallow learning curve for Java developers due to its similar syntax and structure
officially supported for Android development by Google

Drawbacks:

features (like higher-order functions) can introduce complexity for new developers

Scala

Scala is a statically-typed functional and object-oriented programming language. It offers a robust feature set and is widely used in large-scale applications, particularly in data engineering and distributed systems.

JVM:

compiles to JVM bytecode and supports full interoperability with Java, although its more
has a REPL (Read-Eval-Print Loop)

JDK:

it's standard library replaces much of the JDK functionality with more functional approcah
preference for functional paradigms can make combining Scala with Java codebases hard.

Strengths:

highly expressive, with support for advanced features like higher-kinded types, pattern matching, and functional constructs.

Drawbacks:

steeper learning curve due to its rich feature set and advanced type systems
compilation times can be longer

Choosing the Language

Clojure: Best for projects that benefit from functional programming, immutability, and dynamic typing. Ideal for startups, data-heavy applications, and scripting.

Kotlin: Suited for teams migrating from Java but wish to use Java Framweworks like Spring. Standard for developing Android apps. Its modern features make it a great choice for most JVM-based applications.

Scala: The go-to language for distributed systems, big data processing, and teams familiar with functional programming.

Introduction to Clojure

ivan.gavlik — Tue, 21 Jan 2025 20:57:59 +0000

Clojure in one sentence

Clojure is a dynamic, functional programming language that runs on the Java Virtual Machine (JVM).

Functional Programming Language

In Clojure, functions are first-class citizens, allowing them to be passed as arguments, returned from other functions, and assigned to variables. This facilitates a declarative coding style, emphasizing the "what" over the "how."

Hosted Language on the JVM

Clojure code is compiled to java bytecode and then run on JVM.
This means that developers can use existing Java libraries and frameworks when working with Clojure.

Leiningen: Build Automation Tool

Leiningen is a build automation and dependency management tool for Clojure projects, similar to Maven or Gradle in the Java ecosystem. It simplifies project setup, compilation, testing, and packaging.

Creating a "Hello World" Project with Leiningen

Install Leiningen: Follow the installation instructions on the official Leiningen website.
Create a New Project: Open a terminal and run: lein new app hello-world
Navigate to the Project Directory: cd hello-world
and Run the Project: lein run

This command compiles and executes the project, displaying the output.

Project Directory Structure

A typical Leiningen project has the following structure:

hello-world/
├── src/
│ └── hello_world/
│ └── core.clj
├── test/
│ └── hello_world/
│ └── core_test.clj
├── resources/
├── target/
├── project.clj

src/: Contains the source code.
test/: Contains test files.
resources/: Stores non-code resources.
target/: Output directory for compiled files.
project.clj: Configuration file for the project, specifying dependencies and build settings.

REPL: Read-Eval-Print Loop

The REPL is an interactive programming environment that allows developers to execute Clojure code in real time.

Key Features of the REPL

Interactive Coding: Developers can type in code and see results immediately, enabling quick experimentation.
Dynamic Evaluation: Modify, test, and reload parts of your program without restartingwich the application.
Error Handling: Errors are displayed immediately, which makes debugging more efficient.
Exploratory Programming: The REPL encourages exploring ideas and libraries in real time

To start a REPL session, navigate to your project directory and run:

lein repl

This command launches the REPL, allowing you to interact with your code in real-time.

Basics of Clojure Syntax

The base of syntax is expression/form which format is

(operator operand1 operand2 ...)

which is evaluated to produce a value. For example, to add two numbers:

(+ 2 3)

Defining Values

Use def to bind a value to a name:

(def pi 3.14159)

Functions

Functions are the primary building blocks in Clojure. They are defined using the defn:

(defn greet [name]
  (str "Hello, " name))

This defines a function greet that takes a parameter name and returns a greeting string

Data Structures

Clojure provides several immutable data structures:

Numbers: Integers and floating-point numbers. e.g., 1, 1.1
Strings: Sequences of characters. e.g., (str "Hello")
Lists: Ordered collections, e.g., (1 2 3)
Vectors: Indexed collections, e.g.,[1 2 3]
Maps: Key-value pairs, e.g., {:a 1 :b 2}
Sets: Collections of unique values, e.g., #{1 2 3}

Conditional Statements

The if form is used for conditional branching:

(if condition
  then-expression
  else-expression)

Example

(defn is-small? [number]
  (if (< number 100) "yes" "no"))

user=> (is-small? 50)
"yesple

Example program

Generates a personalized greeting message.

(ns example-app.core)

(defn greet [name]
  "Generates a greeting message."
  (str "Hello, " name "! Welcome to Clojure."))

(defn -main [& args]
  "Main function of the application."
  (let [name (if (empty? args)
               "Guest"
               (first args))]
    (println (greet name))))

Handling Complexity - functional + object-oriented programming

ivan.gavlik — Sat, 24 Aug 2024 11:48:44 +0000

Intro

One of The biggest problems in the development and maintenance of large-scale software systems is complexity — large systems are hard to understand.

In any non-trivial system, there is complexity inherent in the problem that needs to be solved.

Also, we have other contributors to the complexity of the code that does not come from the essence of the problem but from the technical decisions and individual developer experience.

Those are
• handling of state
• code volume
• flow of control through the system (about the order in which things happen)

Other causes of complexity
• duplicate code
• dead code
• abstractions (unnecessary or missed)
• poor modularity
• poor documentation

One of the first decision about solving problem is decision about programming language (programming paradigm) decision between object-oriented programming or functional programming. Each approach suffer from different problems when applied to a large-scale system. The goal of this article is to point out that it is possible to take useful ideas from both - combined approach has potential for simplifying the construction of large-scale software

Mechanisms that are commonly used to try to understand system
• testing (to understand a system from the outside — as “black box”)
• informational reasoning (to understand the system by examining it from the inside – reading code)
• formal reasoning (documentation, requirements)

All ways of attempting to understand a system have their limitations. This includes both informal reasoning (reading code) — which is limited in scope, imprecise and hence prone to human error — as well as formal reasoning — which is dependent upon the accuracy of a specification.

Object-oriented approach to managing complexity

In most forms of object-oriented programming (OOP) an object is seen as consisting of some state together with a set of methods for accessing and manipulating that state

One organizes the program around objects: a set of attributes, plus methods that use/change these attributes. A class is a "blueprint" to create objects, all of the same structure. Classes usually model something: a car, an employee, an address... And objects are also values, to be passed along over functions.

OOP can be overused tho. A custom object, or a class should describe 1 specific thing and do it well. Also a custom object should be modifiable only by it's methods, so there's 1 clear controlled way (by checking if the applied modification is valid etc.. depends on the needs).

Functional Programming approach to managing complexity

Functional programming is not only about creating and calling functions - any style of programming has them - but about functions being first-class citizens. In FP, functions can be assigned to variables, passed along to other functions, returned from functions, as it they were any other value, like numbers.

The primary strength of functional programming is avoiding state (and side effects) - which implies that when supplied with a given set of arguments a function will always return exactly the same result (speaking loosely we could say that it will always behave in the same way).
Everything which can possibly affect the result in any way is always immediately visible in the actual parameters.

The main weakness of functional programming is the flip side of its main strength — namely that problems arise when (as is often the case) the system to be built must maintain state of some kind

Diff

And that's basically what makes functions and classes different. Functions is a block of code that does a specific thing and can be used anywhere. A custom object is a set of small things that describe a bigger image and should be controllable.

Real-World Application: Combining OOP and Functional Programming

Object-Oriented Programming is excellent for modeling complex entities with rich interactions. It allows developers to encapsulate state and behavior within objects, making the system easier to manage by segmenting the codebase into discrete, self-contained units. On the other hand, Functional Programming shines in managing logic in a predictable, side-effect-free manner, which simplifies reasoning about the code.

Use OOP to structure your code, model your entities, and manage interactions. Then, leverage FP to handle state transformations and business logic, ensuring your code remains pure and predictable.

Example in Java

Let's consider a simple example in Java to illustrate this approach. Suppose we're building a system to manage user accounts.

In an OOP style, you might define a User class to encapsulate the state and behavior of a user:

public class User {
    private String name;
    private int age;
    private String email;

    public User(String name, int age, String email) {
        this.name = name;
        this.age = age;
        this.email = email;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    public String getEmail() {
        return email;
    }

    public void updateEmail(String newEmail) {
        this.email = newEmail;
    }

    // Additional methods for user behavior...
}

However, when it comes to handling state logic, such as validating the new email or transforming user data, you can adopt a functional approach. Here, you might create a pure function to validate an email:

public static User updateUserEmail(User user, String newEmail) {
    if (isValidEmail(newEmail)) {
        return new User(user.getName(), user.getAge(), newEmail);
    } else {
        throw new IllegalArgumentException("Invalid email address");
    }
}

This combination not only simplifies the construction of large-scale software but also makes it more resilient to change, easier to maintain, and more aligned with the goals of both programmers and architects

Thinking About Complexity as a Programmer

ivan.gavlik — Tue, 06 Aug 2024 18:54:21 +0000

In every line of code, every system, every problem we encounter complexity and this isn't something to shy away from. Let's explore some ways of thinking about it.

What history teach us ?

Think about Isaac Newton and the falling apple that led to the law of gravity, Charles Darwin's theory of evolution, or Albert Einstein's revolutionary ideas about time and space. Each of these breakthroughs involved breaking away from old ways of thinking and embracing new concepts. Every significant breakthrough in science and technology has been about simplifying the complex.
So history teach use way out of complexity often lies in developing new sets of concepts and paradigms.

Thinking about a problem multiple times and from different angles can be incredibly beneficial. Using various tools, frameworks, and technologies to view the problem from different perspectives can lead to more robust solutions

What else helps ?

Step away from the computer and take a walk because physical movement can stimulate mental movement

It's beneficial to read outside your discipline (Exploring fields beyond STEM can provide fresh perspectives and new ways of thinking. For example, reading about psychology can offer insights into user behavior, while literature can enhance your understanding of narrative structures and communication).

One particularly valuable skill is lateral thinking, which is about solving problems through an indirect and creative approach.

For the end

Don't be afraid of complexity, look it as challenge, think outside the box, outside traditional boundaries and incorporate strategies not only from STEM filed, but also from other fields and studies.

What's the real point of Microservices? - should I start with Monolith

ivan.gavlik — Tue, 30 Jul 2024 23:00:16 +0000

In my view, most of the hype around microservices got the concept totally wrong.

The point of microservices

is that we want to organise code in such a way that we have small independent systems that each do well-defined job. The original microservices post said that microservices were "organised around business capabilities", which is a term of art from service oriented architecture, where we look for the things that a business does.

You can identify business capabilities by building a flow chart showing how your organisation generates value, and the key activities that happen at each step. You draw circles around the activities that cluster together neatly, due to required knowledge or resources, and those are business capabilities: Billing, Shipping, User Management, etc.

The point is that when you need to modify code that relates to a particular business activity, it's in one well-segregated codebase, and that codebase can evolve according to the pressures of that business capability without affecting anything else. That's really handy as your org gets larger, and you need to have individual teams who look after the Shipping function, or the Billing function, but it's also a sensible way to build software generally once it gets past a certain size.

The teams at Thoughtworks who named the microservice style were deeply influenced by Domain Driven Design, and by the earlier "Guerilla SOA" approach, also pioneered at Thoughtworks, that emphasised messaging and ReST to connect discrete services, without centralised authority.

In the software community

What happened is that the wider software community heard about this microservice thing, and didn't have the background understanding of DDD or message oriented systems, and misapplied it to mean "make lots of tiny things that communicate over RPC".

This is a disaster. Big tech companies wrote insane blog posts where they bragged about the 10,000 microservices they were running in their k8s clusters with a fancy RPC lib written by a central platform team. Reddit swarmed with excitable engineers who wanted to know how to build a graphql backend-for-frontend for their 50 tiny rpc services, so that their React app wouldn't suck so much. After a while everyone realised this was an insane thing to do. Uber, famously, wrote a blog post where they said that they were moving away from microservices to adopt "Domain Services", in which they rediscovered things like bounded contexts, and autonomous components, and all the other stuff they'd ignored the first time around.

Where does that leave us?

Pretty much where we've always been. Start with a monolith. When you realise that you need to introduce another axis of change, because of throughput, or stability, or release velocity, or sheer bigness, separate services out. Build those services around business capabilities, prefer smart endpoints and dumb pipes, and pay attention to boundaries and contract evolution. Don't build a thousand tiny things. Don't mistake autonomous components for standalone services. Don't use RPC.

How to Improve the Pull Request Process

ivan.gavlik — Wed, 05 Jun 2024 16:11:00 +0000

The pull request (PR) process is essential but often disliked. Despite its critical role in maintaining code quality, many developers find it frustrating. Let's explore common issues and solutions to make PRs more effective and enjoyable.

Common Issues with the PR Process

1. Focusing on the Developer Rather Than the Code

Reviewers often direct comments at the developer instead of the code. Using second-person pronouns like "you" or "your" can make comments seem personal and toxic. Instead, focus on technical aspects and the code itself.

Solution:

Concentrate on the code, not the person.
Avoid personal pronouns; use objective language.

2. Skimming Through Reviews

Large PRs often lead to superficial reviews. It's easy to overlook issues in big chunks of code.

Solution:

Break down large PRs into manageable pieces.
Allocate focused time (25-45 minutes) for thorough reviews.
Encourage collaborative code ownership.

3. Writing Ineffective Comments

Comments can be subjective, unclear, and lack actionable outcomes.

Solution:

Be objective: Explain why changes are needed with clear, factual reasoning.
Be specific: Point out exact lines or methods.
Focus on outcomes: Use the Triple R pattern (Request, Rationale, Result).
Labels for Comments:

needChange: Minor changes.
needRework: Major changes requiring discussion.
nitpicks: Subjective comments that don't affect functionality.
TODO: Conventional comments for future work.

Example:

Can we move this method to Class AX? Similar methods are in Class AX, consolidating them will streamline business logic processing.

4. Not Being Your Own First Reviewer

Authors should review their code before submitting it.

Solution:

Use draft PRs to self-review and refine code.

5. Not Using Automation

Automation can catch lower-stakes issues before the review.

Solution:

Implement linting, formatting tools, and static analysis.
Ensure tests pass before submitting PRs.

6. Unmanageable PRs

Large, unfocused PRs are difficult to review.

Solution:

Make PRs narrow and specific.
Focus on atomic changes.
Split large features into multiple smaller PRs.

7. Treating PRs as Mystery Novels

PRs should be clear and informative.

Solution:

Provide context and a clear title.
Explain the purpose and changes in the PR description.

8. Taking Feedback Personally

Feedback is an opportunity to improve, not a critique of your abilities.

Solution:

Embrace feedback as a team effort to enhance code quality.

Additional Tips

Create a Team Working Agreement: Define coding conventions and processes, and establish a "definition of done."
Use PR Templates: Standardize PR descriptions for clarity.
Auto-Assign Reviewers: Ensure timely reviews.
Celebrate Code Complements: Recognize good work.

By addressing these issues and implementing these solutions, we can improve the PR process, making it more efficient and less stressful for everyone involved.