arnorhs

Same thing I was thinking. I personally don't track unique visitors on my blog, just random sessions where you can't identify unique users, which allows me to not show a banner. If I were to use this technique I'd have to show a banner

I'm curious to see how it deals with dual languages - ie. not switching between them, but using two languages in the same sentence like the google keyboard supports out of the box.

my biggest issue is that i make up a lot of words as i type and the google dictionary for icelandic is .. well it can never be fully complete because of the way the language works, so dictionary words are always a mess.

I think you might be on to something there

This post is good, and it's a great example of taking a problem and solving it with the appropriate tech with the right amount of depth. It really helps to have full domain knowledge of your customers as well.

However, I do not like how it is framed as "simple html is better than react" - because you could just as well have told the same story as a react developer.

(Nb. I could go on forever about the complexities and intricacies of storing things session based on a server vs browser based and etc - and lots of other things that were skimmed over in this article, but that would be too long)

All of those things that are simple in html are also simple in react.

It's literally the same code - there's nothing preventing you from using browser based html validation in react - all the same code that gets complicated in react (overly complicated validation logic) also ends up being complicated in astro - they have their own thing around schema validation etc and integrating it within an astro site means you have to integrate their client router etc etc.. so it's very easy to go overly-complicated there as well.

The comparison is also with an off-shore team doing development for you with probably incomplete knowledge and the way projects are structured they have an incentive to create the solution as fast as possible, in as little time as possible, with the biggest amount of complexity as possible.

The last point is devious - it's not necessarily that the contractor does this by design, but the incentive structure makes it so something that's overly complicated actually benefits them, so they don't have a direct incentive to go with something simple.

Anyways, a simple solution, directly addressing the problem at hand is always better - no matter what stack you pick.

(I'd like to say that I don't have anything against Astro's form validation, I was just trying to highlight how there's more to it than "native html browser validation")

Yes, modest but tangible improvement - same modesty does not apply to the cost: https://artificialanalysis.ai/models/capabilities/coding#cod...

this sure seems like meditation.

it could probably work as well to close your eyes instead of staring at a wall.

i've always found meditation types revolving around focusing on one thing (candle, wall etc), or nothing (empty mind) to be really hard. my mind just wanders and i end up super anxious, frustrated, and exhausted - resulting in me giving up pretty quickly

What I've found is that focusing on "everything" - ie sitting still and trying to observe your surroundings, your body, all sounds simultaneously seems to work much better. It's easier to get to a calm state this way.

Also, doing this while walking can also work - but perhaps easier to accidentally start thinking about something else

i wonder if you could use a bayesian classifier, like the first anti-spam measures used, to automatically classify these submissions.

Kind of off-topic - but why is there always so much focus amongst AI-bros on how good or whether or not LLMs are good at building UI? My shallow assumptions were that the reason is because that's what LLMs are particularly bad at.

But lately I've kind of gotten the sense that a lot of people seem to mostly be building UI stuff with LLMs. Weird.

Since the site is down, you can use the archive.org link:

https://web.archive.org/web/20260421113202/https://lawsofsof...

are you saying performance is 90-99% caching? If so that is so obviously untrue.

If you are saying you _can_ fix 90-99% of performance bottlenecks eventually with caching, that may be true, but doesn't sound as nice

There's something that is written between the lines here.

EU is often portrayed as overly bureaucratic, slow moving. The way this app was developed seems more in the line of "move fast, break things".

I don't know if that says something about the EU, or about the EU-naysayers, but I thought it was worth pointing out.

That's an interesting story, but I'm really at a loss for how this relates to the post you are commenting on.

The author is talking about the case where you have coherent commits, probably from multiple PRs/merges, that get merged into a main branch as a single commit.

Yeah, I can imagine it being annoying that sqashing in that case wipes the author attribution, when not everybody is doing PRs against the main branch.

However, calling all squash-merge workflows "stupid" without any nuance.. well that's "stupid" :)

Does orange peel not produce any CO2 / methane when left like this? I'm assuming there is some negative carbon footprint before this becomes a positive?

The ecological win definitely looks nice on paper, but whenever people talk about compost the carbon footprint / gas emissions is always at the front of people's minds, and I don't really see that discussed in the article.

The article does say

Especially since, in addition to the double-win of dealing with waste and revitalising barren landscapes, richer woodlands also sequester greater amounts of carbon from the atmosphere – meaning little plots of regenerated land like this could ultimately help save the planet.

How long will it take for it to cross the CO2-neutral mark? Maybe a silly question, definitely not my area of expertese.

The way I understood it, the original article is saying the _only_ remaining differentiator is taste and the comment you replied to is saying "wrong, there are also other things, such as effort".

I don't necessarily interpret the comment you replied to as saying that "taste is not important", which seems like what you are replying to, just that it's not the only remaining thing.

I agree that taste gets you far. And I agree with all the examples of good taste that you brought up.

But even with impeccable taste, you still need to learn, try things, have ideas, change your mind etc.. putting all of that in the bucket of "taste" is stretching it..

However, having good taste when putting in the effort, gets your further than with effort alone. In fact, effort alone gets you nowhere, and taste alone gets you nowhere. Once you marry the two you get somewhere.

