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.

We use Jay Fields' Expectations library very heavily for most of our testing needs. We use clojure.test only for our Clojure-powered WebDriver testing. Leiningen has a test task built-in and we had been using lein-expectations for years. It was quite a shock to find out that Boot has no testing tasks built-in!

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.

We switched from Leiningen to Boot. What is Boot and why did we switch?

Leiningen

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?

Yup, blown away again. Alex Miller and his team have created an iconic event that crosses technology boundaries and bridges between academia and industry, to bring some of the brightest minds together to share their ideas. And for attendees too, the opportunity to meet a huge variety of our peers - from novice to expert - in all different technologies, creates an atmosphere of excitement, wonder, and enjoyment.

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?". The key considerations here are "enterprise application" and "Java web devloper, using JPA, JSF etc". Clojure is rightly praised for big data projects, simplified concurrency due to immutable data, and the conciseness of its solutions. The general advice when introducing Clojure to an organization is to take a grass roots approach: use it for some tooling first, or a small low-risk (but perhaps high-profile) project and show how well it works in a Java-dominated world. Then you get more and more developers trying it out and gradually the organization adopts it for more and more projects. It's good advice, and it's often how Clojure has crept into Java shops so far (as opposed to those fast-moving small shops that already have a tendency toward polyglot development).

The first annual Powered by JavaScript conference, organized by Manning Books, took place in St Louis this past week. How did this inaugural event work for someone like me who really doesn't JavaScript?

I'm fairly public about my dislike of JavaScript - and it's an easy language to take pot shots at. Indeed, in the following two days of The Strange Loop conference, several speakers reminded us why JavaScript's flaws have led to so much innovation in both the compile-to-JS ("altJS") and the native JS framework space. Despite the (many) flaws, JS is ubiquitous and has evolved from a hastily constructed scripting engine to become the powerhouse of the modern web and with Node.js has moved into the server side development space and as a common part of a build chain that touches almost every web development shop, regardless of their core technology.

Adapted from a post I made on my old blog in January, 2014, about the first few workshops being planned.

I've been an advocate of diversity in IT for a long time. I'm very pleased to work in a company that has an above average ratio of female to male employees, as well as very diverse cultural backgrounds amongst our staff. In most tech communities, diversity is pretty low. It's why organizations like RailsBridge and Women Who Code and numerous others exist. The lack of diversity hurts us all because a homogeneous community doesn't have diversity of thought either: diverse teams outperform homogeneous teams.

Originally posted on Google Plus on June 14th, 2014.

Why Java 8 might win me back...