Дмитрий Беляев

^ - это операция XOR. XOR вернёт единицу в том случае, если один из операндов (битов) 1 а другой 0. Таким образом, к примеру, 3 ^ 5 вернет 6 потому, что 0b011 ^ 0b101 (для простоты, биты будем считать слева направо):
Первый бит: 0 ^ 1 = 1.
Второй бит: 1 ^ 0 = 1.
Третий бит: 1 ^ 1 = 0.
Вместе: 0b110 = 6.
Ну а функция будет на каждом шаге использовать значение из предыдущей операции. Также, первая итерация будет следующая: undefined ^ N или 0 ^ N, что вернёт нам само число.

"Оптимизировать" - в смысле сократить? Вот так можно:

const duplicates = Object.fromEntries(Object
  .entries(arr.reduce((acc, n, i) => (
    (acc[n] ??= []).push(i),
    acc
  ), {}))
  .filter(n => n[1].length > 1)
);

Если среди значений массива могут быть такие, которые, будучи различными, имеют одинаковый строковый эквивалент, то обычный объект следует заменить на Map:

const duplicates = new Map(Array
  .from(arr.reduce((acc, n, i) => (
    acc.set(n, acc.get(n) ?? []).get(n).push(i),
    acc
  ), new Map))
  .filter(n => n[1].length > 1)
);

Программа dd выводит отчёт не в stdout, а в stderr. Так что нужно сначала перенаправить stderr в stdout, а потом передавать его в tee:

# башизм
dd if=/dev/zero of=/tmp/zerofile  bs=100M count=5 |& tee ku.log &
# должно работать везде
dd if=/dev/zero of=/tmp/zerofile  bs=100M count=5 2>&1 | tee ku.log &

x?.[Symbol.iterator] instanceof Function

например

кода done < <(ls -1 "./my_temp_dir/")

ls -1 выводит содержание каталога в одну строку по одному наименованию
<(blabla) создает из команды поток, который передается как файловый десктриптор
< перенаправление данных из файлового дескриптора в предыдущую команду
done является частью цикла, поэтому перенаправление идет не в done а в весь блок цикла.

В одном проекте можно, в другом нельзя; одному программисту можно, другому нельзя. Если человек хочет развиваться, вы его не остановите. Если не хочет - не заставите. Проект может помогать или мешать, но сам по себе определяющим фактором почти не является. Собственно, вы сами это подтверждаете своим bio:

Несмотря на долгий срок работы в проекте, нахожу новые интересные задачи, которые не позволяют заскучать.

В целом - скорее реально, чем нет, если есть хоть какое-то желание это делать.
Конкретных аргументов тут никаких дать невозможно, потому что проекты все разные, люди все разные. Но это не помешает сейчас тут пяти-десяти людям написать абсолютно противоположные по смыслу ответы, которые будут сводиться к тому, что я написал выше.

function test() {
  const a = [1];
  return a[0] += 3; // что вы вернет?
}

По вашей логике массив a?
На самом деле вернется результат операции сложения, то есть 4.
А если добавить оператор запятую, то вернет то, что после запятой, что и требуется для reduce.

Распишем подробно что происходит внутри reduce c запятой и без.

// с запятой
array.reduce((a,b,i)=>function(){
  const sum = a[i%2] + b; // вычисление
  a[i%2] = sum; // присваивание
  return a; // возврат массива
}, [0,0]);

// без запятой
array.reduce((a,b,i)=>function(){
  const sum = a[i%2] + b; // вычисление
  a[i%2] = sum; // присваивание
  return sum; // возврат результат суммирования
   // и на следующей итерации будет ошибка из-за попытки обратиться к числу как к массиву.
}, [0,0]);

Все, что попало в интернет – остается там навсегда!

Забудь, нет таких сервисов.

function changeField<T extends DataType, K extends keyof T>(data:T, fieldName:K, val: T[K]) {
  data[fieldName] = val
}

