Fork me on GitHub

Good Morning!


tl;dr TDD doesn't make anything better (defects wise)

🙀 2
👀 2

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?

❤️ 2

Though, qualifying quality and comparing it across such different project is a problem that I wouldn’t know how to attack 🙂


well, I think the quality metric they are using is the classic "how many issues"

Jakub Holý (HolyJak)09:09:12

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.

👍 2

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

Jakub Holý (HolyJak)10:09:41

My happiest devops moment was when m we moved off the overly-complex-for-our-needs K8s to the simpler and fully managed Fargate


We use ECS at work with a few fargate instances.


@holyjak I'm all for good qualitative studies. I think we just need to be careful about the claims we make about TDD.

💯 3

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

🍻 1

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


Would be interesting to hear if you can document decreased memory usage


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.

javahippie14:09:29;type=issues If you search GitHub issues containing “JDK 17”, it gives some impression on the problem

👀 1

I've had some issues with stack traces in CIDER. Anyone else had the same?


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.


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’ve read that there’s supposed to be some memory savings and I want them now!


I'm just about to try out our first port from java 11 to 17 on an application too


exciting times!