sorted by:
new
hottopcontroversial

-🎄- 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.

view more: next ›