avolcano

Do you think that, if you don't publish those salary bands, the employees in those different departments will somehow _not know_ that the other departments get paid more?

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.

Interesting discussion here. I've been very happy with Gradle for my first major JVM project, a small Kotlin API with a simple build configuration (https://github.com/thomasboyt/jam-buds/blob/master/rhiannon/...). I suppose I'm not surprised to see more complaints from folks who have worked with it on much longer-lived and _much_ more complex projects.

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)

I think this is a bit disingenuous to post. Your own website[1] says:

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.

[1] https://supabase.io/docs/faq#how-do-i-host-supabase

I've been interested in doing something like this ever since VSCode remote work has become stable. My main side project right now is a Kotlin backend, so I'm waiting for IntelliJ's very-very-new remote features to get a bit more robust (they just added some abilities for WSL and run targets on remote platforms in early access, but I think you still can't e.g. run your IDE's analysis engine on a remote box and avoid local builds entirely yet). That said, if you're able to live entirely in VSCode & command line, you'd be all set here.

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.

In the replies of a March 2 Tesla forum post announcing the 13-day countdown until the platform’s demise, one commenter with supposed “inside info” alleged that the forums were closing because Tesla couldn’t afford to hire multiple full-time moderators to keep up with the barrage of spam and trolls that would frequent the threads.

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.

Ah, gotcha. I actually do have a good use case for that as well (and do think they could go together nicely someday), so I'll still check it out!

This is both a great post and an effective ad - I've been looking for a lighter-weight Postman alternative (and HTTPie, while nice, is no substitute for a graphical UI for such a thing). Will check HTTP Toolkit out!

Of course, in a post-IAP world, you can just charge users multiple $50 "best value" virtual currency purchases over several months, which they can then use to roll for video game items that will 99% of the time be of no use to them.

The technical details of Total Cookie Protection are going to be of interest to any web dev: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Pri...

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.

This is a neat gallery!

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.

One of the most interesting 1.4/2.0 changes is first-class asyncio support, not just for core (the query builder) but for the ORM layer as well: https://docs.sqlalchemy.org/en/14/changelog/migration_14.htm...

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.

The traffic is really fucking bad, to be honest - I've been considering moving back to metro Atlanta post-pandemic (grew up in Gwinnett County, currently up in NYC, still go back to visit 2x a year) and it's the biggest concern I have with taking a local job. It's definitely as bad as LA or Houston (and the pure sprawl seems to match the latter). I'd probably try to rely on MARTA and that's tricky to do even if you want to.

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.

Thanks for linking this! It intuitively made some sense to me (no IPC/network overhead) but neat to see them point this out as an intentional advantage.

I've been building a web service on a cheapo DigitalOcean box lately, so I'm excited to see explorations in this space, especially with an eye towards staying cheap! I'd probably only use this particular tool if it could hook up to Backblaze B2 instead of S3, since life's too short to ever have to engage with the hell that is AWS for a hobby project, but since B2's API-compatible it seems like a feature that could be added in the future.

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.

I don't really understand this. I've never seen a package of plant-based meat and found myself confused, much in the same way I've never seen a carton of oat milk and thought it contained dairy. What's the concern here?

I'm curious about both, and Rust for APIs in general. While I'm excited by the expressiveness of the language (compared to e.g. Go) and how robust the type system is. Right now, though it feels like a bit too much of a barrier both in terms of learning the language and the smaller ecosystem right now (this article covers a lot of my concerns: https://macwright.com/2021/01/15/rust.html). Still keeping an eye on it and would gravitate towards it if I had a smaller service that needed particularly high performance.

Ah, thanks, I hadn't realized that's the underlying library! Runtime validation of types is absolutely the largest missing feature from TypeScript, IMO, so Pydantic is really impressive to me.

I'm excited about Python's typing potential. I recently rewrote an API from TypeScript to Kotlin since I am fairly unhappy with the server-side TS ecosystem, but ran across https://github.com/tiangolo/fastapi when exploring options and really dig it - seems to be by _far_ the lowest-ceremony way to make an HTTP API with static types that integrate with parsing/validation (something TypeScript is still really bad at, unless you bring your own runtime typing libraries...).

Wapo has more details about the structure of the union, which is apparently nontraditional and won't go through NLRB ratification: https://www.washingtonpost.com/technology/2021/01/04/google-...

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.

Have to say, there's a decent number of photos on his Twitter feed of him doing campaign events with folks who don't have masks on (though it looks like he himself was consistently wearing a mask as of late). It might be that he personally wasn't a mask denier, but the Republican base has often taken mask wearing as "weak" or "cowardly," and he felt obligated to not require a mask at these events to not alienate his base.

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=...

Eh, it's a broadly popular policy with huge moderate appeal: https://news.gallup.com/poll/323582/support-legal-marijuana-...

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.

This is an odd thing to see widely published. I'm at a company that had a rather detailed negative article written about us, and we were warned about it internally shortly before it was published, after the reporter had contacted us with details and questions. However, we didn't go public with a reaction until after it was out, since it seemed rather pointless to respond to something that hadn't been published yet, especially when we hadn't even seen it in full.

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"?

Don't forget the part where he sells the Cology domain and trademarks to another tech startup :)

(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/)

Glad to see "throw on unhandled rejections" make it into Node, finally! I can stop carting around this little bit of code I used in every Node API I wrote:

  process.on('unhandledRejection', (err) => {
    console.error(err.stack);
    process.exit(1);
  });

Sadly, if they tried your first suggestion, Spotify would almost certainly lock down developer access like Twitter has for their new API, requiring an application and manual approval.

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).

As far as I can tell, Spotify doesn't really have a Developer Platform team, just a legal department enforcing their ToS. All of their various SDKs are poorly maintained with zero points of contact. I think it's just a handful of engineers who care, working in their spare time at an organization that doesn't have any interest in giving them actual resources.

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.

Is it just me, or is $15/mo for the cheapest Postgres-with-backups a bit steep? Heroku's free DBs (or $9/mo basic plan) support daily backups.

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.

I suppose, as a DigitalOcean subscriber for the past five or so years, I should probably send them an angry email about this. I don't know if they'll be particularly threatened by me pulling my $12 a month, but maybe it'd at least get this noticed by some part of the org that isn't keeping up with engineering news...

This link currently points to the wrong place. Should either be https://www.cloudflare.com/web-analytics/ or https://blog.cloudflare.com/free-privacy-first-analytics-for...

Niantic has a legal requirement to verify that a legal guardian has allowed a child to have an account.

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.