People just don't seem to understand that to do SSO properly and securely for your app it costs decent money and support time. Regardless of if you roll your own or buy 3rd party (recommended). We do include SSO by default but we really only sell to enterprises and the price is baked in. A lot startups won't have that luxury.
I'm in the same situation! Not in the Carribean..yet, but traveling around U.S. coast in a trawler with my husband. Never would have been possible without Starlink. I would have had to wait for retirement that probably would never have come.
Agreed that owning a boat is a lot of work! I need to remind friends it's not all relaxing with cocktails!
Yeah, and not every scrum implementation needs to have a ton of meetings. We do 1 week sprints with no 15m daily stand-ups and a monthly or so retrospective. If someone is blocked I don't need them to wait to the next day to bring it up in standup. That's why we have group chat collaborarion tools after all right??
A lot of comments for Postgres, but it's the only major DB in 2023 that does not let you choose your character collation when creating a database. That is pretty much a deal breaker day 1. Guess you'll be doing a tolower() on every db search and not use indices which will kill performance or using column collation casts on every search query. I just don't get it.
I once tried to migrate a SQL Server DB to Postgres and eventually gave up, with MySQL being a pretty easy switch with some minor stored procedure rewrites.
Also it tends to do things way differently than every other DB. VACUUM is just a completely different concept that can footgun you pretty fast.
Postgres is pretty powerful but it has certainly made some interesting design choices.
> doing a tolower() on every db search and not use indices
If you create the index with lower() it will uses that; e.g. "create index on tbl (lower(email))" and then "select * from tbl where lower(email)=lower($1)". That's more or less the standard way to do this but there are some other ways as well. It's more explicit than MySQL, so in that way it's better. It's more effort and easy to forget, and in that way it's worse – either way: it's definitely possible to do case-insensitive searches with indexes.
When I first used PostgreSQL I ran in to "how the hell do I do this?! MySQL just lets me [...]" kind of issues, but after many years of PostgreSQL usage I now have the opposite when I use MariaDB, which also has its share of awkwardness and issues (just different ones).
> It's more explicit than MySQL, so in that way it's better.
It sounds like you're under the impression that MySQL just makes everything case-insensitive and is silent about this? That's decidedly not the case.
MySQL 8 ships with 41 different character sets, supporting a total of 286 different collations. Collation names explicitly include "ci" (case-insensitive) vs "cs" (case-sensitive), as well as "ai" (accent-insensitive) vs "as" (accent-sensitive), and also the language/region conventions used for sorting purposes.
You can choose collation at the column-level granularity, as well as setting defaults at the table, schema, and server levels. It's completely explicit and very configurable.
Eh, just from a SQL query alone, there's no way to see that (lower(email)) is indexed, or see column data types etc. That metadata lives in the table definition, which is a normal place for it, so it seems reasonable for the collation / case-insensitivity to not be explicit in the query text.
Besides, MySQL also supports functional indexes, so you could do the (lower(email)) approach in MySQL too if you really want!
No, you can't see everything, but you can see the exact comparison it's making. Is that useful? You can decide that for yourself but I like being able to see as much of the logic (and thus verify the correctness) in the query itself. Also helps with copy/paste and some other things.
I never said you can't use functional indexes in MySQL. Someone said "you can't do this in PostgreSQL" and I just commented "here's (one way) to do this, maybe that's helpful some day". That's it.
I was disappointed with MariaDB and tried it before using MySQL. It is so far behind MySQL that it can't be considered equivalent anymore. And I really wanted to use MariaDB instead.
The "MySQL just lets me" stuff eventually adds up and hinders development. For example, your lower() on the param example is now incompatible with most ORMs unless you do that in code or create a special SQL statement for that. This isn't all fringe cases that you run into when you're months in either. I really wonder on some of these comments saying they've vetter both and Postgres wins hands down.
Postgres is solid but it definitely has its warts and downsides too.
I'm sorry, I was wrong in that Postgres does let you specify a few character collations at the DB level, but they are pretty much ASCII vs UNICODE with no case-insensitive configurations. You can create collations in v12 and assign them to particular columns.
I don't get Latinx term at all. And hardly ever see it used by native speakers. It's like they're telling Spanish speakers their language is inherently bad because it's gendered. It almost comes off as a "white savior" thing where someone felt like they had to fix it. For context, I grew up bilingual.
Redis is great, but sometimes it isn't always the best solution.
We almost configured it, but instead implemented our own Cache web service and used the built in memory/cache management of that. Yes, it's only accessible via http but it's given us a lot of flexibility. We are primarily using it for caching of large datasets (hundreds of MBs). When service has to be restarted, it makes a call to get all the items it needs.
The company I work for is in the healthcare tech space and we all generally despise Epic. But when I saw the MyChart app, I was really impressed.
Also, we were in the ER recently, and my spouse got their test/lab results on their phone before anyone came in for like 30 mins. It was all good news.
But probably don't want that to happen if someone ends up having cancer..
Google Photos is that silent offering that wasn't a big deal initially, but just slowly grew into easily the best option to store your years of smartphone photo memories. I pay for it and will always pay.
Chromebooks were also the thing that started out slow, but now are pretty ubiquitous.
It's unfortunate Tumblr made the move to ban explicit content in the first place, but it's definitely not dead. It may not be what it used to be 10 years ago but it's still what I'd rather browse through than what Twitter has become. A lot of the porn/fetish/niche blogs that left may not come back and I don't blame them but at least they have the option.
People just don't seem to understand that to do SSO properly and securely for your app it costs decent money and support time. Regardless of if you roll your own or buy 3rd party (recommended). We do include SSO by default but we really only sell to enterprises and the price is baked in. A lot startups won't have that luxury.