HN user

aranw

577 karma

I'm linking my keytrace.dev: did:plc:2wmjihpa4o2myl4jowni24s6

Posts19
Comments139
View on HN

t once had to tell claude 3-4 times to stop assuming the state of a system was the way it kept iterating it was cause it was in it's memory. I repeatably told it to otherwise and it just never updated it's memory and instead kept referencing it's memory about the state of a particular system

Zed is 1.0 3 months ago

I really like Zed but it's most recent big changes to Git integration and Parallel Agents has forced me to disable both of those features as the way they work just didn't suit me and my workflow

The Parallel agents feature seems to be built around git worktrees or local projects. But I think local project mode defeats the point. In my day to day development workflow I've switched fully to jj and jj workspaces, so this isn't something I'll be using until Zed gets jj support. Also this change ended up with a reshuffled layout I didn't really expect and I can't really figure out how to revert it now

Which SQLite Go library do you use? My biggest pain with using SQLite in Go is often the libraries and the reliance of CGO which is what puts me off using Turso

Edit: Looking at the go mod file I noticed github.com/mattn/go-sqlite3 which I think is a C wrapper library so I'm assuming you rely on CGO for compiling

The problem with mocks is that they test your assumptions, not reality...

When you mock a CRM client to return one account, you're assuming it always returns one account, that IDs have a particular format, that there's no pagination, that all fields are populated. Each assumption is a place where production could behave differently whilst your tests stay green

Your contract tests use cached JSON fixtures. Salesforce changes a field type, your contract test still passes (old fixture), your mocks return the wrong type, production breaks. You've now got three test layers (contract, mock scenarios, E2E) where two can lie to you. All your contract and mock tests won't save you. Production will still go down

I have zero confidence in these types of tests. Integration tests and E2E tests against real infrastructure give me actual confidence. They're slower, but they tell you the truth. Want to test rate limiting? Use real rate limits. Want to test missing data? Delete the data.

Slow tests that tell the truth beat fast tests that lie. That said, fast tests are valuable for developer productivity. The trade-off is whether you want speed or confidence

I really dislike this idea of testing in go: only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.

Same I have zero confidence in these tests and the article even states that the tests will fail if a contract for a external service/system changes

I'm currently working on a project that is using an OpenAPI library that decided to use a non-standard JSON encoder. The developer experience definitely suffers when you can't use common encoding/json patterns in your own code. Simple operations become unnecessarily awkward

I've been using the minio-go client for S3-compatible storage abstraction in a project I'm working on. This new change putting the minio project into maintenance mode means no new features or bug fixes, which is concerning for something meant to be a stable abstraction layer

Need to start reconsidering the approach now and looking for alternatives

There is probably a legitimate basis for some powers against actual foreign intelligence operations. But the proposals in the article defining "subversion" to include environmental activism, independence movements, or criticism of UK policy show how quickly these things expand beyond their original scope. The Terrorism Act was meant to exclude domestic activists but two decades later it has been used against protest groups

That's really nice of the author and awesome to hear. Would love to see TigerStyle be published in a similar format and expanded upon with more detail be great for referencing with my colleagues. Would love to adopt it on projects or some of the rules at least

The attribution to TigerBeetle should be at the top of the page with a link to the original tigerstyle, not buried at the bottom. Right now it reads like official TigerBeetle content until you scroll down, which isn't fair to either you or the original team.

Why in the world do people choose Mongo over Postgres?

I'm using on a project not by choice. It was chosen already when I joined the project and the more we develop the project the more I feel Postgres would be a better fit but I don't think we can change it now

For a few years now it's been feeling like Apple are pushing devs away and are more interested in catering for general consumers. Just look at what DHH has written and said about it, and his move to Omarchy

That's a really nice article, thanks. And I can see how separating the validation logic from processing code is useful. What's not clear to me is why you chose this approach over existing OOP techniques, such as GoF Adapter Pattern, or even just interface implementation (as Go looses a lot of the ceremony of Java/C#).

Thanks for that feedback! Really appreciate it and glad you liked it. I'm planning to try get a series of posts written about the project and also CUE.

You are right I could have used adapters and/or interfaces. The main reason I went with CUE was to keep the transformation logic declarative and in one place. With adapters, I'd still need to write Go code for each sensor type

The goal I had was to minimise the amount of changes I have to make in my Go code. With my current approach I have minimal Go changes and just additions to my CUE schemas. When firmware updates land or I add new sensors, I update the schema and the generic processing code just works.

The CUE schemas are also portable. I can take them to other projects without trying to make generic reusable Go code that works across multiple codebases. The schemas double as documentation too, so if someone asks what a sensor reports, I point them at the CUE file rather than explaining how various structs fit together.

Honestly I also just wanted to try building something with CUE and this felt like a good use case for it

I've owned three Audis over the last decade with no recalls

Tesla deliberately pushes boundaries and breaks from tradition. That's admirable, but traditional manufacturers have decades of engineering knowledge behind their approaches for good reasons. Push the envelope enough and you'll have more misses and in Tesla's case more recalls

Ahh yeah I forgot these two things! I've now added them when CUE is first mentioned in "The system architecture" section, although not at the very beginning as I was trying to give an overview of the project and why I started building my custom solution first