26
points
SPBS
Joined 1,534 karma
- > Amazon / Google / Microsoft offer managed versions of the database and make bank on it. Easily millions in revenue. Original creator / company doesn't get anything, and the hyperscaler isn't obliged to pay.
This isn't what is happening. A company called Garantia Data renamed themselves to Redis Labs and acquired the Redis trademark. They're not the original company, and they used a naming trick to present as if they are official (they are now, and nothing they did was illegal).
https://www.hackerneue.com/item?id=42256757
https://www.gomomento.com/blog/rip-redis-how-garantia-data-p...
- Headers are missing IDs for URL fragments to jump to e.g. https://strongly-typed-thoughts.net/blog/zig-2025#error-hand... doesn't work
- 1 point
- > Spaces should be used to line up the code so that the root keywords all end on the same character boundary.
This style is annoying and I wish it gained less traction. It looks neat but it puts so much burden on the query writer, especially when you modify the query and all of the sudden you need to indent multiple lines just to make them all align. You know what's neat and still easy to modify/diff? Just indent a new line for each row.SELECT file_hash FROM file_system WHERE file_name = '.vimrc';SELECT file_hash FROM file_system WHERE file_name = '.vimrc'; - Sometimes Software is Done, or Why Hugo Why (2024)
https://commaok.xyz/post/on_hugo/
> When I first used Hugo I loved it. It was fast. It was simple. It just worked, as much as any software does, and it solved a real problem.
> It was done.
> But people kept working on it.
> I’m sure that it has been improved in countless ways. But along the way it has gotten bigger and more complicated, and has broken backwards compatibility repeatedly.
- Too much layering. Code like this makes a huge song and dance around what is ultimately issuing an SQL query to the database and returning the results. The solution must always scale scale scale, never mind that simple problems should have simple solutions. A simple solution can always be refactored into a more complex solution, but not the other way round. It's always a safe bet to start with a simple solution.
- I think anything other than deferring Close() and then calling Close() again explicitly is overengineering. Like anything that requires creating a cleanup function, capturing a named return value, requires contorting in unnatural ways to handle a very common scenario. Just... defer Close() the soonest you can (after checking for errors), then call Close() again at the end. Most sane providers of Close() should handle being called multiple times (I know os.File does, as well as sql.Tx ).
- but if he was a scammer, "Adam" didn't have to follow up with a vitriol-filled email chain after abruptly hanging up. This felt personal, he genuinely felt wronged because the small startup calling him back for an interview was not begging to get him on because he was the "best Node/React developer in San Francisco by far" just from looking at his GitHub profile alone.
- > But it certainly is not something you'd want for writing the documentation for an enterprise-grade product.
MDN documentation is written in markdown. I’ve always felt this was a resounding endorsement of markdown over other more “powerful” markup languages because if they can do it, why can’t you? (not you in particular, but anyone who thinks markdown is inadequate for docs)
https://developer.mozilla.org/en-US/docs/MDN/Writing_guideli...
- Hard disagree with the premise. It's disingenuous to pretend there isn't a difference between knowing how to resolve an interpersonal conflict vs knowing the calculations needed to build a bridge. Yes, the skill ceilings may be high, but the skill floor is clearly different.
I'm not downplaying soft skills, by the way. Soft skills are what get you successful in life. And the disdain some people have for soft skills vs hard skills is uncalled for, but that's a separate issue. Technical skills clearly mean something technical.
- > You think your surrogate key will save you? It will not. The world has an external reality that needs to be reflected in your database.
Yes, it will. It is precisely because of a messy external reality that you need an unchanging internal ID that is unaffected by changes to the external ID. If the software designer in the article had followed your advice, changing the chassis number would have likely resulted in broken car ownership records.
Whoever is reading this in the future, please don't follow the parent comment's advice. Use surrogate/synthetic keys for your primary key.
- I don't understand what you mean by easier way, because it's always going to be a script. Unless you mean some low code/no cool tool that was already tailor made to do this.
If you're worried about data not fitting in memory, then stream the file. It seems like the Java API has support for this, surely other languages do too.
- No, I am adamant that "sequel" is worse than "ess que ell". Most people who learned SQL on their own already call it "ess que ell" (a lot of my colleagues at work), because they never had a greybeard over their shoulder saying it be called "sequel". There's zero benefit in insisting it be called "sequel" other than to introduce an additional bump for people learning it all over the world. Reject sequel, join SQL.
Also, anecdotally it seems like the "sequel" preference is relegated to the old-timer Oracle and SQL Server crowd, whereas the newer Postgres/MySQL/SQLite crowd prefer to call it "ess que ell" (simply because it's the obvious way to say it).
- > All I want in a tablet is a nice screen, fast CPU, and quick switching between apps.
> What magic features does an iPad have?
> I am somewhat jealous of is battery efficiency of the fanless macbooks.
I want good battery efficiency on my tablets as well, and I doubt any Android tablet could match that. It's a tablet for god's sake, the whole point is to not have to tether it to a power outlet for any prolonged duration of work.
- I can't believe they changed this too. It's like context doesn't matter, as though "Man" wasn't used in a gender-neutral way in the term "Man-In-The-Middle".
People are free to choose to say PITM instead of MITM if they feel the original term is offensive, but it shouldn't be forced onto everyone (e.g. GitHub issues nagging maintainers to change MITM to PITM in order to be more "inclusive").
> This is very important both for cache locality and for minimizing garbage collector pressure.
How is C# just not straight-up faster than Java then? Instead of both language punching around the same weight on benchmarks? Doesn't cache locality like, have a huge effect on performance?