• Pimp My REPL

    Everyone knows Lisp programmers live in the REPL, and Clojurians are no exception. This is a tour of Clojure libraries and practices that make life in the REPL even more comfortable.

  • Developer Garage in Helsinki on 2014-03-05

    We are organizing a Coding Dojo at Solita's office in Helsinki.

  • Solita Dojo in Helsinki on 2013-10-23

    We are organizing a Coding Dojo at Solita's office in Helsinki.

  • Clojure world domination 2014

    Form follows function in great design. Interestingly we can now eliminate annoying barriers between data, form and function. The Clojure train is accelerating!

  • What's in a Good Commit?

    These tips can help you turn your VCS from a backup system into a valuable tool for communication and documentation.

  • Interdependent Build Pipelines with Jenkins

    When doing continuous delivery for multiple interdependent projects, each project's build pipeline needs to be parameterized with the version numbers and binaries of upstream pipelines. It's easy to do in Go, but Jenkins doesn't support it that well. Here is how I was able to twist Jenkins to my use case.

  • Our Faces Combined

    I wanted to check what an average Solita employee looks like. I had images of all Solita employees' faces, OpenCV-library, Python and some free time.

  • Refactoring Primitive Obsession

    Enriching the domain model by fixing Primitive Obsession code smells requires careful refactoring in small steps. Here I'm presenting some tips for doing that almost fully with automated refactorings, making it much faster and safer to do.

  • Value of Simplicity

    Seize the day and simplify your design. Finding a simple solution to a complex problem is one of the ultimate achievements. In this post I try to convince you and briefly touch the foundations on which one can build a simple solution.

  • Beyond cargo cult software design

    Programmers often reuse designs without questioning their applicability to the task at hand. A program whose design poorly matches its purpose is hard to understand, hard to test, and hard to change. Test-first development guides the design process towards better solutions by keeping it focused on the program's purpose, and by highlighting design flaws that lead to poorly defined components and rigid programs.