Clojurians Log v2

Yeah, in France you need to go to a certified engineering school to get an engineer title. And for a school to be certified, it needs to follow a certain curriculum. I don't quite remember what was in it, but it requires a certain number of hours in math, physics, etc. Regardless of what kind of engineer it is (IIRC) As a result there's quite a few "programming" schools that don't deliver an engineer title, but instead a "Level A" which basically means "yep this guy studied programming for 5 years"

is there a clojure-based analytics for webpages? I am thinking it could be pretty simple: have a collection of accesses via ip address and page and also have a .js file that periodically polls to see who is currently live connected... it could probably all fit into a middleware (?)

I'm searching for the informal "Clojure FAQ" compiled from the mailing list archives. I think it was a gist? Or at least on github

Do you mean this one https://clojure.org/guides/faq or the “Rich Hickey said…” https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f ?

@vemv always takes me a while to find that second one — I should bookmark it!

the latter, thanks much!

I had it starred but stupid me kept using google instead of gist search

(I also had it starred but not with a name that I would have searched for it by!)

As a more interesting follow-up question, anyone has followed https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f#should-i-use-a-namespace-to-bundle-functions-to-model-a-domain-object-like-a-customer-or-product deeply? IME having written parentheses for a living for a number of years, nobody really implements this open, generic codebase where functions process open maps without a predictable schema. Even when using Datomic (which fosters a schemaless design), developers tend to expect, and ensure a fairly rigid modelling. e.g. I have a Product, a User, etc, and defns that precisely handle products and users. I don't have a defn that accepts an "anything" and smartly processes all the keys that may be present (with multimethods or such?)

Datomic isn’t really “schemaless” though, is it? You have to define all your attributes before you can insert data. Whereas Crux and some of the others (Asami?) do not.

true, but an entity can have any number of attributes, not a fixed set like in static typing

a bit like with spec: you describe the attributes, but not the entities as a whole (well, spec 2 let's say) as a closed world thing with a capitalized name

As someone who has maintained clojure.java.jdbc (and now next.jdbc) for many years, I’d say that level of DB interaction can be open and generic to a degree. You can’t just pour “any old attribute” into a SQL DB but you mostly don’t need any schema/type support for basic stuff, i.e., hash maps with “arbitrary” keys whose values are number, string, Boolean, date/time types.

(an approach we’ve adopted there to some degree is writing a loose Spec for a table’s row and extracting the keys from that Spec and using that to select-keys on write — the interaction of optional vs nilable is still kind of a pain, but you’re at the boundary of two systems so…)

I would say that we do have a lot of code that just deals with the keys it cares about and passes everything else back and forth untouched — which you could argue is “open, generic”.

This is only loosely related to your question @vemv, but I've wondered about this kind of "open" vs "closed" question myself in the context of deployments and systems as well. The "traditional" way to do deployments is very artifact-centric - compile the jar, throw it on to a VM or Docker container and then perform some kind of controlled restart of the system in order to make changes to the code. The idea is that the code to execute is "closed" - this machine doesn't execute any code except what I tell it to. However, one could imagine an alternate scenario where you just literally build your system out of a bunch of REPLs. VMs running continuously with a channel open to a trusted source hidden from the public internet (for the sake of argument I'm handwaving away security concerns/PLOP/etc) to receive new forms to evaluate. When you're ready to release your code, just redefine it. You may still need some kind of mount/`component` based system in order to ensure graceful termination of stateful resources when new forms come in on the wire, but I don't think there's anything in principle that prevents this kind of approach. Beyond the ease-of-deployment aspect, you also get the benefit of a running REPL that can execute whatever code other things interacting with the system need to. Again, you may need to take care with sensitive resources like databases and such. However, the idea of a system that can be recomposed at runtime into combinations of components that weren't even necessarily foreseen at compile time is extremely intriguing to me. It seems like it would make the idea of an "API" more or less obsolete, because instead of making calls to a "closed" collection of defined endpoints, you can be "open" and just... execute some code, which is sent on the wire... as data. A runtime-recomposable system like this could save tons of design and architectural work by just giving its users a simple collection of primitive capabilities of the production system and letting users compose them, Unix style, in a more expressive language than Bash. If you want to forbid some dangerous functions like shelling out, opening an untrusted connection, or whatever, you might build a detection mechanism that filters dangerous stuff out (and maybe even terminates the connection that the suspicious stuff came in from) and make sure to log every function sent in and called by these production REPLs. Not saying it wouldn't take work to ensure the security/stability of such a system, but in a trusted environment it could be extremely powerful. Plus, is it really that much worse than shipping around https://www.docker.com/ with every app, just waiting for an attacker to shell out to? Imagining scenarios like this is where I get kinda envious of Erlang-based systems, which seem leagues ahead of anything else when it comes to controlled redeploys and maintaining the liveness of the system. Joe Armstrong described what he called a https://joearms.github.io/published/2013-11-21-My-favorite-erlang-program.html which I think inspired a lot of this. Fred Hebert has https://ferd.ca/a-pipeline-made-of-airbags.html on doing this kind of REPL based deployment and how Kubernetes falls way short of where Erlang has been for decades.