Governments should use a public git for their laws

!rant
!!pride

I tried finding a gem that would give me a nice, simple diff between two hashes, and also report any missing keys between them. (In an effort to reduce the ridiculous number of update api calls sent out at work.)

I found a few gems that give way too complicated diffs, and they're all several hundred lines long. One of them even writes the diff out in freaking html with colors and everything. it's crazy. Several of the simpler ones don't even support nesting, and another only diffs strings. I found a few possibly-okay choices, but their output is crazy long, and they are none too short, either.

Also, only a few of them support missing keys (since hashes in Ruby return `nil` by default for non-defined keys), which would lead to false negatives.

So... I wrote my own.
It supports diffing anything with anything else, and recurses into anything enumerable. It also supports missing keys/indexes, mixed n-level nesting, missing branches, nil vs "nil" with obvious output, comparing mixed types, empty objects, etc. Returns a simple [a,b] diff array for simple objects, or for nested objects: a flat hash with full paths (like "[key][subkey][12][sub-subkey]") as top-level keys and the diff arrays as values. Tiny output. Took 36 lines and a little over an hour.

I'm pretty happy with myself. 😁

If you just git add . by instinct, you're already dead inside

Instead, consider checking out the diffs of your changes before staging them, and then stage the files or directories individually

Of course I'm saying this to complain about my colleagues who stage and commit things they shouldn't, it probably doesn't apply to small side projects, but staging individually is probably a good habit to have

This happened 3 years ago in my previous company. It was a small start up company and we worked on PHP stack. One of the its ex-founders had written Windows Mobile App which now had to be upgraded with new features. So we hired this new dot net guy. I always thought dot net guys were ELITE coders and was excited to see how they work.
While I played Xbox and had fun, our dot net guy stuck to his workstation furiously working. My boss who was casually strolling out of his office for a stretch saw dot net guy working hard and suggested we all developers should take him as an example.
20 days went by and each day the dot net guy did the same. He came, he silently worked on his workstation, he left in the evening. In those 20 days my boss asked twice to the dot net guy if he has finished features he was assigned but he said he did not. After a month when he said the same negative answer and had nothing to show for the work he has done he was fired.
I was so curious to see what code that ELITE coder had written for a month but could not deliver a feature(Maybe some error he could not fix?). So I open the code repo on which he worked and I see 30 commits from that guy to it. He had made a single commit each day(Fair enough he wants to commit everday before leaving). It was time to check his commit diffs to see his ELITE code. What do I find? In every fucking commit he either added a blank line to the DocBlock or removed the same. Nothing less nothing more! So much for the hyped not-so-ELITE dot net guy...

Elasticsearch, from the bottom of my heart...

How can one ecosystem be so batshit crazy inconsistent?

Seemingly every agent does the same (e.g. filebeat vs journalbeat vs packetbeat)… yet there are subtle changes in configuration everywhere.

Plus YML. The most shitty markup language one can use and the cockslubbing durps used it fucking everywhere.

Makes fun to have complex stuff and requiring a python Jinja to JSON to YML converter to be able to write the complex stuff without having the fucking migraine to count like a stupid 4 year old whitespace with both hands...

To make it even more absurd: the ingest pipelines which contain a lot of regular expressions / grok and are thus very prone to quoting issues... Yes. Let's do this in YML too.

If you need to add an fucking manual section how to debug YML errors you should have realized what a fucking stupid idea it was, morons.

Now I have the joy of having a python script regex quoting the shit for a Jinja template which then generates JSON which then generates YML.

Why the JSON part?

Yeah... Because ECS and changes in the upstream YML files / GitHub.

To be able to run diffs in a sane way because in YML distinguishing thing is pretty much impossible, so JSON as an intermediary format solely for the purpose of converting upstream YML to JSON to diff it against modified JSON ingest pipelines downstream.

I fucking hate elasticsearch

So we have this team that deploys some code. We had a change in that code that "we" forgot about. Turns out, a dev on our team decided it would be cool to rename an endpoint. Why? Great question. Because. So this code gets deployed, but the call to that endpoint didn't get deployed. System 2 tries to call the endpoint, 404. We roll back, we're searching, after like an hour, we find it. We go to TFS to see who did it. The dev grabs my keyboard and starts checking diffs, somehow managing to skip their commit (from 5 months earlier). I take back my keyboard and *surprise* it was the commit that was skipped. WTF? Why did you rename that endpoint? What do you mean you didn't do it? It has your name right there!

My manager says you shouldn't be doing archaeology work looking at old pull requests and git diffs to figure out how things work.

Are there scenarios when this is useful? How common are they in your day to day?

Another terrible rant from the inhereted Hydra source code. So deep in the dark dungeon of that code I noticed something interesting. They declare this INT32 array with an incredibly long (like 200 values) list of hard coded magic numbers. Something along the lines of:

INT32 array[200] = {-1,0,1,21,4,7,19,33...};

However, the resulting output was incorrect. After spending a fort night and a good chunk of my remaining sanity I had overcone the 437 levels of indirection left by the previous programmers, and narrowed it down to this line. But it looked perfectly fine.

I pull up the diffs and notice someone had checked in a change to the source. I track it to this line and find what the original data had been.

INT32 array[200] = {-1,0,1,2l,4,7,19,33...};

In VS the default font shows l and 1 as fucking identical. Someone had accidentally made that change to 21 from the original 2l and checked it in. I mean I can't really blame them. Who the fucking hell inatantiates a fucking int32 array and peppers in a fucking 2l (long) for no fucking reason?!

I prefer VSCode over visual studio for a ton of tiny conveniences. Some git operations can really only be done conveniently by switching rapidly between the command line and the big scrollable list of diffs. The currently open file is automatically focused in the tree, not by explicit user command. Ctrl+Tab shows the last viewed section of files and not their name, so I can find an arbitrary point in my jump chain. If I open the diff for a newly added file it's possible that I want to edit the file, but it's also possible that I didn't notice that it's newly added. Painting the whole background green doesn't hinder the first scenario nearly as much as it solves the second, in contrast to VS not showing any changes, which just has me confused because of the total lack of modification marks.

Just finished cleaning up my branch so it can be merge. The PR's Diff is massive... probably the largest on the team based on new lines of code.

Basically a migration of a massive report that took almost 2 years to resolve most of the diffs.

Now just need to get it ready production... By next weekend

Diffs are for noobs anyway!