bastih

But that will make links unstable - or OP needs to to turn ambiguous links into some dispatching view.

Color me a bad reader: what does this mean? The abstract pretty much leaves me in the abstract.

What about plantuml - covers a fair bit of ground!

I have a lot of praise for using Memray as part of working out some memory kinks in a codebase I’m working on. It allowed me to quickly iterate on some hunches and then enshrine the resulting memory savings in tests via pytest-memray.

Other spreadsheets solve this by updating references if you need to add more columns and rows (or at least they try). Is the additional complexity of the infinite grid something that customers actually need?

To combat this scenario, we only had build servers populate the cache. Clients were readonly to the cache, so they would benefit from anything that build servers had already built, which covered 95%+ of what clients usually had to rebuild.

Also release builds were excluded from caching, to prevent any form of poisoning there.

Gotta be one hell of a makefile.

Took me 5 mins to figure out what "Geometry Dash levels" are. Should probably link to the game and show an example screenshot in the README?

My room was next to said bathroom with rather thin walls, so I always appreciated the sound at least be a bit played down by the music.

Another side effect was that you always knew when the bathroom was in use (aside from someone forgetting to turn the light off, which you now had radio playing to remind you off).

My parents just had the radio hooked up to the same circuit that was driving the bathroom lights. You enter the room, turn on the lights and there was instant audio. Makes sense to put this into a product.

Good post to plug the documentary "Tim's Vermeer" ( https://www.imdb.com/title/tt3089388/), which is a joy to watch as they try to reverse-engineer the particular style Vermeer painted in.

my bad: meant multiline lambdas.

Both standard library and other libs make use of them, so you often can't just ignore exceptions.

Also agree on your point - I'm not saying I like exceptions, I like explicitly passing type-encapsulated results/errors more for clarity. Exceptions happen in a "second invisible lane" right next to the code you are writing, and for example aren't immediately visible when reviewing code.

1. no 2. no, not really - however there may be libraries that python has that ruby doesn't have

Side note: Ruby has more syntax to grok, which makes it harder to read (for me). On the other hand Python does have its own idiosyncrasies and subtle behaviors. However, Ruby also has some features (like multiline inline functions) that one may easily miss in Python, but they haven't been worth switching over for me.

> The noexcept specifier protects C++ program from memory leaks and potentially other undesired behaviors brought by throwing exceptions.

While I agree with the presented observation, just letting the exception bubble up to the top would have done the same thing. The memory leak presented here is just the result of not using RAII to clean up the resource.

Throwing an exception through a `noexcept` function terminates (or rather calls std::terminate) because you are doing something you explicitly said you wouldn't do, pass an exception through this function.

> For key functions we hardly know how to handle its exceptions, it might be a good idea to add the noexcept specifier.

On the contrary, `noexcept`s usecase is in places where we want to be sure a function doesn't just throw an exception, as this may thwart some guarantees we want to make to the caller. Sprinkling your functions with `noexcept` just to abort (which is already happening if the exception is unhandled) is bad code. Plus "we hardly know how to handle its exceptions" is the worst cop-out I've heard for dealing with exceptions - C++ exceptions are an essential part of the language and many libraries, so dealing with them should be a prime concern of the programmer.

Having gone through writing a couple of iterations of these, I went back to settling on `PATH="./scripts/:$PATH"`, which in my project root dirs (where I spend 99% of my time anyway on the shell) just works.

Sure, this could be augmented with per-folder environments, fancy runner syntax, but less is more for me in this regard.

Ninja update: Anyway, I like what OP is doing here, seems like a lot of things are done right in this. :)

They also have a presence on Spotify, great for offline listening.

I love when reality pokes holes into clean code and perfectly reasonable assumptions made.

There is a good amount of research on software engineering, I love love love "Making Software: What Really Works, and Why We Believe It" by Andy Oram, as it demonstrates the non-opinion-based way of thinking about software engineering. And has some really interesting insights to boot.

That is great. Love how smooth it looks.

I'd be in the same camp. LEGO scales nicely with age, it doesn't suddenly become boring.

One guess would be that people have become afraid to step in.

Container tabs have made my life much easier, as I'm managing a number of Amazon accounts, and being able to do that side-by-side is a life-saver.

This may just be me, but when I was in charge of hiring a team, I ended up passing on sleep-foregoing candidates (often that wasn't the only thing, but it was a big factor for me).

To this day, candidates that don't take care of getting enough sleep just to get things done, raise a red flag for me.

I've become quite fond of Amethyst (https://github.com/ianyh/Amethyst). Especially it's 3Column Middle Wide layout in combination with swapping windows using the mouse and mouse pointer being placed in the middle of a switched-to window have been godsents for my daily workflows.

Out of curiosity, which topics would you have liked to be taught in a more structured way?