dwg

Same logic applies internationally.

Glad to hear it!

I found that Sash forward switching works about 97% of the time, but still occasionally has a hiccup. Have not been able to pinpoint a cause yet, but I find that even in that case the reverse shortcut still works.

Even without that, I find myself using the reverse shortcut more than I thought I would, so that was a good suggestion.

Information and entertainment are less scarce today than the 1960s. Expensive is not just relative to what it used to cost, but also relative to value.

Added reverse hotkey setting (defaults to none).

Jitteriness has also been addressed.

New release available on GitHub. Please set the forward shortcut again too.

As a counterpoint, perhaps there is a sort of "natural selection" which will drive better abstractions due to being more token-efficient. Albeit perhaps a relatively smaller effect.

Glad you find it useful.

I found cmd+backtick broke in many other situations too. Was driving me mad.

Didn't think reverse cycling was worth it since most apps only have a few windows open. Any use case you have in mind?

Wish I had the courage to do this too.

what are the default values, in case someone wants to restore them?

Love the irony: Man builds a Gemini-style feed aggregator for small web, finding it, well, not so small.

In case it was not clear, that is exactly my point: a language designed for Japanese could open up the possibility of incorporating symbols other than those readily available on QWERTY keyboards.

And my other point is that != is _harder_ to type in Japanese input mode because you constantly have to manage full-width vs half-width input.

@apt-apt-apt-apt pointed out in a separate comment that: >A simple translation of keywords seems straightforward, I wonder why it's not standard.

I replied that for Japanese at least, probably due to symbol input being too tedious. However I think it's worth mentioning a potential mitigation, and maybe even an advantage.

As a mitigation, full-width symbols could be used instead, which are typically the default in Japanese input. Japanese itself is also fixed-width so if done across the board the language itself becomes fixed-width, not just by virtue of a font selection.

As an advantage, some logical symbols, greek letters, other rare characters are easy to input in Japanese mode, and this could lend itself to a more symbol-heavy language design. I already take advantage of this myself with Δ, φ, and τ use selectively in a few projects. Symbols with easy entry may differ by OS, but here are a few other examples that could be useful:

≠, ≡, ∞, ∴, λ, θ, α, β, ・, °, ※

I can't speak to Korean, but thinking about Japanese, one probable reason it wouldn't catch on is how tedious and inefficient it would be to constantly switch between input modes. Japanese input mode is designed for prose, and isn't well-suited to efficiently entering the symbols commonly used in programming. Even spaces. It results in needing a lot of extra keystrokes.

Your choices are not limited to one extreme or the other.

...severe consequences for data breaches...

Often had the same thought, if not shared same opinion. On the other hand, stiffer penalties have the trade off of incentivizing cover-ups, i.e. disincentivize honest disclosure.

Zooming out before taking screenshot and the text is no longer obfuscated. I tried and confirmed it works. In fact, the text is perhaps even more readable than the original.

Essentially agree.

Nonetheless, if reports are to be believed the post-rule change decline is significant, and I can’t help but wonder how big of a positive feedback loop—in other words a bubble—was being created. The gap was, after all, built up over several decades.

The usual culprit you mentioned, perhaps aren’t as much of a factor as we usually ascribe to them.

Just speculating.

Thanks for sharing the report.

Japan has required amortization of capitalized software over five years for qualifying internal-use software since at least 2000. Correct me if I’m wrong, but I believe most other countries have similar rules.

Until 2022, U.S. companies had a real competitive advantage.

Software developer salaries in Japan are depressed—other roles too, but especially engineers. Without digging too deep, perhaps the previously unfavorable (now roughly equal) tax treatment of was perhaps a contributing factor.

I had the same thought. Still, perfect or not, I bet it'll be an attractive option for some.

I guess our gmail content has been fed into an AI of sorts since many years ago. I would surely hope, however, that Google would not use it for any sort of non-private LLM training data.

I've suggested this elsewhere too, but have you considered a mailing list instead?

It ticks the boxes about notoriety—which appears to be the main concern of the OP author—with the added benefit of being more difficult for AI systems to crawl for training data.

Perhaps we'll see more bloggers going the way of a bespoke mailing list.

Makes me wonder, how about changing your blog to a mailing list?

Anecdotally, I once shared a house with a Russian student in Monterey, California. He told me he was amazed by the quality of our roads compared to those in his homeland, though I don't recall which part of Russia he was from.

I grew up in rural California. Despite living quite remote—about 25 kilometers from the nearest town—by my standards our main roads were well-maintained. However, numerous smaller side roads branching off to serve sparse residential areas, sometimes leading to just a handful of houses, were another matter. I wonder if California has a larger proportion of these minor roads skewing the results. Yet paradoxically, two major urban centers, San Francisco and Los Angeles, are it would seem quite terrible.

Agreed.

We try to use browsers standard features whenever possible. Despite looking into using the built-in validation, it's never been worthwhile. Too many gotchas, and we end up using a library to be able to easily support more complex checks anyway.

Furthermore, using a library opens up, in some cases, the possibility of sharing some of the validation code between front and backend.

In particular this article seems to work around one of the issues with `useLayoutEffect`. Not something that should be done lightly.

Are you certain?

I appreciate your thoughts on the value of mind wandering and creative thinking. While I agree that many institutions necessarily focus on immediate outputs, I've seen interesting counterexamples - from companies institutionalizing 'free thinking time' to schools incorporating mindfulness and creative thinking exercises. There is always room for improvement, but perhaps the landscape is shifting to better recognize these different thinking modes. Or, more likely, it has always been recognized, capitalized on, and very highly appreciated when it happens to produce valuable output, probably in almost any organization not just those encouraging free thought.

What has been your specific experience with this in schools or workplaces?

Yep, it often makes more sense to go by car (especially when you can fill your car up), or you want to use your car at the destination (though renting is an option here).

Sometimes going by train is just more pleasant. Kids don't need to be strapped into carseats, repeatedly asking "are we there yet?" You can go to the bathroom or stretch your legs any time. You can do other things, such as enjoy the scenery or read a book. Also, last time I checked, trains are lot safer than cars. There is no traffic. Finally, you don't have to drive!

If you like, you might consider soft factors in addition to the fare :)

I hope trains become more popular, and train travel is reinvigorated in the U.S!

Not making any judgements, but just for comparison, here is a Japan train explorer: https://roote.ekispert.net/rmap/fullscreen.

For context, Japan is roughly the size of California.

Worth mentioning that the population of Japan is about 1/3 of U.S., and if the chart was population adjusted it would look different.

I'm on the same page, but was wondering if there would be any concern about liability on the part of the company that released the code (mandatorily, as suggested).

I'm not saying they should not be required, as I have not thought about this deeply, but in whichever way I imagine this playing out, it seems likely to lead to situations in which people are using some device with a lot of security vulnerabilities that were made much easier to find and exploit once the code was opened up.

Yes, ideally let the browser handle it, and in many but not all cases that is possible.