s4i

Almost certainly a lot of the people saying they are ”crossing” their eyes are actually ”uncrossing” their eyes; focusing the eyes straighter than what would normally happen on the surface where the image is laid out.

This is also how the legendary ”Magic Eye” books were supposed to be viewed. Not by crossing the eyes.

The bigger the codebase, we all eventually find ourselves in scenarios where we were the idiot. Making the APIs as foolproof as possible, utilizing tools like Semgrep, deprecating stuff in the way your language supports that it shows up in the IDE,… all that stuff should be utilized.

I think the maker of this had a point and I was curious what the crowd here thought about that. I think most people didn’t look further into his argument nor the linked YouTube video, where the idea was that you’d accompany these with darker/lighter variants (depending on dark vs light mode).

I think the dark mode colors look way better than the light mode (you can switch at the top).

And then there’s the Fennoscandia test: do you convert äöåø with the same rules as for German? Because, if you do, it looks very silly at least in Finnish. This is often the case in international sporting events and is basically a joke among Finns how Räikkönen becomes the insanity of ”Raeikkoenen” etc. ”Raikkonen” would be much preferred.

That’s not a valid UUID? The version and variant parts are missing.

There is Slonik [1] for instance.

[1] https://github.com/gajus/slonik

This is the reason I find it odd that most of these tools require their own system/DSL for defining the schema and the migrations. Using vanilla SQL DDL for that part gives you more escape hatches. This is possible with e.g. kysely + kysely-codegen.

What kills me with that website is that an example version string is nowhere to be found. The same thing almost plagues the TrunkVer page (unless you realize that you are supposed to ignore the newlines in that gray intro box), except at the very bottom you can see a dogfooded TrunkVer of the spec page itself.

If you want your thing to be popular, make sure someone dumb like me skimming the marketing blurp can quickly understand what the thing looks like in the wild.

Or even better, do that in CI.

Really? We FaceTime a lot with my wife and I keep telling her that I can see her looking at her own face in the corner instead or me. Is that tech accurate enough to tell that the person is looking at themselves and not the other participant, and then not correcting the eyes if that’s the case?

Anyway, I’d much prefer if Apple didn’t silently alter the eye direction of people calling me.

If you’re not in the market, I find it ironic you think you can assess if that $999 electric chair or those sub-$500 manual chairs are good deals. From the other comments here it seems like they aren’t.

I think it's "value #0", "value #1", etc. Confused me too.

I was thinking the same thing. The style reminds me of 90’s computer/game magazines or something… So it looks sort of professional (sans the first letter in the headings) but also whimsy at the same time. Love it.

> I don't think I'd trade the freedom in nodeJS for Swift's type safety

Surely you have considered TypeScript for your Node project then?

”Just add support for selectors” in a library of which whole philosophy is built around ”you test the app like the user would” (via WAI-ARIA roles [1] and text visible to screen readers).

Of course they could’ve forked the lib but that’s definitely not a ”just” decision to commit to.

