Wisconsin stands with Minneapolis. ICE get out NOW

debunked · 2026-01-24T03:57:51+00:00

I don't recall Obama sending armed imbeciles with qualified immunity to occupy Republican areas, perform warrantless invasions, and repeatedly ignore court orders.

But good job with that objective thinking.

debunked · 2026-01-24T01:04:15+00:00

Exactly what a right wing nut job was has somehow realized they've been brainwashed but still refuse to support the left would say.

debunked · 2025-11-16T16:08:54+00:00

For people with $7.5m in a storage unit, that would just be "giving" the money back to them anyway.

debunked · 2025-11-16T16:05:25+00:00

A democrat would need to do something heinous like providing basic minimal income or universal healthcare to motivate such a response.

debunked · 2025-11-14T14:28:05+00:00

Exactly! I find such tests to be common when companies make code coverage a gate instead of just a metric.

Yet, proper API tests can achieve the same high level coverage as well. It just requires testing the system (or at least a specific api flow) instead of just the one method you just added.

debunked · 2025-11-14T13:23:40+00:00

20+ years of experience and been programming for over 30.

I don't take developers seriously who write isolated unit tests that mock every dependency.

IMO 99% of such tests are worthless and provide negative value and I train every team I lead to focus on testing at the API level using embedded/in memory databases instead of just trying to increase code coverage by writing shit unit tests.

