Clojurians Log v2
clojure-uk
Good Morning!
Mornin'
Does anyone know the current situation with json-schema? When I last used it (several years ago) the spec was underspecified and lots of implementations were incompatible. In particular JSON pointers were a bit of a nightmare. Have things improved?
A little
Someone took the helm again and pushed v8, but I've not followed since then
it's okay, but recently I've found typescript interfaces at the edge of our system have solved that problem better, with better integration and editor tooling & it's faster too
You'll struggle to share TS definitions across network boundaries though. JSON schema is a tool of communication.
true, I guess depends how much of your domain is in your control
atm working on a system that's backend and very much glue so we don't have to share our defs with e.g. a frontend
although if they were TS I think we'd monorepo nad share the defs that way
Morn’
Hello Alll 🙂
Does anyone happen to know how to update the exec-path in Spacemacs flavoured Emacs..?
I have never had to do it before, but suddenly, on my work machine (Ubuntu 20) Emacs is no longer seeing my ~/bin folder which is where I put lein
(also, I'ved not had to use lein for a while as I was all tools-deps all the time, but I've been overruled by my team and we are back to Leiningen) (I don't care, I just can't cider-jack-in to the prototype I am working on because of this exec-path stuff)
do you use the exec-path-from-shell plugin? that seems to mostly sort it out for me
Thank @alex.lynham - I will look at that, sounds like a plan
Odd question - anyone else getting an aleph error when trying to evaluate a namespace where [yada.yada :as yada] is in the :require..?
If I comment it out, clearly no errors, but I want yada in that namespace
This is why I should have learned about Java properly, this stacktrace is mental and it appears to be to do with a transitive dependency to the library I am trying to use... https://gist.github.com/maleghast/3cfb6b8a7da2d648b87c6fcf43f148f5
Does anyone have any idea what is goin on there ^^
Looks like a Java 9+ compatibility issue with one of the libs you are using, or maybe how your REPL is getting started?
javax.xml.bind.DatatypeConverter is one of the usual culprits in Java 9+ issues regarding bootclasspath or something like that...
Oh... Yeah, I am using Java11
How would I fix that, without going back to Java8?
More importantly, how do I get Yada to be compatible with a more up to date JVM than Java8 - I love the way that Yada works, but I am not comfortable relying on a JVM that is about to EoL
@seancorfield - FWIW I switched back to Java8 and the code runs, so I am now pretty sure that you are right
XML is treated as a seperate module in Java 9that you have to turn on as a commandline switch
now if only I could remerber what that was
Meh unfortunately I have that stuff on Ubuntu; and I'm booted into Windows for current client work
it was also possible to solve by including java xml dependencies into lein/deps/mvn to bring the processing code into your main user space
something like
java --add-modules java.xml:jdk11
{:extra-deps {com.sun.xml.bind/jaxb-core {:mvn/version "2.3.0.1"}
com.sun.xml.bind/jaxb-impl {:mvn/version "2.3.0.1"}
<http://javax.xml.ws/jaxws-api|javax.xml.ws/jaxws-api> {:mvn/version "2.3.1"}
javax.xml.bind/jaxb-api {:mvn/version "2.3.0"}
javax.activation/activation {:mvn/version "1.1.1"}}}since I'm here
Ooh, thanks @ben.hammond 🙂
🙂
The stacktrace suggests it's Aleph, specifically. Which is pretty much no longer maintained?
(and Yada uses Aleph)
I'm surprised at this point it hasn't all been updated to work properly with Java 9+ tho'... although we ended up switching a couple of our Java library deps because they were taking so long to fix Java 9 compatibility issues in the end 😐
Ah, bummer... I did not know that Aleph has become abandonware - it always struck me as a great library
Thx anyway @seancorfield
I'll drop Malcolm a DM and ask him if there is a plan, and if not see if we can fork our way to a working version, even if that's some work... 😉
I will check to see if that works - does this mean that the fix is in Yada, or has Aleph been updated to work on an "unstable" branch that is actually stable?
Also, thanks @dominicm
So there are plans to get to a 1.0 but it sounds pretty minimal.
Crikey! Thanks for the info @seancorfield - I am stunned, Aleph always seemed to me that it would be around forever; such a shame... I wonder if this is all part of Zac falling out of love with Clojure... 💣
I like Zach, he's really smart, but his projects have nearly always seemed really... weird...
Yeah, no doubt...
What are people using instead of Yada these days then..?
As I just said in another window, I've not had to develop something from scratch for a good long while and this experience has uncovered some concerns to say the least...
I would like to carry on using Bidi / Yada as I like the way that they work together, but the reliance on Aleph and Aleph having an uncertain future makes me wonder what others in this community have been "picking" if they are starting a new project in the last few weeks / months...?
I've never needed anything more sophisticated than Jetty, to be honest. Although we have one system at work that has been built directly on Netty via Java interop in two of its incarnations over the years.
We ran http-kit in production for a while, but New Relic didn't support it very well so our metrics were sub-optimal. So we switched (back) to Jetty, which we'd originally used but abandoned due to random thread death errors (which got fixed by the time we went back to it).
So are you just using Compojure @seancorfield..?
Bidi on one service (built on Jetty). Compojure in everything else, except the one Netty-based service.
I mean I think that Yada could be re-tooled to run on Jetty as the server, although a lot of the async stuff would be problematic...
Bidi -> Bare Ring Handlers or are you using some other abstraction over Ring?
Ring is a perfectly good abstraction IMO. Clean, simple, obvious. And it does have async support (although it's a bit limited, I gather -- we've never used it).
@maleghast That’s a shame he’s not so into it any more, I was a big fan of Elements. Has he written anywhere about why he moved away from it?
Yeah, I am absolutely not dissing it, I think that Ring is amazing, I just got used to Yada and the extra bits of convenience and power I got out of it.
I started building REST APIs in Clojure with Liberator and Yada was a nice middle ground of power and features without being as complex to work with as Liberator
Clojure I mean, not Aleph
@allaboutthatmace1789 He has talked about, yes. I don't have specific links to his reasons. Part of it was due to his work on tuples being rejected/rewritten by Rich after he (Zach) had put a lot of work into.
I could go back to Liberator to get the REST API structure stuff and to be honest there is an attraction in the strictness of that
We're happy enough with Compojure for a REST-like API without all the bells and whistles.
I realise it's not a like for like comparison, but I used to build APIs on Rack in Ruby, and that's like rolling one's own just on Ring in Clojure, so it should feel pretty comfortable for me, I really think that I just got spoiled (in a good way, again not a a criticism) with what Yada did for me.
I looked at Yada at one point and it just seemed like too much "magic" going on if I recall...
@allaboutthatmace1789 -Yeah the impression I got is that he changed jobs and was upset by the way his work on tuples was treated by the core committers and just decided to pursue other interests. Clearly I don't want to speak for him, and I am sure he'd be prepare to tell you himself. I agree about Elements of Clojure by the way, really great book.
(and maybe that was because it was built on Aleph/Manifold)
Several people who were very active in the early days have left the community (and the language) after disputes about stewardship of the language -- and I must admit, I clashed with Rich and some of the other core committers occasionally in the early days, but I ultimately accepted it's Rich's project and he's going to run it the way he wants and if you're going to contribute, you just have to get on board with that.
In a decade of using Clojure, I've had one tiny little patch accepted into Clojure itself, and I've contented myself with maintaining a lot of projects -- some in Contrib, some outside.
Yeah, I can see that being the impression for sure - there was a learning curve in adopting it, but the payoff was automatic content-negotiations, good boundary hygiene around what resources could be used for and best of all the whole API was decoupled from the routes / routing.
I've gone back and looked at Compojure and I have to admit that there is clearly an argument for a different kind of ease of use there, and let's face it it's very widely used so it's widely understood which is not nothing.
Overall I am wondering if it's worth worrying about doing anything other than Compojure / Compojure-API
If I needed the whole content negotiation thing and/or auto-generated API docs, I'd look at a more sophisticated library that handled that stuff.
But I really do like simplicity in libraries and I'd prefer to compose several small, independent things if I could, rather than adopt something all-purpose.
nods
I haven't used this library myself but I saw a great demo of it at clojure north last month https://github.com/metosin/reitit https://github.com/markbastian/clojure-north-2020/blob/master/src/clojure_north_2020/ch03_web/x04_reitit.clj
I am eyeing up reitit from metosin as an altgernative to Yada and Bidi, in that it has a bidirectional routing approach like Bidi
@ssjoleary746 - LoL!
Ha!
Jinx!
Indeed
Thanks for the presentation link I am going to go check that out...
Yeah, I've never had the time or the chops (frankly) to get to a place where I was looking to try and contribute, so it's not touched my life... I am genuinely thankful that smarter people than me are there making Clojure the wonderful day to day professional programming experience. If i ever decided I didn't like it any more there are plenty of other languages I might consider, but the way that the project is run is not a factor in my feelings on the matter 🙂
I use reitit
works very well
I think yada works under java 11 as is on the latest alpha (Which is stable and should be cut as a release)
Yada handles a lot of http that ring doesn't. Or rather, ring is an abstraction over the http protocol, and yada is a proper implementation of http specs.
You should not be choosy about implementing specs. You should attempt to be comprehensive. Ring forces the developer to take care of all of that themselves. I think that's okay, but ring is too low level to be working at regularly. "Need" of compliance is a funny one, because your clients (not you) care about you being compliant.
It's probably also worth pointing out that browsers, proxies, and CDNs can all conspire to break HTTP requests that are not just GET/`POST`/`HEAD`/`OPTIONS` -- so PUT/`PATCH`/`DELETE` cannot be assumed to work universally, which means the HTTP spec is not as useful as some people think 🙂
(updated to say "CDNs" instead of "load balancers" now that I've remembered it was CloudFront that caused us some pain there, not the F5 Big-IP 🙂 )
Broken proxies break http? Shocker :)
(and, no, I no longer remain exactly what that pain was, but it was enough of a problem that we quickly abandoned put/patch/delete as universally viable HTTP verbs)
CDNs don't make sense on that list really. You don't control those, and you can't make those kinds of requests to them.
Our customer base is global, many in Africa and the Middle East, so strange browsers/devices and nasty proxies are bread and butter for us, unfortunately.
Browsers work fine with all the methods afaik anyway. Never heard otherwise. There's limits to the methods available in forms, but there's other details behind that.
Maybe partially implemented browsers on old devices or something?
As in, pre-smartphone
I can't remember exactly how the CDN played into the equation now. But it was a contributing factor.
Content negotiation is still valuable regardless. Having language automatically managed correctly according to browser headers is a win. Same for things like encodings for reducing bandwidth use.
Or setting vary headers, so caching proxies behave correctly.
(we are somewhat "saved" by having our REST-ish API only called by our own React.js SPA -- if we had a public REST API, I would want more HTTP compliance)
I think the web is missing a high level http client that assumes things like caching are implemented, and allows you to skip a bunch of steps even for internal applications.
Eg knowing that 400 means client error, and handling the form appropriately
Yeah, given what we try to do on the web these days, it often feels like we're shoehorning a lot of stuff into what was originally a very simple text-based protocol 😐
I think the goal was always accretion. A surprising amount of stuff is in the early specs. Including caching and proxy headers.