Val Town, speed matters, imaginary problems, a gambler's guide to giving talks, DreamBerd, GPT tokenizers & more

Changelog News

Developer news worth your attention

Hello again! šŸ‘‹

Jerod here with your weekly dose of news-y goodness.

Q: How many Reddit protestors does it take to change a light bulb?
A: None. Reddit protestors donā€™t change anything šŸ˜”

Too soon? (via r/dadjokes)

Ok, letā€™s get into the non-reddit news. Audio version here.


šŸ¦¾ An open platform for operating LLMs in production

With OpenLLM, you can run inference with any open-source large-language models, deploy to the cloud or on-premises, and build powerful AI apps.

Just when you think ClosedAI & big tech might dominate our inevitably AI-infused futureā€¦ open source enthusiasts all around the world rally around each otherā€™s work and launch project after project after project offering viable (and sometimes superior) alternatives. Always bet on open source. šŸ’Æ

šŸƒ Working quickly is more important than it seems

When Mat Ryer was (jokingly) giving his 10 tips to be a 10x dev on Fridayā€™s Changelog & Friends, Adam asked what it even meant to be 10x. Is it all about speed? Is it productivity? Lines of code? Bugs?! I donā€™t think it really matters, but I do think speed matters and James Somers wrote as much back in July of 2015:

The obvious benefit to working quickly is that youā€™ll finish more stuff per unit time. But thereā€™s more to it than that. If you work quickly, the cost of doing something new will seem lower in your mind. So youā€™ll be inclined to do more.

Thatā€™s an interesting way to think about it. He likens it to email exchanges:

Iā€™ve noticed that if I respond to peopleā€™s emails quickly, they send me more emails. The sender learns to expect a response, and that expectation spurs them to write. That is, speed itself draws emails out of them, because the projected cost of the exchange in their mind is low. They know theyā€™ll get something for their effort. Itā€™ll happen so fast they can already taste it.

He generalizes this phenomenon as ā€œsystems which eat items quickly are fed more items. Slow systems starve.ā€ and gives a couple more examples, if youā€™re not convinced.

šŸ‘» Imaginary problems are the root of bad software

There are many factors which can be a catalyst for bad software: from the tools being used, to team communication, to the personal stake developers have in its success, to the testing methodology.

I propose that there is one problem chief among them, an impetus for bad software from which almost all others take root: imaginary problems.

Great post, George! This is why I say YAGNI ad nauseam and fight tooth and nail not to add new features until their value is already demonstrable.

HasuraCon 2023 is June 20-22 (Virtual and Free)

Thanks to Hasura for sponsoring this weekā€™s Changelog News šŸ’°

Our friends at Hasura would like to invite you to HasuraCon! Three days to learn, share, celebrate, and geek out on the future of Hasura and data APIs.

Data APIs are reshaping the world of data delivery, helping enterprises do more with their data by serving it where itā€™s needed and when itā€™s needed in a fast, secure, flexible way. Hasura and their customers are at the forefront, driving this shift. Costco, Verizon, Atlassian, General Mills, over 40 of the fortune 100 companies use Hasura.

HasuraCon features a world-class speaker lineup, hands-on workshops, product deep-dives, and more. Whether youā€™re a seasoned Hasura pro or just starting, there will be something for everyone.

And best of all, itā€™s 100% FREE and easily accessible online.

šŸ˜ļø Val Town is a social website to write and run code

The tagline for this brand new site from Steve Krouse (bankrolled by Daniel Levine) hits the bullseye:

If GitHub Gists could run And AWS Lambda were fun

Gists are cool. But theyā€™d be cooler if you could execute them. Lambda is cool. But it be cooler if it were actually fun to use. Enter Val Town, where you can write and share ā€œValsā€ (Vals are small JavaScript or TypeScript snippets of code, written in the browser and run in their servers.)

A ā€œValā€ dissected

šŸ Finish your projects

Aaron Francis for GitHubā€™s ReadME Project:

Sarting a new project is a rush. The possibilities are infinite. Thereā€™s no legacy code dragging you down; weā€™re only making good decisions this time! The beginning of any project is always characterized by blissful productivityā€¦.

Sooner or later, the blissful productivity gives way to something that feels much more likeā€¦ work. More like a grind. But itā€™s probably just this project, right? Youā€™ve lost interest. The passion is gone. Itā€™s not as fun as you thought it would be. All thatā€™s left is the ā€œboringā€ stuff.

You have a new idea, though, and youā€™re sure that youā€™ll see this one through!

And so the cycle continues, over and over again, until youā€™re left with a graveyard of unfinished projects, wondering how anyone ever finishes anything. What does everyone else know that you donā€™t?

Starting something is easy. Anybody can do that. Finishing is hard. Itā€™s what sets people apart. In this guide, Aaron walks you through the work of finishing and helps you take your project from ā€œmostly doneā€ to ā€œactually doneā€


