blowski

I think it's worth debating the idea, exploring what it would look like. But I think there's a lot of hidden complexity there.

1. Who is allowed to detect, process or store your identity? For what purposes?

2. What about "right to forget"? Does the data need to be destroyed after a certain period?

3. Who manufacturers and sells these private keys? What happens if I lose mine, or it gets stolen?

4. How does this work internationally? Can a key from China access a system in the US?

I too instinctively bristle at this kind of legislation. It's likely to be abused, with many false positive that make it more effective at sweeping up innocent people, while the guilty just find workarounds.

But all coming on here and saying "ooohh, this is bad, innit!" is not very interesting, and unlikely to prevent it.

Why is the EU doing this? Which political groups are supporting and opposing it? Why now? How are vendors responding? How does it affect non-EU countries?

I would argue even with movies it holds true. 30 years ago, it was very difficult and expensive to buy, say, 1950s film noir. Now it takes 5 minutes to torrent.

Perhaps this is what's going on. It's hard for new obscure stuff to make money and so there's less of it, but old obscure stuff (which doesn't need to make money) is more popular than ever.

I have no data to back me up, so take this with a big pinch of salt.

But I think perhaps the top 10 only seems more dominant because the long tail is so much longer and deeper. For example, my 10 year old son prefers to listen to obscure electronic music on Spotify (tracks with fewer than 10K listens), over Taylor Swift or Muse.

We are all goths now.

“Blue tape”, rather than “red tape”.

Treat your audience as people with lots on their minds, distracted by their phones, and who are likely sitting in their 10th presentation so far this week. And be humble - your presentation is probably not as interesting as you think.

The intro/outro is not an agenda, but a summary of the key things you want people to remember from your presentation.

Example:

1. Today I’m going to show you how I make gold from toilet paper. You can do this too, you just need 3 sheets of toilet paper.

2. I developed this process myself in a caravan in my front garden, blah blah blah. (Explain the process)

3. And that’s how you make gold from toilet paper. You can do this too - go and get your 3 sheets of toilet paper, and give it a go!

It may not be a great presentation, but people are more likely to come away from it remembering what you wanted them to remember because you made those points so clear. Great presentations do break these rules, but you’re more likely to be confusing than great.

Better to be dry and clear than attempt to be interesting while leaving your audience lost.

Strong disagree - you can’t practise too much. Looking robotic comes from being nervous that you’ll forget it, because you haven’t practised enough.

Once you’ve delivered it 1000 times you’ll know it so well that it will appear more natural.

1. Tell ‘em what you’re gonna tell ‘em.

2. Tell ‘em.

3. Tell ‘em what you told ‘em.

There should be 2 or 3 key points that you reinforce multiple times. No more.

And my #1 tip: The more natural you want the presentation to sound, the more you need to practice it in advance.

If you’re an experienced presenter you’ll know how and when to break these rules.

Descriptive titles have their place, but so do titles that arouse curiousity and need you to read TFA.

Yes, massive companies are a nest of conflicting priorities. The sales team wants to do whatever it takes to win the deal, and the legal team wants everyone to behave ethically at all times. The board wants to be shocked(!) when it turns out those goals are in conflict, with the ethical side sometimes losing out, to remove any personal risk to themselves.

Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

(From the guidelines)

I agree with you. V7 was good enough that I’d have paid for it over using Apple. But v8 has had me looking for an alternative anyway.

I've found them to be a real pain in the arse because they're implemented so inconsistently. Only the biggest sites are offering them, but it's those big sites where I'm worried about locking myself out because of setting it up wrong.

Muzak aimed to be more than just background noise - it supposedly improved worker productivity, and manipulated your mood.

FWIW, I downvoted because of the complaint about downvotes.

Original title:

> The Mythical Non-Roboticist: Wouldn't it be great if everyone could do robotics?

Not sure why it's been changed here.

Event-driven: At runtime, the client tells the system what has happened, the system stores the event and is configured in advance for how to react to it.

CRUD: Imperative. Client tells us to create/update a specific entity with some data.

Yes, if version 1.3 of Command handler X was the active version when an event happened, then it needs to be replayed with that version, even if you’re now on v4.5.

I was the lead developer on one for an insurance company a few years back, and it’s still in active use. Insurance is a heavily regulated domain, where an audit trail is more important than performance. There was a natural pattern for it to follow, as we were mapping a stable industry standard.

I also tried doing it in a property setting, where profit margins were tight. The effort needed wasn’t worth the cost, and clients didn’t really care about the value proposition anyway. We pretty much replaced the whole layer with a more traditional crud system.

Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going to ask for it later, add a “break condition” that tells you when you need to upgrade. You can put entry points into the code - comments, interfaces - to make it easier to do the upgrade.

I find the term DRY to be pretty vague.

Let’s say you have a business rule that you can never have more than 5 widgets. You can make this assumption in multiple places, even with totally different code, and that’s damaging DRY when the rule changes to allowing 6. On the other hand, having a bit of duplicated HTML can help, as they may only be the same by accident.

My experience is that the problem is avoided in theory, but not in practice.

Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.

I’ve heard this called the “backend-for-frontend” pattern.

I imagine it would be a different flavour to what we have today, but the same intensity. Anything that so deeply penetrates daily life across the globe is going to bring enormous problems with it.

Indeed. It’s probably why so many APIs accept the api key in the URL.

I have said and read “Plan B” many times in my life, almost never in connection with an abortion drug. Searching on Google, “Plan B” is more connected with the musician and politicans’ speeches.

Have they officially said they want to get rid of VBScript?

What if humans are “playing” because they’re bored?

Traditionally, one of Microsoft's weaknesses was how crappy it looked against Apple. Maybe they are trying to say "we care a lot about making this look good".