Hacker News new | past | comments | ask | show | jobs | submit | smugworth's comments login

The risk of counterfeits means I will rarely buy anything electronic from Amazon.

On the other hand, take a category like pet toys. Cheap plastic things where I'm not concerned with getting the genuine article, like a collapsible dog bowl. There are dozens of identical "brands" with thrown-together phonetic names for an entirely identical product with slight price differences. How do I began to choose? And who's to say any of them are produced with safe materials?

I'd really like to know how well Amazon's "put anything on the digital shelf" strategy works over a curated product inventory. Exceedingly well, I suspect, but it seems like the blowback over poor product will continue increasing.


Same here. Amazon is a mess, and in many ways worse than eBay was when it got its (deservedly) bad reputation.

For many product categories, almost every single result flunks Fakespot.com with a D or worse, so it's too much work to keep going in the hope of finding some wheat in the chaff, and easier to just buy somewhere else like B&H Photo or Target.com. Two recent examples: Ethernet cables and sleep masks for airplane travel.

Then there are bizarre things like how when you select "Sort by price, low to high", the results aren't actually sorted by price, and half the results you saw in the default view don't appear in the sorted by price view.


Pet toys and food were the first thing I stopped buying off of Amazon. I have zero faith in the quality control of the product coming down - in the United States, at least, pet food and pet toys are actually held to a decent standard.


Even American pet food/treats is riddled with frauds or questionable companies. There's a treat called No-Hide that people have sent in for DNA testing and other testing that is suspiciously similar to rawhide despite being claimed to be starch based The Pennsylvania Department of Agriculture did an investigation and this person FOIA'd the documents and the testing shows a lot of discrepancies even though the government cleared them of misbranding. https://truthaboutpetfood.com/is-it-no-hide-or-rawhide-from-...


On the other hand, take a category like pet toys. Cheap plastic things where I'm not concerned with getting the genuine article

Are you sure that you're not feeding your dog some lead in the process?

It may be in the coating.


How do you verify that anywhere else, though? Are pet toys a regulated industry? Pet food is, human food is, electronics are, are pet toys?


If the tire had closed sidewalls, you'd never know someone had the new tires without obtrusive labelling. Open sidewalls market themselves, not only do you see it's a different tire, you see it's an entirely different tire design that's relatively easy to comprehend the benefit of even if you know nothing about them.


I love F-strings, my only gripe is the chosen syntax for invoking them. For starters, F may or may not be capitalized, so these two lines are identical.

  F"My string with {interpolated_value}"
  f'My string with {interpolated_value}'
Like using apostrophes or quotation marks to enclose strings (or F-strings), I find myself wasting time questioning the trivial notion of whether to capitalize or not.

I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string.

  "This is my ${interpolated_value} string"
  'This is my plain old string'

But these are nitpicks, and it's really too late to implement something like that.


> I think Groovy's syntax is great, where quotation marks denote an interpolated string, and apostrophes denote a plain old string.

That's Perl's syntax, from about 15 years before Groovy, whippersnapper. Off my lawn, now.


Yeah, Groovy got it from Ruby which got it from Perl.


Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $.

Oh, although I guess Perl got that syntax from the Bourne shell…


> Yeah, Ruby uses the doublequote/singlequote distinction from Perl, but Ruby tags variables to interpolate with #{}, while Groovy and Perl use $.

Huh, I could have sworn that I remembered that Groovy has taken it from Ruby.

Incidentally, Ruby uses just # for variables, it uses #{} for arbitrary expressions. A common style prefers #{} even where # alone works, though.


#notallvariables


Apache Groovy's string syntax is deficient, not great. It doesn't have the docstrings syntax that Python, Ruby, and Perl all use.

An early beta version of Groovy 1.0 had it (thanks to a Sam Pullara), but it was later yanked out. Groovy's self-styled Project Manager at the time said he only wanted syntax in Groovy that would cause the Java syntax highlight rules in Eclipse and Netbeans to highlight Groovy code similar to Java, so if a manager was walking around the programming area, the screens would look like the programmers were using Java.

And that's how Groovy got its deficient string syntax.


Funny you should mention Kafka. Jay Kreps, Jun Rao, and Neha Narkhede, formerly of LinkedIn who worked on Kafka, left to form Confluent. They provide support, managed cloud, and licenses for their own flavors of Kafka and ecosystem add-ons, and recently made license changes to their open source add-ons to block providers like AWS from offering them as SaaS as well.


It always seems to me like security solutions rarely take into account usability and user experience. Even something which should be simple like configuring a client to use SSL over plaintext can block productivity for a multitude of reasons until you finally put all the pieces together correctly.

Maybe it's out of necessity, because convenience features would be less secure. Maybe there's not much overlap between those concerned with security and those concerned with ease-of-use, except for cases where companies can develop tools that encourage good security practices while exposing the end user to other risks (e.g. password vaults with one entrypoint).

So what you end up with is people gravitating towards bad security practices and using shortcuts because it's a PITA to maintain the good ones. Let's skip using SSL because we need to get work done instead of troubleshooting the dozen possible misconfigurations. I'll use a really short password for my AppleTV account because it's too hard to type the damn thing with the on-screen remote. I'm tired of getting a 2FA code 50 times a day to get work done, so I'll implement a hot key to generate it from the command line.

Seems like ease-of-use for security solutions should be almost as much of a priority as the security implementation itself in some cases.


> I love the concepts Kafka defines so clearly, but the software is too complex and have dozens of knobs you have to adjust.

This is one of our biggest headaches, and it's not even that a Kafka server itself is so configurable. We have hundreds of teams writing client applications, and jumping on bridges because Kafka clients have poor configurations is getting old. Too many knobs to twiddle, but I guess that's what happens if you're expecting to be able to tweak for high performance.


I think the strategy of "monolith first" isn't a poor one, but it is a little humorous to see someone who makes part of their living helping companies break apart their monoliths advocate it.


I guess. My partner is currently starting a mushroom farm. She hopes one day it will be big enough to make use of a very large facility. Right now it isn't, though. Do you find the same humor in her real estate broker guiding her towards smaller properties initially even though if her business successfully grows the broker will make part of their living helping her move into a bigger location?

Makes perfect sense to me.


I get what you mean by saying it's humorous, but I think it's important that nobody easily dismiss what he says because of who he is.

A lot of what he's arguing against is cargo cult programming, and I think it's fair for anyone to argue against that. If your only explanation for why you chose one architecture or design pattern over the others (especially if that option introduces a lot of additional drawbacks) is "because that's just what you do", you need to stop and objectively evaluate what you're doing.


I'm working on a team for a platform built on open-source software which actively replaced a previous IBM solution, and there are more services from other vendors being phased out in favor of internally developed tooling.

Seems like a good long-term investment, in an era where people are constantly criticizing CEOs for short-term cash-grabs. Why shackle yourself to a vendor if you plan to be around for awhile.


C'mon man, I hadn't had my coffee yet that morning.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: