DEV Community: Domi

Better (decentralized) Regulation and Protocol for Parental Control?

Domi — Sat, 24 Sep 2022 09:01:37 +0000

There seem to be more and more discussions on and revalations about how some corners of social media are downright dangerous for kids. This makes me have a few reactions:

That's awful, and:
Oh no... politicians are going to pass non-sensical regulation on a topic they don't understand.
But... I like to browse anonymously... I don't want services to be required to verify someone's identity before being able to use it. But I can definitely see it happen, especially in Europe.
And most importantly: I don't want to re-enact 1984, like they do in China, where facial recognition and id cards must be provided to use all kinds of online services (such as games), so companies (and the gov) can prevent ~~everyone~~ kids from accessing the internet as a whole or just certain content. Also, I don't trust anyone to keep that type of data safe ever.

So I was wondering... If this problem needs to get tackled, can we find a better solution, before panicked politicians take a sledgehammer to solve the problem?

What about instead of trusting services to perform identification verification, can we somehow leave it to the parent?

To that extent, considering the immense amount of resources that identity verification would cost to begin with, can't that money be used to develop a better parental control mechanism and experience instead? Maybe one that is tied to the computer/phone/device (or even network of devices if they have more than one), rather than being enforced by the provider/company/gov?
I'm thinking, why not implement an open source protocol that works as follows:

The privileged parent can turn on and off certain types of content (e.g. by domain/url/"content flags"/even keywords; e.g. nsfw, partial nudity, PG-13 could be "content flags").
Applications and content providers can opt into that protocol, to check whether something may be accessed or not.
There would be sensible and maybe crowdsourced default settings, so parents don't have to make the hard decisions on their own (that is similar to how ad-block works afaik)

