470 karma · joined November 20, 2014
[ my public key: https://keybase.io/napster; my proof: https://keybase.io/napster/sigs/1DYMjeTxF3HkRhxXM_0iHIP9wTgJl3Vb-sXCh57AQf8 ]
Then it's bad unnormalized data design that is the problem here. If that is a team level, it should be in the team table, not the player table.
More info: https://berto-meister.blogspot.com/2011/08/unintelligent-des...
Was quite a similar idea: load Playlist from Spotify but play the actual music from YouTube. Still proud of that one, good times when Discord was wild territory.
The end does not justify the means. Name me one single objectively bad political movement which internally thought of themselves as bad or negative. There isn't one. They all claim and for the largest part of their membership believe to serve the greater good. Therefore I find this argument of the author extremely weak. Surely they can come up with some less naive arguments?
testcontainers so I can write proper integration tests instead of mocking dependencies away.
AssertJ for fancy assertions with great failure messages.
Mockito for the rare mocking/spy usage.
Awaitility for the rare async/timing based test.
When there is a Frontend (templated or SPA, doesn't matter), I like writing the tests with Selenide assertions and using its Selenium integration to run against a large array of browsers + variants (Chrome, FF, Mobile etc) launched via testcontainers.
Hahaha...great choice of words for an article on functional programming =)
In any case, one of the large problems remaining is the bad discovery of stuff-it-can-do-and-how-to-configure-that, and making it too easy for devs to write imperative code when they should be staying declarative.
Also, I don't very much like how complicated some of the newer features are to use, and how much weird magic they require to be turned on / configured.
Another thing I absolutely hate is how it splatters the build scripts into half a dozen files. Personally, even for large monorepos or multi-module builds, I prefer to have one huge script file + plugins.
The strengths of Gradle, if the scripts are written properly, however are very clear to me:
- Task avoidance and therefore crazy good build speedup ofc that requires tasks to be well defined, ideally the whole project to be split up into smaller modules, and each of the build tasks being deterministic. unfortunately many devs don't understand how to do this, and some of the more exotic build steps in monorepos might not be properly deterministic (looking at you, frontend build tools)
- It can be wrapped around other langs and exotic build steps for monorepos. E.g. you can first fire up a database in a container, and run your migrations against that, then use the resulting schema to generate your database entities. In parallel, you might want to run some protobuf generation, that is then used by e.g. a Java backend and a JS frontend built that's actually using yarn in the background. There are plugins available that will wrap the yarn scripts to the Gradle lifecycles. The output of the frontend can be used to be included in the static files of your jar, which you can fire up for tests with browsers running in docker containers and doing e2e tests from the Java BE code, so you can do amazing test setups. Gradle can do all of that, with incremental builds / cached in- and outputs. Imagine having to keep all these steps in your head and running them on-demand when you think its necessary. Or running them every time no matter what (looking at you, Maven) Gradle allows me to write down all of these steps as individual, declarative tasks, making use of a vast and high-quality plugin ecosystem. Then wire up their order, again, declaratively. Once that is accomplished, I can turn off my brain and focus on building code and don't have to know which parts needs to run when exactly.
When I joined one of my previous teams, they were using a rube goldberg machine of Bash, AWK, Python scripts with a lot of JSON slurper and AWK sprinkled in to manage multiple modules in different repos into a monorepo-like state with individual releasing and versioning. With Gradle, that was much easier to accomplish: The dependency resolution rules could be written as simple code with easy and well defined conditionals, instead of manipulation of Maven pom files during random build steps. Also introspection into the build dependencies allowed an easy way to find out which projects dependend in which other ones. (Now was doing all of this a good idea in the first place? probably not :) but they certainly didnt allow themselves to be stopped by Mavens inflexibility, and the resulting horror of a build pipeline was certainly worse then writing all of that in Gradle)
In think, in the end, for small projects, Gradle isn't that benefitial. Maven can accomplish simple builds with no special rules and no necessary task avoidance just as well as Gradle, if not better due to the restrictions. But once you need to build something bigger (did someone say Enterprise?), Gradle starts shining - as long as you tread carefully.
Writing your own software, or just importing a lib, and the resulting side effects such as huge amounts of code to maintain or dependency hell, are tradeoffs - they are neither good nor evil - it all depends on the context.
I'd love to see an article from the author drawing from their experience on making that kind of decisions.
Yes, you can tell what I think about this article (and the one before it).
If your goal is to ship a product, there is no reason to reinvent anything that is not your core business. I don't see the author of this article writing their own OS from scratch, so why stop there? Why should all the auxiliary libs and frameworks be created from scratch? Because they don't like all the communities around the existing ones?[0] If everyone around you is the problem...maybe its you who is the problem. I've never had any pull requests with fixes or minor features rejected from upstream, so my view may be biased.
I prefer hiring and working with people who understand the value of contributing to OSS instead of building their own little castles.