I remember learning a lot of these programming tricks over the years. They would give me happiness: learning something new about nvim, or some new shortcut in the Fish shell, or a new Vim macro, or the difference between 1 bracket or 2 brackets in Bash scripts, etc. But now it seems like all of them are irrelevant, and I wanted to see how others think about the situation.
Analysis and any artifacts are all handcrafted by me. I mean, that is the work. I have never seen papers or code as an outcome. What I want is to learn and enable other to learn. That I can only get from doing the work myself.
I'm fortunate I guess in that most of my work tasks have very loosely defined deadlines, if any at all.
I don’t mean this to brag, mostly to point out that in my line of work, actually writing the code is not the biggest bottleneck.
For context I work on greenfield network security appliances
So i still get daily use out of these tricks.
Are there people that are literally ONLY interacting with a computer via an LLM? thats crazy if its true
I write everything myself. After 41 years of coding, I think in code — code flows from my brain through my fingers effortlessly: translating my thoughts to English for an LLM to then translate back to code is much, much slower than me. And once my hyperfocus kicks in, the last thing I need is to be jolted out of it by an LLM prompting loop.
JetBrains Rider has an AI auto-complete which I do use for the 5-10% of the time that it can predict what I’m going to write next. But even the next-word/next-block-of-code prediction seems so hopelessly out of its depth (which is supposed to be LLM’s party piece), it’s genuinely shocking how wrong it is most of the time.
Disclaimer: I’m not writing vanilla line-of-business code or bog standard web apps, so I suspect I’m just not in the training data.
Then, there's language-ext [1], which is my large open-source functional-programming framework for C#. And although this isn't beyond the realms of an LLM: they know FP and they know C# and even my library has been around for more than a decade, so it'll be in the training data, when it comes to bending C# to my whims or to trying to eek out exceptional performance, they're all at sea.
A good example would be what I am working on at the moment, which I have in a standalone prototyping repo [2]. Basically I have introduced functional traits to C#, like `Functor<F>`, `Applicative<F>`, `Monad<M>`, etc. This brings more rigour to things like LINQ comprehensions and allows for the building of truly generic trait-based behaviours. Something that just doesn't really exist in C#.
In language-ext today I have `Foldable<F>`, which is a little bit like `IEnumerable`, but pure. I want to be able to provide a super efficient set of default implementations for any `Foldable` (or enumerable/iterable). For this I need an efficient lazy-stream or co-routine system. The one built-in to C# (`IEnumerable` and `IEnumerator`) is impure (it mutates as it enumerates), so I am trying to build an efficient iterator/enumerator that:
* Takes around 0.25 nanoseconds per-iteration-step for its housekeeping (this speed is then on a par with the mutable IEnumerators that are a core part of C#).
* Doesn't allocate any memory
* Is immutable
* Is lazy
* Can be stopped at any point and the iterator reference be passed around (because it's immutable)
* Can be composed with standard functional operators (functor map, applicative apply, monad bind, etc.) without performance degradation and without a large memory-allocation cost.
I've been building several prototypes to try different ways of bending C# to my whims. I've managed all but the last item on that list.
Not allocating memory means using value-types (stack allocated types), but that also means the entire state of the co-routine needs to be stored in the value-type as each value is yielded (because control needs to be given back to whatever code is processing the values). To solve it, I'm pretty much building my own runtime, stack-machine, and memory manager on top of the .NET CLR so that I don't have to submit to its rules. I'm trying to apply as many of my old-skool low-level engineering chops as I can (without making it brittle); but to do the last item on that list needs more space in a value-type than would be reasonable (to avoid copying costs), so I'm looking at other pooling strategies and into building lots of bespoke to-the-metal memory managers.
After all of that, it may be a fools errand, and not doable. The LLM wouldn't understand, and that's for just one feature! Also, it must be stated, I just love doing this shit, it's brain fuel. The idea of having this conversation endlessly with an LLM as it continuously gets it wrong is nightmare fuel.
I'm not anti-AI, I love the fact that people who can't, now can. But, at this point in my journey with code, I think quicker and can produce quicker than an LLM. I think it's akin to a virtuoso piano player. If the piano player had to describe what they wanted to an LLM, the magic would go, the enjoyment would go, and potentially the quality would go. It would it also take much longer than if they had just played.
That's how I feel with code. An LLM can maybe churn out more code than me, but I can build more value and I can invent. And when in my flow state, nothing can stop me.
I will certainly keep checking in though, I'm sure there'll be a point where I feel like it augments me rather than hinders. It's just not there for me yet.
Too much information? :D
[1] https://github.com/louthy/language-ext
[2] https://github.com/louthy/iterator-prototype (this is messy prototype code, don't hate me).
LLM's have not affected us in the slightest when it comes to coding. Maybe we write a snippet, post it for llm to scrutinize, and usually LLMs spout bullshit and wrong suggestions and after enough verbal abuse it points to some issues with the code.
But I don't get this delegation to LLM's for your entire coding. I hope everyone delegates to LLM :) (sarcasm)
That's basically I all do. I might ask a few questions to LLMs here and there like Google/StackOverflow in the days of yore.
Still, every line in all my codebases are still hand-typed. I get everything I need out of the chatbots, and I cannot use any kind of agentic coding tools at work, oddly enough. Trust me, I'd love to have access to something like Codex at work. That way I could save my mental bandwidth for personal projects that I find interesting and enjoying.
Here's one that I think more people should know: avoid branches. If I can do the same thing without an if statement and even a logical expression, the code typically both becomes easier to understand for people and easier to run for the CPU.
if (x == 0) {
return y;
}
y += 25*x;
return y;
and skipping the if just makes the function shorter and simpler, while also not involving the CPU branch prediction. Another one that doesn't necessarily skip all branching but at least drops one - and more importantly makes the code simpler and easy to verify, is removing the if statement in code like if (count == 0) {
return;
}
for (int i = 0; i != count; i++) {
puts("hello");
}In the first case, the compiler removes the first if/return
In the second case, if you don't have the first if/return the compiler will add it. That's because it will actually convert your loop into a do/while, with the test in the end, because it is more efficient. But it has to handle the count == 0 special case first, so it will do that early return even if it is not explicitly there.
That's the kind of optimization modern compilers are good at.
=====
Should you go branchless?
Most of the time, no. Branchless code is harder to read and easier to get wrong. Besides, compilers know a lot of tricks and already do a lot of this work for us.
Only when a profiler points at a hot loop, and the loop contains a branch on unpredictable data this technique can pay off big.
if (thingThatIsTrue):
// a bunch of logic here...
else: // different logic here...
they mean:if (thingThatIsTrue):
return doThisWhenTrue()
return dothisWhenFalse()Just a simple example. I'm not sure if this is what you consider "obfuscating" the branches. Logically the same, but a bit more linear to understand?
Edit: I am bad at formatting comments here.
Example:
No space before start of line.
One space before start of line.
Two spaces before start of line.
Thus, you can put multiple lines of code with indentation as well as long as you put two spaces at the start of the line:int main() { return 0; }
int main() {
return 0;
}
See https://news.ycombinator.com/formatdocIt's not applicable to every situation, but one way to do this is some very basic fuzzy logic. You do a little math and then either choose a single branch at the end, or sometimes avoid a branch altogether. https://www.geeksforgeeks.org/artificial-intelligence/fuzzy-...
Another way to avoid some branches is to have specialized routines, maybe with multiple dispatch, rather than more general methods with a bunch of checks within them for slightly different situations.
A classic performance hack for critical sections is loop unrolling.
if Val === "A" then Do funcA() else if Val === "B" then
and so forth for lots of values, or using a switch statement or similar branching instead of
Object functions = { "A": funcA() {does what funcA does}, "B": funcB() {does what funcB does} etc. etc.
}
runnableFunction = functions[val]; runnableFunction();
Actually writing it I remember now someone who did this, a junior who had to update a validation function for XML invoices based on their root namespaces, which there could be a large number of these, and so she wrote out
switch namespace == "somenamespace" { validatingscheme = "someschema"; doPreliminaryFunctionToDetermineifshouldvalidate(); }
I can't remember all the details as this was almost 20 years ago, however while it was true that one branched on the schema, it made much more sense to look up what one was supposed to do based on the rule for branching and then just execute that one action rather than writing a bunch of branching logic.
So to make it more concrete: Once branching rules becomes sufficiently complex prefer query for what you should do rather than branching
on edit: note again, not real code, but should be understandable and translatable into real code to understand what is being said easily enough.
on 2nd edit: this is also just basically one of the things I prefer instead of getting a lot of branching logic. I have never seen any stats on any benefit to this model than just having a bunch of branching statements, but I feel that the benefit is there nonetheless.
Like imagine you have a few different classes of things A,B,C so instead of checking if the thing you're handling is an A,B,C you have like a shared interface across all and can call Thing.do_it or whatever.
Still branching conditionally but it's passing it off to language features instead of code you have to write.
A trivial example is actually written with a branch in C/C++, but relies on compiler optimizations to kick in. If you compile a ternary operator in C/C++ (and probably rust, C# and other languages) such as in:
int min_branchless(int a, int b) {
return a < b ? a : b; // Often emits cmov with -O2
}
With gcc/clang a -O2, one would expect the compiler to emit the following assembly: cmp edi, esi
cmovle eax, edi ; select a if a <= b
ret
There's numerical tricks for other operations/comparisons, and compilers know a lot of them. But, I just suggest compiling your code and configuring your compiler to emit the generated assembly with references to the code it was generated from (you should be able to get it to emit source line references in the assembly). You'll likely be surprised at the optimizations applied at -02, and utterly confused by what you find at -03.edit: Also, it doesn't mean to never branch, but to minimize branching, especially in tight loops. Branch outside loops, not inside, for instance.
e.g. don't do:
for (...) {
if (condition independent of loop variable) {
...
} else {
...
}
}
do: if (condition independent of loop variable) {
for (...) {
...
}
} else {
for (...) {
...
}
}If you want to tell the Rust compiler that you're certain a branch predictor can't help here [be very sure, most often humans are wrong which is why historically these "I know better than the branch predictor" features get ignored by optimisers] you can core::hint::select_unpredictable(condition, a, b) rather than using a dedicated operator.
† That's not its actual name, some languages have an operator with three operands which does something else, such as fused multiply-add so in a multi-lingual context better to say explicitly you mean the ternary conditional operator.
vector conditionmask = <some computation...>; // E.g., 11111111 00000000 00000000 11111111
vector truebranch = <some computation...>;
vector falsebranch = <some computation...>;
vector result = (truebranch & conditionmask) | (falsebranch & ~conditionmask);
where each lane of the conditionmask has either all bits set or all bits clear, depending on the outcome of the conditional test for that lane.The processor obviously does execute both branches here, so there's going to be wasted work. But since it's just a linear sequence of operations it can often schedule them independently and run them out-of-order and in parallel. And of course, if there's any shared computation between the two branches, the compiler can do common subexpression elimination.
That said, that sort of approach where you go ahead and do both and then blend them was definitely the kind of optimization where you'd want to profile rather than doing it blindly. But it was a pretty common thing to do when hand-vectorizing code. (Thankfully, auto-vectorizers are pretty good at doing this sort of optimization for you these days. It's been a very long time now since I've had to hand-write vector intrinsics.)
A common pattern in an old C++ job I had: People writing for loops, coupled with if conditionals, for things that could just be done by chaining functions in the algorithm library.
Don't do a for loop, check for a condition, and break. Use find_if.
Or stupid, like all those vloggers posting "ZOMG! Go all in with these secret hidden weird trick iPhone life hacks to level up!" that are just regurgitating what's in the manual.
As we used to say, RTFM: https://support.apple.com/en-us/docs/iphone
total = calculateOrderTotal(user.order);
if (user.isPremiumMember) {
total = total * 0.9; // 10% discount
versus total = calculateOrderTotal(user.order);
discount = calculateDiscount(user); // Returns 0.9 or 1.0
total = total * discount; total = calculateOrderTotal(user.order);
total = total * user.discount; total = calculateOrderTotal(user.order);
total *= user.discount;
or: return
calculateOrderTotal(user.order)
* user.discount; return 1 - user.isPremiumMember * 0.1;
would also cut it. v = setup()
if v == 1:
side_effect_1()
elif v > 1:
side_effect_1()
side_effect_2(v)
else:
raise Exception()
then we can "refactor" v = setup()
if v < 1:
raise Exception()
side_effect_1()
if v > 1:
side_effect_2(v)
i know that this might seem "dumb" that the code was ever setup the first way but code can grow into that shape pretty easily. this refactor "removes" the v==1 branch. this new code also follows the "early return" pattern, which improves readability.I have always felt like my bar for publishing something (even just to internal wikis/channels) is too high due to being overly self-conscious. I think we should try not to validate that feeling by implying that there is a non-negligible number of readers who will think you have a personality flaw because you wrote down your personal collection of tips in a public place, or that those people deserve consideration in the first place.
There is no such thing as "the things everybody knows". There are just too many things. Even a list of basic tips is probably going to contain one thing I didn't know or perhaps forgot. Write-ups like this are where most of my practical knowledge comes from, not RTFM (which I do).
IMHO the value of these nuggets is that you understand what you're doing and why; opening yourself to large amounts of non-default behavior likely will end up in a less than pleasant setup.
Not taking into account that different users might disagree on what is convenient and what is not, which is basically the point of making things configurable.
I would find that annoying, however to not be seen as a jerk I wouldn't say anything.
I frequently do the same, but not everyday; only when i think its something actually useful/helpful beyond the everyday crap. Most recently, we have had a huge push to use ai (just like everywhere else), ive been getting pretty creative with it, and at this point have a well polished setup that i can give a shitty sentence on a problem, not only does it understand the task, but theres a full ticket->branch->work->pr review->ready comment flow that it uses. My team also uses ai but they havent quite wrapped their head on ways to really work with it. I have built and shared a number of helpful things with the team to try and help them grow. One such thing was a doc i had my ai instance write, based on how ive been using my setup. This alone has started to get the rest of the team up to where i am.
My team doesnt share the same types of things i do, but they still share helpful things.
Call it what you will; I think if youre not helping your team grow by providing insights and helpful things, then youre not the kind of person i want to work with.
One is actually helping and the other is making yourself more visible to mgmt for promotions.
Share knowledge? I don't think anyone here is arguing against that in any way (or conversely arguing for hoarding knowledge).
The concern, one I share, is where the sharing has to happen publicly "every day" - so no matter how trivial, useless, niche, overly-specific the tip is (whatever, the list isn't exclusive), someone shares it.
That's the part that's not sharing knowledge for the benefit of others, but rather self-serving. I might even go so far as to say self-serving doesn't even need to be selfish; the person might genuinely believe they're doing good, but even there, self-serving.
TLDR: Share your knowledge, don't make sharing something every day, even when you don't have something valuable to share, your target.
PS - if this note irks anyone (are routine maxxers a thing?), make the goal to learn something every day, then share where appropriate.
Offering to teach someone something proactively? Sure, go ahead.
Sharing stuff freely when asked and arming someone with the tools to investigate further? Amazing!
Treating a public channel like ye olde facebok wall? Mildly annoying.
Every team/department/org/whatever should have channels everyone should subscribe to, and channels individuals set up that are optional for everyone. The appropriate way to handle this is for the OP to write a few tips once in a while in the public channel, and if people seem to like it, announce that all future tips will be in that channel.
Most senior engineers I've worked with have forgotten all these tricks, and they actively tell you that while you should try to get better at these things, career gains lie elsewhere. Focus on things with higher impact.
"Oh, yeah, I know a cool trick, but y'all have to wait until tomorrow to find out what it is."
"Look! It's a way to evaluate SQL expressions with a select with a from! Oh, you already knew about it?"
I have nothing against sharing knowledge, especially when seeing someone else do something that can be done better. But just leaving daily breadcrumbs to remind people you're the guy that teaches random trivia feels like attention seeking.
I see it more as: every day they will go on the slack channel and pause, wondering "Is there a neat trick I've learned or used recently?" then they share it. It's like a ritual to remember that you can share things because it's easy to forget other people don't work the same way you do. Writing it all at once is difficult (you have to remember a lot of stuff at once) and it tends to go unread.
I also think every single day is a stretch, but it's nice to pause once in a while to think about how you could help other people with something you've learned.
Both a centralized repository AND a daily message, especially for new employees, would be ideal, imo!
Normalize chatting and sharing stuff in slack!
Personally I don't care if the guy looks for attention or not. IMO people that do care have likely some jealousy issues ("I don't want other to get more attention than I do"). Lose-lose attitude.
Annoyance is a clue; not about them, but about you.
What I'm saying is I am not a jerk and actually do care about my coworkers, however I also don't want a bunch of noise in a chat app I have to use to do my job.
>I shared a trick on slack every day with the engineering team
Sorry for the "personal attack" but my point stands, you may not think of yourself as a jerk, but I saw your comment and thought "this guy imagining himself being annoyed at a coworker for a daily message with a helpful tip might be more of a jerk than he realizes". As a jerk myself I judged myself qualified to make that assessment and commented accordingly.
;with [[[]][[[](_)as(select 1 union select 0),[[]][]][](_)as(select 1 from [[[]][[[] []]]][]]],[[[]][[[] _),[]][]][[](_)as(select 1 from [[]][]][] []]]][]]],[[]][]][] _),[[[[[]][](_)as(select 1 from []][]][[] []]]][]]],[]][]][[] _),[[[]][]]](_)as(select 1 from [[[[[]][] []]]][]]],[[[[[]][] _)select _ from(select row_number()over (order by _)from [[[]][]]])[[[]][[[](_);
/s
In the macOS terminal you can...
Ctrl + Option + -
...and it'll undo your typing.Dunno about other OS keys!
I’ve always used Ctrl+U, it’s an Emacs shortcut, so it works in many shells and other prompts (especially since readline supports it) by default.
(For example Ctrl+Opt+- doesn’t seem to work in the Python REPL whereas Ctrl+U does.)
Record a debugging terminal session including output to a file. Its pretty great.
For me, I personally use nothing fancy other than normal KDE Kate for backend development.
Function and variable names are chosen after putting a lot of thought into it which also includes being amenable to grep and sed.
You can see the discussion about it here: https://news.ycombinator.com/item?id=39877637
Still, Zsh history with fzf fuzzy searching is fantastic. I have years of history I can recall commands with a few keystrokes.
Truly a second-brain.
And as another commenter said, you often forget the target, and use Ctrl-r to find it. Although just does support fzf...
well not specificlly but its bound to it. Having durable history stored in an SQL database (with secrets filtering and option syncing) you can search global history, or local. (as in if you have two terminals open, you can just search the commands you've typed in one terminal for that session, that session plus history or that session plus what you've just typed in any other session. )
Its awesome
My "find" is almost always
tree -if | grep "<whatever-pattern>$" | head -1
head, of course, being optionalThe tradeoff is needing to learn regex, which is not any easier to learn than find arguments.
similar to ripgrep, though, fd is a modern replacement that’s a bit friendlier to use.
yells at cloud
..it's probably ok actually and I should give it a real go, but I'm too used to find and even have a keybinding in my ~/.inputrc to insert a find + where loop
"\e\C-f": "find . -type f -print0|while read -rd '' f; do ; done\e-b\C-b\C-b\C-b\C-b\C-b\C-b"
(yes I know about -exec; I find the loop easier to work with)And I don't think that's a good thing. Especially because AI coding agents use it a lot. They only need to hallucinate a little to destroy your filesystem.
It's essentially like the SQL SELECT expression.
find -name '*.md' -and -not -type d
Of course, then it becomes more obvious why there are parens, why those parens must be escaped for the shell, etc. E.g., find '(' -name '*.md' -and -not -type d ')' -or '(' [...] ')'
I think once someone groks the nature of the expression args, then find becomes easier to start working with.The most messed up part in my mind though is that while most things in find are clearly helping the expression towards its goal of "true" or "false" on whether to include the file or not in the results, some, like -prune or -exec do so but with side-effects. And since they're usually invoked primarily for their side-effect, it isn't immediately obvious that they even return a value, or are participating in the expression itself. (-prune is true, and -exec depends.) And this is where it becomes important that `find`'s -and & -or are short-circuiting, too. (In a purely logical expression, it wouldn't really matter except as an optimization.)
People also sometimes omit -and, which I'm not a huge fan of the legibility of. (But using -and makes it not POSIX; you can do -a but ew. which brings me to the last bit…)
macOS: the find there requires the starting-point arg; so my examples above, on macOS, would all need to be,
find . [expression args...]
… which is lame. Brew install GNU find and be done with that.While I agree with globbing (or fd) for interactive use, I think for scripting I'd still say "you might want find"; there are limits to arg list lengths (see xargs) that (esp. recursive) globs can exceed; unless you know you'll never glob the world, find might be appropriate. Also:
echo *nope*
Globs will betray you on the zero-match case. (`man bash` & cf. `nullglob`.)Is this just plain old rage baiting? I literally can’t tell any more.
IT was always fast, and I explained my students what IDE cable was and they don't even knew about SWAP because they never had memory issues.
Those are also the current days if you have any sense. It's a bad idea to run an LLM with access to your machine at all, but if you absolutely must, you better review everything it does to make sure it doesn't run anything insane.
The rest of us picks a level between "approve some" and "YOLO" depending on how much they worry about having to clean up the workspace afterwards. Encouraging using the repo and some dedicated per-session storage, while discouraging changes to global state (like installing packages system-wide) reduces cleanup problem to "every now and then `rm -rf` some agent session dirs".
There are other terminal specific shortcuts for removing last word (ctrl+w) but they don't seem to be as portable.
stty -ixon
The advantage of doing it this way ('software flow control') is it worked with just TX and RX lines, rather than having to connect up additional wires to indicate when the terminal was busy ('hardware flow control').
I haven't put in enough effort to replicate the experience on GNOME but once I jump ship from Apple I'll have to.
The way macOS treats shortcuts thanks to the separation of Command and Control is great. It even makes Google Docs pretty painless to use because it's mostly like Emacs. Word still tries to hijack the shortcuts so that's suboptimal.
--date=2026-09-16
--date 20260916
and all variations thereof. It's annoying enough to have to check which script expects what format that I probably should've wasted some time or tokens to align them all, or at least put it into an MD file. But it's just an illustration of how LLMs can make CLI commands more obscure than they need to be.
I rarely type "cd" anymore. A huge quality of life improvement!
The "Unix Power Tools" book is an excellent source for Unix and shell usage tricks
Usually what I do is writing these tricks down to a document that is easily accessible at a place where I know that I will look for when failing to remember them. I have a directory of docs where I write stuff like this down by language/tool/etc., so I can quickly look it up without having to search the internet. But I also have to actively remind myself that these things exist whenever I have a problem, stop me from just doing the inefficient thing.
It's not even that bad of a habit with zsh either where it will only scroll through history matching a substring in your history, for instance if I type "rg -i" and then start pressing up arrow, it will only cycle through history entries starting with "rg -i".
though one function that i recently added will narrow your history down based on a space separated set of filters which i found useful
function hgrep
set -l cmd history
for pattern in $argv
set cmd "$cmd | grep -- "(string escape "$pattern")
end
eval $cmd | cat
end
use `hgrep ruby debug foo` would filter for a line that contained all the words ruby, debug and foo.type eg "rg" then up or down arrow, and the history shown is filtered by that rg prefix.
bindkey '^[[A' history-search-backward
bindkey '^[[B' history-search-forward
So far it works. Thank you diath.bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
yes, it's improved a lot in the last couple of years! what in particular bothered you?
Make sure you’re using the daemon (the install script will handle this) and you should be good to go
Very happy to help if you have any problems. Ellie at Atuin dot sh
what a time to be alive.
I think for a digital solution to come close you need it permanently present on a nth monitor
Seems like overkill until it saves my ass. It continues to do so almost half a decade into all the LLM hype. It hits the sweet spot between simplicity, convenience, reliability, and precision.
People strongly underestimate how good the git life can be, especially with all the blogspam on here trying to dethrone it lately.
Don't let IT hear that unless you work on FOSS.
People had this same problem last century. They would use templates that fit over their keyboards with all the common shortcuts and commands printed on them. Sometimes they were for a specific program, but you could buy blank ones to write your own notes.
Today, "keyboard templates" have an entirely different meaning, so the best thing for this is paper. Print your shortcuts out on a piece of paper and put it near your monitor. You could even categorize them by writing them on different-colored Post-Its.
So if you want to use ctrl-r, but you’re using the up key, use the down key to navigate back to a clear line, then use ctrl-r. Do it enough times and your brain will work overtime to find a shortcut (aka just doing it the new way).
"Use Ctrl-R for fuzzy history, or Ctrl-P/Ctrl-N for history entries"
(I have those bound to bindkey '^P' up-history and bindkey '^N' down-history instead of up and down arrow's "up-line-or-history" which is really annoying with multiline commands)
Was originally turned on to this by Derek Sivers: https://sive.rs/srs
welllll that depends entirely on the DB Software you're using. A certain IBM product certainly has opinions on this.
Another option is to do a ‘git log -p’ followed by a string search ‘/‘. It can give more context and let you browse more easily, especially if the project has small commits. It won’t work well for every project or search though.
If anything, I wish I had paid a lot more attention to this in the early days and made a nicer shell environment full of my own utilities, as I felt my skills just kind of slowly erode over the years with each migration. Make a nice little nest for yourself and curate those tools as your own (text) UI.
https://gist.github.com/GNOMES/6bf65926648e260d8023aebb9ede9...
I use this often instead of chaining together multiple '../..'.
Also nice for when I use Zoxide to CD into a deep nested directory. I quickly found out unless you manually CD each hop, the different parent directories aren't added to your Zoxide DB. (I have come across snippits to recursively CD into all directories in a path to "prepopulate" Zoxide).
I made this to jump directly from say `/foo/bar/batz/abc/123` to `/foo/bar/batz`.
alias ..="cd .."
alias ...="cd ../.."
alias ....="cd ../../.."
Just keep typing period and hitting enter until you get where you want according to your prompt. I haven't found much use for more than four periods. One period would be well-defined but useless.Now I have these to complement - thanks!
#!/bin/bash
# SSH to remote system and change into same (current) directory
DIR=$(pwd)
ssh -t $1 "cd $DIR; bash -l -i"it expects the remote fs is mounted under .../ssh/HOSTNAME/ and runs any command in that dir on the remote host. if it is not the root which is mounted, looks up mtab for the remote base directory.
https://codeberg.org/hband/hband-tools/src/branch/master/use...
Of course shell scripting is programming according to some HN commenters
Perhaps others would call SQL a programming language
Is it true that you can pass a nodejs agent to fetch ? I don't think so
I think for most cases `git ls-files` does this job quite well. If you provide pathspecs, this can be very powerful!
Anyways I find it mind boggling how many useful actions are not known by „normal people”. Most people are really using computers in a very inefficient way.
My idea is if we would spend time making people learn computers or software they use daily better - we wouldn’t need AI agents and we would triple GDP.
There's no amount of skill/efficiency/productivity a human worker can reach that will make employers give up on the dream of one day replacing them with software. The AI companies looking to profit from renting out the collected works and creativity of humanity certainly wouldn't shut down if the GDP tripled either.
People should still take time to learn how to use computers though. As long as they're going to use computers they can save themselves a lot of trouble and anxiety by investing some time in learning about them a little. Same with many other things people use and depend on.
I agree... but also this is so wrong it's painful. If you do have a good worker, they don't cost money, they MAKE money. Of course if you as the CEO think you are smart enough to cover everything and anybody but you is just wasting money, then that doesn't work and optimizing makes sense. Corporations have grown in size to be mindless heartless engine, literally, and that comes at the heavy price of ... not thinking, just an automaton with a single goal, growing profit, leading to an even more inhumane setup within which removing costly humans makes perfect sense.
Alt M + V = Move Alt E + C = Extract Component Alt S + E = Search Everywhere _ many more.
Or just vim combos.. with ideavim
:(){ :|:& };:
https://en.wikipedia.org/wiki/Fork_bomb
(See in particular the "Implementation" section where there's an explanation of how it works)
Folks need to be sufficiently motivated to learn it. All hell break loose when `RTFM` becomes taken offensively; What do I know - I am just a weird guy with a beard.
And folks always wanted to type the commands without RTFM'ing - now we have two problems instead of one.
Also, these were hard learned tricks YOLO'ing until 3.30AM debugging a failed DNS clusters or why the HSM suddenly decided to trip up at 5AM! Nobody even cares about the things we learn these days - Google and then your AI agent already does 98% of what I know already. So, let them blow up the clusters and the racks - your pal AI agent knows. Go ask them instead.
You can accomplish the same things in vi editing mode (with ? and !!) but they’re not as interactive.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Ba...
You can just record and play back your exact keystrokes like a _Super Smash Melee_ game plays back your inputs to replay matches. If you can figure out how to do any mildly complex action once you can literally replay it a thousand times. Just like AutoHotKey! To my that's the essence of citizen programming!
bash: Ctrl-L to clear the screen
VSCodium: Shift+Alt+[arrows|mouse click] to select a rectangular block
scp for moving files (instead of ftp)
Both rsync -avz /path/to/file user@server:/another/path/to/ or rsync -avz /path/to/file/ user@server:/another/path/to/file
Will create directory named /another/path/to/file which will contain all contents of the original directory (/path/to/file/*).
Basically, if you include the trailing slash in the source path, only contents of the directory will be copied (useful when you need to rename it).
rsync -avz path/to/old_dir/ user@server:/path/to/new_dir
If you omit the trailing slash in the source path, rsync will create the target directory for you. See man rsync for more info.Ctrl-l to clear the screen, Ctrl-p to select previous command, Ctrl-j to enter it again. I don't even use Enter key when in terminal anymore.
When you want to pause entering a command for a moment do Ctrl-a to go to the start of the line, and type # to comment out. Then Ctrl-j. You can return to that later with Ctrl-p, then Ctrl-a again and Ctrl-d to remove that comment.
To edit complex commands you might want to use Alt-e to enter $EDITOR.
I always wanted the same for Vim, zsh, etc.
//*
normal path
/*/
debug path
//*/
take away the the first slash to toggle the debug zone ON! #if 0
// Normal path
#else
// Debug path
#endif
Only works with C and C++, though.here's python:
#'''
normal path
'''
debug path
#'''
when I comment out python code I do it with ''' ... #''' so I can uncomment it with 1 keystrokehttps://github.com/hiAndrewQuinn/shell-bling-ubuntu
More readable presentation: https://hiandrewquinn.github.io/shell-bling-ubuntu/
Among other things, fzf gets installed with all the proper key bindings, ripgrep, fdfind... basically every papercut I could find between going from a vanilla Ubuntu or Debian box to a configured one is handled in this shell script.
^a ^e \
<------- --------> } Moving
alt-b alt-f /
<---- ---> /
^b ^f /
<- ->z
$ cp monfi[c]hier dir/ <---- --->
^w alt-d \
<------- --------> } Erasing
^u ^k /
precisely because combinatorial mindset and efficient navigation are so important to my workflow.PS: visual adapted from https://gist.github.com/tuxfight3r/60051ac67c5f0445efee
This hypothetical system has a bunch of users, belonging to groups. A possibility is that most groups have a only handful of users, but a few famous group might have disproportionate amount of users say 500,000.
If you wanted to put these groups in buckets, you can create linear buckets of fixed size based on number of users like
bucket 1: 0 to 100 users
bucket 2: 101 to 200 users
bucket 3: 201 to 300 users
...
bucket 600000: 599001 to 600000 users
Now the problem is you have way too many buckets, and most of them are probably empty. In situations these "buckets" actually cost you money, you might want to optimise the number of buckets.So the code converts the user distribution to logarithmic scale:
const bucket = Math.floor(Math.log10(userInGroupCount))
This essentially creates buckets as number of digits: bucket 1: 0 to 9 users
bucket 2: 10 to 99 users
bucket 3: 100 to 999 users
bucket 4: 1000 to 9999 users
bucket 5: 10000 to 99999 users
bucket 6: 100000 to 999999 users
With this, you have needed only 6 buckets. Moreover, this probably maps to the real life distribution, so your charts read cleanly.- having strange networking issues on the blue side of a blue/green deployment
- networking engineers are involved
- nobody seems to be able to figure out what's going on despite LOTS of tcpdump/wireshark etc
- I suggest tcpflow[0] (which I used for protocol analysis of chat services etc)
- (there is some skepticism as I was SRE and not networking)
- Turns out that the TCP messages were getting truncated on the problem side
- Networking guys realize the config issue and fix it
I have other examples but this is why it's always good to learn new commands/tools etc.
This, in turn, reminds me of a quote from an army jungle survival expert: "People ask me if it's a good idea to read survival books. I say: 100%. You would be surprised how many people survive an emergency situation because their brain pops out some critical piece of information from a book or article they read 10 years ago."