rivo

This is also my experience. I'm not a DJ but I perform live electronic music using various MIDI controllers. If I quickly want to add or remove a sound, like a kick drum, to/from the mix, a slider is best. If I need fine control over a parameter, like a low-pass filter frequency, a rotary controller is usually better for the reasons you mentioned.

As alluded to in the article, rotary vs. linear seems to be a proxy for the circuit which actually influences the sound. I would think that anyone claiming "mixers with rotaries always sound better" does not fully understand how they work. There's a lot of those kind of claims in the music scene.

Some larger retail stores in Germany ask you for your postcode during checkout, presumably to learn a bit about their customer base. I don't mind telling them mine, there are about 16K people with the same postcode. But I'm pretty sure I would not tell them if I was one of the two forest rangers in Reinhardswald. (And yes, I do pay cash whenever I can.)

It's funny how every TUI developer eventually stumbles over Unicode and then handling international characters and emojis correctly turns into its own project close to the same scope of (or even bigger than) the original TUI project. It happened to me on rivo/tview and through the resulting rivo/uniseg package, I learned that all other TUI library maintainers deal with the same issues. Finally, everyone invents their own unique solutions to the problem because character width is not standardized and terminals are messy, as noted in the article. OP simply supports Unicode 9 only (Unicode is at version 15.1 at the moment). Sooner or later, users will complain, however, that certain emojis or international characters are not rendered correctly. So I'm not sure that this is a great solution.

I tried the model the article links to and it was so refreshing not being denied answers to my questions. It even asked me at the end "Is this a thought experiment?", I replied with "yes", and it said "It's fun to think about these things, isn't it?"

It felt very much like hanging out with your friends, having a few drinks, and pondering big, crazy, or weird scenarios. Imagine your friend saying, "As your friend, I cannot provide you with this information." and completely ruining the night. That's not going to happen. Even my kids would ask me questions when they were younger: "Dad, how would you destroy earth?" It would be of no use to anybody to deny answering that question. And answering them does not mean they will ever attempt anything like that. There's a reason Randall Munroe's "What If?" blog became so popular.

Sure, there are dangers, as others are pointing out in this thread. But I'd rather see disclaimers ("this may be wrong information" or "do not attempt") than my own computer (or the services I pay for) straight out refusing my request.

Completely agree on not setting a deadline, it will likely lead to disappointment as we tend to set unrealistic deadlines anyway, even more so for personal projects which rely on having time off of work and other responsibilities. I would even skip the "define a goal and a scope" part. Just go for it and see where it will take you, it might go into a totally different direction, which is fine.

I started recording songs for a Christmas album in 2007 and just published them this month. I thought I would never release them. And every time Christmas was over, I didn't feel like working on them anymore. So I only had about a month per year to occasionally work on them. There were years when I didn't touch them.

So after 16 years, I could see the home stretch and I decided to make it to the finish line. (I recorded the final music video today, actually.) If you had pushed me to name a deadline back in 2007, I would've said 2008.

I have a whole bunch of "projects" lying around, some of them are just ideas at this point. They will get finished eventually. Or not. No pressure.

When I see these kind of readability-decreasing optimizations in code reviews, I always push back. Almost always, that same Go code queries some other service over the network or loads data from the database, or similar, and nobody will ever notice the speed improvement of IndexOf over Split at the bottom line. But everyone working with that code at a later time will spend extra time (sometimes hours) just trying to understand what's going on. That's much more expensive than a few extra CPU cycles here and there.

Sure, if you're writing an inner loop for some heavy workload, e.g. in graphics or maybe parsing terabytes of JSON, it makes sense. But outside of these rarely occurring situations, you should always prefer readability over low-level optimizations.

Chrome Developer Tools allows this. There's a button in the Source tab to deactivate breakpoints from debug statements. The button looks like an arrow cut in half.

To my knowledge, there is no specification for monospace width. Applying the East Asian Width attribute as a proxy does not work reliably. So in my opinion, it is all a matter of agreeing on what's reasonable while keeping it simple. I.e. if allocating text-presentation Pictographics to a width of 1 is reasonable, that's what renderers should do. It's what users would expect.

The library I posted uses colour information. It won't map to greyscale first.