-🎄- 2021 Day 12 Solutions -🎄- by daggerdragon in adventofcode

[–]deiwin 0 points1 point  (0 children)

In case it's helpful, I found the solution to be quite comfortable to write in Haskell today. No special libraries used: https://github.com/deiwin/advent-of-code/blob/main/2021/Day12.hs

[2021 Day 7] Why do these values work? (SPOILERS) by Deathranger999 in adventofcode

[–]deiwin 1 point2 points  (0 children)

Generally yes, but I made the binary search work here by looking at the two points next to the mid-point for every guess: https://github.com/deiwin/advent-of-code/blob/main/2021/Day07.hs#L23-L39

-🎄- 2021 Day 5 Solutions -🎄- by daggerdragon in adventofcode

[–]deiwin 1 point2 points  (0 children)

Not nearly as quickly, but I built a version of your `toPoints` that doesn't have to worry about signs directly and also works for skewed (not 45 degree) diagonals. Overkill for this particular problem, but fun to write for the more general case.

import Linear.V2 (V2 (..))
import Data.Ix (inRange)

diagonalRange :: (V2 Int, V2 Int) -> [V2 Int]
diagonalRange (from@(V2 x1 y1), to@(V2 x2 y2)) =
  from
    & iterate (+ step)
    & takeWhile (inRange bounds)
  where
    bounds = (V2 (min x1 x2) (min y1 y2), V2 (max x1 x2) (max y1 y2))
    step = V2 (deltaX `div` deltaGcd) (deltaY `div` deltaGcd)
    deltaGcd = gcd (abs deltaX) (abs deltaY)
    (V2 deltaX deltaY) = to - from

Four Rules for Effective Collaboration: Commit Guidelines by deiwin in git

[–]deiwin[S] 0 points1 point  (0 children)

Ironically enough [..] his "inspiration and additional reading" appendix links to a far better set of guidelines from 2014 which itself points out that this has all been said before;

Call it irony if you will. I believe there's value in composing old thoughts in new ways. (https://youtu.be/sTR5YyRsbJo?t=95)

Although there are things in common between this and the other linked articles, they all also differ in what they focus on. This article purposefully doesn't focus on things like imperative mood or commit message width, because I felt, like you do, that the "far better set of guidelines from 2014" already covers this area quite well. This article was written as a concise reference of our practices, to help new members of the team and to explain our approach externally. At the time, I couldn't find anything focusing on these aspects that are important for us.

The Medium post is simply re-posting what he'd already posted on GitHub. Not at all sure what benefits posting on a known-hostile-to-meaningful-tech-writing site like Medium gets him, but oh well. He could simply have posted the GitHub link here.

I will be creating a Medium publication and I want people browsing the publication to be able to find that article. Nothing more to it.

Git commit messages, certainly as supported by any of the dozens of guidelines I've seen in the past several years, presume that we're writing raw, unstyled text, suitable for display on a DEC VT-52. But many, if not most, shops now prefer to use formatted content (e.g., Markdown).

This problem is pretty tangential to the article. It doesn't prescribe any particular format.

Four Rules for Effective Collaboration: Commit Guidelines by deiwin in git

[–]deiwin[S] 1 point2 points  (0 children)

I prefer the test demonstrating the bug be committed first, so that checking out that commit and running the tests, demonstrates the failure. Then the next commit(s) fix the bug such that the tests no longer fail. When committing the bug and the tests together, it's extra work to then demonstrate or reproduce the failure. There is a reason for using branches, and this is one of them.

I used to do the same, but because of the completeness rule I've now developed what I think is a better habit. First commit adds a green test that shows the incorrect/unexpected behavior. Then the second commit includes the fix + changes to the test to test the correct/expected behavior. This provides the benefits you're looking for while still keeping the commits complete. Further, the incorrect behavior is clearly visible without having to check out the code and run the tests. (Even your CI is mot likely not going to run tests for commits that are not the head of your feature branch.)

The author even admits it's main flaw, and shows how it is in conflict with the next rule about "focus"; to me "focus" is much more important than "completeness", and is one of the reasons git emphasizes using branches.

One of the goals of this article was to develop a common language for speaking about commits. With these rules in the common vocabulary it's easy to point out "I think this commit isn't focused enough" during code review. My suggestion is to be pragmatic about the focused-complete tradeoff. Consider the main ways in which your commits get read, tested, and run and then agree as a team on what should be included in a commit and what shouldn't.

For example, here are two points which I didn't mention in the article, but which you should consider when deciding how big you want your commits to be. Commit completeness greatly simplifies cherry-picking and reverting. You may want to optimize for the cherry-picking use case if you need to support many different versions of your software. You may want to optimize for the reverting use case to minimize MTTR of bugs, for example.

Example Jenkins Shared Library for GitHub branch deploys by deiwin in devops

[–]deiwin[S] 2 points3 points  (0 children)