It made me angry because makes the point that natural selection has become ineffective on humans and thus intelligence declines unironically. There is no joke in that - all jokes build upon the assumption of this being true.

you seem pretty convinced that intelligence plays an important role in natural selection. I'd argue that decisiveness, confidence, looks, social skills all play a more important role. (I'm not saying that's a good thing)

I'm interested in understanding your point of view, can you elaborate on what you mean by "There is no joke in that"?

ISP's often have different infrastructure for different sets of customers (regional, mobile/landline differences etc) - often due to legacy M&As etc..

Which EU grant did you receive? Ie. from which fund?

edit: nm, rtfm, it was on the landing page: Horizon Europe programme

The only cases where I've had gemini step on my toes like that is when a) I realized my instructions were unclear or missing something b) my assumptions/instructions were flawed about how/why something needed to be done.

what ever will i do /s

the upside this is a great opportunity to do an early bed time

interesting, so you guys call it a ratchet file? i thought it was something that OP came up with

Interesting, props for coming up with a good name.

But it's weird to me to call this a "ratchet", and not just a custom lint rule. Since it sounds exactly like a lint rule.

The hard-coded count also sounds a bit like something that I would find annoying to maintain in the long run and it might be hard to get a feeling for whether or not the needle is moving in the right direction. - esp. when the count goes down and up in a few different places so the number stays the same.. you end up in a situtation where you're not entirely sure if the count goes up or down.

A different approach to that is to have your ratchet/lint-script that detects these "bad functions" write the file location and/or count to a "ratchets" file and keep that file in version control.

In CI if the rachet has changes, you can't merge because the tree is dirty, and you'd have to run it yourself and commit it locally, and the codeowner of the rachet file would have to approve.

at least that would be a slightly nicer approach that maintaining some hard-coded opaque count.

Presumably this would work to prevent infections, but not to eradicate them once they have infected the subject.

I mostly have my scripts in package.json "scripts" section - but sometimes the scripts invoked will actually be .ts files, sometimes just bash if that makes more sense.

Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno

Yes I agree, and the replies don't really make it any more clear.

The biggest differentiator of design thinking is really addressing the XY problem. In 95% of cases clients will come to you to design their solution. Ie they already think they have a solution to their problem and now they want it to look good.

Design thinking is basically more like root cause analysis, or the 5 why's.. and an emphasis on taking to end users (the people with the problem) without having a solution.

Once you understand the problem more fundamentally is only when you start cooking up with a solution.

And the result of that process might not even be a traditional design, but perhaps just a tweak to something, like moving your onboarding to later in the ca process..

In practice however.. 95% of designers who say they practice design thinking disregard this, and just want to design wherever the client asks for

I agree with you, however your approach results in much longer LLM development runs, increased token usage and a whole lot of repetitive iterations.

+/-

They are bad at deciding requirements by themselves.

What do you mean by requirements here? In my experience the frontier models today are pretty good at figuring out requirements, even when you don't explicitly state them.

They are bad at original research

Sure, I don't have any experience with that, so I'll trust you on that.

for example developing a new algorithm.

This is just not correct. I used to think so, but I was trying to come up with a pretty complicated pattern matching, multi-dimensional algorithm (I can't go into the details) - it was something that I could figure out on my own, and was half way through it, but decided to write up a description of it and feed it to gemini 2.5 pro a couple of months ago, and I was stunned.

It came up with a really clever approach and something I had previously been convinced the models weren't very good at it.

In hindsight, since they are getting so good at math in general, there's probably some overlap, but you should revisit your views on this.

--

Your 'bad at' list is missing a few things though:

- Calculations (they can come up with how to calculate or write a program to calculate from given data, but they are not good at calculating in their responses)

- Even though the frontier models are multi-modal, they are still bad at visualizing html/css - or interpreting what it would look like

- Same goes for visualizing/figuring out visual errors in graphics programming such as games programming or 3d modeling (z-index issues, orientation etc)

That's the orm argument. "If I need to switch DBs..."

In practice, that is not really viable and should not be a motivating factor when choosing technologies.

I would guess it is.

Also:

Exploitation of this vulnerability requires an attacker to first gain authenticated access to your Redis instance.

This idea of every PR being a small chunk that you can review in 5-10 minutes is completely ridiculous. It is reasonable for bug fixes or small improvements, but the review time you should expect for a PR should reflect the size and impact of a feature, not some arbitrary number.

Yes, everybody would love it if every PR was small enough. In reality that is not a good way to build substantial features.

Often, fully building out a substantial feature, causes you to change your mind and completely changing your approach the further along you are. You don't want to be muddying up the PR pipeline with a bunch of half-assed changes.

Doing that just makes reviewers less inclined to give good feedback on a PR, because they "know it's going to change so much anyways".

If you are building a substantial feature, it is reasonable that the PR is large and reviewers will have to dedicate substantial time to reviewing it. Reviewing it is work on its own and hopefully your engineers have dedicated time to review substantial features.

Of course, you should make sure your substantial feature is as minimal as possible, for whatever is needed to ship the feaure - but not any less than that.

Yes, those have been really decent IIRC - don't remember ever having issues upgrading