Simple Remix of Clubhouse

Two weeks ago I'd shared a story about GTA Online loading times, this week brought a resolution! In an update, t0st informed that Rockstar reached to them and granted them with their $10k in-game bounty. Seems like time well spent on investigation!

Day after bug fix got released, and loading times went down to only 2 mins.

What started as a joke became a self burn. But the interesting outcome of it is that I've found that maybe Remix will join Vite in using esbuild.

Following the thread, I've learned that Parcel file search has been lately rewritten in Rust. It seems that in the future Parcel may be using SWC

Maybe in the future, all our tooling will be written in compiled languages providing native-like speed. This begs a question: is it still worthwhile to write tools in JS?

Well, probably not 😅

But as Rome author suggest we may be good with TS 😉

Dan North wrote why he doesn't like SOLID principles - CUPID - the back story. As he explains this is based on a short talk he once gave. Based only on the slides from this talk original author of SOLID Principles - Robert Martin wrote his response. It looks to me that there is some misunderstanding happening and that both of them expect the same properties from simple/clean code. As usual, the devil is in the details.

That's not the first time I see SOLID principles being critiqued. Years before Kevlin Henney gave similar arguments against them in his talk The SOLID Design Principles Deconstructed.

It's impossible to not mention phenomenal talk by Rich Hickey Simple made easy, where he digs into the meaning of the word simple. He identifies that one of the characteristics of simple code is that it's simple to change. Dan Abramov also wrote about this in, a rather short take on optimizing for change.

Also, Fred George talks about simple code in the talk The Secret Assumption of Agile. This presentation, although not showing any code, was very inspirational for me. For quite some time I had the feeling that I've stopped progressing my skills. I knew that I had a lot to learn but no clue where to go. Fred showed me the way.

He gave a few simple sounding bits of advice:

• use tiny little classes, functional classes
• don't use getters and setters
• kill -ors and -ers in your code
• write code that's easy to change

Fred says that he spent years learning how to write simple code. He also pointed to a few resources from where we can learn this style of writing programs. One of them is Refactoring by Martin Fowler, the second would be Smalltalk Best Practice Patterns by Kent Beck.

I didn't read Kent's book but I did the second-best thing and watched Sandi Metz talks on YouTube
a few of them. All of them are in Ruby, and as simple as Ruby is, not all its idioms translate well to other languages. I also saw this critique of OO code.

This is a huge topic, and I have neither time nor willpower to give it true justice. So let us wait for what Dan will show us in a follow-up story.

Maybe while waiting let's consider one more thing. At the 2019 React Conf Jenn Creighton give a talk titled React is Fiction. In it, she draws comparisons between writing fiction and writing React components. Starting from classical "Show, don't tell", going through character (component) motivations, and writing what you know, to rewriting. I really like how almost all quotes she presented can apply directly to the craft of writing programs.

Lately, Paul Graham wrote an essay on writing simply. He clearly talks about writing essays, but it's not a long stretch to view it by a prism of writing programs.

One of the very first things I've learned in my first job was that I don't need to use every esoteric feature of a language to make the code fit into the least amount of lines. That it's easier for others (and my future self) when I use ordinary constructs and well-known patterns.

Reducing jargon is also one of the core technical philosophies of Rome.

An emerging social platform somehow found in the center of my interest this week. This is quite strange as I don't own iPhone so I cannot join.

But first I've run into a DogeLog. It wasn't the first time I've heard about the project, I saw the introduction video where it still was ea VS Code extension. As I'm more of a visual person, and I get lost fast with audio-only media, I ignored DogeHouse at first, thinking it's a joke. Still, I don't think I'll join but it was really nice to learn about its architecture.

Then I've run into this thread

It's long so if you prefer here's a blog version of it. The gist is that Clubhouse's focus on real-time audio-only may be really hard to scale to a bigger audience, and in time people will get bored with it.

I also got reminded that Kent C Dodds build a similar feature into his Discord Community, called Meetup. This sounds like Kent, going a step further of being kind and inclusive to his community.

Also, it looks like Telegram joined the game with the release of Voice chats 2.0.

Recently cURL celebrated its 23rd birthdays. This was an occasion for a reflective post. It's a story of how a side project until tool becomes a hobby and then a men life work. The story of cURL is a story about building over time, slow and steady growth, and persistence. Build upon UNIX philosophy the tool found its place as a backbone of modern-day internet powering cars, games, TVs, and whatnot. The most mind-blowing thing is how it grew over all those years. From merely 2,200 to an outstanding 172,000 today!

I've run into this short (8m 5s) video on looping in Python. Coming from JS where loop times are quite equivalent I was surprised to learn that there is a difference between using while and for loop in it. The straightforward explanation made it obvious why though. In the end, I was quite blown away 🤯.