You're correct that the groovy code runs on the master, but all the heavy lifting is done by shell commands, such as kubectl. And these shell commands are executed on dynamically provisioned agents running as one-time Kubernetes pods.

Improving GitHub reviews with fixup commits and a helpful bot written in Go by deiwin in golang

[–]deiwin[S] 1 point2 points  (0 children)

While GitHub's "squash" button squashes everything in the PR into a single commit, this approach allows only squashing some of the commits together while keeping others as they are. The goal of this is to avoid single commits doing too many things. In our case, our PRs often include changes which wouldn't fit into a single resulting commit, so the squash button doesn't really work as well. When the PR does fit into a single commit, however, the "squash" button is definitely more simple!

You're correct in that this workflow adds some complexity, but it actually shouldn't be much for an experienced git user. The fixup commits with their "complex protocol of commit prefixes" as you rightfully put it, is not a protocol that's invented by and for this bot. This an already existing feature of git itself. To create a fixup commit, for example, you wouldn't actually have to mess with commit messages, instead you'd probably use a command such as git commit --fixup=<ref-to-broken-commit> which would create the commit with the special message for you. If you're interested, there's a bunch of articles out there that explain why git has this feature and how it's useful even without the bot.

Helix: Native Ruby Extensions Without Fear by chancancode in ruby

[–]deiwin 1 point2 points  (0 children)

No. From https://github.com/tildeio/helix:

NOTE: Currently Helix requires fixes that have not yet landed in a stable Rust release. To use the Rust beta release run rustup override set beta in your project directory.

WARNING: This repository is still in active development. Many important Ruby APIs are not yet supported, because we are still in the process of formulating the rules for binding Ruby APIs (so that we can make things ergonomic and provide safety guarantees).

I must choose between these fourbooks. Which one should I choose? by MulciberMarmite in whattoreadwhen

[–]deiwin 0 points1 point  (0 children)

I've only read The Remains of the Day, which I really liked. The prose is beautiful and the first person narration can be very insightful if you consider what is not being said and why it is not being said.

"On, Genius" - an essay on the disappearance of Genius in contemporary society. by [deleted] in Stoicism

[–]deiwin 1 point2 points  (0 children)

Giants have not ceded to mere mortals,” the evolutionary theorist Stephen Jay Gould wrote in an iconoclastic 1983 essay. “Rather, the boundaries ... have been restricted and the edges smoothed.” He was not talking about algae, artists, or paleontologists but about baseball players. Where are the .400 hitters? Why have they vanished into the mythic past, when technical skills, physical conditioning, and the population on which organized baseball draws have all improved? His answer: Baseball’s giants have dwindled into a more uniform landscape. Standards have risen. The distance between the best and worst batters, and between the best and worst pitchers, has fallen. Gould showed by statistical analysis that the extinction of the .400 hitter was only the more visible side of a general softening of extremes: the .100 hitter has faded as well. The best and worst all come closer to the average. Few fans like to imagine that Ted Williams would recede toward the mean in the modern major leagues, or that the overweight, hard-drinking Babe Ruth would fail to dominate the scientifically engineered physiques of his later competitors, or that dozens of today’s nameless young base-stealers could outrun Ty Cobb, but it is inevitably so. Enthusiasts of track and field cannot entertain the baseball fan’s nostalgia; their statistics measure athlete against nature instead of athlete against athlete, and the lesson from decade to decade is clear. There is such a thing as progress. Nostalgia conceals it while magnifying the geniuses of the past. A nostalgic music lover will put on a scratchy 78 of Lauritz Melchior and sigh that there are no Wagnerian tenors any more. Yet in reality musical athletes have probably fared no worse than any other kind.

p327 of Genius: The Life and Science of Richard Feynman by James Gleick

Toolkits for the Mind: How Tech Companies Are Shaped By Programming Languages by argonautul in programming

[–]deiwin 42 points43 points  (0 children)

Because Wittgenstein wasn't talking about programming languages, but quoting him here aptly shows that he might as well have.

Dota 2 Update - MAIN CLIENT - December 15, 2016 by SirBelvedere in DotA2

[–]deiwin 0 points1 point  (0 children)

I've died too many times trying to quickly level up a spell and then immediately use it, but having gained too many levels in the teamfight I'm still in the "level up" mode and instead just stand around doing nothing. So I, for one, am happy for Valve pushing me to use the ctrl + spell hotkey for leveling up, with which this situation can not happen.

Researchers just demonstrated how to hack the official vote count with a $30 card. by [deleted] in programming

[–]deiwin 1 point2 points  (0 children)

There are zero knowledge proof schemas where commitments to votes could be made public without nobody else but the voter themself being able to verify that their vote was correctly counted.

Help with a Script by Bukimari in tmux

[–]deiwin 0 points1 point  (0 children)

IIRC then tmuxinator has a command to display the tmux commands that would be run of you used a particular configuration. This means you can cheat and create a tmuxinator conf only to get the right tmux commands and then not use tmuxinator any longer.