Talk Python in Production (opens in new tab)

The cover has a stack that says "ngirx", and it's all a smudgy mess.

"Don't judge a book by its cover" is for people who don't actually read books. You can't necessarily tell when a book is good based on its cover, but you can absolutely tell with a high certainty that a book with a lazy, crappy, low effort cover is probably going to have a similar level of care and attention put to the contents. It's easily at least a 95% hit rate. Is not overly critical to see something presented lazily and assume it will also be lazy inside, and in this kind of field, I'd also expect that if the cover is AI generated, most of the content could easily be as well.

With an image that is that poor quality, if it didn't matter then it would have been better not to include it.

"Don't judge a book by its cover" indeed (and litteraly in that case), but also "first impression matters".

In that case throwing a generated image without touch up shows the lack of care of the author for a work that's not as fleeting as a podcast. It's not that hard to type the correct words and/or a non wobbly font with Paint.NET / Photopea / Gimp / Affinity Photo / Photoshop / <your favorite pixel editor here>. It also shows an usage of AI without supervision which is kind of a red flag.

I used to listen to Michael Kennedy a lot when my day job was Python, and still occasionally do so this may get a pass, but it's still a bad signal in my books.

But there was no care in the images, which made me skeptical of the content. The free chapters are also poorly written. It reads like he dictated the content and didn't do a single review pass on it. The Docker Compose chapter especially is very light on details and doesn't explain how to use the various features and what tradeoffs or issues you may encounter. Like the AI images, the whole product feels rushed and haphazard and lacking in quality.

In which case it is very infuriating and sad. Honestly if he just did not put that AI art on every page, the whole thing would look way more serious. Presentation and first impression sadly do matter. Put a pile of trash in a museum and people will think it's art, put art next to a pile of garbage and people will think it's trash.

Thanks Ayhanfuat. I appreciate the comment. Yes, the image is AI generated, but the book and the content is not. I spent 9 months writing it. Cheers.

but clearly he lapsed here and as a non-listener I immediately clicked out.

Just not enough to actually record a podcast, but generate a script and send it to an API to generate a (very recognisable) AI voiced podcast. It's literally called "Talk Python" with no humans talking.

I agree with everyone! Michael's name is a big stamp of "this will be high quality" for me, but if I didn't previously know that and saw an AI generated cover, there's a good chance I'd assume the content inside was AI generated slop, and might tune out without looking any further.

And you definitely don't want to miss "Web Arppss" running on "Limux"!

we've integrated granian into our stack at $WORK recently and couldn't be happier

How many people who you hire for $100 will do this themselves without AI these days?

Hey Joel, please point to example of AI voices, especially sold as real, on the podcast.

> ngirx and granian are my favorite technologies to work with!

I had the same initial thought, but I was skimming the page and came across this line:

> Then, see how to deploy a Flask+HTMX app via Granian, wire it into NGINX, and ensure automatic startups with systemd.

So I've just discovered that https://github.com/emmett-framework/granian exists...

The dark mode still has a white background so there's no reason to have it.

Zero percent of the text is AI generated. The image, yes, but I spent 9 months writing this book personally.

I recently compared AWS and Hetzner, not only in terms of raw compute costs but also by factoring in the personnel costs required for operation. I found this perspective particularly interesting: https://beuke.org/hetzner-aws/

Very cool Kumzy. Litestar is awesome, I interviewed some of the folks (you?) on the podcast. I give it some good press in that chapter.

Hey, you just run whatever backup command you would regularly do via compose.

For example, if you run `sqldump --db umami ...` in regular postgres (which is what they are using IIRC), then you run:

docker exec umami "sqldump --db umami ..."

Or something almost exactly like this (just from memory here and I wrote that script a year ago).

I don't think I've seen a cloud-first company that spent less engineering time on managing their infrastructure. You just replace one set of work with another.

See my comment above. In the book, I "show my work" on the math.

At which monthly spend should we negotiate with AWS for example? And will they check if we are using 25 of their services instead of easily migratable VM-hosted apps?

The main text is black yes, but anything that's bold is light grey as per the CSS, which is near unreadable (even if you're not as colourblind as me I suspect)

It only happens if you are using dark mode. That seems to be the only difference between light and dark mode on that site.

Presumably just directly on whatever system they are using. If you have something that can be plopped on whatever linux distro and run reliably then you've already got what docker is supposed to give you.

Exactly as sibling comment says, e.g. let's pretend the popular httpx cli was my project to deploy and run on the server. With only uv installed, i can:

    uv tool run "httpx[cli] @ git+https://github.com/encode/httpx"

To be clear in this example i'm not pulling a package published on pypi, i'm running the HEAD of that git repo (i could do a branch or tag instead). I could use the "uvx" shortcut instead of "uv tool run". I could specify a specific python version (either one already installed on this OS or choose a dist which uv downloads for me).

This caches the deps in an isolated virtual env for me. It'll only download the deps in the first run.