An interesting Clojure question came up on Quora recently and I decided that my answer to “how do you use clojure.spec” there should probably be a blog post so that folks without a Quora account can still read it. [If you do have a Quora account, feel free to read it there instead and upvote it!]

Lots of Releases

Over the last week or so I’ve released minor updates to several of the projects I maintain, so I thought it would be nice to have a summary blog post rather than a scattering of minor announcements.

clj-time 0.15.2

Add type hints, fix a bug in overlaps?, improve tests and documentation.

See the change log for more details.

jkk/honeysql 0.9.5

Support JDK11 for dev/test, support Turkish language users, enhance format-predicate to match format (parameterizer).

See the change log for more details.

seancorfield/clj-new 0.7.7

Pin Clojure (and test.check) version in generated projects instead of using "RELEASE".

See the change log for more details.

seancorfield/depstar 0.3.1

Add -m / --main option to override Main-Class in generated manifest.

See the change log for more details.

seancorfield/next.jdbc 1.0.5

plan’s “mapified” ResultSet is now a full IPersistentMap implementation which adds support for cons, count, dissoc, empty, etc. Continued improvements to documentation.

See the change log for more details.

next.jdbc 1.0.0 and 1.0.1

First off, seancorfield/next.jdbc 1.0.0 was released on June 13th, 2019 (and I announced it on ClojureVerse but did not blog about it), and yesterday I released seancorfield/next.jdbc 1.0.1 which is mostly documentation improvements.

Someone recently commented that this blog had the Release Candidate announcement on June 4th and was surprised I didn’t “make a big deal” about the “gold” release. The 1.0.0 release is a big deal and this blog post is about that – what it’s taken to get here and what’s to come.

seancorfield/next.jdbc 1.0.0-rc1

next.jdbc – the “next generation” of clojure.java.jdbc – is a modern Clojure wrapper for JDBC. The first Release Candidate is now available to test – containing only accretive and fixative changes from Beta 1. The API should be considered stable enough for production usage.

https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-rc1/doc/readme

The focus of this release is providing more flexibility in result set builders, so that it is easier to implement your own naming strategies, via new builders that accept :label-fn and :qualifier-fn options. These mirror the :column-fn and :table-fn options used in next.jdbc.sql – which are updated versions of clojure.java.jdbc’s :entities option. These new builder options are updated versions of clojure.java.jdbc’s :identifiers option.

Changes since Beta 1

• Fix #24 by adding return type hints to next.jdbc functions.
• Fix #22 by adding next.jdbc.optional with six map builders that omit NULL columns from the row hash maps.
• Documentation improvements (#27, #28, and #29), including changing “connectable” to “transactable” for the transact function and the with-transaction macro (for consistency with the name of the underlying protocol).
• Fix #30 by adding modified variants of column name functions and builders. The lower variants have been rewritten in terms of these new modified variants. This adds :label-fn and :qualifier-fn options that mirror :column-fn and :table-fn for row builders.

Please take it for a test drive and let me know if you run into any problems via GitHub issues or in the #sql channel on the Clojurians Slack or the #sql stream on the Clojurians Zulip.

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.

https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-beta1/doc/readme

The group and artifact ID will remain seancorfield/next.jdbc, the namespace structure will remain next.jdbc.*. With auto-generated documentation hosted on cljdoc.org and Continuous Integration testing hosted on circleci.com, I have decided to continue work on next.jdbc outside Clojure Contrib, rather than merge it into clojure.java.jdbc as new namespaces there. I have updated the Contributing page on GitHub to reflect that Pull Requests can now be submitted.

Changes since Alpha 13

• Set up CircleCI testing (just local DBs for now).
• Address #21 by adding next.jdbc.specs and documenting basic usage.
• Fix #19 by caching loaded database driver classes.
• Address #16 by renaming reducible! to plan (this is a BREAKING CHANGE! from Alpha 13 – the naming of this function was the blocker for moving from Alpha to Beta).
• Address #3 by deciding to maintain this library outside Clojure Contrib.

Please take it for a test drive and let me know if you run into any problems via GitHub issues or in the #sql channel on the Clojurians Slack or the #sql stream on the Clojurians Zulip.

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).

https://cljdoc.org/d/seancorfield/next.jdbc/1.0.0-alpha8/doc/readme

The next generation of clojure.java.jdbc: a new low-level Clojure wrapper for JDBC-based access to databases. It’s intended to be both faster and simpler than clojure.java.jdbc and it’s where I intend to focus my future energy, although I have not yet decided whether it will ultimately be a new set of namespaces in the Contrib lib or a separate, standalone OSS library!

At this point, I’m looking for feedback on the API and the approach (as well as bugs, performance issues, etc). Please take it for a spin and let me know what you think via GitHub issues or in the #sql channel on the Clojurians Slack or the #sql stream on the Clojurians Zulip.

The group/artifact ID will change at some point: and the actual namespaces will too, but I will try to make that as painless as possible when I take this out of the alpha phase.

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…

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

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.