I don't understand the architecture section. The title is "layered architecture," but then it talks about Ports/Adapters, which would be hexagonal architecture?
I was about to leave a very witty "just be idempotent ;)" response but did not consider the nonce. I'd be surprised if Google is quick to change this, so I guess be stateful on the receiving server, persist that you handled a certain request already, and if you get a duplicate request, replay the response from the first one?
At this point, I cannot take these kinds of safety press releases serious anymore. None of those models pose any serious risk, and it seems like we're still pretty far away from models that WOULD pose a risk.
After having used Datadog for several years, going back to Grafana / Loki / Prometheus felt like regressing by two decades. As much as I appreciate free solutions, I feel like Grafana has really fallen behind when it comes to developer experience
Why, exactly, do we need to put a memory cache such as Redis in front of Postgres?
Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?
I'm assuming you're targeting this mainly at enterprises and business use-cases such as callcenters, but are you planning to make this usable for personal use cases as well? For example, having a bot to bounce ideas off while coding. Pretty much "just" the TTS / STT layer to talk to my finetuned LLM in a natural manner while you handle interruptions and such.
I think the main issue right now for personal use would be cost (and I'm guessing STT / TTS are the most expensive parts..)
I really do not understand these memes about overengineered FactoryFactoryFactories. I have 10 YOE, did I just get lucky? I've worked at enterprise Java shops as well, but even there I'd call the software pragmatic. Are these overengineered monstrosities REALLY still a thing, or is it "just" people suffering in legacy projects? Even the juniors I worked with were following KISS and YAGNI.
I wonder if we're at a point where you could build a voice assistant like that, except almost-realtime and streamed end to end:
User speaks and speech to text starts streaming text while the user is still speaking. That text stream is piped into a LLM, which also streams its output text. That output text is streamed to text-to-speech, which also generates audio in a streaming manner.
Great. Glad to see we're still world leaders at shooting ourselves in the foot. It makes sense to regulate AI use in critical infrastructure and flat out outlaw use of AI to manipulate public opinion, but that's where it should have stopped.
At the risk of sounding like a complete idiot, isn't the hypothesis of the original paper still true? Let's assume self assessment score is perfectly random between 0% and 100%, so on average every group will always estimate themselves to be 50% correct
Then by definition that means people who are unskilled and often incorrect will overestimate themselves, while people who are often correct will underestimate themselves. Take a complete idiot for example. You always get 0% test score. Yet your self-assessment is random between 0% and 100%. Hence you overestimate yourself much more often than people who always get 100% test score.
In fact, if the two are uncorrelated, then that still means that
Sometimes I have this urge to try getting into a manager role. I really want to see and experience for myself if most managers I work with are just bad at their job, or if being a "good" manager is simply impossible and you're doomed to fail regardless of skill.
Are you suggesting everybody should use event sourcing instead of using transactions? Because the general consensus on event sourcing is "don't use it unless you absolutely have to."
> You're saying that a software startup's selection of available engineers is so limited that it's not possible to approach general population demographics?
Yes, because engineers don't follow general population demographics.
> In 2021 alone, over 100k people graduated with bachelor's degrees in computer science. That sample size is too small to approach general population demographics?
Yes. Again, that sample too does not follow population demographics.
> Okay, let's lower the bar. Why doesn't your staffing at least approximate the demographics of computer science graduates?
It does. Which is why I said "mostly" (but not exclusively) male. However that is not a "lowered bar", that is the only possible way things can work out. Unless you argue that a number of male engineers should be systematically doomed to never be hired in the name of equality, because otherwise we cannot reach your perfect demographic distribution.
That makes no sense. You don't just hire people out of the whole general population, you hire people with skills you need. If a tech startup hires engineers those will be mostly male. Not because the startup is sexist, but because there are more male engineers around.
Yes, pretty much. It's a pain to write, but easy to read. On a larger scale the average engineer likely spends more time reading code than writing code