AWebOfBrown

I honestly think Yegge has reached a point where he knows he isn't interested in doing the leg work of today's software engineering, but wants his career to ride the wave. The lowest effort, maximum value to extract in his position is abusing the crap out LLMs to an extent that is genuinely novel to secure thought leadership, but on close inspection it's just pointless token spend driving blog posts and publicity.

To me it is absolutely farcical that he was being being paid by a harness company (Amp) as a staff software engineer, slop-coded a solution to keeping LLMs on track (Beads), and having paid for all of this Amp and Steve...parted ways. Beads never went into Amp. Someone cottoned on to the value Steve was providing, for my money.

If you're interested in hosting it at no cost on Oracle Cloud's always free tier (4 cpu, 24GB ram), instead of buying a Mac Mini or paying for a VPS, I wrote up how-to with a Pulumi infra-as-code template here: https://abrown.blog/posts/personal-assistant-clawdbot-on-ora...

It doesn't, but from my perspective the thinking behind zero trust is partly to stop treating networking as a layer of security. Which makes sense to me - the larger the network grows, the harder to know all its entry-points and the transitive reach of those.

Another interpretation of this is that the lead developer adequately mitigated the risk of errors while also managing the risk of not shipping fast enough. It's very easy to criticise when you're not the one answering for both, especially the latter.

I really wanted to adopt tRPC but the deal breaker was it being opinionated on status codes without allowing configurability. Because I needed to meet an existing API spec, that meant ts-rest was a better option. I think there's an aditional option with a native spec generator in frameworks like Hono, and maybe Elysia.

I think that's demonstrably false.

His point about the runtime complexity of an API being entirely distinct from how the interface to it's code is exposed (whether GraphQL or REST or otherwise) is fairly obvious, I think.

The counter-argument is that unlimited query complexity makes it far bigger problem, and the author's point is that if you're using it for private APIs with persisted queries, you shouldn't have that problem unknowingly.

Don't get me wrong - I think the takeaway is that GraphQL's niche is quite small, and he's defending exactly that niche. It's not often the case that you can develop an API in a private manner which doesn't undercut higher-order value in the future, as the rise of AWS hopefully made evident.

Everything I needed to know about Russell's performance war was answered when, whilst he was working at Google, folk started asking him why he was naming and shaming companies for poor performance when his exact critiques were swiftly applied to Google's apps (calendar, maps, gmail). I wish I could find the twitter thread from back then, but the gist of his response was that what Google was doing was incredibly complicated, far more than anything the targets of his ire were working on, and as such it was reasonable not to have fixed those issues.

He wasn't wrong in his assessment of complexity, but the fact he refused to acknowledge the business priorities were the same between Google and companies he called out, absolutely baffled me. The gist from my perspective was that companies external to his own should bend over backwards for performance, while his should not, because his personal goals were tied to improving the performance of the web. Hopefully that's an over-simplification and I've missed something, but that's what I can recall.

> Folks seems to lack a kind of basic economic perspective.

I agree with most of what you said, but this seems a bit ironic.

Your suggestions almost exclusively involve large investments of time with little established proof that they are efficient. Do you genuinely believe reading RFC 2616 "cover to cover" is an efficient way of solving the specific problems they came across?

I would wager most developers wishing to be "really good" actually have a concrete desire like a greater paycheque or employer in mind. If that is true, I doubt reading someone's booklist necessarily is their fastest pathway, and their economic perspective is exactly what stops them doing so.

Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admit is a bit of a nuisance workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.

By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).

The reality is that I've heard unit, integration and e2e almost entirely used interchangeably, maybe except the former and latter. I don't think trying to nail down the terms to something concrete is necessarily a useful exercise. Attempts to do so, imo, make subjective sense in the terms of the individual's stack/deployment scenario.

To me, it's a contextual term much like 'single responsibility'. In this case, the two "sides" of an integration test are present. A consumer issues a request and a provider responds accordingly. The tests would ascertain that with variations to the client request, the provider behaves in the expected manner.

