ghusbands

Debouncing doesn't need to delay a touchstart event, in general, so latency shouldn't really increase in a carefully designed system, especially if you can be animating in advance of the touchend event.

This is an interesting take on debouncing, but I found the choice of TV remotes as an example a bit confusing. From my understanding, the issues with remote controls aren’t typically caused by bouncing in the mechanical sense but rather by the design of the IR communication. Most remotes transmit commands multiple times per second (e.g., 9–30 times) intentionally, and the receiver handles these signals based on timing choices.

If there are problems like double channel jumps or missed commands, it’s more about how the receiver interprets the repeated signals rather than a classic switch debounce issue. There’s definitely a similarity in handling timing and filtering inputs, but it seems like the core issue with remotes is different, as they must already handle repeated commands by design.

That (to quote you) means you have to keep them in the queue until the next time the client connects, which could be a very long time.

To be clear, there's no real difference - in both cases you have to keep messages in some queue and potentially resend them until they've been acknowledged.

That's not the same trick, though it has similarities.

That's simply self-contradictory, as written. You say that it has (opt-in) types, then say that it doesn't have types. You could say "I hate that it doesn't have types by default", but it would be even more accurate to say "I hate that it doesn't enforce types by default", since it does have types, both strict and not.

Being able to open decades-old repos is very much the norm for widely-used version control systems.

What jjav is referring to is "at will" employment - in almost all US states, employees can be fired for almost any reason, with no recourse. So the fact you're saying that firing people is expensive and time-consuming in the US flies in the face of the actual legal environment there compared with most other relevant countries.

Maybe you could do some research, since you're introducing a technology that could easily make accessibility worse or impossible.

However, from what I can see, it probably is accessible, as it is still usable without a mouse, which is an easy first test.

(Though, in Safari, neither slider test has any kind of slider, so there are other big problems.)

Browser-based screen sharing is the subject. Is it normal to advertise unrelated projects in HN comments?

Please consider changing the name - it's already hard to find the pages out there talking about how to fix technical issues or use the javascript developer console or such as a jaws user, and your project will end up hiding some of those or at least causing confusion. How about JAWSM (pronounced like awesome), like benmccann suggests?

When you're down to 90% of them only providing location (unless you stop caring about topology), it's no longer as clear-cut. I was only really arguing against the implication that it's "funny" to use nodes; the topological connections and normalisation/deduplication do have advantages and it looks like a reasonable technical decision to have made.

I also imagine that creating new topological connections may become trickier when most locations are 'hidden' in ways.

However, I do hope you find a common way forward that reduces the apparent redundancy and excess processing/storage requirements.

Your wiki link states that multiple nodes can share the same latitude and longitude (different heights/layers), so the ID could not be subsumed. (Unless you were trying to imply something else?)

> This (index ordering resulting in useless indices) is not true, at least not in newer versions of Postgres (I just tried with 15).

> While the query will take much longer (for me, it was about 47 msec vs 0.6 msec for 2,000,000 rows), it still uses the index.

I'd argue that something being 78x slower can make it pretty useless, but it is indeed at least used, in some cases.

Bookmarks become outdated or the pages may be updated to no longer have the text you are interested in. If you're bookmarking a page that's fairly static, you're probably more interested in the content than the URL.

Most programming languages have easy and well-known string concatenation and the simplest querying function typically takes just a string - it's easy to see why people naturally reach for string concatenation.

Trampolines can help with that.

That was fairly standard startup behaviour across all makers. The comment you're replying to talks about the heatsink suddenly falling off - a very specific testcase seemingly chosen to make a company look bad.

Just don't extract archives into a non-empty folder. That will always be dangerous/insecure.

A factor of six is a very long way off, pretty much universally.

I assure you that people made the same mistake plenty in the old days, too. Most programmers who come across an array of values assume they know what the values mean, and that stands true across time. Many paint packages and other programs still get many transforms/effects wrong due to it, and in fact some people seem to prefer some effects when not linearized.

> There's another one which hits every 2 minutes without fail [...] it's the one feed user-agent I've had to block outright. It doesn't stop requesting things [...] Clearly, I need to use a bigger hammer.

I'd be tempted to go the opposite direction and give it articles that seem new, every time, called "Your feed reader is very broken and you should use a different one".

That was such a common technique that it's odd to talk about just one game in particular doing it.

This comment is just a copy/paste of a quarter of the article.

The article says "C64 games did a lot of work to stay single-load since the C64 drive is so slow" - what are you surprised by, since you seem to be in agreement?

If you play it, though, expect something that's not a challenge but more just an interesting presentation of some ideas.

I've read them and somewhat disagree. The protaganist(s) in the book almost never choose a sensible course of action for their goals, even given elapsed decades in which to make them. If I can come up with much better plans on the fly while reading, the main character surely could in decades.

If the two parties are equal, sure. If it's a person vs a corporation of significant size, then no, it's not safe to assume that people have free choice. That's also ignoring motivations apart from business ones, like them actually wanting to be at the leading edge of AI research or wanting to work with particular other individuals.

It's a common mistake on here to assume that for every decision there are equally good other options. Also, the fact that they feel the need to enforce silence so strongly implies at least a little that they have something to hide.

The direct link is https://shakti.com/document/sql.d

Many ORMs have similar features - jOOQ is not unique in this. The article is talking about an addition to SQL syntax, not a DSL embedded in another language.

> All in all, I would not call this a simplification.

It is a simplification, as it gives you less that you need to understand and decode. Working with a query with ten to twenty joins and join conditions, you have to juggle a lot of intermixed concerns and you probably have to read a lot of query text and table/column definitions. And you have to look back and forth to know which tables are pulled in for checks and which for data. For example, this with just four tables:

  SELECT alpha.*, epsilon.zoo FROM beta INNER JOIN alpha ON beta.id=alpha.foo LEFT JOIN epsilon ON alpha.boing=epsilon.id INNER JOIN gamma ON gamma.id = beta.bar WHERE gamma.baz='bar'

Requires you to understand more about everything and spreads things out more than this equivalent:

  SELECT *, boing.zoo FROM alpha WHERE foo.bar.baz='qux'

(This is based on a real query I was given to work with.)