How to make a QR code with Stable Diffusion

Two weeks ago I linked up an app for making QR codes with arbitrary designs in the middle and was properly link slapped by a reader with a (then dark) Reddit thread of someone making even more impressive QR codes with the help of Stable Diffusion.

So, last week I linked to an Ars Technica article about said Reddit thread with the full story and example images of anime QR codes created by Stable Diffusion.

This week I found an actual tutorial of the process, so you can stop merely admiring other peopleā€™s QR codes created by Stable Diffusion and start creating some of your own. I think Iā€™m done covering this topic. But I thought that last week tooā€¦

A gamblerā€™s guide to giving talks

Iā€™ve really been enjoying Benn Stancilā€™s Substack even though it tends to be more data-oriented than my usual fare. This post, however, strays from Bennā€™s usual fare into at topic on many of our minds: how to give a great talk. His advice on this is, in my opinion, priceless:

there are only two types of presentations: Forgettable ones, that waste away on YouTube with 18 views; and memorable ones, that bestow their creators with the lifelong benefits of having done something Good.

Nearly every talk is the former, and nearly everyone goes to every talk expecting it to be the formerā€¦ Thereā€™s very little risk in taking chances. A daring talk that flops and a cautious talk that safely sticks to all the comfortable best practices are equally ignored. But stick the landing on something bold, and the upside is unbounded.

Thereā€™s so much actionable advice here that part of me wants to give a talk soon just to try it all out and see if I can stick the landing.

DreamBerd is a perfect programming language

Donā€™t have time for the README? Just want to see this perfect language in action? Jump straight to the examples. This feature is super cool:

Itā€™s worth noting that Github Copilot doesnā€™t understand DreamBerd, which means that Microsoft wonā€™t be able to steal your code.

This is great for when you want to keep your open-sourced project closed-source.

Comic Mono is like Comic Sans but for coding

A legible monospace fontā€¦ the very typeface youā€™ve been trained to recognize since childhood.

Iā€™m pretty sure this is a joke but honestly I donā€™t hate itā€¦

Comic Mono in action

I donā€™t need your query language

Anton Zhiyanov pens up a (perhaps harsh) defense of SQL.

Every year or so, a new general-purpose database engine comes out. And thatā€™s great! It can bring new valuable approaches, architectures, and tools (plus, building database engines is fun).

Often this new database engine comes with a new query language. And thatā€™s probably good, too. Or maybe itā€™s not.

Iā€™m a big fan of SQL because I already know it* and not a big fan of new QLā€™s because I donā€™t know them. Does that make me lazy? Yes, perhaps. Does that make me wrong? Maybe someday, but it hasnā€™t yetā€¦

*(and Iā€™m an even bigger fan now that I donā€™t have to write it anymore)

Understanding GPT tokenizers

One question Iā€™ve been asking myself (and others) about AI things is: how much do I actually have to learn how they work and how much will I be able to get away with not knowing and still be awesome/productive/useful down the road? (Because Iā€™m lazy, remember)

I donā€™t yet have a solid answer to that question (WDYT?), but Iā€™m settling in on learning most of the stuff our friend Simon Willison writes about it and thatā€™s about all. šŸ˜œ

Ask not what the compiler can do for you

The folks at Hyperswitch arenā€™t ashamed to share their tales of woe:

Everyone knows that Rust is the language of the gods. Hereā€™s how we still managed to shoot ourselves in the foot. We were gearing up for a release and had just deployed to our internal test environment. We were not particularly seeking any adventure that evening but our application promptly crashed. We checked the logs to quickly find out that we had reached the thread stack limitā€¦

A good story with a potentially unintended consequence in its conclusion: is Rustā€™s compiler so good that devs trust it with too much?

Debating whether or not to make PostgreSQL multi-threaded

The pgsql-hackers mailing list lit up this month when Heikki Linnakangas from Neon started a conversation about if and how they can move the venerable database from its current multi-process architecture to a single-process, multi-threaded architecture:

I feel that there is now pretty strong consensus that it would be a good thing, more so than before. Lots of work to get there, and lots of details to be hashed out, but no objections to the idea at a high level. The purpose of this email is to make that silent consensus explicit.

Responses vary from ā€œthis will be a disasterā€ to ā€œare there other areas we should focus effortsā€ to ā€œletā€™s do thisā€ and the technical discussion is both interesting and inspiring.


āš”ļø Lightning round!


Thatā€™s the news for now!

Wednesdayā€™s interview is with frequent guest Adam Jacob whoā€™s been toiling in stealth mode on what he calls the 2nd wave of DevOps for years and heā€™s finally ready to talk about it.

On Fridayā€™s talk show weā€™re joined once again by our old friend Brett Cannon from the Python Steering Council who would really like to help me with my pip install anxiety.

Have a great week, forward (or copy/paste) this to your friends who might dig it, and Iā€™ll talk to you again real soon.

ā€“Jerod