HN user

rivo

854 karma

www.rentafounder.com

Posts9
Comments98
View on HN

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.

I programmed something like that back in 1999:

https://kuederle.com/university/fur/improvedtext.jpg

Each hair consisted of four segments. All segments were sorted, then drawn back to front. Each segment was drawn as an anti-aliased line (no hardware support for this back then, so I had to invent my own line renderer). So a hair could not be thicker than one pixel but that's a reasonable assumption at a certain distance. This made it reasonably fast given the hardware at the time.

I've been wanting to reimplement this using modern shaders, to see how fast it would be these days, but haven't gotten around to it yet.

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.

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.

I spent quite a bit of time coming up with an algorithm that gives me the correct width for any Unicode character, including emojis [1]. The reality is much more complicated than what wcwidth does and using the East Asian Width attribute will give wrong results, as outlined in the article.

Unfortunately, since a lot of terminals simply use wcwidth, you often have to use that same flawed algorithm in your application to make it work in those terminals.

[1] https://pkg.go.dev/github.com/rivo/uniseg#hdr-Monospace_Widt...

I was in Madagascar in 2019 and while some people have top notch fiber connectivity at home, most people only have Facebook. It's free on mobile phones while any other internet traffic costs money which most people can't afford. And I doubt that the idea of net neutrality is on anybody's mind.

Whenever I asked someone to google something, watch a YouTube video, or simply go to a website, I got nothing but bewildered looks — as if I just talked gibberish. Even Instagram was completely irrelevant. But if something was on Facebook, everybody knew about it or how to find it. All of most people's online life happens exclusively on Facebook.

Does this count as "using the internet"?

These stories always bring back that anxiety I got as a teenager when I read Kafka's "The Trial". You're guilty and being punished but we won't tell you why, what you did, and there's no way to appeal. Back then, I found comfort in the thought that this kind of thing wouldn't happen in the modern Western world. Boy was I wrong.

You're definitely right in that children are very different from another. In my experience, however, fear almost always comes from a previous bad experience or it transfers from other people. I've done the "first time at the hairdresser" with both of my children and they still love going there, ten years later. Back then, we took our time looking at all the tools and watching other people's hair being cut. With the permission of the hairdresser, I let them play a bit with the revolving chair. No talk about how it might hurt or anything.

In the story above, the only explanation I can think of is that the boy already had a previous bad experience with a hairdresser. (Didn't look like it but I can't be sure.) Even then, I'm not sure this was the best way to handle it.

I don't quite remember where I heard this and whether or not it was a joke, but a skydiving instructor told this story where his students were supposed to land on a plain empty field. But there was one tree somewhere on this field. And whenever he cautioned his students not to land on that tree, invariably, at least one student would manage to land exactly on it. When he didn't mention it, it wouldn't happen.

With children, I find it's almost always a better strategy to focus on the positive sides of an experience. Of course, it's more difficult when they're already afraid of something (maybe through their friends, a previous experience, or the parents themselves). But there are lots of blank slates and it's one of the great parts of being a parent to let them write something positive on it instead of tainting it with fear.

I recently witnessed a boy's first time at the hairdresser while waiting for my turn. Both his parents came with him. Long before they were called to the chair, his parents already discussed how they were going to handle this situation. (The boy likely didn't understand the details but could feel that something was up.)

When it was his turn, they immediately started telling him not to be afraid and that it wasn't going to hurt. He sat on his dad's lap, his dad holding him tight, while his mom desperately tried to deflect his attention by waving a teddy bear in front of him and non-stop talking to him. Predictably, the boy was completely terrified and cried the whole time. I'm sure it will be a long time before he can get a haircut without being scared.

It was such a missed opportunity because there are indeed so many interesting things going on at the hairdresser. I've seen other children almost fall asleep on the chair because it was all so relaxing to them. It's too bad they chose to focus on all the scary parts of the experience.

Note that WKRL and DIDRL (two new European directives) will be in effect in Germany starting Jan 1, 2022. They include a consumer's right to updates that allow the device to keep working (including security updates).

But they don't specify an actual period for updates (this will have to be decided by the courts). And, what I find worse, they force the seller to provide the update, not the manufacturer. If the seller is not able to do that (which will be the case most of the time), they can be relieved of their duty.

We're only halfway there.

A few highlights from a conversation with a friend who works for Zeiss and regularly deals with ASML (take this with a grain of salt, I may have misunderstood some of it and he also may not be an expert in all of these areas):

- The lenses (actually mirrors for EUV) only demagnify by a factor of 4. So your wafer template is already extremely small and costs millions to produce.

