This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-23
Channels
- # announcements (5)
- # babashka (22)
- # beginners (240)
- # calva (51)
- # clj-commons (1)
- # cljsrn (9)
- # clojars (12)
- # clojure (81)
- # clojure-australia (2)
- # clojure-europe (40)
- # clojure-france (10)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-uk (37)
- # clojurescript (59)
- # clojureverse-ops (2)
- # copenhagen-clojurians (1)
- # cursive (9)
- # datomic (18)
- # emacs (12)
- # fulcro (24)
- # graalvm (48)
- # hyperfiddle (5)
- # introduce-yourself (1)
- # jackdaw (1)
- # jobs (2)
- # juxt (8)
- # lsp (25)
- # malli (8)
- # missionary (1)
- # music (3)
- # off-topic (32)
- # polylith (16)
- # quil (4)
- # re-frame (52)
- # reitit (5)
- # reveal (3)
- # rewrite-clj (26)
- # rum (1)
- # sci (1)
- # shadow-cljs (14)
- # sql (2)
- # tools-build (40)
- # tools-deps (14)
- # vrac (2)
- # xtdb (63)
light blue touch paper and stand well back... https://neverworkintheory.org/2021/09/16/analyzing-the-effects-of-tdd-in-github.html
paywall means i can't read what they actually did, so i know whether to believe it or not
From the abstract, the metrics that they reference seem largely quantitative. They do not concern e.g. the quality of issues recorded. Perhaps the TDD projects had largely the same number of recorded issues, but the content matter of those issues were âpastâ the issues that theyâd caught already using TDD?
Though, qualifying quality and comparing it across such different project is a problem that I wouldnât know how to attack đ
One could also argue that number issues is not the only important/expected effect of TDD. Smaller, more decoupled classes and thus lower case of maintenance are. However whether that materializes in any extent is an open question. Also, given, "very few projects actually use it" - how statistically significant can it be? It would be worth a qualitative study to look at the actual effects (or lack thereof) of TDD.
Morning! Iâve just been a co-pilot in configuring a simple service with AWS Fargate. Iâm not a devops type of guy, so very happy I got expert help. But Fargate seemed nice enough.
i've not tried fargate... but we use EKS directly, and it's nice - that your containers get a routable IP in your VPC (rather than only in some private network overlay) makes life so much easier
Revised my opinion on Kubernetes lately and migrated all of our applications to DigitalOcean K8S. It just improves CI/CD so much. The learning curve is steep, but now that itâs running, itâs just so easy to add new things to it
Turns out, the complexity that confused me was AWS, not K8S đŹ Although Fargate looks less complex, now
đŻ k8s is great - the small-verb-set acting on open-noun-set works very well
the operators which fall out of the approach make complex things quite simple
My happiest devops moment was when m we moved off the overly-complex-for-our-needs K8s to the simpler and fully managed Fargate
@holyjak I'm all for good qualitative studies. I think we just need to be careful about the claims we make about TDD.
I donât see TDD as a guarantee of any quality that you wouldnât have otherwise, just as a method of development that might suit some, and not others.
I agree w/you, but that isn't my whole understanding of what some promise with TDD
Our first Clojure Prod app is now running on Java 17. We just switched the image which builds the app and the base image for our Docker Images, and that was it, no additional work. The Java apps howeverâŠ. đ©
I recently did the same and was interested in memory usage on JDK 17, but couldnât get clj-memory-meter to work on it (it worked fine on Java⊠whatever I was on before, 13 I think).
I heard that, too, but cannot confirm or deny it, unfortunately. I guess I could do a testrun with visualvm
Does it matter much? Most times cpu is tied to memory anyway, and most times the cpu is the limiting factor. But I guess gc would also be faster? So less spiky response times.
On the cloud, memory is the limiting factor, at least it is for us. If we were able to run our pods with a lower footprint, we might save money.
(And experimenting with the GC is also on my List. Shenandoah looks promising)
@javahippie Care to share? Do they use the forbidden fruits of sun.misc etc?
Mostly Illegal reflective access by third party dependencies. Gradle is not there, yet, also. In one project there is an architecture test rule, that introspects code and checks for certain aspects, all using reflection
Spring MockMvc in tests also fails with InaccessibleObject. Half of the Java ecosystem needs to upgrade, it seems. And Iâm convinced there will be libraries out there, which are not maintained anymore or might not find a way to work without the now illegal reflective access.
https://github.com/search?q=%22JDK+17%22&type=issues If you search GitHub issues containing âJDK 17â, it gives some impression on the problem
When we went from JDK 8 to 11, we had to find alternatives for a couple of Java libs we used because they were slow to get compatible. The road block for us with JDK 17 is New Relic which hasn't even gotten itself "compatible" with JDK 16 yet because they relied so heavily on reflection to do all of their class instrumentation at startup. They say the 7.3.0 agent will be JDK 16 compatible and then they believe it will be a short gap to get to JDK 17 compatibility. We can't upgrade until that's done (and probably until they've had a few patch releases to iron out bugs and performance problems). The Clojure stuff all got shaken out very quickly in the move from JDK 8 to 9 so by the time we moved to 11 (and have since tested on 14, 15, 16, and now 17 locally), it was pretty smooth sailing.