It’s always funny when you read something and think the exact opposite thing for every point.
I guess what initially converted me was dealing with a data flow that hovered at about 10 requests/min and then every hour jumped to 10k requests/min. Being able to do that without thinking about scaling or cost really changed the way I imagined data flows in the backend.
I guess now that I have boilerplate of code that works and its quickly deployed and tested with GH actions, I consider it a no brainer for most workflows.
I ended up having replace a compact with a crossover mainly to stop getting blinded by headlights at night time. It was getting way too dangerous. I tinted the back window, but was still getting blinded in the side mirrors.
If statements that either add conditional statements or blank lines to the SQL block. There are a lot of tradeoffs to the pure SQL method but I prefer being able to look up exact snippets in the codebase to find things.
Also, note that all of the negative examples are politics related. If a politician reads the word 'ilk', it is going to be interpreted negatively. It might be the case that ilk does "always mean" a negative connotation in politics.
You could change 'ilk' to 'friends', and keep the same meaning with very little negative connotation. There is still a slight negative connotation here, in the political arena, but it's a very vague shade, and I like it here.
"Altman and his ilk try to claim that..." is a negative phrase because "ilk" is negative, but also because "try to claim" is invalidating and dismissive. So this has elements or notes of an emotional attack, rather than a purely rational argument. If someone is already leaning towards Altman's side, then this will feel like an attack and like you are the enemy.
"Altman claims that..." removes all connotation and sticks to just the facts.
Well even if ilk had a negative connotation for my intended audience (which clearly it does to some people), I am actually trying to invalidate and dismiss Altman's arguments.
When someone is arguing from a position of strength, they don't need to resort to petty jibes.
You are already arguing from a position of strength.
When you add petty jibes, it weakens your perceived position, because it suggests that you think you need them, rather than relying solely on your argument.
(As a corollary, you should never use petty jibes. When you feel like you need to, shore up your argument instead.)
Well I don't think it really matters what most readers think of it because I was writing it hoping that it would be read by congressional staffers, who I think will know what ilk means.
I'd argue that you're right that there's nothing intrinsically disparaging about ilk as a word, but in contemporary usage it does seem to have become quite negative. I know the dictionary doesn't say it, but in my discussions it seems to have shifted towards the negative.
Consider this: "Firefighters and their ilk." It's not a word that nicely described a group, even though that's what it's supposed to do. I think the language has moved to where we just say Firefighters now when it's positive, and ilk or et al when it's a negative connotation.
I'm mean, at this point I'm going to argue that it you believe ilk is only ever used derogatorily, you're only reading and hearing people who have axes to grind.
I probably live quite distally to you and am probably exposed to parts of western culture you probably aren't, and I almost never hear nor read ilk as a derogation or used to associate in a derogatory manner.
Punch is typically referring to a waveform with high dynamic range - the opposite of compressed. Warm usually indicates a sound with rolled off highs and boosted midrange.
Interestingly, in addition to being a bassist, I'm also an electronics freak. I've studied every amp schematic that I can lay my hands on, have built my own gear, and read a lot of online commentary on the subject.
In my observation, a fair generalization is that for every term describing tone quality, there are equal and opposite definitions and explanations.
Honestly, as soon as I saw "wife" I rolled my eyes... there were four or five months (from the end of 2020 to the beginning of 2021) where I only had a scant handful of in-person interactions with humans I "knew", and like, they weren't even friends... I just mean "people whose name I know and would notice if they were replaced by an NPC"; one of them was "the guy who lives in the park near my house". I have never been so lonely, and I am the kind of person who normally "hates people" a bit :(.
My mother is still affected from this psyop. She doesn't even go out anymore. I try to encourage her to find a therapist but my words fall on deaf ears.
When I used prisma a few years ago I was not impressed and it couldn't do a lot of what I needed so I had to dump into raw sql queries anyway. It was easier for me to use knex and get the types mostly right.
A lot has changed in the past years of Prisma, it's a really great tool, to be honest, "raw sql" escape hatches to do anything raw when you need it, if you haven't tried it in years, I'd recommend you to try again since if you tried it years ago, it was a very different maturity level.
I believe the sidecar is optional now, and I think even the one that exists comes in the form of their paid service called Prisma Proxy. It doesn’t seem necessary for most use cases.
You should take a look at ts-sql-query [1] - it is not as popular as the older alternatives that have been around for a while, but it is a very feature rich query builder that takes type safety very seriously and supports most mainstream databases.
I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything. One example is our ODATA query and client library, which makes it incredibly easy to debug issues related to it, because everyone uses it.
Anyway, the one place where Typescript isn't great in the fullstack approach is the Database stuff. We used Prismo for the better part of a year, until we eventually moved on to Mikro-orm which has been great so far.
I'm personally not a big fan of OOP or "over architecture", because I've seen how bad it can go too many times. Instead I favour functional programming and keeping things as simple as possible, even having "almost duplicate" code once in a while. So with this in mind, it may strike you as odd that we moved from Prisma to Mirko-orm, but Prisma just clashes with the way we want an ORM to work in so many ways.
Maybe this is by design. Prisma doesn't want to be a "real" ORM after all, but things like having to put everything in a single schema file is bothersome. Yes, you can put it in different files and then cat them together, but that leads to other issues. Like the VSC Prisma extension highlights not working outside the main Prisma.Schema file. More than that though. We like to have "ID, UpdatedAt, UpdatedBy, CreatedAt" sort of things on basically all our models, and since Prisma doesn't have the inheritance I almost never use, that means you need to duplicate it soooo many times. It's also hard to write generic methods for basic CRUD stuff because of the way Prisma uses the Prisma Client Classes it auto-generates to operate. On top of that, migrations can't go backwards in Prisma.
Some of these issues are on the Prisma road map, others aren't, and you're always going to bang heads with an ORM, but Prisma just didn't feel as mature as it's extremely excellent documentation (and marketing) might lead you to believe in my experience.
I can certainly see myself using it again, once their roadmap is a little further ahead though.
Duplicate code is one of the biggest near-non-problems programmers waste a ton of time trying to address.
Sure, duplication isn't a goal, but DRY shouldn't hold back work as long as it has no meaningful consequence on performance. In some cases, duplication is a good thing, but your average programmer will address duplication by making a routing more complicated and further away from where it's being used. This is often a mistake.
Worse yet is when programmers DRY up tests. Tests are the worst place to be applying DRY. The point of testing isn't to write an entirely new application on top of your actual application. If you're DRYing up your tests a lot, you're probably writing a second application and should probably stop doing that.
> I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything.
We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend. It's very nice.
> We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend.
I've wondered about this approach for a while, but have yet to actually try it in any meaningful context. Do you use a framework like React via Scala.js, or are you doing something different?
Yeah it's React and some component library etc.. Library interop is pretty good if the library has type information available, and most of them do these days.
I'm using prisma with postgres. It's pretty nice. You define all your tables in their custom schema format which has VS Code integration and lots of type checks so it will tell you if there's a problem with the schema. You can generate types from the schema file automatically and also a statically typed ORM layer that will let you write queries against those tables with full code completion. It also will generate migration scripts for you when your schema changes.
It's not as good as EF by a long shot (nothing really is), but for most queries it works fine. You can also use SQL or stored procs for the exception cases which no ORM ever fully replaces anyways.
Influential people use it as a town square. Until the politicians and business magnates move to another platform this is where a lot of news originates.
A very large percentage of federal possession cases are drug smuggling at border crossings. This amendment is to keep those people locked up since their initial charge of “possession” was chosen over illegal border crossing or whatever else since it was probably a) easier to prosecute, and b) carried a harsher sentence
