nicopappl

Diaspora is a book for Math PhDs, involving a lot of physics and math theories. Accelerando is a book that anyone can read. Involving hyperintelligent cats and sentient shrimps (actual shrimps, not aliens).

I would recommend it not just for the philosophical aspect (it has a very interesting way of placating transhumanism) but also for the entertainment aspect (aforementioned shrimps, did I mention the Iranian space program?)

Stross is a very approachable author, Accelerando is not his most accessible book, but if you can go through half of Diaspora, you can easily go through the entirety of Accelerando.

Yoo, congratulations to the author for going from this blog post dated to October 2023 to shipping an actual rust crate (bevy_light_2d)!

I suspect the author might be reading this post back and cringe a bit. That last code listing with handle_session_completed triggers my inner clippy. Why clone session.customer_id to then pass it as a reference? Why are those CheckoutSession fields Options?

The other advice I would give is to identify what the author calls "Service" as what is called "view type" or "newtypes" in rust. A newtype wraps another type, to give it a different set of methods. For example, a counter could wrap an i32 and only allow incrementing and reading the value. Or put together a set of references to fields/slices of a struct.

It can be useful, but the way it's used by the author here is not very rusty, and the final suggestion of using a function is a descent alternative. Although I think defining handle_session_completed as a method on CheckoutSession or UserRepo might be better.

Wow, this is exactly how I felt with regard to my first job as well. This old codebase no one wants to touch but works somehow. The quite nice later-on additions. Even the "build a pipe-separated string using reflection and a 150 classes hierarchy" rings something.

The old codebase was an hairy ball of scala using a very outdated version of a (now) infamous actor framework. Before they figured out that untyped messages kinda left out one of the major selling point of Scala.

The code was readable, but the authors had this strange idea that every little piece of logic should be part of its own "Actor". An actor is pretty much equivalent to a class, and each one of them had their own little file. With this many classes, with very specialized purposes, you ended up with 90 character identifier names.

To understand what would be a single function in a normal code base, you would have to dive through half a dozen files through several repositories to piece together the logic. Generally, at the end, you find that most of the code is about passing around a value, and there is this one file where there is actual logic applied to the value.

It wasn't that awful. The thing was that it was impossible to change anything: no documentation, no test, no bug tracking, not even any PR process, laconic commit messages, no Wiki pages. And the actor framework made it very difficult to add tests. But later developers did manage it pretty well, they drew fences around the old services, with an HTTP API to communicate with it. And all later additions were part of different services that were very cleanly and consistently designed.

Tooling

When your text editor is not enough for a task, and it hopefully is extensible, consider writing little plugins to reduce repetitive tasks.

Here is an example. I was working with a legacy code base using an infamous Scala actor framework. Basically, all function calls were replaced by message passing. All messages were sent as 'Any' objects, then downcast to the expected type, so an IDE wasn't of much use. I wrote a little bash script to populate a jump buffer in vim with the result of a grep, and suddenly, I had jump functionality! Originally, I had to jump to type definition, hope that the associated "received message" type was in the same file, then look for downcasting into that received type. I don't remember precisely the details, but what I do remember is that the little script helped go from a few seconds to just pressing two keys to navigate the code. It's especially useful for legacy code, where the main activity associated with it is reading and understanding.

Our capacity to focus as humans is limited in time and energy. Writing tools to do in half a second what otherwise would take a few seconds can help, not only to make you faster (for that, refer to xkcd 1205) but also to effectively increase your capacity to focus.

Though being able to develop your own tooling is less important today. Languages and frameworks nowadays prioritize tooling as an important feature. And I'm grateful for that, programming used to be much more annoying.

To go in your direction, a few countries in South American did ban advertising for junk food. In addition to education in schools, it dramatically helped reduce overweight-related sickness.

The kagi universal summarizer has been pretty descent on my end. But I've only lightly tested it on two pages.