It's not like I got bored with OpenAI Codex or have spare time to play with the new toy - it's quite the opposite. I like codex - it's my main productivity tool. However, for 4 weeks in a row I hit the weekly Codex limit 1-2 days before the end of the week. So I had to use the alternative to avoid blocking, not for some quick "let's try this" session.
That gave me something much more useful than hot takes: side-by-side comparison under actual usage. Last time I used both codex and claude back to back was ~5 month ago.
Can you imagine people downloading random binaries from GitHub, running them locally, and then trusting them with secrets? I can't either, but apparently this is a perfectly normal thing people do every day.
If that makes you mildly uncomfortable, here's the less trusting version: do not install the binary directly, just run it in a container with no network access and only mount the working directory you actually need.
For those who can relate:
alias sops='docker run --rm --network none -v "$(pwd)":/work -w /work ghcr.io/getsops/sops:v3.11.0-alpine sops'
It is not magic, and it is not a perfect sandbox, but it is still a lot more defensible than casually piping a random release artifact straight into your machine and hoping everyone involved had a good day.
Imagine how bad it must be that Google Gemini, sitting in the very same Gmail window, works worse than an externally connected ChatGPT for mail search? Google literally hosts all the data but is incapable of answering basic questions. I regret getting the Pro subscription.
"docker cp" exists and does exactly what you think
Over a decade with Docker and still keep finding new things about it! Thanks to Perplexity – I wouldn't even think of such a way of grabbing files from the container. Neat feature.
Despite them being jerks about incorrectly issued invoices, the platform is just amazing. It's never been this easy for the average Joe to build something custom from scratch.
Monthly rubric about the curious things I have learnt / discovered
Golang stdlib can't unmarshal the whole JSON from the stream
I believe that stdlib should dictate the standards of high-quality, efficient software development. Generally, I don't expect much from Go, but recently I came across unmarshalling of a large JSON blob. Apparently, there is no way to deserialise from the stream – the only single method json.Unmarshal exists – it reads from a byte[]. Indeed, that would occupy about 2x the original size in memory for the structure, where less than the size of the JSON input could be used.
Obviously, there is a stream json.Decoder that allows processing of the input stream io.Reader, but it's essentially semi-manual processing.
No surprise at the very stereotypical answers from the Golang community: "you don't need it":
Someone prohibited the use of JSON for that – tell your company that the project can't be implemented because a Golang developer shouldn't want to stream-parse the response efficiently.
Impersonate Web3 EVM wallet
That's a life-saver. Regardless of how comfy I feel about Foundry tools or ethers.js, nothing will replace proper user experience – especially while researching other accounts. impersonator.xyz allows spoofing of a wallet address via the WalletConnect protocol. Highly recommended for DeFi degens, analysts and builders.
I was reflecting about what language is easier to use for the production grade apps and MVP. Certainly, the real grading depend on the context, type and maturity of the service being developed and dozens of other factors. Not trying to simplify things - the table below is just a subjective estimate of the complexity of producing code in two radically different development workflows: AI-driven, and ruX(human)-driven.
