njitbew

Sounds like a problem that the Mockito team created for themselves, and like a problem only they can solve.

See https://openjdk.org/jeps/451: JEP 451: Prepare to Disallow the Dynamic Loading of Agents, which has a lot of background on the topic.

I respect the maintainer's decision, but I don't understand the justification.

but when it was communicated with Mockito I perceived it as "Mockito is holding the JVM ecosystem back by using dynamic attachment, please switch immediately and figure it out on your own".

Who did the communication? Why is dynamic attachment through a flag a problem, and what was the solution? Why is "enable a flag when running tests" not a satisfactory solution? Why do you even need a _dynamic_ agent; don't you know ahead of time exactly what agent you need when using Mockito?

While I fully understand the reasons that developers enjoy the feature richness of Kotlin as a programming language, its underlying implementation has significant downsides for projects like Mockito. Quite frankly, it's not fun to deal with.

Why support Kotlin in the first place? If it's a pain to deal with, perhaps the Kotlin user base is better served by a Kotlin-specific mocking framework, maintained by people who enjoy working on those Kotlin-specific code paths?

and it feels bloated (Java!)

I'm curious, what exactly feels bloated about Java? I don't feel like the Java language or runtime are particularly bloated, so I'm guessing you're referring to some practices/principles that you often see around Java software?

Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

Most of these arguments probably don't outweigh the benefits. If you're in need of a managed, highly-consistent, highly-scalable, distributed database, and you're already an AWS customer, what would you use instead?

Oracle Cloud only charges a fraction of want Google, Microsoft, and Amazon charge. Any idea how Oracle is able to keep the cost so low? Or are the others just inflating the price so customers don’t move to the competitor? In that case Oracle deserves a shout out for not applying these vendor lock-in practices.

ORMs could (and most do) provide some escape hatch, where you can write the query yourself and reuse the hydration layer, or reuse the query generator and customize the hydrator, or a combination. Or you can just bail out completely for the few performance critical queries.

Honestly, ORMs are just an abstraction. They come at a cost and they’re not a silver bullet, just like most abstractions. I believe the hate for ORMs in many cases is due to a lack of understanding/wrong expectations.

I don't understand the negativity in this thread about Oracle and the pricing model. GraalVM is an amazing piece of technology that enables many new applications. Oracle has the courage to invest heavily in this research, provides a community edition for free, and asks a very reasonable fee for the enterprise version. The pricing model is admittedly a bit complex, but from what I've been told it is a fairly common pricing model in this industry. And if you use the enterprise version in a way that is not allowed, you risk facing the consequences; no surprises there.

Disclaimer: You guessed it, I work at Oracle.

After upgrading my MacBook Pro 13" (2017) to Big Sur in Dec 2020 I had a similar experience. I use a 4k monitor and everything got super slow, fans started spinning, processes got throttled, and I could barely get any work done. I later did a fresh install of Catalina and everything was fast again.

I never did proper benchmarking, but my feeling was that resolution played a role. When using 1080p things were fast, but the resolution is unusable on a 27" 4k display. When using 2160p things were fast, but too small for my eyes. Any resolution in between (this implies things are being scaled?) was sluggish.

Note that this is a 13" model, so the problem does not seem to be restricted to the 16" model that the author is talking about.

I know nothing about Android development with Gradle (or Android development in general, for that matter). I feel that is where a lot of negativity in this thread comes from. But then it's not per-se Gradle who is to blame; it's this specific use case of Gradle with Android which apparently is giving people a poor experience (e.g. lacking documentation).

You are probably doing a bit simpler stuff, if that basic tutorial suffices you.

I've written a couple Gradle plugins, one of them was to build and test programs in our custom DSL. This exposed me to all facets of Gradle, because whatever Gradle offers to compile Java, Kotlin, ... you will most likely use for another language as well. I could not have written these plugins without the Gradle documentation. But again, it's totally unrelated to Android development.

This is funny, because I have the complete opposite experience. Yes, it took me an afternoon to find my way around Gradle. But ever since I really appreciate their documentation. It is to the point, well written, contains code samples (which I believe are unit-tested, so they the code samples are always up-to-date), contains examples in both Groovy & Kotlin, and I could keep going on. A good entry point, for example, is Build Script Basics (https://docs.gradle.org/current/userguide/tutorial_using_tas...).

But I am yet to encounter a developer who actually learned Gradle inside out just from using it and reading the documentation.

You just met him! ;)

The problem is that it is super easy to modify a Gradle build scripts, but also super hard to get it right (e.g. understanding of configuration vs. execution phase, concept of configurations, task dependencies). As long as you don't touch the build script, Gradle is superior to Maven in _so_ many ways.

Why so negative? You don't _have_ to do all of that, but as a software engineer you are in the unique position in which you're able to do a bit of all of that _if you want to_. It's like saying: why should I do operations work when I'm a developer. But then DevOps became a thing and every developer was suddenly also an operations guy. Being able to pick up different roles is an extremely valuable skill, and you're limiting yourself if you're drawing an imaginary boundary between technical and non-technical things.

