Top 5 Perl Git Projects
Good-lookin' diffs. Actually… nah… The best-lookin' diffs. :tada:Project mention: A New Indentation for Lists | reddit.com/r/haskell | 2021-06-16
If you want easier-to-read diffs, diff-so-fancy is pretty great.
Text::Amuse-based publishing platform
Scout APM: A developer's best friend. Try free for 14-days. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.
create fixup commits for topic branchesProject mention: Stacked Git – manage commits as a stack of patches | news.ycombinator.com | 2021-05-27
Somewhat (or possibly greatly) related:
Are tools like git-absorb safe/reliable?
"Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run `hg absorb` and the uncommitted modifications are automagically folded ("absorbed") into the appropriate draft ancestor changesets. This is essentially doing `hg histedit` + "roll" actions without having to make a commit or manually make history modification rules."
I haven't wrapped my head around the algorithm. I get that an algorithm can "recollate" a series of commits in a way that yields no commit conflicts, but that's not the same as rearranging and combining commits into a sequence of semantically coherent atomic commits.
Scripts for generating project statistics and for plotting them as graphs. (by curl)Project mention: I ****Ing Hate Science | news.ycombinator.com | 2021-07-20
> do not believe in the possibility of a "General Theory of Productivity." I'm highly skeptical of attempts to quantify the precise relationship between error discovery stage and cost in a way that is generalizable, although I think it might be possible given a large group of engineers using a highly homogenous process, tools, and accounting. Google is pretty close to this (common dev infrastructure across tens of thousands of engineers), and even across Google this kind of generalization would be extremely difficult.
I don't think you are incorrect, but I think a lot of the aspirants behind ESE just want to have a better sense of what works and what doesn't; I'd even welcome negative results! The current state of things is to read 100 opinionated people and their blog posts. And given enough time, you'll encounter someone who swears that after drinking their morning coffee and jumping on one foot for 1 min, they enter a VRChat standup with their team and hit max flow. There's just so little knowledge right now about what works and what doesn't that I'd welcome more clarity, especially negative results.
> As a result, academic research into productivity can be difficult to generalize
I think defects are what we should measure for, not productivity because of the subjectivity of measuring productivity. But even measuring defects is complicated. The best way I see to measure defects is to ask a Team Under Test to document bugs that they encounter along with resolution times, but this is not only expensive, but something I doubt most corporations will be willing to share outside of their walls. Perhaps open source projects can try to store this data, like curl's stats .
Various Perl projects and smaller Perl scripts.Project mention: just have discovered cheat.sh | reddit.com/r/linux | 2021-05-27
What are some of the best open-source Git projects in Perl? This list will help you:
Are you hiring? Post a new remote job listing for free.