modal-soul

I like this article a lot more than the previous one; not because of length.

In the previous article, I was annoyed a bit by some of the fluffiness and redefinition of concepts that I was already familiar with. This one, however, felt much more concrete, and grounded in the history of the space, showing the tradeoffs and improvements in certain areas between them.

The section that amounted to "I'm doing all of this other stuff just to turn it into HTML. With nice, functional, reusable JSX components, but still." really hit close to how I've felt.

My question is: When did you first realize the usefulness of something like RSC? If React had cooked a little longer before gaining traction as the client-side thing, would it have been for "two computers"?

I'm imagining a past where there was some "fuller stack" version that came out first, then there would've been something that could've been run on its own. "Here's our page-stitcher made to run client-side-only".

In order to get value out of Tailwind, you need to be using a templating language that lets you create reusable components. So in this way, you are not repeating the 7 classes each time you need a card, but just using the component.

This is also makes "zombie CSS" a thing of the past, since the resultant CSS file that tailwind generates is based solely on what is in use.

This is not true. If your sync function loops until the value is set, then the Promise will never resolve, since it never yields to the event loop.

I made friends with someone else who kept circling around. The look of it reminds me of Boku no Natsuyasumi.

The only things that have significantly bugged me are the lack of a background app area by default and how they hide path editing in the file browser behind Ctrl + L.

My teacher used the following short story:

The negative boy couldn't decide if he wanted to go to the radical party. So he decided to be square, missing out on 4 awesome chicks. It was all over by 2 AM.

If LiveView is backed by PubSub, then I think you can offload persistence to Redis.

Ruby's refinements sound somewhat similar; they let you scope your monkey-patches.

Gell-Mann amnesia effect: https://en.wikipedia.org/wiki/Michael_Crichton#GellMannAmnes...

> In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know.

It was not included in this announcement, but Shippable (purchased by JFrog in Feb. 2019) is being shut down as well.

Just because a function is pure doesn't mean there is zero-risk in exposing it publicly. You're conflating complexity in managing state with complexity in managing domain boundaries.

A tangled web of function calls can be very confusing to work with, regardless of purity.

Emacs and some Vi-likes. Some people are very attached to their editors and their configs.

I've been using something like this for exponential backoffs, but I think it'd work for this case as well.

Let's say you've got one exchange and one main queue for processing: jobs.exchange and jobs.queue respectively.

If you need to schedule something for later, you'd assert a new queue with a TTL for the target amount of time (scheduled-jobs-<time>.queue). Also set an expiry of some amount of time, so it'd get cleaned up if nothing had been scheduled for that particular time in a while. Finally, have its dead-letter-exchange set to jobs.exchange.

This could lead to a bunch of temporary queues, but the expiration should clean them up when they haven't been used for a bit.

Is there a name for the aesthetic of the equipment being modeled here?

Saw an interesting talk just about this topic [1]

The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong.

Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applications, anyways).

As such, (this definition would be another sticking point) these less rigid methods should still be considered engineering, with engineering being a balancing of resources with outcomes, not fixation on mathematical models.

[1]: https://www.youtube.com/watch?v=RhdlBHHimeM

In this case, the incidental heterochromia actually makes it feel even more authentic.

Even more natural if you write Ruby, which uses an identical syntax.