karanlyons
Generally speaking leaking that two plaintexts are the same is better than leaking two plaintexts XORed together. If you’re in a use case where that’s liable to happen (i.e., you don’t rekey “frequently”) I’d happily take the former leaked bit over the latter leaked messages.
There are also a handful of existing constructions you can just take off the shelf rather than rolling your own thing and getting it wrong.
This is different to the widening of value types within objects, which is a tradeoff made towards unsoundness with the belief that it would otherwise make interoperability with existing js too difficult, for which `as const` now serves as a way to explicitly opt into sounder behavior.
I don't think you should reinvent the wheel unless for some reason all available wheels are insufficient for your case. But knowing this requires that you have some understanding of how wheels work, how to compare them, and how to hew your own out of raw materials if the need arises.
I would say JS is partially a wild west due to title inflation and the relative numbers of lesser experienced developers in the space relative to, say, your pool of Erlang engineers.
It's also not necessarily required that you understand all of what you're doing down to the logic gates, but if you don't (to crib your example) understand some of what docx parsing may entail, or can't actually write any sort function (nor understand how to compare them), you're stuck with black boxes at even the highest levels, and then you're very likely to be exposed to the article's defined fatigue as you continually jump to whatever looks shiniest, lacking the understanding with which to properly compare your options.
I think this is true of a much larger category of developers than JS developers (though one could argue that defining yourself by a specific language is indicative of belonging to this category), that is developers who can't do more than plumbing, i.e. developers who can't actually solve problems properly on their own.
The flighty attraction to the new shiny is somewhat driven by a lack of understanding of how either the new or the old shiny actually work. If you understand the job you're setting out to do you're in a much better position to decide upon tools, frameworks, what to do in house, etc. If you don't you're stuck gluing black boxes together, because any actual code you write will be far worse.
JS being an "accessible" language and a mandatory part of practically all software companies with a front facing website makes this the most apparent in both the constant flow of new tools and libraries and the view that the new tools and libraries must be adopted. But any novice developer can fall prey to this behavior regardless of their choice of language, JS just makes it easier.
But even then it's hard to debug, or work out ideas in the REPL, testing is a bit more complex than it should have to be, etc. There are probably better languages to reach for (I'd love to see rust firm up a one true way of async).
I think this is just one of those problems that's hard to sell to people.
There are two types of features and related clustering algorithms: categorical and numerical. Numerical features are the most commonly supported by out of the box clustering tools (meaning most of the algorithms made easily available to you will expect numerical features). Categorical features can be reduced to binary numerical features, however, though whether that’ll make sense for your data depends: For example, if products have a set of categories they can be sorted into you may want to just use that data along with K-Modes clustering or some other approach that considers categorical features. (Though to me those don’t really seem to produce useful results.)
For short text clustering I’d try an ngram frequency approach, wherein you reduce the text to a set of features describing the frequency of ngrams from, say, unigram up to trigram. You’re attempting to balance the number of features you end up needing to process with the amount of locality information you need to get a useful result. If you end up with far too many features, you could attempt to cull them with an approach such as PCA, but it may not even be necessary.
Do note that I’m only a little above 0 in terms of insight or knowledge, so take my advice with a good heap of salt. Clustering of this data would group together products that are described “similarly”, but “similarly” in this case doesn’t imply the products are in fact similar, but only that they’re described in a similar manner.
You may also want to explore graph clustering over vector clustering, which—while there may be no out of the box solutions readily available—is likely a much better fit for text in general.
Moreover, anything can be stolen from you or become otherwise lost or incapacitated. Do you have a laptop that is theft and spill proof?
But were I the head of a large company, or in any position wherein I was keeping track with an unmanageable number of people, I'd definitely be willing to pay $20 a year to ensure that when I urgently need to get in touch with someone, I'm not burned by having outdated contact information.
I'm actually a little bit surprised that my desktop mail client doesn't do anything like this already.