Строго говоря, никак. Если украдут, то судиться. У тебя же есть свидетели того, как ты разрабатываешь свою игру. Возможно, ещё какие-то концепты, которые ты не расшарил. Это всё косвенно поможет.

Однако вряд ли кому нужна сомнительная недоделанная игра без команды разработки, то есть без тебя. Так что основную ценность представляешь как раз ты, а тебя у тебя украсть не могут. И не будь уверен, что игра обязательно сразу принесёт миллионы. Шанс есть, но это далеко не факт.

К слову, идеи вообще никак защитить нельзя, даже авторским правом. Так что если компания посмотрит на твою игру и сделает (с нуля) примерно такую же (типа клон), то это абсолютно законно.

Можно для «половины» числа пробежаться и составить словарь { сумма: счётчик }, сколько раз каждая сумма встретилась на всём диапазоне 000..999 (для n = 6, т.е. половина = 3)
Сумма квадратов счётчиков даст общее число счастливых билетов.

function getLuckyTicketsCount(n) {
  const sums = {};
  for (let i = 0; i < Math.pow(10, n >> 1); i++) {
    // посчитать сумму цифр
    let sum = 0, d = i;
    while (d > 0) {
      sum += d % 10; // прибавили младшую цифру
      d = Math.floor(d / 10); // сдвинули число вправо на 1 цифру
    }

    // и в словарь прибавить 1 для этой суммы
    sums[sum] = (sums[sum] || 0) + 1;
  }

  return Object.values(sums) // счетчики суммм
    .map((n) => n * n) // квадраты
    .reduce((acc, c) => acc + c); // сложить все
}

Спецификаций CSS занимается рабочая группа в составе W3C. Там же есть и информация о том, как принять участие / предложить свою идею.

К примеру вы можете создать issue в репозитории рабочей группы.

Однако вам стоит понимать, что работа над спецификацией уровня CSS Grid - это многолетний труд сотен людей для того, чтобы довести её до реального использования. Если вы предполагаете что за всё это время никто из них не додумался до этой идеи - то вам стоит подумать ещё раз.

Важно помнить, что в отличие от каких-то конкретный use cases которые были бы интересны для пользователей создатели спецификации сосредоточены на совершенно других вещах. Их цель - создание по возможности полного и непротиворечивого механизма, который при этом будет реалистичным в реализации и использовании.

За примерами далеко ходить не нужно: parent selector - мечта уже нескольких поколений разработчиков и тема постоянных вопросов. Однако его нет в спецификации (хотя он был в первых драфтах CSS 3 насколько я помню) и скорее всего не будет. Причину, если интересно, попробуйте поискать сами.

Или, к примеру, такое очевидное, казалось бы, опущение как отсутствие аналога :hover для "stuck" состояния элемента с position: sticky. Ведь его явно не хватает почти любому кто использовал этот стиль. Однако его не будет, о причинах (логичных, но далеко неочевидных) можно почитать в соответствующем issue.

Конечно, если вы внимательно и детально изучите все спецификации и проработаете и напишете своё предложение - оно, вероятно, будет рассмотрено. Но более вероятна ситуация что где-то здесь вы найдёте аналогичную или близкую идею.

Отерытый payload нужен для двух вещей:
1. Чтобы клиент мог получить всякую информацию о токене не делая запросы к серверу.
2. Чтобы сервер мог работать не делая лишние запросы к серверу авторизации или к БД.

Для проверки подлинности есть подпись

По-моему всё началось c Google, который действительно применяет разную логику в зависимости от того, какой email введён и поэтому ему важно разделять ввод email и пароля.

Другие сервисы в основном просто тупо копируют без реальной необходимости, потому что "ну вот Google (или кто-то ещё большой) же так делает, значит так надо". Вплоть до того, что форма по факту одна, просто на JavaScript скрывают поле и показывают после первого submit'а.

Другими словами в большинстве случаев - карго-культ и "следование моде" без реальной потребности. Конечно, есть сценарии при которых это действительно нужно, но их меньшинство.

Кстати, дополнительно, подобный подход ещё и ломает ввод логина / пароля из менеджеров паролей.