I was commenting too much, and thus can't reply with the same account, but I wanted to say I do agree with the fact that while you can't control what happened to you in the past (and maybe even what led you to drugs in the first place), your addiction is yours and having a victim-complex (warranted or not) is pretty detrimental to getting clean.
I was pretty fortunate in that while I may not have had the picture perfect childhood, my family was always there for me and in no way shaped my decisions to use. So even if I wanted to feel like a victim, I'd get snapped out of it pretty quickly.
When I look back at what set me apart from most others (I've been in numerous treatment centers, jails, and hundreds of NA meetings), the one thing that stood out to me the most was my support system. Others probably had a greater desire or more to lose, but because desire alone isn't enough, didn't always make it through. One example, my mom would drive hours each weekend to come visit me in treatment. That just didn't exist for the others I was there with.
Are you purposely misreading the comment? Where did it say that http was the only form of communication (or even the best) between microservices? Where did it imply there weren't other methods?
> While HTTP can be considered as a transport layer for RPCs between microservices, it seems to me to be a very inefficient and bug-prone solution.
This is so irrelevant to the point being made it's nuts.
> Not what happend to Office.com or what you think about their products.
I don't understand this point. Are you suggesting that less people being happy with their product and thus less people buying it is not related to the valuation of the company and their stock?
> Also, you and me are not the customers. Govs and corporations are.
Huh?
I get you're trying to make a point about the bottom line, but that doesn't mean the bottom line is impervious to bad product decisions or that the people who are paying for their products are not in fact their customers.
So React, the most popular front-end library and used my hundreds of thousands of successful apps, is the ridiculous electric screwdriver? See how weird that sounds and makes it obvious you guys can't give an honest assessment?
> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”
This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.
> but then it breaks, or has awful performance.
You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.
> You can’t use if-else in JSX,
I don't need to use if-else in JSX to control flow. I can write if(condition) return html;
> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.
See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?
> And regarding signals, preact is using it and it doesn’t seem to break anything there.
It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.
In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.
I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.
> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.
This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.
It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).
> It's inefficient because it's stringy data in an SQL database, but I look forward to support tickets because i don't have to "debug". I just read the events, and have the evidence to back up that the customer is wrong and the system is right.
I think one of the draws of ES is that it feels like the ultimate way to store stuff. The ability to pinpoint exact actions in time and then use that data to create different projections is super cool to me.
No problem and likewise. Conversations like this are great because they constantly make me re-evaluate what I think/say and often times I'll come out of it with a different opinion.
> Could be that some of the bad experiences we hear about are from people applying it to fields like content management (I've been tempted to try it there) or applying it to whole systems rather than individual parts
Amen. And I think what most people miss is that it's really hard to do for domains you're just learning about. And I don't blame people for feeling frustrated.
I think having constantly changing product requirements would certainly make it difficult, but that makes all development more difficult.
In fact, I think most complexity I create or encounter is in response to trying to future-proof stuff I know will change.
I'm in healthcare. And it changes CONSTANTLY. Like, enormous, foundation changes yearly. But that doesn't mean there aren't portions of that domain that could benefit from event sourcing (and have long, established patterns like ADT feeds for instance).
One warning I often see supplied with event sourcing is not to base your entire system around it. Just the parts that make sense.
Blood pressure spiking, high temperature, weight loss, etc are all established concepts that could benefit from event sourcing. But that doesn't mean healthcare doesn't change or that it is a static field per se. There are certainly parts of my system that are CRUD and introducing event-sourcing would just make things complicated (like maintaining a list of pharmacies).
I think what's happening is that a lot of hype around the tech + people not understanding when to apply it is responsbile for what we're seeing, not that it's a bad pattern.
You can blame the endless amount of people that jump in these threads with hot takes about technologies they neither understand or have experience with.
How many event sourced systems have you built? If the answer is 0, I'd have a real hard time understanding how you can even make that judgement.
In fact, half of this thread can't even be bothered to look up the definition of CQRS, so the idea that "Storing facts" is to blame for people abusing it is a bit of a stretch, no?
> CQRS sounds good, until you just want to read a value that you know has been written.
This is for you and the author apparently: Prating CQRS does not mean you're splitting up databases. CQRS is simply using different models for reading and writing. That's it. Nothing about different databases or projections or event sourcing.
This quote from the article is just flat out false:
> CQRS introduces eventual consistency between write and read models:
No it doesn't. Eventual consistency is a design decision made independent of using CQRS. Just because CQRS might make it easier to split, it doesn't in any way have an opinion on whether you should or not.
> by folks and companies who host queueing technologies (like Kafka).
Well that's good because Kafka isn't an event-sourcing technology and shouldn't be used as one.