[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

Depending on your read and write patterns, overflowing even every few days might be appropriate, and also obfuscate the creation time [1] more.

[1] https://news.ycombinator.com/item?id=40272446

This topic resurfaces quite frequently, I've noticed. One thing I find quite frustrating is that most of the time this is discussed, people don't remember that exposing the creation time of a database row to the public is not acceptable in many systems. This makes v7 UUIDs, ULIDs, KSUIDs, etc. not appropriate for the task.

In any application where the user is able to first create a draft of something (a video upload, a news article, a blog post, ...) and then release it some day in the future, we probably don't want the public to be aware of when the author created the initial draft. For instance, news websites often start drafting articles about people that are speculated to pass away soon.

The problem also affects numeric/auto-incremented IDs. The "Finnish BBC" YLE uses numeric IDs in their news article URLs, making it possible to ballpark when the article was first started. Here's [1] an article about the death of former president Martti Ahtisaari from 2023/10/16 and here's [2] the next integer ID dated 2023/5/5 (5 months before).

[1] https://yle.fi/a/74-20030335

[2] https://yle.fi/a/74-20030336

I wonder if they have plans to introduce any default emitters as part of the package? Nothing about that in the docs that I could find. [1]

[1] https://typespec.io/docs/extending-typespec/emitters

Google Earth is often a nice balance between usefulness and delightfulness.

SQLite, plain localStorage in the browser, the file system for desktop apps, …?

There are painpoints in working with ”modern web stuff”. But:

> My counter-argument is that the simplest tool has the largest chance of not breaking over long periods of time. I have dynamic websites I built 10 years ago that still run almost untouched because I used the simplest stack possible.

My whole argument was that any reasonable frontend stack can work if your requirements stay constant. But let’s say in a startup you definitely don’t know on day one what you’ll need to implement. So it’s understandable why people pick something that’s popular and capable.

Ok, why then do we pick Postgres for many projects that could be build on something simpler?

The ”YAGNI” motto usually needs to be combined with ”don’t paint yourself into a corner”.

Don’t get me wrong, I’m not a Next.js fan either. Could’ve widened my list of examples to any SPA libraries and server-side JS frameworks. I just wanted to highlight the issue with the analogy: unlike some criminal a police officer is using force against, the nature of issues to be tackled in most software projects will keep changing.

> suggests choosing the least powerful [computer] language suitable for a given purpose

This doesn’t work for projects that are planned to live for years and we aren’t sure of the scope of it beyond the next few months.

You may feel you completed all the current features neatly with HTMX or whatever, but what happens when later your PM or designer asks your team to implement, say, a complex multi-step form with a bunch of frontend state and validations?

People downplaying the need for tools like React and Next.js don’t usually acknowledge that these tools are used to ensure long-term flexibility of your tech stack and to maximize the talent pool to draw engineers from. It doesn’t matter if your site is slightly less broken for the few people that turn JavaScript off in their browsers.

> to the point some European CRT televisions frame-doubled 50 Hz video to 100 Hz, causing objects to appear doubled in motion

Hmm, this is not accurate (or I don't understand what you mean). 100Hz CRT TVs available in the 90s/00s did not interpolate frames to get smoother motion – they only existed to reduce flicker. I think such TVs also existed in NTSC markets (120Hz)?

Anyway, ever since the late 00s, pretty much all the TVs you can buy from a store do come with an interpolation algorithm to artificially display a higher frame rate image (e.g. 100Hz/120Hz) from a lower frame rate source (e.g. 23.976/24/29.97/30/50/59.94/60 fps) – which (personal opinion) looks terrible (and can be turned off from the settings – but the default is always on). This is an interesting side tangent when it comes to motion blur, because the blur is prebaked in the input signal and cannot be easily removed. Thus, the end result always has an artificial look.

For instance, if the source material is shot in 24fps with the typical 180 degree shutter angle, each frame spans 41.6ms of which the shutter was open for 20.8ms. Then your TV interpolates that to be 96Hz or whatever. However, the individual output frames still look (or, with the added artifacts etc., mostly look) like the shutter was open for 20.8ms per frame. However, each frame now spans 10.2ms which is a shorter time than the shutter speed!

> Anything is better than a laptop mic.

This is not true if you have a fairly recent Apple MacBook. The mic quality especially on the Pro models from the last few years is actually pretty good. I often ask people to switch to that mic in our Google Meets if they are using almost any bluetooth headphones (even high end Bose or Sony ones).

The v7 isn’t a silver bullet. In many cases you don’t want to leak the creation time of a resource. E.g. you want to upload a video a month before making it public to your audience without them knowing.

It’s mentioned in the article. It’s more to do with business intelligence than security. A simple auto-incrementing ID will reveal how many total records you have in a table and/or their growth rate.

> If you expose the issues table primary key id then when you create an issue in your project it will not start with 1 and you can easily guess how many issues exist in the GitLab.

The list is missing URL query params, arguably one of the more common yet underlooked places to store global state in web apps.