My theory is that vibecoded replacements haven't succeeded for the same reason why GitHub's quality has declined: because vibecoding/AI software development isn't as efficient as believed when measuring real-world outcomes.
I use a Moonlander keyboard: https://www.zsa.io/moonlander It's very easy to change the layout on these boards since you can do it directly from their website.
That's basically what an LSP is. It's true that it's built on top of the file system, and most IDE users will navigate using the folder hierarchy, but it still stores information about the name, type, and connectedness of the codebase, and allows querying. Your idea about arbitrary tags (feature, environment) would be useful but does not seem to be supported by the spec [^1] yet.
> proximity of this federal U.S. District Court to the defendant’s country of citizenship, Australia
This is a little disingenuous, and made me chuckle. It's faster and cheaper to get to Australia from the US mainland than it is from Saipan. Yes, it's physically closer as stated, but does not confer the claimed benefits.
This is an amazing project and I'm glad it exists. My college capstone project was building a 3d scanner, and we were able to use POV-Ray to create a repeatable test environment for our algorithms. Wish I had an excuse to play around with it nowadays.
For anyone interested: the article mentions “How to Hide an Empire” by Daniel Immerwahr. It's a very well-written and well-researched book -- Immerwahr does a great job creating a narrative from all the historical events in the book. The reason I mention it here is because it goes into detail about Americans' reluctance to grant full citizenship to residents of its overseas territories.
Flight costs are a pain, and the flight durations are nothing to sneeze at either. I live out in Guam (my wife is stationed here with the Navy) and the two most common ways to get back to the mainland are via Tokyo (Narita) and Honolulu.
I would definitely encourage visiting if you have the means! I find there are two types of people here: those who feel limited by the island and its infrastructure (no Target, no Starbucks, etc.) and those who enjoy its incredible outdoor environment. Some of the best snorkeling and scuba diving in the world is right here, and as for hiking: we've been hiking very frequently for the two years since we arrived and haven't gotten bored yet. Depending on where you go on the island, the terrain and plant life looks very different.
This article brought to mind a different but related scenario. I live on an island that was recently affected by a typhoon. Internet speeds are usually pretty good, but in the aftermath of the storm cable internet has been up-and-down depending on the day, and the cell towers are very spotty. I've found that most modern apps depend on a high-speed connection, and give a very poor experience otherwise. Of course this seems obvious in hindsight, but it's a different experience living through it.
It’s ironic that VS Code has become the premier Electron-based IDE, since Electron (originally called Atom Shell) came from the original Atom project.
I loved using Atom, and I like that there’s a community trying to keep it going. However, I think there’s value in trying to push the platform forward, too; maybe rethinking the extension model to maximize stability/performance would allow Pulsar to start stealing market share back from VS Code.
I work from home, in a home office with no sane way to route an Ethernet cable to, and I've been feeling the crunch during video calls. We have a wifi-enabled baby video monitor in a corner bedroom, and from my experience it's been proving "Rule 10: Your Wi-Fi network is only as fast as its slowest connected device" (see source [1]). My best-practice workflow has been to unplug the camera before an important video call.
I remember this fondly from SimCity 2000, where you could build a "microwave power plant" that would collect beamed energy from space-based solar panels. (If I remember correctly, sometimes the beam would get out of alignment and set fire to nearby neighborhoods.)
One thing that I believe is under-documented in code is _business decisions_. The team arrives at a decision in a meeting or informal discussion, and it leads to some code that might be tough to understand without context. I'll usually add a comment briefly describing the decision, and initial and date it.
Initially I would just link to a wiki page in a comment, but occasionally these links break, so in my experience it's better to include the notes directly.
I love JavaScript but agree with your point about hype fatigue. At some point, you have to ask yourself if you're using JS to solve your problems anymore, or if you're just allowing yourself to be nerd-sniped by all the trivial choices you can make.
It's like [Obama's suits][1]. JS gives you all these little decisions you _can_ make, which wear you down. As soon as you stop caring and decide to "just pick one", you'll generally be fine.
Wonderful; now we can proactively modify Curiosity's code to act as an interplanetary telegraph so Matt Damon doesn't have to do it once he gets stranded there.
Viewing it on OS X, it looks like they're using the San Francisco font. A little jarring if you're used to seeing the old typeface 20+ times/day, but it looks good.
Generally I'll copy it to the clipboard (usually `pbcopy < file.json`), fire up Chrome, Cmd+Alt+J, then paste into the console. Instant, attractive, collapsible rendering of the content. Usually when I do this I'm interested in performing some sort of transformation on the data, and this way I can prototype it without any further steps.
Yeah. The two differences seem to be that end-users are guaranteed to be able to use their own version of Qt (because Qt is LGPL and the user should be able to modify it) and that now there's more protection against patent claims.
Somebody correct me if I'm wrong or missed something.
EDIT: oh, and I forgot the GPLv2 -> v3 bit, but that doesn't affect your use case.