Here’s the motivation behind this Rust-based TUI:

I do most of my git work in a terminal but I frequently found myself using git GUIs for some use-cases like: index, commit, diff, stash, blame and log.

Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable.

GitUI provides you with the user experience and comfort of a git GUI but right in your terminal while being portable, fast, free and open source.

This week on The Changelog we’re talking about Stable Diffusion, DALL-E, and the impact of AI generated art. We invited our good friend Simon Willison on the show today because he wrote a very thorough blog post titled, “Stable Diffusion is a really big deal.”

You may know Simon from his extensive contributions to open source software. Simon is a co-creator of the Django Web framework (which we don’t talk about at all on this show), he’s the creator of Datasette, a multi-tool for exploring and publishing data (which we do talk about on this show)…most of all Simon is a very insightful thinker, which he puts on display here on this episode. We talk from all the angles of this topic, the technical, the innovation, the future and possibilities, the ethical and the moral – we get into it all. The question is, will this era be known as the initial push back to the machine?

Austin Gil joins the show and KBall continues an old email correspondence about the JS community and growth. Then, the gang plays a round of TIL where Austin shares his learnings about the HTML capture attribute. Finally, Austin shares what it’s like to have a blog post blow up.

So you got tired of AI just suggesting code edits, and now you want it to help you run code, too. Silly human, you have come to the right place. This will take five steps.

This gets an A+ for creativity. Fire up your shell, then launch Neovim. Then shell out with :VimShell to get back to where you started, but with Copilot suggestions.

My guess is the ergonomics of this are… bad. But a cool hack, regardless!

This tool calls itself the “best RSS search experience you can find” but really, are there other RSS search experiences out there? The results are a little underwhelming at the moment, but I’m sharing it because RSS and I’m sure it’ll get better with more eyes/feeds on it. 👀

Devon Zuegel draws a comparison that I would’ve never thought of:

Pirate crews developed a surprisingly similar approach to compensation in the 17th century. Just like many startups, they also balanced equity incentives with other mechanisms that would be familiar to a startup employee today, such as bonuses.

These surprising similarities offer an interesting frame through which we can reflect on why startup equity and bonuses are structured the way they are. We can learn a lot about the theory of compensation in modern companies by looking at how pirates designed incentives to organize and motivate their work.

Maybe it’s time to stop hiring “frontend wizards” and start looking for “frontend pirates” instead, matey.

Inbal Cohen, Product expert and Agile evangelist, joins Natalie & Angelica for a conversation about all things Agile. Inbal lays out some agile tips for Go devs, discusses if and how remote work changes things, describes some downsides of the methodology, and more.

Dan Hollick nerds out on the history and anatomy of a QR code. This bit at the end is super cool:

Perhaps the coolest thing about QR codes is that Denso Wave, the company that invented them, never exercised their patent and released the technology for free!

The title of this post is “Why I Love Go”, I saw it shared by Rob Pike (one of the founding team for Go). In the post David Yach talks about how productive interns can be with Go, writing substantial prototypes in a short period of time. That’s one of the reasons I like to use it for OSS container/networking projects and developer tools too.

Jaun Diego covers some little known yet extremely useful APIs, such as the Page Visibility, Web Sharing, Broadcast ChanneI and Internationalization.

In today’s Kaizen episode, we talk about shipping Adam’s Christmas present: chapter support for all Changelog episodes that we now publish. This feature was hard because there are many subtle differences in how the ID3 spec is implemented. Of course, once the PR shipped, there were other issues to solve, including an upgrade the world kind of scenario. Since Lars Wikman did all the heavy ID3 lifting, he is here with us too.

This nifty little web app lets you tour the history of a file on GitHub. The coolest part about it is that you don’t have to download or install anything! Just change the github.com part of the URL with github.githistory.xyz and you’re in action!

The new stable diffusion model is everywhere! Of course you can use this model to quickly and easily create amazing, dream-like images to post on twitter, reddit, discord, etc., but this technology is also poised to be used in very pragmatic ways across industry. In this episode, Chris and Daniel take a deep dive into all things stable diffusion. They discuss the motivations for the work, the model architecture, and the differences between this model and other related releases (e.g., DALL·E 2).

(Image from stability.ai)

This is cool because portability. But also because you can embed it as a library in your Go projects. It’s not identical to jq in practice, though. Here’s a long list of differences between the two.

This is a nice round-up of some new(ish) HTML and JavaScript features related to forms. Now that Safari 16 is out, good stuff like requestSubmit and showPicker are looking pretty green!

Hillel Wayne:

I practice “weak TDD”, which just means “writing tests before code, in short feedback cycles”. This is sometimes derogatively referred to as “test-first”. Strong TDD follows a much stricter “red-green-refactor” cycle…

Turns out I also practice “weak TDD” most of the time, but I didn’t know there was a (derogatory) term for it. In this post, Hillel lays out why he does weak TDD and why he doesn’t do strong TDD. Oh, and stick around to the end to learn why he thinks TDD hasn’t conquered the world…

A lot of ink has been spilt over the years trying to elucidate the divide between junior and senior. Miłosz Piechocki makes the distinction this way:

Junior Engineers care about writing Software. They value code quality, employ best practices, try to adopt cutting-edge technologies. They invest a lot of time into learning new technologies. To them, the ultimate goal is to create elegant, performant, maintainable software.

Senior Engineers care about building Systems. To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.

He goes on to describe how hard it is to build Systems and lists activities that are part of that process.

Jacob Kaplan-Moss writes up a hot take on software quality, Wilfred Hughes creates the diff tool he’s always wanted, Josh Collinsworth thinks React is only great at being popular, Jetpack’s Devbox project looks pretty cool & James Williams sets out to find the shortest URLs on the internet. Oh, and chapters are here!

11ty creator Zach Leatherman recently released a standalone HTML serializer for generating markup for Web Components. Here’s what Zach had to say about it on Twitter:

This is an early preview and I welcome feedback! I think it’s a great way to build standards-based HTML-first components without JavaScript framework overhead 🙌🏻

Jacob Kaplan-Moss with a hot take on software quality:

Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance. That is: a group of mediocre programmers working with a structure designed to produce quality will produce better software than a group of fantastic programmers working in a system designed with other goals.

What does he mean by “a system designed for quality”? Read on to see for yourself..