Haven’t checked out the article, I’m sure its great. But another reco is boot.dev’s git course taught by Primeagen. It’s interactive and He goes real deep down to manipulating files in the .git directory. Came out of that course with a whole new mental model of how git works.

All this negative feedback had me second-guessing as well. But I took the plunge this month and I’ve been very happy tbh. Setup was flawless and I haven’t run into any issues since purchase.

But my setup is just Beam + Ikea Symfonisk for surrounds. Planning to add the sub mini later on.

My guess is the issues start to occur the bigger your setup and if you heavily use the app? I havent touched the app since setting it up.

I don't know if it's related to the size of the setup, but (quick calculation...) I have 8 zones, seven with individual speakers and one of them is a Beam+Symfonisk Frame+sub surround thing.

We're on starlink, which is great but adds some latency to some stuff, and the new app has been terrible - barely loads, claims to start playing but nothing happens, volume adjustments take random amounts of time or may be ignore, all sorts.

But also when not using the app (just watching tv) the surround system is still pretty perfect.

Muse. I love how I can write something on my iPad with the pencil and see the strokes real time on the mac app.

I then switch to my mac to drag images and screenshots and see it synced to the ipad in real time. Then i annotate w the apple pencil.

One of the best “whiteboarding” tools I’ve used.

Have you taken a look at swimm.io? Been curious about it for a while now but not a fan of the friction to demo it.

Yea agree. I feel one of the best books ive read that makes this concrete is Grokking Simplicity by Eric Normand. It’s less about functional programming and more about functional thinking. Lots of concrete great advice in that book.

Not exactly a notebook but Quokka gives you that REPL playground experience.

IIRC it has something to do with full screen apps/use of spaces. Just don’t use either and the bug shouldn’t occur. Annoying but I love the app too much that it was worth giving those up.

If it annoys you enough see if rcmd works for you. It’s the next best alternative Ive found so far. The Dev is great too I use a bunch of his other apps (Lunar and Clop).

As a fresh dev, I’d like to know the answer to this as well. Abstract to function w multiple params, abstract to multiple functions, no abstraction and keep as switch statement.

`print_table() + print_table_without_emoji()`

vs

`print_table(remove_emoji= False)`

vs

`switch table_name: case emoji: print(table) case no_emoji: print(table no emoji)`

If callers typically know statically whether they want emoji or not (in other words, if the parameter would typically be a literal true or false at the call site), then the parameterless version is better. (Note that you can still factor out common code from the two functions into a separate private function if you like. So the parameterless version doesn’t necessarily imply code duplication.) If, on the other hand, callers tend to be parameterized themselves on whether to use emojis or not, then the parameterized version is better, because it avoids having to make a case distinction at the call site.

It depends on the implementation, but in general you prefer the parameterless version because in theory a bug that shows up in print_table has less code it could be in (less surface area to debug).

Without understanding the implementation no one can truly say which is the better approach, but this idea of "surface area for bugs" is something that should be considered when approaching these types of decisions.