erikbern/git-of-theseus: Analyze how a Git repo grows over time
Link: erikbern/git-of-theseus: Analyze how a Git repo grows over time: "Analyze how a Git repo grows over time."
Look at this interesting graph showing code “survival” over time. It reflects an almost too “textbook” pattern, with older code getting refactored out of existence. The chart comes from the tool linked here.
rhannequin/astronoby: Ruby library based on astronomy and astrometry books
Link: rhannequin/astronoby: Ruby library based on astronomy and astrometry books: "Ruby library based on astronomy and astrometry books - rhannequin/astronoby"
This is for you #astronomy geeks out there. A package containing a bunch of technical algorithms used in astronomy. If you’re writing the next best solar eclipse automation app, this is for you!
System tests have failed
Link: System tests have failed: "When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to imple..."
DHH declares system tests to be a failed experiment in the attached document. This is surprising to me but then not surprising. Surprised because intuitively it seems that system tests should be better for the stated reasons. And politically because it seems that the Ruby world had accepted that unit tests are easy to write but too brittle. And system tests were more real-life and robust. But not surprised because I have always found system tests a pain to write. But I don’t have large scale experience with that so I tended to agree with the world that system tests (aka end-to-end tests) were better. So here comes #DHH to argue that system tests have failed!
Smooth Concurrent Updates with Hotwire Stimulus - Blog - Visuality
Link: Smooth Concurrent Updates with Hotwire Stimulus - Blog - Visuality: "It's time to get familiar with another part of Hotwire: Stimulus! In this article, I'll demonstrate using Stimulus to handle more complex frontend logic."
I admit I get confused by the various packages in this family of related low or no JavaScript goodies released by DHH. Hotwire, Stimulus, Hotwire Stimulus (something different, I guess). Some come with rails, some compete with each other. No matter, I love them all. I love the idea of not having to write and debug JavaScript. Here’s an article with code that shows a great use case.
Don’t Refactor Like Uncle Bob. Please
Link: Don’t Refactor Like Uncle Bob. Please: "Correction: Throughout this article, I attribute Chapter 2 of Clean Code to Robert Martin, however I was recently informed that this particular chapter was actually authored by Tim Ottinger. That s…"
A nice deconstruction of a refactoring gone bad. The article makes good points and I agree that Uncle Bob’s (tm) refactoring is not great. Oh but apparently a ghost writer wrote that chapter. Now in defense of the book, it was written many years ago and we’ve all gotten a lot smarter about what it means to write Clean Code (tm). Here’s the article:
Silicon Valley’s Best Kept Secret: Founder Liquidity
Link: Silicon Valley’s Best Kept Secret: Founder Liquidity: "Ask most venture-backed founders why they get 10x more equity than employee #1, 100x more equity than employee #5, and 1000x more equity than employee #15, and you'll get the same answer: "I'M TAKING SO MUCH RISK, IT'S SO HARD TO START A COMPANY, I MADE A BIG MOVE!!!" And"
Another reason why I believe being the founder of a well funded startup is not risky. If the startup is indeed well funded then you as a founder or employee can count on your salary for say between one and three years. No matter what revenue or earnings are, because they are not expected at the very start. Compare that with a job at an established company where layoffs can come out of nowhere and affect anyone. Not sure which is riskier … it depends … but in my opinion the startup is not clearly riskier. See the attached article for an explanation of one factor, but not the only factor.
TEO
Link: TEO: "TEO is the schema-driven web server framework native to Rust, Node.js and Python. It reduces developing time and improves developers' life experience."
Wow a brand new web framework! Where did this spring from, apparently fully formed, out of nowhere? Or am I not hanging out in the right neighborhood? Take a look at the attached site!
How to Annotate a Graph with Matplotlib and Python - Mouse Vs Python
Link: How to Annotate a Graph with Matplotlib and Python - Mouse Vs Python: "The Matplotlib package is great for visualizing data. One of its many features is the ability to annotate points on your graph. You can use annotations to"
The attached article shows nice code examples on how to put arrows pointing at specific points in your graph
How to Build Anything Extremely Quickly - Learn How To Learn
Link: How to Build Anything Extremely Quickly - Learn How To Learn: "Do “outline speedrunning”: Recursively outline an MVP, speedrun filling it in, and only then go back and perfect. This is a ~10x speed up over the ‘loading-bar’ style (more on that below) Don’t just read this article and move on. Go out and do this for the very next thing you make so you can […]"
This reminds me of the oil barron”s secret to great wealth: “wake up early. Work late. Strike oil”.
So I tried Rust for the first time.
Link: So I tried Rust for the first time.: "My first attempt at writing a program in rust."
Rust is an interesting language no doubt. I’ve written about it before. The attached article does a nice job of laying out the pros and cons, and it rings true to me.