E.g. the browser implements the protocol as a "hub"-actor, and websites that want to offer any non-safe or unmoderated content must (over the time frame of implementation, let's say a few years or so) implement the "content provider" actor of the protocol, which communicates to the hub the type of content (could start out as simple as adding a new HTTP header, or maybe an initial handshake whose result stays cached for a while etc.), to check if it should be served.

It's just a rough idea that I have been having, but it certainly sounds more appealing than waiting for the next (much worse) iteration of the "Do you want to allow our cookies?" bull.

Making React less stupid: automatic `useMemo` and `useCallback` insertions are coming!

Domi — Tue, 26 Jul 2022 20:20:23 +0000

Is it just me, or is the recently announced optimizing compiler an absolute treat that removes one of the most annoying aspects of modern React development? It finally takes care of the pesky old question of whether or not to bother adding useMemo or useCallback (and it comes with several more goodies).

The ups and downs of memoizing everything have been discussed again and again, including on r/reactjs, more recently, in this thread. That thread also includes several important comments by u/acemarke on this matter, where amongst others, he shares his insightful blog post on "memoizing everything".

Of course, there are trade-offs to be made, but I love the fact that this difficult, and often just downright annoying decision making process of whether or not to add the call can finally be deferred to an automatic process. I for one have always been a big fan of the two, even at the cost of performance in some cases, just for the crucially important (and criminally under-documented) property of upholding referential identity.

I can't wait!

[JS Quiz] Guess the Order of Execution (chances of getting this right are slim)

Domi — Tue, 07 Jun 2022 16:27:08 +0000

(() => {
  function l() { console.log('l()'); return 'l'; }
  function r() { console.log('r()'); return { l: 1 }; }
  function x() { console.log('x()'); return 'x'; }
  function o() { console.log('o()'); return _o; }


  var _o = {};
  ({ [l()]: o()[x()] } = r());

  console.log('test1', _o.x);
})();

(() => {
  function r() { console.log('r()'); return 'r'; }
  function x() { console.log('x()'); return 'x'; }
  function o() { console.log('o()'); return _o2; }

  var _o2 = {};
  o()[x()] = r();

  console.log('test2', _o2.x);
})();

For test1, which one is it?

r → l → o → x
l → o → x → r
r → o → x → l

For test2... just run it yourself. The result being "surprising" might be an understatement.

The Future of Debugging

Domi — Mon, 18 Apr 2022 17:51:22 +0000

Update

Talk: The Future of Debugging

Original

(Ignore this ↓, this is not well written jibbajabba - the talk is quite a bit more coherent, and has pretty pictures!)

Recently I have found myself really enjoying asking all kinds of new types of questions (questions I have not considered in the past), like...

While trying to find a bug: "What might be three possible 'good' next steps? Which one should I pick and why?"
After I fixed a "difficult" bug:
- "Had I known what I know now, would it have taken just as long?"
- "Which step was the hardest? Why?"
- "What can I do to make that hardest step easier for me (or for the next dev) next time around?"
- "If there is such a thing, what kind of tool or method of dynamic analysis could have saved me the most time or pain?"
When working on a "difficult" piece of code, even before the first bug rears its ugly head:
- "How debuggable is this code? Should I make it more debuggable?"
- "What kind of tool could help analyze such code without having to change the code?"

...and so on.

I guess, I have only started asking these types of questions because I have been working on a new type of debugger (called "Dbux") over the past few years. At the same time, I'm thinking: what is going on in other people's heads?

Do you talk about debugging at work (or with other teammates, if any)?
What happens in your debugging sessions?
What kind of opinions do you have about debugging or debuggers?
Are there types of codebases or industries that are more in need of better debugging tools than others?
If code is not well tested, does debugging not deserve being talked about? If so, at what point does the topic start to deserve our attention, if ever?
Do you have questions about debugging you would like someone to answer?

But Why...?

I am posting this with two goals in mind:

I am genuinely wondering about what is going in people's heads on this topic (and reply to the best of my ability).
This post also serves to let people know about my talk on this very topic this Thursday (it's free). I want to extend an invitation to my fellow debuggerheads, as well as to those who are just a little curious. The talk covers what we can expect of debugging, debugging tools and its good friend, the rarely discussed field of "dynamic analysis", as well as the types of questions they can (or maybe will be able to) help us answer. Maybe I'll see a few of you there (or maybe not). Either way, thanks for reading all the way to down here!

A Brand NEW Kind of DEBUGGER for JavaScript (Dbux: Why? What?)

Domi — Mon, 21 Mar 2022 17:48:59 +0000

Intro Video

Dbux is an integrated debugging environment (IDbE) and omniscient debugger for JavaScript runtime analysis.

The following video:

explains why we need better Debuggers,
demonstrates all of Dbux's tools with plenty of examples,
is fully timestamped (if you are impatient, we recommend taking a quick glimpse by skipping around a bunch).

On a Personal Note

I have been programming for some 20+ years, in all kinds of languages. And until recently, I could not quite figure out why sometimes even some of the easiest bugs take some 10+ minutes to find.

It was that frustration that moved me to start this project on 2019/11/16 (2+ years ago). The project has been driven by the wish to better and more intuitively understand what is going on under the hood, not only in the applications that I build myself, but also in all that third-party code that I am making such heavy use of.

At this point, I feel, this project has started providing some very good answers to those mind-boggling questions I had before. I start to feel a greater sense of clarity when confronting that "dark matter" of debugging, even when Dbux is not available.

Call to Action

If you are so inclined, please check it out, and just bombard me with any questions, complaints, any kind of feedback. I would greatly appreciate it!

References

GitHub: https://github.com/Domiii/dbux/
Documentation: https://domiii.github.io/dbux/
Discord: https://discord.gg/QKgq9ZE
Install: https://marketplace.visualstudio.com/items?itemName=Domi.dbux-code

The video briefly mentions Henry Lieberman's informal The Debugging Scandal and What to Do About It. I strongly recommend the avid reader to check that out as well.

Also: shout-out to https://www.replay.io/!

Credit

Lastly, thanks go out to Michael who has been with me from the beginning, and everyone else, who, for a brief period of time, contributed whatever they could!

Race Conditions and Fallacies of `Promise.all`

Domi — Fri, 18 Feb 2022 15:14:14 +0000

What fallacies does `Promise.all` have?

Promise.all is a convinient synchronization mechanism. However, unbeknownst to many, when facing rejections, Promise.all can cause two big headaches:

Upon the first rejection, the promise created with Promise.all will settle with that first rejection. All its other unsettled promises are now "dangling". This means that code chained/nested in those promises is now running concurrently with all code that is chained after Promise.all. This can lead to ugly race conditions if you are not aware of and explicitely consider that possibility.
If you have more than one rejection, any rejection that is not the first, not only is "dangling", but is explicitly muted. The JS engine will not report any of its unhandled rejections, that is not the first.

What about `Promise.allSettled`?

Promise.allSettled is not quite as user-friendly and even foregoes promise error/rejection handlers. You have to provide a fulfillment handler and manually loop over the results array to decipher whether you have any errors at all (i.e. Promise.allSettled(...).then(results => ...)). It's OK, if you make sure that you diligently handle all the information, but it makes things quite a bit more convoluted.

Solution

I present an alternative to Promise.all which uses Promise.allSettled and aggregates all errors.

NOTE: Just like, Promise.all, it ignores fulfilled values, in case of any rejection.

Pros:

Easy to use alternative to Promise.all that does not allow dangling, thereby preventing race conditions.
Reports all errors, not only the first

Cons:

Error aggregation mangles error objects into one big string. That can be further improved.
Promise chain not moving forward on first rejection can slow things down considerably in case the first error happens fast, but the critical path is slow.

The following code is also available in this gist:

/**
 * Fixes the "dangling problem" of Promise.all.
 *
 * {@link betterPromiseAll}
 * @see https://dev.to/domiii/a-solution-to-the-deep-flaws-of-promiseall-4aon-temp-slug-8454028
 */
async function promiseAll(promises) {
  const results = await Promise.allSettled(promises);
  const values = [];
  const errors = [];

  for (const result of results) {
    if (result.status === 'rejected') {
      errors.push(result.reason);
    }
    else {
      values.push(result.value);
    }
  }

  if (errors.length) {
    // NOTE: `AggregateError` seems not too mature YET. It's internal `errors` property is (currently, as of 2/2022) NOT rendered when reported, so we do some manual aggregation for now.
    // throw new AggregateError(errors, 'Promise.allSettled rejections');
    throw new Error(`${errors.length} promise rejections: ${errors.map((err, i) => `\n  [${i + 1}] ${err.stack || err}`).join('')}\n------`);
  }
  return values;
}

/** ###########################################################################
 * some samples
 * ##########################################################################*/
async function runSample(cb) {
  try {
    const result = await cb();
    console.log('########\nFULFILL:\n', result);
  }
  catch (err) {
    console.error('########\nREJECT:\n', err);
  }
}

// reject
runSample(() => {
  return betterPromiseAll([
    Promise.reject(1), 
    Promise.reject(new Error(2)), 
    Promise.resolve().then(() => { throw new Error(3); })
  ]);
});

// reject
runSample(() => {
  return betterPromiseAll([
    Promise.resolve(1),
    Promise.reject(new Error(2)), 
    Promise.resolve().then(() => { throw new Error(3); })
  ]);
});

// fulfill
runSample(() => {
  return betterPromiseAll([
    Promise.resolve(1),
    Promise.resolve(2),
    Promise.resolve(3)
  ]);
});