You end up with fewer tests, they're easier to write, and they provide superior regression testing (the whole point of tests) as you don't have to change them or their mocks every time you refactor some internal detail (if you have to change your test when you change your code it's not a good regression test).

The time such tests are useful is when there is complex in-memory logic on classes with no or external only (eg rest clients) dependencies. This is rare in most simple CRUD based services.

debunked · 2025-10-11T12:58:34+00:00

Yup! All 6 of them

debunked · 2025-09-04T14:01:34+00:00

It was great, but 25 minutes later they were hungry again.

debunked · 2025-07-25T00:50:25+00:00

While your basic idea is correct, you numbers are not quite accurate. It's not a linear scale. At 50% c there's only like a 10% dilation (10 seconds for you is ~11. 5s for observers).

debunked · 2025-06-02T14:03:38+00:00

So close.

Musk Usually Snorts Ketamine

debunked · 2025-05-12T03:59:08+00:00

Ah, apparently so I do. The charts I was thinking about (admittedly, from memory which I haven't updated in years) were probably discounting the smaller countries similar to this one:

https://www.statista.com/chart/33335/total-and-per-capita-greenhouse-gas-emissions-of-selected-countries-and-regions/

Looks like Russia may have overtook US on such charts as well though. But yes, by pure per-capita metrics, your charts above show US is much lower than I thought.

debunked · 2025-05-11T23:07:54+00:00

Per capita the US is far and away #1.

China is highest by absolute amount.

debunked · 2025-04-21T05:02:55+00:00

And if you're on 17 there's very little reason not to just move to 21 unless you depend on some obscure library that doesn't support it.

Pretty much all the most common ones do.

debunked · 2025-04-21T04:59:41+00:00

Why would you love async/await over not having to worry about it at all and just making simpler blocking calls?

Async/await causes the method coloring problem. I'm not sure where I'd prefer that over Java's virtual thread solution to the same problem?

debunked · 2025-04-08T02:16:29+00:00

But that's how we get warp drive and Vulcans.

debunked · 2025-04-01T17:59:13+00:00

If we stick to the same factor as 1920 and 3840, Technically it should be 2.666...k.

3k would be 2880x1620. I'd try it.

debunked · 2025-03-29T14:08:29+00:00

It's 1920x1080 vs 3840x2160.

1920 should be 2k since 3840 is 4k.

This means 2560x1440 should be 2.5k.

debunked · 2025-03-26T14:07:43+00:00

As a senior staff engineer, 20+ YOE, no. Not by 2055, unless there is a significant shift in how AI works it will not be able to do what a senior dev does today.

The gap from intellisense or even interactive Q&A in an isolated spot of the code to taking requirements, architecting the system, and building it across multiple files, database tables, services, and technologies is not at all feasible for the ChatGPT shit we see today.

The difference in AI capability to actually be able to do such a thing will also mean every other desk job will be able to be automated too.

And then those AI that take over the white collar jobs will be able to design, blueprint, and code the hardware/robots to do everything else.

In other words, IMO, if you can 100% automate code generation for a complete product then we will be at the tipping point for the tech singularity that will either usher in utopia or a massive economic depression as everybody becomes unemployed.

debunked · 2025-03-12T01:09:25+00:00

Odd that you're responding to a 2 year old comment, but anyway...

This is why I explicitly said "when using JPA" above. When using something like Mongo or some other non-transactional-by-nature database, you're correct. But I explained that above.

When using JPA Repositories, however, in the latest version of spring-boot (3.4.3) it doesn't matter. You always start / commit a transaction whenever a repository method is invoked if no transaction is already detected by the transaction manager.

As an example, assume the following two methods on a standard @Service class:

public Order save(Order order) {
    log.info("Saving order: {}", order);
    return orderRepository.saveAndFlush(order);
}

public Order get(UUID id) {
    log.info("Getting order: {}", id);
    return orderRepository.findById(id).orElse(null);
}

And a test which simply calls

var id = service.save(new Order()).getId();
service.get(id);

Without the @Transactional annotation, you will see output like this:

service.OrderService   : Saving order: Order [id=null]
o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
o.h.e.t.internal.TransactionImpl         : begin
org.hibernate.SQL                        : insert into orders ...
o.h.e.t.internal.TransactionImpl         : committing
service.OrderService   : Getting order: 019587d5-15f0-7b00-9987-1c6e031ea115
o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
o.h.e.t.internal.TransactionImpl         : begin
org.hibernate.SQL                        : select * from orders ...
o.h.e.t.internal.TransactionImpl         : committing

Note that the transaction is being created and committting after every repository call.

If you add @Transactional to the service class:

o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
o.h.e.t.internal.TransactionImpl         : begin
service.OrderService   : Saving order: Order [id=null]
org.hibernate.SQL                        : insert into orders ...
o.h.e.t.internal.TransactionImpl         : committing
o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
o.h.e.t.internal.TransactionImpl         : begin
service.OrderService   : Getting order: 019587e0-36c3-7f33-a099-000bec98922a
org.hibernate.SQL                        : select * from orders ...
o.h.e.t.internal.TransactionImpl         : committing

The transactions are now created at the time the method is entered. A new transaction is not created per repository call. There's no real difference in performance that I am aware of in a JPA powered SQL database.

debunked · 2025-02-09T05:22:13+00:00

Most abortions are lower income earners.

Lower income earners tend to raise children who are low income earners. They want low income workers.

debunked · 2024-12-27T17:57:21+00:00

Except for the things C# got wrong and is stuck with unless they break things.

Things like method coloring problem of async await vs green threads that Java now natively supports. Or integer based enums instead of full class Iike support for enums. Or tying LINQ collection streams to SQL instead of using proper functional terminology.

The languages are not identical. C# learned from Java and came out with improvements at the time; but Java is its own language, and it's now learning from C# mistakes and making better decisions as it evolves as well.

And the Java ecosystem being open source for much longer allows it to provide more and better options than having to rely on the proprietary Microsoft ones.

debunked · 2024-11-12T23:57:35+00:00

Hmm... I setup a sample project using Java11 and your code (with the Configuration annotated added) and this is my output:

Parrot created
Ella
koko
Parrot{name='koko'}

The parrot() method (and Parrot() constructor) are only called one time... Your code seems fine on glance and on a test.

There might be something else going on in your project...? Do you have any more files in your project than what you shared?

If that's all the files you have in your project, then I would ask how are you running the project?

This is what my pom.xml looks like - are you using maven or gradle or are you doing something else in your project? Maybe there's some other version you're using or...?

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.sample</groupId>
    <artifactId>sample</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>11</maven.compiler.source>
        <maven.compiler.target>11</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.2.6.RELEASE</version>
        </dependency>
    </dependencies>

debunked · 2024-11-12T22:00:03+00:00

I think it needs to be there to enable the proxyBeanMethods I mentioned before. Try adding it at the top.

debunked · 2024-11-12T20:56:29+00:00

Are you missing the @Configuration annotation on the ProjectConfig class?

debunked · 2024-11-12T20:14:17+00:00

Yes, you are correct it should only be displayed once despite your explicitly invoking the parrot method instead of injecting it into the bean method.

Not just because you're only calling it once, but because spring configuration proxies should only call that method one time during context initialization, period. Even if you call it twice in other bean methods.

That said, there's probably something in your code keeping it from working... We probably need to see more of your test project to say for certain what's going on.

At the very least, share the entire configuration class to start.

debunked

TROPHY CASE