seancorfield/next.jdbc 1.0.0-beta1

next.jdbc -- the "next generation" of clojure.java.jdbc -- is a modern Clojure wrapper for JDBC. Beta 1 is now available to test -- only accretive and fixative changes will be made from this point on, so the API should be considered stable enough for production usage.

seancorfield/next.jdbc 1.0.0-alpha8

I've talked about this in a few groups -- it's been a long time coming. This is the "next generation" of clojure.java.jdbc -- a modern wrapper for JDBC, that focuses on reduce/transducers, qualified-keywords, and datafy/nav support (so, yes, it requires Clojure 1.10).

Daniel Compton has continued his excellent trend of writing an analysis of the State of Clojure survey comments and one of the comments in his Community section stood out for me:

"I suggest moving off of slack to a more accessible chat system. Losing history is a bad thing. Check out discord or matrix or gitter or mattermark or any other number of tools made for this purpose."

About a month ago, I was praising Chlorine, the new Clojure package for Atom and I've been using it, day-in, day-out, for all my Clojure development. On a Mac, that's straightforward because I start a Socket REPL on the Mac and I run Atom on the Mac so when I connect via Chlorine and issue the Chlorine: Load File command (via Ctrl-, f in my keymap), it sends (load-file "/path/to/file.clj") to the REPL, for the file being edited, and that is evaluated and loads the source from disk and compiles it. On Windows... Well, on Windows there are a few obstacles to this workflow.

The first obstacle (for me) is that clj doesn't run on Windows and that's what I use for everything Clojure on a Mac and on Linux now. There's a PowerShell implementation in progress but Windows has always been a bit of a second-class citizen so it's still a ways off. But Windows has WSL (Windows Subsystem for Linux) so I can and do run (user-mode) Ubuntu on my Windows laptop and I do all of my Clojure work on that...

I've been using the Atom editor for about two years now. I switched from Emacs after Clojure/conj 2016, having seen Jason Gilman's talk about ProtoREPL [video]. It may sound like heresy, but I'd never been happy with Emacs -- not 17.x back when I first started using it, not 18.x, not 19.x when I first stopped using it, nor 24.x onward when I came back to it after learning Clojure a few decades later. I built several configurations from scratch, I tried several "curated" configurations, none of them felt like "home". Emacs just leeched too much of my development time for my tastes. I wanted a simple, modern text editor, that offered a wide variety of "plugins" and supported all the languages I used, with a sane set of defaults. Atom -- with ProtoREPL -- seemed to be exactly what I was looking for!

And for two years, it has been my day-to-day development environment.

Rich Hickey gave a very thought-provoking talk at Clojure/conj 2018 called Maybe Not, where he mused on optionality and how we represent the absence of a value.

His talk covered many things, including how clojure.spec/keys currently complects both structure and optionality (and his thoughts on fixing that in a future version of clojure.spec), but his mention of s/nilable was what triggered an "ah-ha!" moment for me.

One of the more mysterious new features in Clojure 1.10 seems to be the pairing of datafy and nav (and their underlying protocols, Datafiable and Navigable). Interest in these new functions has been piqued after Stuart Halloway showed off REBL at Clojure/conj (video). Stu presented this functionality as "generalized laziness": datafy produces a "data representation" of things and nav lets you (lazily) navigate around that data.

The REBL "is a graphical, interactive tool for browsing Clojure data". And in Clojure we're used to the concept of "it's just data" so a graphical browser might sound useful but not exactly earthshaking. But REBL is just an example of what can be built with the new functionality in 1.10 and, indeed, Stu's claim of "generalized laziness" is well made but a little hard to grok until you actually build something with the new protocols and functions.

It has been a crazy busy year, both at work and personally, and it's hard for me to believe my last blog post was in April!

Clojure/conj is coming up fast and the schedule was posted today, which has made me even more excited about it. Here's a run down of the sessions I plan to attend -- I'll write up my thoughts on everything shortly after the conference.

With the recent arrival of clj and tools.deps.alpha as a "standard" lightweight way to run Clojure programs and the seed for tooling based on deps.edn dependency files, it's time to take a look at the terminology used across Clojure's various tools.

Running Java/JVM Programs

Sometimes you just can't help having a "random 3rd part JAR file" in your project. The best practice is, of course, to upload it to your preferred Maven-compatible repository via whatever service or software you use for all your in-house shared artifacts. But sometimes you just want to play with that JAR file locally, or you haven't gotten around to running your own shared repository.

If you're using Leiningen, you'll probably reach for the excellent lein-localrepo which lets you "install" your random JAR file into your local Maven cache (in ~/.m2/repository).