Yeah, it's included as one of the gradle scripts which fails the build in CI if the rules don't pass.
No template, as it's specific to my team's project, but one example is that we enforce that classes within our core domain don't import types from outside the project. You could accomplish this with separate projects, but that comes with its own complexities. This rule basically says "any domain type shall not import a non-domain type".
I love Detekt! It's particularly good for enforcing project conventions that can't be covered with standard linters. With access to the full AST, you can basically enforce any kind of rule you want with custom analyzers. And LLMs take out 90% of the effort for creating new analyzers.
Almost my entire org uses it for backend server development at Amazon. There is very strong support for Kotlin support within the Amazon dev community.
Someone who actually knows what they're talking about.
Even with the Customer Obsession LP, it's not too hard of a stretch to arrive at a conclusion where more ads are shown. Better are worse are, in many aspects, quite subjective in these areas.
In my Amazon team, we use PostgreSQL as a queue using skip-locked to implement transactional outbox pattern for our database inserts. People commenting 'just use a queue' are totally missing the need for transactional consistency. I agree with the author, it's an amazing tool and scales quite well.
Even if are "down to several nano-seconds", a slight clock drift can be the different between corrupt data or not, and when running at scale, it's only a matter of time before you start running into race conditions.
For a small web app, fine, but if you're running enterprise level software processing billions of DB transactions per day, clocks just don't cut it.
This is precisely why large tech companies generally offer parallel career progression paths for individual contributors who don't wish to go into management. A Senior or Principal engineer at Amazon carries nearly as much weight, sometimes more, in software related decision making as their SDM counterparts.
A couple ways. If the need is not real-time and analytical, you feed the data from multiple services into a separate BI database which can do slower and more complex joins across data from multiple data sources. Or if the need is real-time, you build a paginated API with a page limit that can always be processed within the API SLA. Then you build workflows on top of the paginated API to operate on that data.
Generally, unbounded operations have to be broken up at some point. It just depends on how big the data set is.
Man, I remember running this and ophcrack as a 15 year old to recover the windows login password for my mom's computer after she forgot it. She was convinced her password had just stopped working, until I recovered it and she realized that she just forgot what it was lol.
> Checked exceptions are optional. But they're one of the BEST features in Java.
No
> So much code fails unexpectedly. When you want to build a professional application you need to handle every error.
Yes
> Checked exceptions help you avoid that nonsense.
Wrong
> People hate checked exceptions because of laziness. Java guards you against yourself.
Wrong
Java checked exceptions are almost universally regarded as being a mistake because they don't actually solve the problem they were meant to solve, and they make the code extremely hard to work with.
Yup, I work at Amazon and my team along with many surrounding teams are only coding in Kotlin from this point on. The JVM and its ecosystem brings insane value to the table, and Kotlin lets you take all the benefits while removing most of the downsides of Java.
Commit messages don’t matter. In fact they matter so little that I'm going to write a blog post about how much they don't matter. Commit messages are probably one of the worst places for documentation and a common source of bikeshedding. So let me kickstart some more bikeshedding since there's not enough already.