The larger an organisation is, the more decisions on tooling are fixed. So I was expecting many battles of persuasion, but it turns out many things were much easier than expected, especially getting our favourite development tooling accepted. Building a streamlined development and deployment pipeline for Clojure was a bit more challenging, especially due to the constraint on using a specific CI server. We experimented with the Netflix approach to continuous integration and using Maven (without much XML).
Encouraging other teams to adopt Clojure has changed our developer tooling, as I wanted to make the gap to Clojure as small and manageable as possible. This involved reviewing the merits of IntelliJ, Atom, Visual Studio Code and of course Emacs from the viewpoint of the corporate developer.
Arguably the biggest technical challenge was the corporate firewall itself, especially when it came to downloading Clojure libraries only on Clojars.org. We found two solutions, one very hacking and ultimately failed, the other was trivial and worked perfectly.
So come along to the event and discover what technology stack we are using, our different development tooling choices, how we build our Clojure apps, how we got other teams to build Clojure apps and generally manage a Clojure application that processes millions of transactions a day across the world.
John is a speaker, author, conference organiser & community obsessed developer. Loves Clojure, Emacs, Cats, Cycling & Agile development.
He is a conference organiser for Clojure Exchange, London Java Conference, etc) with 20 years of speaking experience.