We've been experimenting with various skills and MCPs in our day-to-day Ruby development at Poll Everywhere. This is the internal skill that's been most useful for preserving the context window while letting agents explore Ruby code.
It's a CLI wrapper around Ruby's Prism gem that lets the agent do this:
Back in 2004, while bored in my college dorm, I learned the Ian Knot from this site. I've used it ever since. A few weeks ago, my 10 year old decided it was time to learn how to tie his shoes "dad's way". I was pleasantly surprised to see the site was still up, so I used it to help teach him how to do it.
Also been exclusively Ian Knot every since. Lightening fast and consistent.
Funny anecdote: In college when I learned it, the woman I was with was leaving my place and when she was putting on her shoes I said "wait I gotta show you something" and dropped to one knee to tie my shoes. She looked terrified until I clarified it was my tying my shoes quickly and not a proposal.
I also learned it back in 2004 and it was one of the single most useful skills I have ever acquired. My shoes never come untied anymore. Coaching baseball, when a kid's shoe comes untied, I re-tie it for them with the Ian knot. Life changing skill.
Amongst all of the technological advances available to us, tying my shoes using the Ian Knot is the one thing that will get people to accuse me of witchcraft.
I've tried a couple of these "better" shoe tying knots and have never had the patience to learn them to the point they become habitual. So I can spend 2 seconds tying a shoelace the way I learned when I was 5 years old, or I can spend 5 minutes fumbling with some other knot. I go with what works for me. Optimizing the time I spend tying my shoes just isn't anywhere on the radar of things that would have a worthwhile ROI.
Part of me wonders if I should be on ozempic since I have a family history of several of the issues it's reported to help with.
Another part of me wonders if all the ozempic headlines I've seen over the past few months are just an incredibly effective and well orchestrated ad campaign.
The symptoms you are describing are indicative of a subtle and well orchestrated ad campaign. You start seeing a lot of news articles about [commercial product]. You start hearing a lot of seemingly grassroots talk about [commercial product]. [Commercial product] is touted as miraculous and too good to be true. You start thinking maybe you need [commercial product]...
Ask your doctor, you may be suffering from acute advertisement-induced judgment impairment.
It's possible, but I don't think it would be necessary. I know multiple people who have lost weight on it, and it sells itself.
After years of talking about the overweight epidemic, there's now medication that solves it. It's impossible not to talk about, whether your angle is "too good to be true" or "amazing step forward for humanity" It's ripe journalism bait and if a journalist decides to investigate they are going to write an article. Even if they don't find anything of value.
I used this to build my current keyboard a few months ago. It was my first hand-wired keyboard, and this made it much more approachable. Thanks for creating it!
GET shouldn't be used for a delete action, because it's specified as a safe method[0], which means essentially read-only. On a practical level, clients (like browsers) are free to cache and retry GET requests, which could lead to deletes not occurring or occurring when not desired.
That means I can make you delete things by embedding that delete URL as the source of an image on a page you visit.
GET is defined to be safe by HTTP. There have been decades of software development that have happened with the understanding that GETs can take place without user approval. To abuse GET for unsafe actions like deleting things is a huge problem.
This has already happened before in big ways. 37Signals built a bunch of things this way and then the Google Web Accelerator came along, prefetching links, and their customers suffered data loss.
When they were told they were abusing HTTP, they ignored it and tried to detect GWA instead of fixing their bug. Same thing happened again, more things deleted because GET was misused.
GET is safe by definition. Don’t abuse it for unsafe actions.
You can already do POST requests by embedding forms and/or JS. And with the proposed <button method=DELETE> you could also embed that. So I don't see how the proposal of adding more HTTP methods to html elements prevents abuse.
I think you're misunderstanding what your parent meant by "abuse".
In in this context it meant "misuse", there's no malicious actor involved. GET should have no side-effect which enables optimisation like prefetching or caching: they used it for an effectful operation (deletion) so prefetching caused a bug. It's the developers fault, for not respecting the guarantees expected from GET.
If they'd used POST, everything would have been fine. There's much less of an argument for using `POST /whatever/delete` rather than `DELETE /whatever`. At this point it's a debate on whether REST is a good fit or not for the application.
It prevents "required" abuse of the HTTP protocol (having to pipeline everything via POST even though that's not its purpose), without the requirement of adding javascript to the page.
Well, its correct, so its likely to be optimized correctly, to aid in debugging, to make testing easier and clearer, and generally just to be correct.
Correctness is very rarely a bad goal to have.
Also, of course, different methods have different rules, which you know as an SE. For example, PUT, UPDATE and DELETE have very different semantics in terms of repeatability of requests, for example.
If it only lets you select one, that's strictly less powerful. What if I want some parts of it into one commit and another parts into another? The `hg absorb` works for this case.
Yeah, it's definitely less powerful that what absorb is doing. I wasn't trying to argue that it was equivalent. I just wanted to share a bash one-liner that I've had success with in case others find it helpful.
> What if I want some parts of it into one commit and another parts into another?
Looks like absorb will automatically break out every hunk into a separate fixup commit. My one-liner will create 1 fixup commit for everything that's staged. That's typically what I need, but on the occasions it's not, I use `git add -p`, as kadoban mentioned, to stage exactly what I want for each commit.
Oh, hrm, looking at this description and the one liner, I rather like.
Once you mentioned `git add -p` I realised that this is pretty much what I do already, except with a far more efficient way of selecting the relevant commit to do it to.
Then you use `git gui`, which is part of the git distribution itself, or `tig` if TUIs are your thing. I have a key binding for `git commit --squash=%(commit)` in my tig config, so I can interactively select lines or hunks to stage and then the target commit for the squash.
That still requires you to manually select hunks. The point of `hg absorb` is to automatically select hunks even if these hunks are to be squashed into different commits.
# make a fixup commit for the last time the file was modified
cff = "!f() { [ -n $@ ] && git add $@ && git commit --fixup $(git last-sha $@); }; f"
# Get latest sha for file(s)
last-sha = log -n1 --pretty=format:%h --grep 'fixup!' --invert-grep
Given a file like `git cff path/to/file.rb`, It'll find the last commit that touched that file, and make a fixup commit for it. Its great for the try-this-change-on-CI cycle: Change the Dockerfile, git cff Dockerfile, push, repeat, without it screwing up because you changed a different file while you were working on it.
It won't matter until it does, but $@ expands arguments into separate words but those expansions are themselves only word-preserved if the $@ is itself quoted. The [ will probably get away with what you want, but its use in $(git add) and $(git last-sha) almost certainly will not
$ cat > tmp.sh <<'FOO'
for a in $@; do echo "a=$a"; done
echo
for b in "$@"; do echo "b=$b"; done
echo
for c in $*; do echo "c=$c"; done
echo
for d in "$*"; do echo "d=$d"; done
echo
FOO
$ bash tmp.sh 'alpha beta' $'charlie\ndelta'
a=alpha
a=beta
a=charlie
a=delta
b=alpha beta
b=charlie
delta
c=alpha
c=beta
c=charlie
c=delta
d=alpha beta charlie
delta
Your alias seems like a completely unecessary complexity. If you want to meld new changes into your branch head you can just alias “git commit --amend”, you don’t need that mess.
Absorb will find the commits to fix up for each change in the working copy, it doesn’t just merge everything into the head.
I see, the reason it’s that long complicated alias was that I didn’t want to open up the editor to change the commit every time I updated. “git commit —amend” does that.
I read the rough how it works and it now makes sense. I might give it a try. Thanks!
That is correct, and there is a `--edit` to revert that, so my personal alias is to `git ci --amend --no-edit` such that by default it just merges the staging into the HEAD, and then tacking on `-e` will open the commit message in an editor to expand it.
This was 100% my inspiration. I used emacs+magit for years. After switching away from emacs for dev work, I still cracked it open for git interactions for another year or so. Eventually, I moved entirely to the shell with a bunch of aliases to replicate my magit workflow.
Give me 10mb and an API like service workers have to manage a library of custom elements that can be used on my site as soon as the page loads.
reply