I don't understand what nginx has to do with this. nginx's language is just that: a language. If Lambda@Edge would support nginx language, you would still be invoking a lambda. But I'd must rather write some header rewriting code in, say, JavaScript than nginx's language.

Then why a (Turing-complete) programming language and not a config language? Simple: because a programming language gives you infinite more power than what any config system could ever provide. E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language.

Sounds like it. Which in turn is similar to Akamai EdgeWorker (Akamai's JavaScript-at-the-edge)

Without reading the article, I can imagine that listing the components of a technological product (i.e., an SBOM) is a _first step_ towards the goal of solving all those problems. Once you have a standardized way of communicating what a software product is made of, you can start thinking of automatically upgrading dependencies (Maven's pom.xml does this to some extent, and Dependabot and Renovatebot leverage this semi-standard to automatically upgrade your dependencies). If you take this one step (or two steps) further, you can start to automatically rebuild the code, automatically deploy the code, patch running systems, detect when CVEs are actively being abused, and so on. Basically, automate the heck out of this so that the "they just didn't do it" will not happen. And for automation, you need standards.

The distinction you're making is more about _fundamental_ research vs. _applied_ research, but it is research nevertheless.

From the first hit I found on Google:

* Fundamental researches mainly aim to answer the questions of why, what or how and they tend to contribute the pool of fundamental knowledge in the research area.

* Opposite to fundamental research is applied research that aims to solve specific problems, thus findings of applied research do have immediate practical implications.

Are these "leather cups" you're talking about these "ear cushions" (https://www.bose.com/en_us/products/headphones/headphone_acc...)? If yes, then that's only 30-40$, which does not seem unreasonable for a product you use so intensively? I replaced mine after about 2 years. I remember the sound insulation being a _lot_ better afterwards.

I have the same experience on the battery: my pair is almost 3 years old and I can go about 2 days of work (~12 hours) before I have to charge them.

There seems to be a connection though. This project tabler/tabler-icons is part of Tabler, which features FeatherIcons: https://preview.tabler.io/icons.html.

Not saying there's anything wrong here, for all I know it might be the same author on both projects. Taking a closer look, it might even be the case that tabler-icons is just a rebranding of FeatherIcons.

Quality as in "a BMW is of better quality than a Peugeot" ;)

I'm not sure if the author is trolling or actually presenting this as some groundbreaking insight. I thought it was obvious to anyone that no cookies means no cookie notice (and there are plenty of static websites that do this). The point is that most websites try to make money, and making money means advertisements, and advertisement (often) means tracking.

Contractor / CEO / founder, $900k base, $1b equity

This one made me smile.

My sister’s former boyfriend used to carry a phone without a SIM. His mom ended up calling my sister or our landline to check up on her son. It was annoying AF.

Feel free to live off the grid, but please make sure you don’t leech off of those around you.

I recently came across her "Perf zine" [1] and immediately bookmarked it because I enjoyed it so much. It may target entry-level engineers, but it's still a joy to read for anyone.

[1] https://jvns.ca/perf-zine.pdf

I'm Dutch speaker, we're known to be very direct, but I too believe adding "Please" in front of a request does not per se make it more polite. Another example that bothers me quite a lot is adding "Thanks" to a request without awaiting a reply. Writing "Can you please do xyz? Thanks" makes it come over as an instruction instead of a request, even though the author may have had the best intentions (express his gratitude). Or maybe I'm just overly sensitive ;)

In my experience, EV certs are not a technical thing but a marketing thing. EV certs show your name in the address bar, so it's certainly more visible. If an EV cert boost sales by 1% and costs 500$ a year, then it will make sense for even the smallest webshop. And as long as this is the case, there will be a market for EV certs.

Though it's true that compilers usually turn assignments into SSA, that's not really the same as what parent was referring to. Static single assignment has the same semantics as normal C-style assignments. The parent was referring to assignments that have (Erlang's) pattern match semantics.

Also, there's a simple counterexample. You can have static single assignment that has dynamic multiple assignment (e.g. within a loop construct). Under the pattern-matching semantics, evaluating the assignment (or rather the pattern match) a second time could fail, whereas an assignment always succeeds.

Yes, this sucked. I just had a 1 hour delay on a 1 hour flight (AMS-ZHR). Unfortunately, no compensation until its a 2 hour delay (but thank god it was only one hour!). Passengers who had a layover were noticeably less happy.

This is so true. I remember that I had to pause video playback after about 30 minutes or you would experience jitter. The next generation did not suffer from this problem, but I'm still kinda disappointed in Apple for selling such a bad product. A $1000+ laptop that cannot play 30 minutes of HD video is just sad, even in 2009.

I enjoyed reading this a lot. I wonder why the developers decided to allow reading kernel-memory in the first place. When a scalar processor reads kernel memory, it crashes. When a speculative processor reads kernel memory, it relies on the assumption that the read is never committed to prevent leakage. It takes no expert to realise this is a potentially dangerous decision (and, as becomes clear now, is only valid in the absence of a cache).

To me it would make a lot more sense to use a special value to indicate the read did not succeed and propagate this value until it is time to crash. I guess this introduces some overhead (e.g. reserve a special value); but are there any other drawbacks?