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.
Is it possible for a multiplexer process to die, but in such a bad way that its child processes continue to run?
I’ve been relying on the fact that in the worst-case scenario (if a pane hangs and tmux session becomes unresponsive) I can just kill tmux server and not have to hunt down and kill dozens of individual processes afterwards.
A `kill -9` will cause many a process to die and give no chance to cleanup any child processes. Some percentage of users continue to use `kill -9` by default, which may result in a mess of a process tree. Otherwise if the crash is bad enough that cleanup code cannot run (maybe it's being run on OpenBSD and an incompetent programmer didn't check the return value of a malloc and for some reason the kernel now nukes the process) then there may be orphan children. There may also be sporadic failures to cleanup if the crash, maybe, causes the whole process to exit before the cleanup code in some other thread can run. System load average may also influence how things maybe go sideways.
Typically upon control+c being mashed in a shell (unless the terminal is in raw mode or such) a SIGINT signal is sent to all members of the foreground process group, and most of the processes in that group (ideally, probably) go away. This usually includes a portion of the shell (which forked itself to spawn the pipeline or whatever, to call setpgid(2), etc) that usually ignores the signal. In this case it may seem like the OS is doing something, but really it's shell job control (assuming your shell has job control, which most now do, and that you haven't turned "monitor" off, which most folks do not). The kernel is mostly there for shuttling signals around and process bookkeeping.
However a different process management model is that each parent must in turn signal its child processes to exit, in which case if the parent dies before that can happen you easily get orphan processes. There are use cases for both the process group model and individual signal models, and pros and cons to each.
When a child process finishes (that is not actively being waited on) it is left in a "defunct" or "zombie" state and will stick around in the process table until the parent process waits on them to fetch exit code. When you kill a parent process with active children, these subprocesses will become orphaned and re-parented to the OS pid 1 (or another "sub-reaper" process depending on your setup).
The OS will typically not kill orphaned/re-parented processes for you. It will simply wait/reap them so they are not left as zombies once they complete. If your parent process spawns something like a daemon server that needs an explicit signal to be stopped (e.g. SIGINT/SIGTERM), these processes will continue to run in the background until they are manually killed or they crash.
I see, so I might still need to hunt down non-daemon but hung processes even after I kill tmux server in which I ran them. Might explain a couple of odd occurrences in the past…
Maybe some keybind in a software. Another mentions Claude code, so it may be used to enter new line where enter is bound to send the prompt.
Terminal programs don’t see key events. It’s all text. I just checked st (suckless) code and the RETURN key will send “\r” aka carriage return. Control+j is “\n” or line feed.
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.
> 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!
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.
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.
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.
reply