i'm thinking of writing an "implement a toy version of HTTP in a weekend” guide, similar to https://implement-dns.wizardzines.com/, but not sure what would be fun to include
thinking of:
1. sending a simple HTTP GET or POST request over a TCP socket
2. some very very basic header/status code parsing
what would you be interested in seeing in there, if you're curious to learn more about HTTP? As usual the goal is just to write a fun throwaway implementation, not something resilient
what would you call a git commit that can no longer be reached from any branch or reference (for example because you ran `git commit --amend` or `git rebase`), but that you can still get to from `git reflog`?
I've considered "orphan", "dangling", and "unreachable" but none of these seem right:
- orphan has another meaning in git
- dangling only refers to the "tip" commits
- "unreachable" means that you can't reach it at all
i uh spend a lot of time thinking about whether various surprising software design choices are
a) intrinsic to the problem domain ("it turns out it DOES make sense!”)
b) made sense historically ("this made sense in 1992, but it didn't age well”)
c) just a typo/mistake (the "Referer" header)
d) related to budget/time constraints (“well, prototyping with shell scripts is fast!”)
e) cultural/organizational (“well, Google is the main funder for this project, and…”)
f) something else
@93761c39 that's definitely true, how do you think it's related to those things being shell scripts originally? feels like you could have shell scripts with consistent flags
this morning I'm thinking about how git's history of being built as a series of shell scripts has affected its user experience
my sense is
1) a lot of git was originally built as shell scripts
2) the user experience you can provide in a shell script is extremely limited
3) a lot of that now can't change for backwards compatibility reasons
does anyone have examples of this? will talk about how I think this affects merge conflicts in the next post
(1/?)
i just understood today that the reason I feel stressed out about merge commits is that you can't figure out the contents of a merge commit by looking at it with `git show`
for example in this screenshot I have two merge commits (`merge1` and `merge2`). They both have the same parents. They display the exact same way with `git show`. But they have different contents.
https://cdn.masto.host/socialjvnsca/media_attachments/files/111/999/930/147/508/928/original/b31370668435f50b.png
A while back I wanted a spellcheck, and I couldn't find one that gave me the results I wanted (because I use a lot of terminology/jargon that isn't in the dictionary). Someone suggested that I write my own spellcheck program, based on this guide by Peter Norvig, and it's actually worked really well, better than any other spellcheck I've tried https://norvig.com/spell-correct.html
it looks like this https://gist.github.com/jvns/702a51110d55b99d6c468cde60b45dbb
you probably shouldn't use my spellcheck script (it's a bit of a mess) but I feel like the reason this works well is that I put together my own list of "correct" words (based on my own past writing and google n-grams) and it results in a lot fewer false positives
feels like there must be a "real" spellcheck program out there that has tools to help you automatically assemble your own dictionary of "correct" words based on a corpus of your writing
would folks be interested in some kind of “get print copies of every zine julia has ever written" product?
(right now there's a 13-pack for sale on the store, but it doesn't include print copies of the free zines)
@30947101 very simple, just sending the zines with letter mail. The weight limit for letter mail is pretty low though so I think it only works if you're ordering 1 zine.
@b2f27659 printing is easy. the main problem is that I use a really incredible US-based shipping service (https://www.whitesquirrel.com/) to handle fulfillment and I'm not aware of any similar overseas services.
@cd901075 i love zulip (i’ve used it every day for 10 years) but my impression is that it can be a bit hard to use for casual/infrequent users, probably because it’s a small company with less designers. It definitely has a lot of UI stability over time which I really appreciate as a long time user
@0d50376e i'd love to read that article! when i talk about avoiding async rust i'm talking about programs that interact with networking (like for example a program that captures packets) but aren't very performance sensitive
@0d50376e this might be a bad question but as someone who finds async rust confusing and who (I think) has no real need to use it, do you think there's a reason for me to learn about async rust?
i've been trying on and off for years to find a small subset of rust that I can actually get comfortable with and I haven't yet been able to figure out which parts of Rust I want to learn vs ignore
has anyone tried using the 'git undo' from the git-branchless project? https://github.com/arxanas/git-branchless
a general "undo" feature for git seems like such a cool idea and I'm curious about whether it works well in practice
(the way we solved expensive international zine shipping was the simplest possible thing: just use letter mail! put a zine in an envelope with a stamp. It took a while to work out the logistics though.)
Oddbean new post about login | logout
Notes by Julia Evans | export
i uh spend a lot of time thinking about whether various surprising software design choices are a) intrinsic to the problem domain ("it turns out it DOES make sense!”) b) made sense historically ("this made sense in 1992, but it didn't age well”) c) just a typo/mistake (the "Referer" header) d) related to budget/time constraints (“well, prototyping with shell scripts is fast!”) e) cultural/organizational (“well, Google is the main funder for this project, and…”) f) something else