HN user

cyclotron3k

612 karma
Posts0
Comments162
View on HN
No posts found.

This article doesn't land for me. The author complains about having to scan the code in sequence, but overlooks the fact that a waiter/waitress/till can only serve one person at time. And as you say, multiple people can scan a QR code, _and_ it would be trivial to print more.

Maybe I missed the point, but the aside about parking metres seems irrelevant. Just makes me think this is an anti-technology rant.

And again, the gripe about splitting up the bill. Not only is that a problem with existing systems, it's a problem that is solved by QR codes (if implemented correctly).

What the article misses is that money is saved for the company by moving the work to the customer / end user.

It doesn't miss it. The whole framing of the article is the Dooman Fallacy - an organisation trying to save money by shifting [apparently] menial work to the customer ends up losing more than they save.

Interesting and useful article, but:

If you are new to 3D printing and/or CAD for 3D printing, this is not the right article for you.

I feel like I would have been fine with this article about a week into my 3d printing journey.

I don't know a single homeschooler that sits at home all day long.

Well, you wouldn't, would you?

Sorry, not to detract from your other points, but I thought it was funny.

Until you click the "accept" button, you haven't agreed to accept any cookies, so if you instead click through to settings, it shows you the current state: cookies off. I think the toggles could be a bit clearer, but I don't really have a problem with it.

Having worked at AI (a long time ago), I can assure you this isn't some mastermind plot to sneak a couple of cookies onto the computers of the one or two people who click through to settings.

Thiings 1 year ago

If you're making an icon of Tower Bridge, you're going to tag it with "London" and "bridge", so it's going to turn up in all searches for London bridge.

At this point though, the two bridges should just swap names.

Hey, they don't have excel or word, like I have at work, and none of the other professional software like Photoshop or premiere, I can't play AAA games, and none of my friends use it either. But that's cool. The clipboard though... that I cannot abide.

Put another way, I strongly disagree that the clipboard is the main obstacle. (And fwiw, Linux has been my main OS for decades)

In practice, it's not really an issue. In some applications (most notably terminal emulators, where ctrl+c is already used to terminate a process) you have to use an alternative combination (e.g. ctrl+shift+c).

MacOS neatly avoids this issue with the command key, but I'm not sure what happens in Windows.

It doesn’t even matter if I’m right. Sometimes, you just have to be kind.

The article seems to imply that kindness/correctness are somehow mutually exclusive. Even if that wasn't the author's intent or belief, it certainly seems to be the way some commenters conduct themselves.

Personally, I find Ruby's syntax more natural, (I'm going to be heavily biased though, having written Ruby for 10+ years). But for example, let's say I wanted to make a hash (dict) of files, keyed by their size (for some unknown reason), in Ruby it would look like:

  Pathname.glob('*').filter { |f| f.file? }.each_with_object({}) { |f, h| h[f.size] = f }
Whereas the equivalent Python would be:
  result = {}
  for file_path in glob.glob('*'):
    if os.path.isfile(file_path):
      result[os.path.getsize(file_path)] = file_path
Or capitalizing a string in Ruby:
  string.split(' ').map(&:capitalize).join(' ')
And in Python:
  words = string.split(' ')
  capitalized_words = [word.capitalize() for word in words]
  result = ' '.join(capitalized_words)
Python seems to be more convoluted and verbose to me, and requires more explicit variable declarations too. With the Ruby you can literally read left to right and know what it does, but with the Python, I find I have to jump about a bit to grok what's going on. But maybe that's just my lack of Python experience showing.

Totally agree! Other tricks I rely on:

a) put a `binding.irb` (or `binding.pry`) in any rescue block you may have in your script - it'll allow you to jump in and see what went wrong in an interactive way. (You'll need a `require 'irb'` in your script too, ofc)

b) I always use `Pathname` instead of `File` - it's part of the standard library, is a drop in replacement for `File` (and `Dir`) and generally has a much more natural API.

c) Often backticks are all you need, but when you need something a little stronger (e.g. when handling filenames with spaces in them, or potentially hostile user input, etc), Ruby has a plethora of tools in its stdlib to handle any scenario. First step would be `system` which escapes inputs for you (but doesn't return stdout).

d) Threads in Ruby are super easy, but using `Parallel` (not part of the stdlib) can make it even easier! A contrived example: `Parallel.map(url_list) { |url| Benchmark.measure { system('wget', url) }.real }.sum` to download a bunch of files in parallel and get the total time.

MacOS has Ruby 2.6 installed by default which is perfectly serviceable, but it's EOL and there are plenty of features in 3+ that make the jump more than worthwhile.

where the Al couldn't use it's raw computing power. I'm not really sure what that would be, though (if were, l'd probably write a novel!).

You may enjoy Use of Weapons by Iain M Banks, which features a plot point along these lines