imankulov

You can actually test it yourself. The actual URL is in the post and the website is still up.

Like others mentioned, I like the framing of treating Claude Code as a tool (and I had to remind myself of it constantly).

Like any tool, it takes effort to master and configure. Before LLMs, I used cookiecutter templates to codify my best practices. Now I invest in custom skills and context management so the tool produces solutions that match my standards and team conventions.

I agree with the author that the craft still matters, and probably now more than ever. I'd add that mastering and configuring your agent is now part of the craft.

I left tmux for zellij after several unsuccessful attempts to get Shift+Enter working.

Was quite impressed initially and invested weeks in building new muscle memory, but somehow Zellij crashed with panic more than once, leaving all my processes orphaned. Decided to go back to tmux, and found a simple fix for my Shift+Enter issue.

In case anyone is looking for it, the fix is "bind-key -T root S-Enter send-keys C-j" borrowed from https://github.com/anthropics/claude-code/issues/6072.

Building Smello (https://github.com/smelloscope/smello), a Python library and a local server that capture your outgoing HTTP requests to help you debug API integrations.

The idea was inspired by Mailpit, which I've used for years to debug outgoing emails. A few implementation details were literally stolen from Sentry SDK with an "implement it how Sentry does it" prompt.

https://smello.io

I liked GPT primarily because I felt like it respected me: I never felt like it was trying to distract me from my work or get me to waste time doomscrolling.

Not about Sora, but about ChatGPT. I felt the same way for quite a while until I noticed that its response pattern has changed, apparently aiming for higher engagement. Someone aggressively pursued a metric.

At some point, ChatGPT started leaving annoying cliffhangers in its every response, like "Do you want me to share a little-known secret of X that professionals often use?" Like, come on!

There are several alternatives. Most of them, including mailcatcher, seem to be unmaintained.

Mailpit is an alternative that has regular updates: https://mailpit.axllent.org/

I was using Grammarly for a long time, but a while ago I made a wrapper around the OpenAI API to fix grammar and style and highlight the changes.

- Demo: https://refiner.roman.pt/. - Source: https://github.com/imankulov/refiner.

For me it works better than Grammarly.

In my experience, the "Citadel pattern" is a good alternative to microservices for small to medium teams. I have seen it emerged as a natural evolution of a monolith in several places where I worked, where it served us well.

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Hackbraten is right. When I talk about dicts, I refer to a specific Python data type. Still, the truth is, I struggle to spell "dictionary." Even now, I copied the word from your comment.

I'd rather phrase it as "well-defined data structures help maintain your app." In another comment, leetrout recommended using named tuples. They define a list of their attributes without saying anything about their types, and this may be a perfect choice for some scenarios.

Huh, I worked with this architecture, and while it was convenient at first, it became an issue down the road. Here's what we had.

- A few times, we inadvertently exposed internal fields. They were not sensitive, just internal. Still, clients discovered and started using them and effectively blocked us from changing the data schema without updating the API version.

- A risk of inadvertently exposing sensitive fields. We never had this, but the mere fact that it was too easy to have, kept unnecessary pressure on us.

- Adjusting the serialization format for different purposes became a problem. When everything is a dict, it's difficult to bolt in custom serialization logic. We had this issue when we had to support different API versions, different object representations for different clients, or different purposes. For example, when we cache an object, we want to keep all the fields, but when we return it to an object, we need to maintain the subset of them.

- Slower onboarding. When a newcomer joins the project, they need to be aware that any database change may leak as an API attribute. They couldn't start working before they saw the whole picture.

Yes, the context is Python.

Hey, molly0! Do you have a specific example in mind? I'm thinking about how common this use case could be but can't come up with anything.

True. Don't slap in types just because you can — add types when you need to work with your data. Most of the time, I worked with systems where my python code *was* the downstream and required data to run some business logic. In that context, types make the most sense.

The standard for type hints in Python is lengthy and detailed PEP-484.

PEP-483 is 2x shorter and builds the foundation for this work. It summarizes the typing theory and outlines its guiding principles for Python. I found it helpful to see the bigger picture.