Particularly interested in:
- developer acceptance (unless they were already all clojure guys?)
- training materials
- changes to devOps.
Particularly interested in:
- developer acceptance (unless they were already all clojure guys?)
- training materials
- changes to devOps.
It's hard to know where we started seriously advocating a move to Clojure and where it was just our enthusiasm but we did quite a few things to sell it.
- A Clojure club where we booked a big meeting room and taught some of the basics of Clojure
- Buying a bunch of books and leaving them around the office
- Re-writing an existing service into Clojure as an example of how quick this was to do, and how nice the resulting code was (as a note we haven't gone back to re-write working services)
- High levels of enthusiasm and trying our best to make sure everyone got a chance to be included
At some point we decided that we had enough support to try things more seriously so we got all the devs together in a room and made a proposal to work on a few new services in Clojure. Having a Service Oriented Architecture actually really helps here as we didn't have to make too big of a bet. That was enthusiastically accepted by the team and from there we ended up writing more and more things in Clojure. A few people were more resistant than others and they stuck working on Java projects for longer. After a while though curiosity or necessity led to them working with Clojure and they ended up convinced. I'm not aware of anyone now who isn't a fan.
Training was a combination of self taught, books and, later on, booking a 3 day, onsite training course from the guys at Lambda Next. This is something Cognitect also offer now.
From a dev ops perspective not much had to happen as our existing Java tooling continued to work. That said we have recently rewritten all our deployment tooling (in Clojure) to target AWS (and generally improve it in just about every way). We actually have a blog post due to be published this week talking about our new, Clojure based, tooling.
We did have a big meeting with all of R&D where we talked about all the pros and cons. Hiring was a big question early on although it's still my belief that using Clojure rather than Java is a positive in terms of attracting good programmers. I don't think we have enough data to answer that either way though.
I think that most important part was that we weren't betting the whole company on it. We were only betting a few weeks of developer time. If it didn't work out then the worst case was rewriting those services back into Java (in fact until recently we had a single Scala service from a previous experiment). Quite a few companies start off by writing some internal tooling in Clojure as an easy to stomach first step. That may be a good path if management are resistant.
- Joy of Clojure. I think a lot of people would say this was their favourite. It's less about learning Clojure and more about loving and writing good Clojure.
- Clojure Programming. There are mixed review on this one but I quite liked it as a reference book early on.
- Programming Clojure - Similar to Clojure Programming. Pretty good.
Thinking about it a lot of people also spent some time working through the 4Clojure exercises.
Personally I found that the only way to really get it was to jump in. We have a few early services that could perhaps do with a re-write but no real harm was done!