- 13.5nm is pretty much the smallest wavelength you can reasonably handle. If you want to go smaller, you have to build a particle accelerator. (He heard that from a colleague, wasn't sure how much of that was actually true.)

- The prices in this Twitter thread are pretty spot on. The EU wants to invest into chip making to become more independent in this area. But the sums they're talking about wouldn't even pay for one such machine. Politicians don't seem to be aware of the dimensions we're talking about here.

- Also in the thread, ASML has a monopoly on this tech. Others have not invested into EUV and by now, it's pretty much impossible for anybody to catch up.

- Everyone's hiring like crazy atm. He started home office during Covid and now Zeiss says he can't even go back to the office because they don't have enough office space anymore. He doesn't mind. Everyone's distributed all over the place anyway so whether he does conference calls at the office or at home makes no difference.

- He said they're not very affected by the chip shortage.

I've worked with D3 for many years. It's great for small, quick visualizations. But I've more than once reached its limits. For one, anything more complex (e.g. custom axis labels that don't overlap) requires you to roll your own implementation, making D3 not much more of a tool than, say, jQuery. Also, because it's SVG/DOM based, if you have a lot of data, it gets slow quickly. Nonetheless, for anything quick but (at least slightly) out of the ordinary, I'd pick D3 any time.

For a visualization project, I needed to be able to automatically generate a visually pleasing colour palette. Customers would provide one or more base colours (e.g. based on their corporate design rules) and the generated palette should then complement those base colours. So it didn't help to manually pick those colours in advance because they may not play well with the base colours.

If you find yourself in a similar situation, I wrote a blog post on how such a palette can be calculated:

https://rentafounder.com/generating-colour-palettes-for-char...

The algorithm basically picks colours one by one, each being the most distant colour to all previous colours within the same saturation plane, all in CIE94 space.

It ended up working quite well.

Maybe I'm assuming too much but it wouldn't occur to me to let tx.Commit() depend on the outcome of another connection (here: db.Query()). Either use tx.Query() (which I guess is partly what you're advocating) or put db.Query() in a different goroutine and let tx.Commit() proceed.

It is quite similar to other Go concepts. For example, you don't want to have circular dependencies between channels. The difference is that such a thing would fail very quickly whereas dependent DB connections would only fail after the connections are exhausted.

Trying to figure out how much it would cost the customer to develop the same functionality is probably the best strategy (and suggested by most posters in this thread).

I would add that the customer may not come up with a detailed estimate/calculation so it's more a question of how expensive they perceive their development costs to be. (If their developer casually says, "I can do this in two days", that's bad even if it's wrong.)

One probably has to factor in the (possible) inefficiency of the customer, i.e. inexperienced devs and the usual overhead of working at a large company.

At first, I thought that by cutting the costs in half, you would end up with a fairly low price. But giving them the option to receive the source code at double the price is a nice touch, especially since you say most of your customers want that anyway.

There was a HN post three years ago on how to declare someone as dead [0]. Granted, this was not the decision of a machine but like in OP's story, it's a one-way road with no way to "undo" or at least "sudo kill -9" the process, which makes it a very unpleasant experience.

I can't count the number of times I've hit "undo" on Gmail. Just because I hit "send" doesn't mean I won't have second thoughts. And in this case, it appears to have been the absence of an action which triggered the whole process, making it even more likely that a wrong decision will be made at some point.

[0] https://news.ycombinator.com/item?id=10063659

The quote at the end is meant as a joke but it's interesting how often this is true. A lot of magic tricks rely on being prepared for different outcomes, while often trying for the least likely one first. This unlikely outcome happens surprisingly often and therefore makes the effect even more unbelievably amazing.

I had a friend think of a playing card and any number (1-52). She picked the 6 of spades and the number 15 which is exactly the position where the card was located. It was only the third time I had done this trick with anybody.

Obviously, card and number picking is not uniformly random, especially when you influence their choice (e.g. "pick a large number"). But the odds of someone guessing the exact combination should still be extremely low.

A lot of what you see from David Blaine on TV is exactly this. He always has a backup plan but more often than not he doesn't need it.

Let's say this is a modal dialog which is supposed to appear in the center of the screen, fixed (but the size is unknown and may scale with its contents). With any of the existing solutions, the HTML code for the dialog will always be <div><div>...</div></div>, i.e. unnecessary DIVs due to the limitations of CSS. Since it is supposed to float on top of everything else, it does not matter what its container is. May as well be the <body> tag but applying flexbox to that tag is likely not an option.