Back in February I talked about boot-new and talked about a “future 1.0.0 release”. We’re not there yet, but generators got added in release 0.4.0 and, in the four minor releases since, the focus has been on refactoring to match the core Boot task structure and improving compatibility with Leiningen templates. At World Singles, we’ve continued to extend our usage of Boot until we have only a couple of Ant tasks left and we expect those to be within Boot’s reach soon. In this post, I want to cover some of the things we’ve been doing with Boot recently.
In my previous three blog posts about Boot – Rebooting Clojure, Building On Boot, and Testing With Boot – I looked at why World Singles decided to switch from Leiningen to Boot, as well discussing one of the missing pieces for us (testing). Once I had boot-expectations written, I was casting around for other missing pieces in the ecosystem and one glaring one was the lack of something to generate new projects from templates.
In Building On Boot, I gave some high level benefits we’d found with Boot, compared to Leiningen, and how it had helped up streamline our build process. That article closed with a note about Boot not having the equivalent of common Leiningen plugins, and that’s what I’m going to cover here, since that was the first real obstacle we encountered.
In yesterday’s blog post, Rebooting Clojure, I talked about our switch from Leiningen to Boot but, as Sven Richter observed in the comments, I only gave general reasons why we preferred Boot, without a list of pros and cons.
Over the coming weeks, I’ll write a series of posts about some of the specifics that worked better for us, as well as some of the obstacles we had to overcome in the transition.
In this post, I’m going to cover some of the pros at a high level as it improved our build / test process.
I did not intend to stop blogging in 2015 but that’s certainly what it looks like here!
So what kept me so busy that I didn’t get around to blogging anything?
I’ve often said that I try to follow The Pragmatic Programmer’s advice to learn a new language every year. I don’t always achieve it, but I try. As I’ve settled into Clojure as my primary language over the last several years, I’ve made a fair attempt to learn Python, Ruby, Racket/Scheme, Standard ML and more recently Elm. I learned that I like Python, I don’t like Ruby, Racket/Scheme is “just another Lisp” (I already have Clojure) and SML is very interesting but not really widely useful these days (it’s a great language for learning Functional Programming concepts tho'!). I also spent some time with Go last year (don’t like it).
The Elm language is really nice - and useful for building interactive browser-based applications (and games). I’ve been meaning to blog about it for quite a while, and I hope to get around to that in due course. Elm is sort of inspired by Haskell, and that’s really what this blog post is about. Sort of.
Last week I attended The Strange Loop in St Louis. I attended in 2011 and was blown away. I missed 2012 but attended again in 2013 and was blown away once more. I already have 2015’s dates in my calendar. How was 2014?
This was originally posted on corfield.org back in April 2013 and I noticed it was recently referenced by Eric Normand in his recent blog post Convince your boss to use Clojure so I figured it was time to update the article and bring it onto my new blog.
A question was asked in early 2013 on a Clojure group on LinkedIn about reasons to migrate to Clojure for enterprise applications in a Java shop. It’s a fairly typical question from people in the Java world when they hear the buzz about Clojure, and of course asking the question on a Clojure group garnered a lot of positive responses about why Clojure is a good choice. I didn’t feel anyone had really addressed a core aspect of the original question which was, essentially, “Why should I, as a Java web developer, using JPA, JSF etc, choose Clojure instead for an enterprise application?”.