It could have been nothing. Which is why you investigate.
It wasn't nothing.
EDIT: You probably meant the code. Whoops. That's simple: Removing guardrails. Removing a null check, because it's "unnecessary" or "unreachable", etc. Opening memory holes, and burying that in larger commits.
He did not understand that things can change without him seeing it in the frontend and I was in the middle of a crucial rewrite.
Just like LOCs and commits, it's a starting point. A general indicator of where you need to dig deeper or who to prioritize in your review.
They say "oh it's not the only measure" ofc. Anything to downplay it to ICs. But then you chat with your jaded manager and you hear echoes of the insanity that goes on in performance review calibration and you aren't so sure about those qualifiers anymore..
1. How many developers have actually been working on this stuff
2. Has the guy who set up the wire-frame actually stepped back
3. Are there more developers doing stuff, then what we get the impression of, based on the weekly Teams meetings
All of these questions could be answered in 1 minute by starting 'gource' + increase the speed of the visualization for the past year. I was afraid that this newly hired consulting company was pretending to use less resources then they actually did, in order to sink their hooks into our company, which I could see instantly that they had been doing. I could also see that the "big gun" setting up the wire frame for the project, had not really been taken of the project at all, but had been helping some of the jr. devs all along. Something that would have taken some digging with 'git log' or 'tig'..
Appreciation for both the form and the function well blended in an artful way should not be offhandedly dismissed. We make a conscious choice when we build things to consider the users delight to be our responsibility, or not, so taking the extra step to make it beautiful as well as useful may sound superfluous but it isn't. Not by a long shot.
Also Amelia Wattenberger at GitHub has a great vistualization tool for those who think Gource is too much [1] while on the other side of the spectrum Ren Yuan [2] has been knocking out these amazing audiovisual art-meets-engineering pieces for all the big repos.
[1] https://githubnext.com/projects/repo-visualization [2] https://renyuan.io/commit/
It was appreciated by exactly zero people.
No regrets, I loved it.
https://github.com/martinn/repoblame if anyone's curious.
I didn't think much of it and run Gource on it for fun.
Turns out, he did countless rewrites over the year.
Interesting to watch and explained why the CEO seemed to so concerned about the dev, lol
Was it cool? Yes. Did it show the issue in an easily to understand way anyone could understand? Yes. Did it change anything? Hell no.
Only way to try it out is build it?
This makes me sad that this became an expectation. And yet, I've been distributing softwares via Docker for almost a decade now, but CLI/GUI tools?
The code is in C afaict. If it would be Go or Java, I would be fine to build it myself, but C…. I’m worried about getting into a rabbit hole especially as GPU support is required. Building with GPU on mac silicon can be pretty complex.
Compare this to running a container with 1 - 2 lines.
Btw I should have inquired about a container image, don’t want to imply that Docker is the default.
https://hub.docker.com/r/utensils/opengl/
Gource has two modes. One to generate the correctly formatted input file and another to render it.
If you are doing fixed renders, then it’s easy enough to run each process in turn, given a git repo URL which you need to pull locally.
You pipe your gource data source output to the gource renderer, which is running with a virtual screen via xvfb, which needs the same resolution viewport. You can then pipe that to ffmeg and save the output to a volume.
You could pipe using the flv option to an RTMP server or stream (see rtmp-hls based on nginx).
If you want to do realtime on Docker you’ll need to pipe one to the next and you will need to tweak ffmeg to provide a okish steady output video stream using the realtime flag on gource. You’ll need to find a way to poll your git repo and append to the gource input file though for full real time. Gource is smart, but not smart enough to do that without some workarounds. You might find supervisord useful to separate your processes in your docker container.
IIRC, there's another YT channel that took up the torch. I'm grateful they did. I know, they might seem a little spammy, and it can be frustrating when you Google for a repo and only find a mostly useless YT video of a Gource visualization. And yet, random devs used to email me with grateful messages every week. I felt like, in some microscopic way, I was doing good.
Yeah, I need to ponder and write on that. Hm. Well, this bubbly isn't going to drink itself.
I'll edit this comment into shape later. I'm on my phone at Hedwig's.
Love you to the random internet stranger who read this comment.
Love you to the person who posted this Gource link.
Love you to Andrew Caudwell, the creator of Gource. He seems like a good fellow, that Andrew Caudwell. Yes, quite so.
I think there is much value in Gource visualizations. My remake was rooted in a vocal minority who expressed a few negative comments on my uploads saying they were useless. I suspect they were just frustrated that they were looking for docs/tutorials and only found my video, heh.
With the right options and extensions/augmentation, Gource is incredibly useful. Especially when slowed down and when you add custom tailored config for each repo. That takes time, but can be automated as well. Ooo, that sounds so much fun!! Issue titles, big refactor custom highlights / slow-downs. Have it right next to JSCity (or equivalent for non-JS), gitstats, and... What was that other tool... You know, the one that makes watching network traffic fun? Oh! Codeswarm? No... It was... I'll find it. It's like ping pong. Where is my AI side panel when I actually need info without leaving HN?? Ok bye.
Next time I spam the planet with Gource videos, I vow to do it more justice :cat-salute:
Wow, what a monumental waste of resources. I'm kind of surprised you didn't get banned from Youtube for that.
I'll go first: Here is a Gource video of some months of development on Typeform when I worked there: https://www.youtube.com/watch?v=jTo9qy5mIWg
Uploaded ~10 years ago, and I'm pretty sure none of that code is being deployed anymore, at least I hope so.
Here's my personal projects from 2023: https://www.youtube.com/watch?v=BuzFtbM3qU0
1. Change to unlisted without selecting "for children"/"not for children".
2. Save, see an error about fixing it.
3. Select appropriate options.
4. Save and see "unlisted".
5. Video is actually still "private".
Otherwise a person who commits often (had someone committing per line changed) will make it super noisy. And someone who merges in a giant branch will just blow up the screen for a bit.
As long as they squash their history before it goes into the branch everyone shares/branches off from, I couldn't care less how they do their work.
But, pushing that aside, what could be the supposed benefit of committing each line like that? They'd spend more time writing commit messages than actual code, assuming the commit messages actually had proper meaning in them,.
If you're making two meaningfully different changes, I would always say two tiny commits are better. Not only for organization, but to make it easier to revert just one change.
As long as the tests pass on every commit that ends up the main development branch, you can pretty much do it however you want.
But committing per lines changed isn't "making two meaningful different changes", it's saying since they are on two different lines, they aren't related, which just seems wrong.