Because, trust me, as someone who's worked at multiple B2C companies with large customer service departments, everyone absolutely knows, which is why us in the engineering department were always happy to buy the rounds at cross-company happy hours.
3,882 karma · joined March 12, 2011
website: thomasboyt.com
Because, trust me, as someone who's worked at multiple B2C companies with large customer service departments, everyone absolutely knows, which is why us in the engineering department were always happy to buy the rounds at cross-company happy hours.
I've been thinking of taking a peek into Java, which I've never really written[1]. Is the general thinking that, for something like a Spring Boot application, it's much better to just start with Maven? I'll admit I am, aesthetically, displeased with the mountains of XML config I've seen in some tutorial articles, but I imagine it's a lot simpler to maintain over time than any DSL would be.
[1] slightly off-topic, but if anyone's curious why: I haven't been very impressed by any of the "Kotlin-first" JVM libraries I've seen (like ktor or exposed), I think coroutines are neat but much more suitable for main-thread-focused situations like Android apps than something more easily threaded like web servers (and with Project Loom hopefully upcoming in the next couple years this might be a moot point soon), and I don't like the JetBrains tooling lock-in (e.g there's no well-supported language server for Kotlin, unlike what Red Hat's been building for Java)
> Supabase is an amalgamation of 5 open source tools (and growing). We don't have a simple way to install everything on a single server, but we will work on this as soon as we have a stable set of features.
Now, it's fair to say "we don't have a simple way" is different from "we don't have a way at all," but you clearly discourage users from trying to self-host right now for any reason beyond developing Supabase itself (which appears to be the use of the Docker Compose setup you have linked).
Personally: I'd love for Supabase to have a clear guide for self-hosting, including system requirements for single-box hosting, advice (even without code or tooling!) for scaling your setup, etc. Until then, it's just another hosted service with vendor lock-in, no different from Firebase to me.
It really is wild how the VSCode language server architecture enables all this, btw. I'm not sure whether this was an intentional goal of the LSP when they started working on it, or if it was originally just to keep the language analysis in a separate process and this wound up being a nice benefit, but being able to run all of your editor's language features on another box and just use the editor as a dumb client for them is brilliant.
Truly amazed at the number of companies that set up social platforms like this and then refuse to actually moderate them in any way. While it's obvious Tesla "could afford" to moderate it, it's also probably the kind of line-item no one actually considered being part of running a forum. I'm sure they think of a forum's overhead as just being hosting and maintenance, without considering the human cost of moderation until they were forced to, at which point they said "eh, fuck it."
We all talk about the moderation problem a lot with massive platforms like Facebook, but the number of people who just think "let's just throw up a small little forum/Reddit clone/Discord channel for people to talk to each other on" and then don't consider that, maybe, there might be some bad actors on there, is... I dunno, the majority, it seems.
Maybe it's because I grew up posting on forums like Something Awful that were famed for strong moderation, and IRC channels with as many ops as lurkers, but it almost seems like this was a weird forgotten aspect of building social platforms. I kinda blame the proliferation of upvotes and downvotes, which people seem to think is a replacement for moderation.
It's not enabled by default (it's part of Strict privacy controls), but I think the heuristics it's using might be copied by other browser or extensions implementing similar features. I don't love the amount of "heuristics-based" features being added to browsers, since they're not always easy to discover as a developer, but it's certainly better than a whitelist/blacklist system like Google"s used for certain features. The console.log entries that article mentions should help a bit with debugging as well.
I'm personally thinking of getting a split keyboard soon, but I'm so split on what I want. Currently using a Preonic and find the ortholinear/compact layout fairly pleasant, so I might just want to get something like the Let's Split. Still, I can't decide if I'd prefer a board with thumb clusters and/or staggered rows (like the Ergodox).
I'd honestly be fine going back to a more traditional layout on a split keyboard (not ortholinear, punctuation keys in normal places, all that stuff), but I've been really unimpressed by what I've seen of those in terms of features. I really want QMK, and I'd also like boards that are flat/don't have a strong tilt since those tend to be a bad ergonomically (in fact, I'd ideally like optional negative tilting). I also want something that's relatively low profile, which is also tricky to find in my experience.
As this notes, there's several changes you have to make to your assumptions around the ORM interface. SQLAlchemy, for better or worse, supports "lazy loading" of relationships on attribute access - that is, simply accessing `user.friends` would trigger a query to select a user's friends. This kind of magic is at odds with async/await execution models, where you would instead need to run something like `await user.get_friends()` for non-blocking i/o.
It looks like they've done some good work in making the ORM layer work reasonably well with these limitations (https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.htm...), but I wonder if removing "helpful magic" like this will push more people to stick with the query-builder, rather than the ORM.
My sister now lives in Decatur and I've been looking at some of the apartments near the MARTA stations there, and they're unfortunately mostly exclusively new luxury buildings (which I am very lucky to be able to afford on my current salary, but maybe not at a local job, or an adjusted-for-relocation remote one).
Frustrating how there's so little walkable development around the MARTA stations other than Decatur's, and what there is is so expensive. Of course, I could deal with a five minute park and ride, but it's kinda the principle of the thing.
That said, I've always been a little worried about trying SQLite since I'm so used to Postgres. I've currently got Postgres running alongside my app in a Docker container, which isn't too hard to manage. I'm curious whether anyone has switched from Postgres to SQLite in a web app context (whether in the same project, or when making a new project) and if they've found themselves missing any of the features Postgres offers. I've tried to research this before but always found just googling "sqlite vs postgres" just results in surface-level differences that mostly focus on performance, whereas I'm more curious about e.g. the differences in their JSON extensions.
However, while that article says they will not be able to be a collective bargaining unit under US law with that structure, the announcement oped in the NY Times (https://www.nytimes.com/2021/01/04/opinion/google-union.html) implies they will be pursuing becoming one, so not sure if that nontraditional structure is temporary or if the Post got some details wrong.
I can't help but think of the ol' "I never thought the leopards would eat _my_ face" tweet: https://twitter.com/cavalorn/status/654934442549620736?lang=...
Centrist Democrats have been trying to get this moderate base for a while, and leftist Democrats are obviously gonna support legalization, so this seems like the rare case where they actually get to be aligned on something broadly and would push it if they were in power.
It is odd to me that they would preemptively go loud on this, drawing attention to a story that might not even get that much traction. It seems like it would have been much easier to just let that story go out and respond with a simple "We've investigated this before and dispute the claims, except for these few unfortunate stories we can confirm happened, and here's how we will prevent them in the future." What on earth do they gain with a preemptive memo like this? Are they really scared of their employees leaking this? Would anyone even pick up a story of "someone's about to publish a bad article about Coinbase"?
(I have quite a few friends who have some fondness for what Glitch-the-game was trying to do. Always appreciated that they open sourced the art from it: https://www.glitchthegame.com/public-domain-game-art/)
process.on('unhandledRejection', (err) => {
console.error(err.stack);
process.exit(1);
});
Had become as second-nature for me as "set -euo pipefail".Login/password and scraping is a more interesting alternative, but then Spotify would presumedly block any server-side scraping. Really, best option I can come up with is browser automation that is entirely client-side (whether a browser extension or maybe wrapping Puppeteer).
For example: their web playback SDK has a provision about "contact us to use for noncommercial purposes," and there's a long-standing GitHub issue specifically about how no one has ever gotten a reply back when they email about this.
Meanwhile, when I had a problem with MusicKit JS - the Apple Music equivalent - I actually got a reply back within a few weeks from an Apple engineer about it that helped me resolve it. Obviously not the shortest timescale, but at least there's clearly some effort being put into it. It helps that they actually are using MusicKit JS to power their own Apple Music web player, while Spotify's playback SDK is a separate codebase, which is why it's missing features like Safari playback that are present in the web player.
Spotify's new mobile SDKs are also unusably awful, and can't do basic functions like "playing a single song and stopping instead of autoplaying onwards." They also have deprecated and killed off several past mobile SDKs that were far more feature-filled. I saw a new Spotify-powered radio app that launched recently (Station Rotation) appears to be using the legacy undocumented SDK for playback because of this - can't imagine that app will have much of a future if Spotify ever decides to finally break that SDK.
Honestly, I expect Spotify to completely kill their public APIs and SDKs within the next two years. They clearly see no value in them, or they would have invested in maintaining them.
I've currently got a web app I'm just self-hosting on a DO VPS for $5/month. I have a Postgres DB on the same VPS (via a Docker image), with a 10-line shell script & cron job for backups to Backblaze B2 (which costs ~nothing/month for my tiny DB).
Additionally, my web app is a Kotlin API and a Nuxt.js SSR server, so I think I'd have to set it up as two separate "apps" on this platform. That means I'd be going from $5/mo to $25/mo.
On one hand, that's not a ton in the grand scheme of things. On the other hand, the whole reason I use DigitalOcean and self manage my infrastructure is to _not_ have to pay that kind of money for my projects with no revenue.
To do so, they use credit card verification, a commonly-accepted way to verify an of-age user that satisfies COPPA/similar requirements. Credit card verification generally works by placing a small authorization charge that is shortly refunded. This is explained here: https://parents.nianticlabs.com/faq/
There are a variety of reasons they likely can't use IAP for this. Two I can think of are that (a) IAP may not be sufficient enough for COPPA, if e.g. a parent has allowed their child to make purchases using a gift card balance, and (b) they likely have no easy automated way to refund this fee if handled through IAP.