default-kramer

I understand how the Same Origin Policy protects browsers from executing malicious scripts. I also understand how the Access-Control-Allow-Origin header can be used by servers to declare additional origins as trustworthy, relaxing the SOP.

What I still don't understand is what purpose the Access-Control-Allow-Headers header serves. It doesn't seem like it improves security for the browser (and definitely not for the server). Was it included "just for completeness" by the protocol designers? See also https://stackoverflow.com/questions/17992042

I probably spent over 20 hours debugging, scanning the emu-dev Discord, creating tests, and even throwing the issue at earlier AI models. Nothing worked. But then after a few weeks away from the emulator I tried Claude Opus, and it found the issue in just a few minutes.

Even if you want to write all the code yourself (which is a fine decision), the only reason in 2026 to bang your head against a problem like this for 20 hours is if you really enjoy doing so.

(I'm surprised that "earlier AI models" didn't work for the author. For me, free-tier Gemini gets stuff like this correct all the time.)

I think it's another case of the whole industry being driven by the needs of the very small number of systems that need to handle >10k concurrent requests.

Interval training will help https://www.musictheory.net/exercises/ear-interval

Each interval has a unique "flavor" and once you can hear them you should be able to hear multiple intervals at the same time, which effectively identifies the chord. (Admittedly for complex jazz chords it can get very difficult and you probably need more powerful tools, I can't say.)

What's strange is that many people who believe in a Mature Creation (as I've heard it; "Last Thursdayism" is new to me) will readily accept it as the explanation for ancient starlight but then deny evolution and claim that the fossil record is actually evidence of the biblical flood. Which is an unnecessarily weak position to take when you have already accepted a perfectly unfalsifiable cop-out! The truth is that most of them don't want to think too hard about it.

I'm not really concerned about the availability of SW dev jobs, but I am concerned about the quality of them. For many companies the velocity (and quality, much to my chagrin) of the code you can produce doesn't really matter. What matters more is whether or not you're building the right thing, and too often you're not. These companies also tend to keep more headcount than seems justified, I think because they are gambling that a few employees are going to do something awesome but they don't know which ones. As AI gets better what will these companies do? I don't think they will fire a bunch of SW devs. I think instead they will embrace the slop and just take more shots, and crazier shots. It doesn't just give us something to do, it also gives a bunch of PHBs something to do.

You're right, but for EDM this was pretty much already the case. The scene survives in large part thanks to DJs who wade through countless mediocre tracks looking for the few hidden gems to deploy at the right moment. I think AI means that DJs will become much more important in all genres.

But for the time being there remain a few things that humans can do very easily which computers find difficult. Along with counting traffic lights and crosswalks, one of those things is finding the exact BPM of a song. Not an estimate like most software does, but the exact value with extreme precision across the entire song.

I thought BPM detection has been extremely precise for some time now (for electronic music anyway). Does this mean when software like Mixxx reports (for example) 125 BPM the raw output of the algorithm might have been 124.99, but some higher logic replaces it with an even 125?

I formerly worked for a travel company. It was the best codebase I've ever inherited, but even so there were select N+1's everywhere and page loads of 2+ seconds were common. I gradually migrated most of the customer-facing pages to use hand-written SQL and Dapper; getting most page loads below 0.5 seconds.

The resulting codebase was about 50kloc of C# and 10kloc of SQL, plus some cshtml and javascript of course. Sounds small, but it did a lot -- it contained a small CMS, a small CRM, a booking management system that paid commissions to travel agents and payments to tour operators in their local currencies, plus all sorts of other business logic that accumulates in 15+ years of operation. But because it was a monolith, it was simple and a pleasure to maintain.

That said, SQL is an objectively terrible language. It just so happens that it's typically the least of all the available evils.

Every time I've worked on a project that used AutoMapper, I've hated it. But I'll admit that when you read why it was created, it actually makes sense: https://www.jimmybogard.com/automappers-design-philosophy/

It was meant to enforce a convention. Not to avoid the tedium of writing mapping code by hand (although that is another result).

But, unless you have some way of enforcing that access between different components happens through some kind of well defined interfaces, the codebase may end up very tightly coupled and expensive or impractical to evolve and change

You are describing the "microservice architecture" that I currently loathe at my day job. Fans of microservices would accurately say "well that's not proper microservices; that's a distributed monolith" but my point is that choosing microservices does not enforce any kind of architectural quality at all. It just means that all of your mistakes are now eternally enshrined thanks to Hyrum's Law, rather than being private/unpublished functions that are easy to refactor using "Find All References" and unit tests.

I think you're underestimating the huge variety of productive apps in existence. For every system that handles >1M requests per second, there are probably at least 10 systems that won't even see 1M requests per hour. For example: Twice I've worked on apps for configuring motor control centers. I think you would consider these "productive" apps, but even if we had 100% market share there just aren't that many people in the world who need to configure a motor control center on any given day. The world is full of such apps.

most productive applications work at similar scale

What do you mean by "productive" here? The overwhelming majority (probably >99%) of billed/salaried software development hours are not spent working on FAANG-scale software. Does none of that count as "productive"?

