Clojurians Log v2

That’s a good point, thanks! I guess it is not too far of to assume, that there might be multiple classloaders at work when connecting Cider to a REPL… :thinking_face:

Is there anything in the Clojure ecosystem approaching an auto-generated admin web interface, à la Django or JHipster?

For read-only tasks you could use Metabase, I'm not aware of any solutions providing R/W access.

I've used retool and react-admin via a REST interface for this sort of thing.

Does anyone have a source for "don't write wrapper libraries that are thin wrappers around Java unless you're adding value", I want to use some appeal to authority :)

I think I remember @hiredman saying something like that a few times.

Similar quote

Because the Java invocation syntax in Clojure is clean and simple, it's
idiomatic to use Java directly, rather than to hide Java behind Lispy wrappers.

another one

Clojure embraces Java and its libraries. Idiomatic Clojure code calls Java
libraries directly and doesn't try to wrap everything under the sun to look
like Lisp. This surprises many new Clojure developers but is very pragmatic.
Where Java isn't broken, Clojure doesn't fix it.

this was the primary feature of the defunct Caribou project (what I worked on at my first ever Clojure job ages ago...)

personal experience: it's like a framework, it works perfectly until you leave the original author's happy path, then you need to fork it because they misunderstood or incompletely covered the underlying API

doing interop in the first place is less work than maintaining a fork of a thin wrapper

also the wrapper adds layers / complexity

Wonderful, thanks :)

it totally depends. wrappers can give idiomatic access while leaving the Java world open for extension

right - ring for example

@noisesmith Exactly right. Even just minor things like spending 30 minutes wondering why a property that's clearly in the libs docs isn't being applied until you reason the wrapper is shit and only passes along the 3 keys that the original author cared about. /tableflip.

but I haven't seen this for thin wrappers

Ring is not a thing wrapper - it's a unique abstraction :)

@dominicm What wrapper is this about?

@borkdude just some react component that's pretty thin when used from Helix anyway.

ok. what I had in mind, e.g. babashka.process: https://github.com/babashka/process it's a convenient way of creating processes from Clojure while still having access to the raw underlying java stuff

That's not thin. It's a little bit of an abstraction. Like a cracker, but not quite a biscuit.

though ideally I wouldn't have to, the node process should be able crash without clojure sticking around

@timsgardner Babashka supports killing all sub-processes on shutdown. It has great startup time. So you could consider booting node from bb and then kill all on shutdown

I might switch to it, thanks

An example using clojure:

$ bb -e "(require '[babashka.process :as p]) (p/process [\"clojure\"] {:inherit true :shutdown p/destroy-tree}) @(promise)"
Clojure 1.10.1
user=> (+ 1 2 3)
6
user=> ^C%

You can also do this in Clojure proper btw, babashka/process is also available on the JVM. Or you could just write the JVM interop code yourself

ah, interesting! https://github.com/caribou

it's very old, and not under active development

yeah, might still be interesting to peruse and see the approach taken, as compared to the aforementioned frameworks

the general idea was defining the content of the site via database, then using DB CRUD to control what's displayed

use case was the end user has content admins who could be trained to use the admin UI, with the power to create new assets paths and layouts via DB upload without dev work

yeah, that sounds quite similar to what Django was originally envisioned to do, actually

the original sponsors ended up switching to squarespace

yeah, django was definitely an inspiration

I have no clue how many deployments kept the auto admin interface, though, versus rolling their own

@jeffrey.wayne.evans one example of an idea from that project that could be imported elsewhere: using a db data model for paths, and then consuming that in the back end to create a router

Does anyone have any experience with jdbc / mysql here? Namely I have an issue where after some time of inactivity, and then again trying to connect to the database .. it fails with a Operation timed out (Read failed) . I’ve been trying to find a way to configure it to reconnect on timeout, but haven’t yet found a way. Does anyone have any ideas?

#sql is your best bet as a channel for that Q @asko

Ah, didn’t know of it! Thank you for pointing me in a direction :)

I like wrapper libraries. I have written many which I would characterize as thin but add a modicum of value. There are many situations where Java libraries have unwieldy class structure and wrapping eases the pain.

I really don't like when engineers create context-free edicts for all to follow. We don't need that much religion.

This is a good point and puts the quotes into context. Obviously if your wrapper provides some tangible benefits outside of just hiding Java interop, then it adds value. The point of the quotes are rather: Java interop by itself is both idiomatic and ergonomic and doesn’t require wrapper per se.

I agree, I have moved away from clj-time, but more importantly java-time , for example, and prefer java.time access via interop.

I don't have one either, was just curious.

By the way, I don't know if it helps. But where I've landed with my experimentation is something very similar to how symbols and namespaces work. I quickly details it here: https://clojureverse.org/t/spec-ing-entities-and-how-to-organize-the-specs-and-our-entity-keys-a-new-approach/6817/8?u=didibus

This is a very informative discussion! It particularly reminded me of a recent case where I recommended not returning AWS data *Response Java objects from functions, but rather converting them to Clojure maps. Does the maxim discussed here suggest that that was wrong? In other words, does the interop argument extend to directly working with Java data structures (in object hierarchies), rather than wrapping them in a thin Clojure data translation layer? How about when all the operations and data involved are limited to a single namespace?

the watershed line is if the wrapper is an external dependecy

bringing in an external dependency that doesn't justify itself is bad, and wrapping is no justification

for internal stuff the question is a lot less clear cut