At which point you might point out that this sounds like an e2e test, but actually using the client web app, for example, might involve far more than a simple http client/library - in no small part because the provider can easily run a simple consumer in memory and avoid the network entirely. E2e tests tend to be far more fragile, so from the perspective of achieving practical continuous deployment, it's a useful distinction.

integration tests in this instance: varying HTTP requests (infrastructure layer) provoke correct behaviour in application layer.

e2e: intended client issues http requests under the correct conditions, which provokes certain provider behaviour, which client then actually utilises correctly.

This, to me, is why the most important part of testing is understanding the boundaries of the tests. Not worrying about their names.

I don't think it's poor to test http handling either, as a coarse grained integration test.

The problem I've seen is over-dependence on writing unit tests with mocks instead of biting the bullet and properly testing all the boundaries. I have seen folk end up with 1000+ tests, of which most are useless because the mocks make far too many assumptions, but are necessary because of the layer coupling.

This was mostly in Node though, where mocking the request/response gets done inconsistently, per framework. Go might have better tooling in that regard, and maybe that sways the equation a bit. IMO there's still merit to decoupling if there's any feasibility of e.g. migrating to GraphQL or another protocol without having to undergo an entire re-write.

In the latter example, the question is really one of how tightly you wish to couple the application layer to that of the infrastructure (controller). Should the application logic be coupled to a http REST API (and thus map application errors to status codes etc), or does that belong in the controller?

I don't disagree that it's more practical, initially, as you've described it. However, I think it's important to point out the tradeoff rather than presenting it as purely more efficient. I've seen this approach result in poor separation of concerns and bloated use cases (`DoTheActualThing`) which become tedious to refactor, albeit in other languages.

One predictable side effect of the above, if you're working with junior engineers, is that they are likely going to write tests for the application logic with a dependency on the request / response as inputs, and asserting on status codes etc. I shudder to think how many lines of code I've read dedicated to mocking req/res that were never needed in the first place.

If you have an aggregate root, it is responsible for knowing when changes to the aggregate have occurred, and thus making those visible.

What is the mechanism for it to do so? Does the aggregate root retain the events and decide when to dispatch them (likely after successful persistence to a datastore)?

Once ready for dispatch, what do you use to handle the events? Some kind of DomainEvents class ala https://udidahan.com/2009/06/14/domain-events-salvation/ ?

This is the boilerplate I'm referring to.

> Could you explain which aspects specifically require a lot of boilerplate code?

Probably the most frustrating part for me is tackling domain events and the implementation of the aggregate root. How have you tackled broadcasting domain events when an aggregate changes in a way that might be of interest to other bounded contexts?

This is interesting to me as someone who loves DDD but finds the tactical side hard to implement in Node.

A few questions stand out:

AFAICT implementing tactical DDD involves a lot of boilerplate code. That seems to be consistent with what you've written in your article on writing the book, mentioning "...we even built a Node.js framework as byproduct." If tackling DDD in Node requires so much work on something that isn't the businesses' core domain, and there's a lot of surface area for it to go wrong, why do it in Node?

As someone who writes predominantly TypeScript, static types feel like a much lower hanging fruit for alleviating some of the pain in tackling rich domains. As you've written the book in JavaScript, I'm curious whether you used plain JavaScript on the professional projects?

Also curious to hear from someone who has done tactical DDD in Java or C#: do you find a good supporting framework essential?

Fargate is considered a serverless service. Serverless generally encompasses FaaS + BaaS. Think anything whose infrastructure you can use without touching the underlying VM(s): SQS, SNS, EventBridge, RDS, Lambda, Fargate, Athena, Kinesis and so on.

This doesn't sound like the worst way to reduce expensive reads of normalised data. Is the implication that it should have been solved with views, was incorrectly normalised, or that a document/key-value store should have been used other than Redis?

