Clojure Concurrency Tutorial Available

Update: all six parts are now available. That’s over two and a half hours of Clojurey goodness.

Update: There are now downloadable versions available in wmv and mp4 formats in a variety of resolutions. Just click the download button by each module. Also, the refs module is now up.

A while back, I wrote up some slides on concurrent programming in Clojure that I used at a DC ALT.NET presentation. Since I had them ready, and since Pluralsight has a great infrastructure for doing online training (it’s called Pluralsight On-Demand!), it made sense for me to record the content and make it available. So I have.

I’m happy to announce the immediate availability of the first four parts of my six-part Clojure concurrency tutorial, a screencast. You can find it here. It is freely available, and no registration is required. The final two parts will be available in less than a week.

I wrote the tutorial from the perspective of a .NET programmer who is new to Clojure. I don’t focus on the language itself, but rather the concurrency support in it. However, I don’t assume any prior knowledge of Clojure, so we start by covering just enough language syntax to get us through the demos. From there we dive into vars, atoms, agents, refs, promises, futures, and all sorts of good stuff.

If you’ve been reading my blog, you’ll know I’m a big fan of Clojure. One of the reasons for this - but not the only reason - is its fantastic support for concurrent programming. I like to say that it provides “sanity in the face of concurrency”. If you’re interested to learn more, check out the tutorial, and please – let me know what you think!

The Zero-Argument Overload of Any

I'm a pretty big fan of Linq. I use it all the time in my C# code. But it's a relatively big library, and I've never studied it exhaustively, so from time to time I come across some neat corner of it I've never seen before. In fact, that happened just the other day. 

I find that I'll frequently write test code that looks like this: 

Assert.AreEqual(0, collection.Count()); 

or the inverse: 

Assert.AreNotEqual(0, collection.Count()); 

I've done it often enough that I have thought I ought to write a pair of extension methods on Assert called IsEmpty and IsNotEmpty. That's probably still a good idea, but it also turns out that the Linq extension method Any (normally used to test if at least one element of an enumeration meets some criteria) also has a zero-overload method that simply returns true if the enumeration has any elements at all. So I could rewrite the above tests as: 

Assert.IsFalse(collection.Any());

and

Assert.IsTrue(collection.Any());

respectively. While having Assert.IsEmpty and Assert.IsNotEmpty extension methods would be better (perhaps your test framework already provides them), this is still a handy little thing to know about.