Cool article, but the one it acknowledges and riffs off of, at https://lr0.org/blog/p/arabic/ , is much more informative, and tells all about how we got decent Arabic script rendering on our browers and OSs, but still notably imperfect.
Which makes me think: come on, in the age of Claude, the gap between "we know what to do" and "here is the working code" is narrower than ever.
Who will be the one to pick up the job? Has to be an Arabic speaker I guess!
The point is not about what it means exactly to "own" something, you'll get plenty of noise discussion around that one.
But if I care about some piece of digital art enough to pay for it, I sure want a non-DRM copy to sit on my hd at the end of the transaction. If the store won't supply, the pirate sites will.
Redis is a great piece of tech but it suffers from trying to be good at two different jobs (persistent data structures, volatile cache) which should not be combined. And indeed in Redis itself they don't combine well - persistence is globally on or off.
Personally I'd use memcached or some equivalent for strictly cacheing, and then bring on Redis with persistence if you need its data structures for e.g scoreboards.
At $WORK we never imported either, our cache layer for slow operations keeps its data in both the filesystem and a db table (used as a k/v store). The database helps coordinate thundering herd problems - this operation is being calculated by another thread, so just wait for it. Reads from the same server just hit the filesystem, and reads from another server hit the db once and then keep it in the filesystem. We could change the fs layer to memcached but so far it's working great.
Search around, there's surely a way to break the drm. When theres no better way that's what I do too: pay for the book, convert to plain epub.
The publishing industry never got its head out of... some dark place. We've been able to buy mp3s without drm for ages, but somehow books are different.
Yep, if you haven't lost the will to put a bit of curation work upfront, RSS never stopped being the right answer.
Substack has been a pretty good addition to the landscape, bringing lots of people into blogging (without calling it that). But for the skimming/reading interface, RSS beats the app.
I've been using Claude to work on a medium-sized (100+kLoc) codebase, and it's a great productivity multiplier. Putting hours into creating a good AGENTS file is more improved results a lot. I find that over time it picks up the codebase quite well. Tedious tasks that would take a day are now a matter of a few prompts.
Still... I'm not ready to give it more autonomy. Even as it gets high-level things quite well, I still look at the code, give feedback, and have 3-4 rounds of tweaks until I'm happy with it, and also happy that I stil feel I have a good handle on the codebase.
I basically skipped React. I went from jquery to Vue3, and use even that sparingly. When React got really popular, I read the docs and played with it, but I prefer the Vue model where the component runs once and sets up its reactive tree. Why would you want to recreate the component's inner functions every time it renders? And manually declare dependencies, when every other framework is doing them automatically?
My favourite front-end architecture is MPA actually mostly server-rendered, with Vue only on the pages that need high interactivity, and vanilla JS on the others.
If postgres is too heavyweight for you but you still want client-server, I'd consider MySql. It's an old classic, pretty fast and scalable, and has much better mainstream support and a bigger ecosystem than Firebird.
I'm not really sure what Firebird is for at this point in life really. It was pretty exciting when it was open sourced in the early 2000s, before postgres became the mature beast it is, before mysql acquired something as basic as transactions, and before sqlite became the default embedded db. But then it never really went anywhere.
It's called euthanasia. You can ask the medical system for an assisted suicide if your life situation is extra painful with no hope for recovery.
This case got heaps of media popularity because the christian right wing latched on it, and the father tried as hard as he could to impede the euthanasia. Ultimately got told that the lady unequivocally wants it and qualifies, and he can't override that.
What kind of context has you deploying into old systems that don't ship a recent perl? If that is a legacy requirement for whatever reason, then at least I'd use docker or podman to get a recent runtime. Or would you also write Python 2 or Php 7?
What are you using for parameter type checking? I switched to native function signatures, native try/catch and might look into the new class system soon, but I don't recall native type checking...
This looks like a huge project, even with AI help... I have a sweet spot for perl but I'm honestly not sure if the current community has the bandwidth and interest to sustain an alternative implementation. At the very least it should be ported to MacOS too. Breaking with XS is a bold decision. Best of luck though!!
Alcohol has been deeply embedded in human culture for thousands+ years, that's why prohibition is a bad idea. Loot boxes are a new invention, if they're deemed too harmful we can just do without them.
It's amazing how people will jump to something new just because it's there and it's being promoted.
When wireless headphones came out, I looked at my wired ones and asked the simple question: is a tangling cable worse than bluetoth pairing and having to keep yet another thing charged? My answer was no, so I kept using cheap wired ones.
A few years later, now that makes me look rich. Or something.
I guess it's really not for me though. First thing I do is turn autoplay off, and I'd refuse to use a service that doesn't give me that option. OTOH, I do sometimes find it fun to hunt for good stuff among the recommendations.
You've probably already done this, but first thing, turn off autoplay and make sure it stays off. Much easier to not get sucked into things when you have to actively click on them.
Why would you want to do that? I'm so happy I can search exactly what I want among heaps of long tail stuff, I would never want to go back to a "live tv" interaction model.
For most situations, I deal with this by keeping dates as strings throughout the app, not objects. They get read from the db as strings, passed around as strings. If I need datetime calculations, I use the language's datetime objects to do it and convert right back to string. Display formatting for users happens at the last moment, in the template.
No-one seems to like this style, but I find it much simpler than converting on db read/write and passing datetime objects around.
Which makes me think: come on, in the age of Claude, the gap between "we know what to do" and "here is the working code" is narrower than ever.
Who will be the one to pick up the job? Has to be an Arabic speaker I guess!