It's not insane. The best codebase I ever inherited was about 50kloc of C# that ran pretty much everything in the entire company. One web server and one DB server easily handled the ~1000 requests/minute. And the code was way more maintainable than any other nontrivial app I've worked on professionally.

I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.

Hmm, maybe, but somehow Marvin Gaye's estate still pulled it off. Yes it was a copyright case, not a patent case, but Robin Thicke and Pharell Williams had a well-funded defense. Seems like Nintendo could easily bully an indie game out of existence if they wanted to.

I've done something like that too. I also noticed that enums are even lower-friction (or were, back in 2014) if your IDs are integers, but I never put this pattern into real code because I figured it might be too confusing: https://softwareengineering.stackexchange.com/questions/3090...

I think checked exceptions were maligned because they were overused. I like that Java supports both checked and unchecked exceptions. But IMO checked exceptions should only be used for what Eric Lippert calls "exogenous" exceptions [1]; and even then most of them should probably be converted to an unchecked exception once they leave the library code that throws them. For example, it's always possible that your DB could go offline at any time, but you probably don't want "throws SQLException" polluting the type signature all the way up the call stack. You'd rather have code assuming all SQL statements are going to succeed, and if they don't your top-level catch-all can log it and return HTTP 500.

[1] https://ericlippert.com/2008/09/10/vexing-exceptions/

To be fair, Persona 5 is my least favorite out of 3/4/5. Most fans of the series agree it's embarrassingly easy. Persona 3 (Portable is best, or FES if you're a masochist, but not Reloaded) offers a perfect challenge on the hardest difficulty, and Persona 4 was pretty well-tuned also. It wouldn't surprise me if P6 was closer to P4 or P3 than P5.

Not so much with video games. The industry is so young that most of those "classics" are actually much less fun than I remember them. (Super Mario World does hold up very well though.) But since you mention Persona, consider how much better Persona 3 Portable is than Persona 3 FES. Game design has come a long way, and I believe it still has a long way to go. Not to mention the technical improvements that allow a game like Uncharted to exist, which cannot be compared to any 16-bit or earlier game.

I strongly prefer FP over OOP, but... Is there any desktop GUI library that isn't built on subclassing? Winforms, WPF, Swing, Qt, Godot all do. This doesn't prove that subclassing is necessary, but it sure seems like the best approach we've found so far.

How many people actually write exhaustive tests for everything that could possibly be null? No one I've ever met in my mostly-C# career.

I can confirm that at least 30% of the prod alerts I've seen come from NullReferenceExceptions. I insist on writing new C# code with null-checking enabled which mostly solves the problem, but there's still plenty of code in the wild crashing on null bugs all the time.

I'm convinced that some people don't know any other way to break down a system into smaller parts. To these people, if it's not exposed as a API call it's just some opaque blob of code that cannot be understood or reused.

And it's not obvious thanks to the logarithmic scale... There must have been a better way to present this information.

I realize no one is claiming otherwise, but this writer almost certainly did it intentionally for humorous effect. ("Aubergine wyrm" is just too good to be accidental.) It's like "the lick" in jazz.

"How can I change the background color of the selected item in a WPF ListView? It must work whether or not the ListView has focus."

I only tried ChatGPT which gives me 5 incorrect answers in a row.

I highly recommend Dragon Quest Builders to anyone who enjoys (or might enjoy) Minecraft even a little bit. It can reliably make me feel like a kid with a new Lego set for hundreds of consecutive hours.

Killer Feature #1 is the room system, which can be a great source of inspiration if you don't know what you want to build. Killer Feature #2 is the overall charm you would expect from a modern Dragon Quest game, especially the NPCs. DQB1 has the better story mode (in my opinion), while DQB2 gives you much more freedom to build.

I'm very surprised we don't see more people using a level 5 language to generate Terraform (as level 3 JSON) for this exact reason. It would seem to be the best of both worlds -- use the powerful language to enforce consistency and correctness while still being able to read and diff the simple output to gain understanding. In this hypothetical workflow, Terraform constructs like variables and modules would not be used; they would be replaced by their counterparts in the level 5 language.

https://developer.hashicorp.com/terraform/language/syntax/js...

Yeah, automated tests are great when they are good. But when they are bad, they can be worse than no tests at all.

Multiple times in my career I've taken ownership of a codebase written by someone else. Some of the most pleasant ones had very little test coverage, but the code quality was high enough to make the lack of tests not really matter. On the other hand, some code is so bad covering it with tests adds nothing of value; it's just one more thing I have to analyze and decide what to do with.

I agree with most of the author's points in general, but I think that most programmers who are capable of writing good tests are also capable of recognizing situations when it's not worth the trouble.

Kind of disagree with this article, when you add a "noun" (aka type), you're often introducing a new abstraction.

The article is talking about simple "bundle of values" types; the example is the CreateSubscriptionRequest. This is not an abstraction. It is simply a declaration of all the fields that must be provided if you want to create a subscription. And it is usually superior to passing those N fields around individually.