Edit: I suppose a hypothetical can go many ways, it could be a poor data access pattern. What was the root cause in some of your experiences?

I thought Messenger was ReasonML's flagship use-case inside Facebook. If so, it will be interesting to know what impact this has on its development.

Any chance you'd be happy to elaborate on what your role is? Are you primarily part of a dev-ops team, or tackling Kubernetes as part of developing the product? Did you obtain CNCF certification / think there's much value in those?

Or, phrased differently, from working another job.

A quote about salary, that I bookmarked as I could see myself making the same mistake:

"Salaries never stay secrets forever. Hiding them only delays the inevitable. Last year we were having a discussion at lunch. Coworker was building a new house, and when it came to the numbers it was let loose that it was going to cost about $700K. This didn't seem like much, except to a young guy that joined the previous year and had done nothing but kick ass and take names..." (edited for brevity).

"...The conversation ended up in numbers. Coworker building the house pulled about $140K base (median for a programmer was probably $125K), and his bonus nearly matched the new guy's salary, which was an insulting $60K -- and got cut out of the bonus and raise in January for not being there a full year, only 11 months.

Turns out he was a doormat in negotiating, though his salary history was cringeworthy. It pained everyone to hear it, considering how nice of a guy he was. In all honestly, $60K was a big step up for him. Worst of all, this wasn't a cheap market (Boston). The guy probably shortchanged himself well over a half-million dollars in the past decade. This was someone who voluntarily put in long hours and went out of his way to teach others, and did everything he could to help other departments like operations and other teams. On top, he was beyond frugal. Supposedly he saved something around 40% of his take home pay, despite living alone in Boston. He grew up in a trailer park.

He spent the next day in non-stop meetings with HR, his manager and the CTO. That Friday he simply handed in his badge without a word, walked out and never came back.

Until 3 months later. As a consultant. At $175/hour."

https://news.ycombinator.com/item?id=2439478

Can you elaborate on what they are, for the curious?

Is it still the case that one realistically needs to write their layout in flexbox as a fallback? Last I checked grid support was about 87% globally. I learned grid at one point but then just ignored it on the basis that if I had to write everything in flexbox already, why do both? Would love to know if this is a false assumption.

> How can any server administrator trust Matt Holt or his software again?

I sincerely hope much of the community views this kind of personal attack on an open source developer for what it is: disgusting.

If this kind of behavior is encouraged, imagine the message it sends to people building open source software. Not only does your open source work not directly reward you financially, but it will be used as ammunition to tarnish your reputation, all because someone doesn't like the direction you're taking your project.

Honestly, this is shameful.

Because laws and the consequences for breaking some of them are often morally questionable to a large portion of society. Compounding that, the judiciaries' understanding of esoteric technical topics can be sub-par, and a juries' interpretation can be as predictable as a coin-toss.

That's all to say that, when you are contributing to robbing someone of their freedom, you'd better have a darn good reason for doing so. In this instance, I think many would arrive at the conclusion that Microsoft did not.

I felt the __typename was really awkward too, but Peggy Rayzis (of the Apollo team) told me awhile ago that they're working on removing that requirement, if it hasn't been done already. I don't think it's anywhere near as feature rich as MobX for local state though, so I use Apollo for remote data and MobX for local.

You might want to fish up the MobX users list in one of its github issues. The users list is huge, and includes rather large projects such as Battlefield 1's UI, CoinBase and I think the new MS Outlook to name just a few.

Performance was my main concern with MST, most notably if your data modelling involves A LOT of entities, things can get slow: https://github.com/mobxjs/mobx-state-tree/issues/440. Binding methods on every instance of an object is a lot of overhead.

I really liked using MST when I spent a few days fiddling with it. However, I really don't want to get trapped with perf bottlenecks I can't easily fix. Whether I'd actually run into trouble - I have no idea, but vanilla MobX is excellent enough that I'm happy sticking with it. I'd love to use MST more though.