We can assume that Twitter was a vocal opponent to the repeal at the time and that they have now become somewhat more in favour if it means knocking out their competition whilst they enjoy special protection.
All it would take is some catalytic content to kick things off and a compliant state judiciary to get the ball rolling.
Bluesky's Terms Of Service explicitly state that they are not liable for the impacts of their user's content. They say they reserve the right to delete content or accounts at any time at their discretion. And then there's this:
Indemnity: Summary: If someone brings a legal claim against us based on your actions on Bluesky Social, you are responsible for our defense in, and the consequences of, that claim.
It all looks bulletproof on the surface but I just don't know if it will survive under Trump/Musk.
> Write everything (generally, new features) twice has turned out to be really good strategy for me, but it doesn't sit well with bizdev or project managers and tends to be perceived as unnecessary slowness.
Silo-isation compounds this. If the maintenance costs are borne by another team or if any rework will be funded out of a different project, the managers are not going to care about quality beyond the basic "signed off by uat".
There was a detailed proposal to introduce encoding/json/v2 last year but I don't know how far it's progressed since then (which you probably already know about but mentioning it here for others):
The flaws in the sewerage system are fundamental and pervasive. It would be a national multi-generational effort to rebuild it all. It's going to be far cheaper to simply make swimming outdoors illegal and alter insurance guidelines to deny claims for water-borne health issues.
Stuff like this appears in UK newspapers all the time. It's just the think tanks putting controversial ideas out there so that public outrage can be gauged. This then informs government policy going forward.
This is what happens when you privatise monopolies. They're not looking at a 100y plan, they're paying shareholders and [unnecessary] c-level positions.
However lavish or detailed or faithful to the Gibson Vibe this adaptation turns out to be, it will live or die on its realisation of Molly Millions, the baddest badass take-no-shit progenitor of Lisbeth Salander, Lara Croft, and The Bride.
It feels like there's a tiny bit of conflicting advice in this. There's the "not rocket science" rule which results in "no CI-failing commits on main" and then there's this:
> Third, our review process is backwards. Review is done before code gets into main, but that’s inefficient for most of the non-mission critical projects out there. A better approach is to optimistically merge most changes as soon as not-rocket-science allows it, and then later review the code in situ, in the main branch.
But the tip about adding a failing test as a separate commit on the feature branch wouldn't survive a merge and it wouldn't live long enough to be reviewed either.
I like most of the advice in this article but this review one is giving me pause.
The big draw of ORMs is (was?) the idea of database independence which is a fools errand unless you're a vendor pushing some kind of application which needs some kind of relational database.
If working in-house or building something bespoke, an ORM provides negative value. The only possible upside I can think of is that it offers an opportunity to capture databases access events or... no, that's it. In exchange for this dubious capability, ORMs end up sacrificing the full generality of SQL for simple CRUD statements. On top of that, if ORM migrations are in play then database maintenance becomes bifurcated because, like on the CRUD side, ORMs can only provide crippled imitations of DML.
No, the big draw of an ORM is you can map objects to your database relations. That's why it's an object-relation-mapping. When working with Postgres I think of database rows as instances of a class in my app's native language. I think of queries for the table as static methods, queries for rows as instance methods. Going with raw SQL queries means you not only lose good intellisense on query methods as well as composability, but for a non-trivial app you'll end up implementing much of what an ORM will give to you anyway.
It's the power of an ACID RDBMS with the level of integration of DAOs written in whatever language you want.
Maybe we're coming at this from different ends? I've always adopted the position that the database is the source of truth, not the ORM data model. I've always maintained that mirroring the database schema in an ORM data model is an anti pattern. And I don't like exposing tables to client code under any circumstances -- a view for queries is an absolute minimum and for updates I prefer to implement those through stored procs.
There's nothing stopping anyone from writing their own DAO layer with bespoke SQL statements and allowing intellisense to index the API over the top of that.
> There's nothing stopping anyone from writing their own DAO layer with bespoke SQL statements and allowing intellisense to index the API over the top of that.
That sounds like a homebrew ORM. It could end up being better than any out-of-the-box solution. Or you could make a spaghetti code mess. But I’d rather spend my time elsewhere.
In my opinion the bespoke app code is the center of everything. The database is on the periphery and should conform to my needs as a software engineer building a user facing product. I need to live in reality, though, and understand the database accessed through an ORM is a leaky abstraction. But for many common use cases (find by ID, update a field for a row, etc) I can forget that it’s Postgres under the hood.
I know SQL well enough, understand how to craft a decent schema, how to keep the database happy as tables grow in size. But the main job is writing web app code, not operating as a DBA.
I operate on the principle that the center of the app can be determined by finding where most of the bullshit is. For an app where you’ve got some tables and indexes, the database is too idyllic to be the center of bullshit. Your app code probably has 1000x more bugs and spaghetti to it.
DRY also removes an easy opportunity to expose patterns which are things that people are incredibly good at recognising and internalising. I used to religiously apply DRY but now I prefer to leave repetition in unless the git log shows changes being applied to the repeated sections.
https://www.cfr.org/in-brief/trump-and-section-230-what-know
We can assume that Twitter was a vocal opponent to the repeal at the time and that they have now become somewhat more in favour if it means knocking out their competition whilst they enjoy special protection.
All it would take is some catalytic content to kick things off and a compliant state judiciary to get the ball rolling.
Bluesky's Terms Of Service explicitly state that they are not liable for the impacts of their user's content. They say they reserve the right to delete content or accounts at any time at their discretion. And then there's this:
Indemnity: Summary: If someone brings a legal claim against us based on your actions on Bluesky Social, you are responsible for our defense in, and the consequences of, that claim.
It all looks bulletproof on the surface but I just don't know if it will survive under Trump/Musk.