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

Почему рекоменудется носить трусы? Чтобы жопа была в безопасности.

Вот тут прибилзительно то же самое. Чтобы программисту не надо было думать как поведет себя код, если ВДРУГ кто то снаружи изменит то, что менять не надо вообще.
Когда вы делаете переменную публичной - вы тем самым говорите "эту переменную можно менять, я все предусмотрел, все будет ок. Это интерфейс взаимодействия - пользуйтесь". Но ведь далеко не для всех переменных класса НАДО предусматривать такое - зачем же делать лишнюю работу - ставим private и все, манипулируем переменной только изнутри, ЗНАЯ все варианты ее изменения.

Нужно добавить следующие меты:
property="og:type" content="article"
property="og:image" content=...
property="og:image:width" content=...
property="og:image:height" content=...
name="twitter:image" content=...
name="twitter:card" content="summary_large_image"

но оно оказалось маленьким

А размер вы в метатегах указать не забыли?

Изучите прерывания биос.

И вообще, интерпретатор это довольно простая задача, если вы уже научились работать с устройствами ввода-вывода, поэтому может быть стоит потренироваться на более простых программах, чем сразу писать свою ОС?

У вас примеры с new и без new не эквивалентны. Вы просто посмотрите, что там на самом деле находится в получаемых переменных:

function Foo(arg) {
    this.bar = function() {
        return arg;
    };

    return this.bar();
}

const notfoo = Foo('not foo');
console.log(notfoo); // "not foo", т.е. notfoo - это не новый Foo, это строка текста.
console.log(notfoo.bar); // undefined, что логично, у стандартной строки никакого bar нет.

const foo = new Foo('foo');
console.log(foo); // [object Object], т.е. вот это - настоящий новый Foo.
console.log(foo.bar); // function() { ... }, и метод bar в нем есть.
console.log(foo.bar()); // "foo"

можно через infer:

type Schemas<P extends keyof paths> = paths[P]['post'] extends {requestBody: infer R} ? R : never;

playground

Мне кажется, прямо в названии отражать, что он unstable не обязательно, ибо стабилизация существует только в рамках стандартной библиотеки - просто дай ему другое название и закрой за feature, которую можно включить только на nightly.

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

У тебя там self referential struct, так что придётся при помощи NonNull указателей сделать и запретить перемещение структуры при помощи PhantomPin.
Лайфтайма наподобие 'self нету

Я не из МТС банка, но у нас в собесе тоже есть похожий вопрос, но я бы не назвал его простым, так как там дальше ещё много дополнительных вопросов и обсуждений можно невертеть.

Основная идея заключается в том, что нужно как-то обеспечить транзакционнлсть при общении с левым сервисом.

Самый простой и часто используемый вариант - Outbox.

Смысл в том, что мы должны в нашей основной базе завести таблицу, в которой будет записано, что нам нужно отправить запрос в тот сервис и с какими параметрами. (Например отправить письмо по электронной почте)

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

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

Переносить взаимодействие со сторонним сервисом в Outbox также имеет смысл из-за того что ты не можешь гарантировать его доступность и задержки - если будешь работат с ним при обработке запроса от клиента по API, то можешь просто упасть по тайм-аут.

Также Outbox часто сочетают вместе с очередями сообщений - тогда ты уже не просто отправляешь запрос, а кладешь его в очередь, которую тот сервис будет разбирать.



Благодаря тому что мы записываем основные бизнес-данные и намерение сделать запрос в сторонний сервис в одной транзакции - мы гарантируем, что мы не будем отправлять запрос, если данные не записались и наоборот - если данные записались, то мы гарантируем, что попытаемся рано или поздно отправить запрос.

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

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

Или у вас вопрос, почему указатель? Ну ведь фунция - это огромный кусок кода в памяти. Логично же ее передавать как указатель, как и массивы, например. Но тут есть еще и низкоуровневая проблема - в процессоре есть защита от исполнения данных. Без дополнительных танцев с бубном, вы никак данные не выполните, даже если там записан корректный машинный код. Поэтому все функции записаны в read-only секции памяти, специально помеченной, как разрешенная к исполнению. Поэтому единственный сопособ как-то эти данные куда-то передать - это указатель туда. Сами данные-то не перемещаемые.

static int Print(){
это ФУНКЦИЯ
для ее вызова нужно использовать скобки
Bacteria::Print()
иначе ты получаешь ее адрес

peer-зависимости - обычно предназначены для подключения особо крупных библиотек

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

Теоретически, мы могли бы отмечать и мелкие библиотеки как peer-зависимости.

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

Ну и вообще-то не особо понятно, в чём конкретно у вас вопрос.

Как-то так, если без учёта дубликатов, в один проход.

function removeSomeShit(arr) {
  const table = {};
  const result = [];

  for(const current of arr) {
    const {uid, owner, createdAt} = current;

    const uidOvnerKey = `${uid}\0${owner}`;
    const ownerUidKey = `${owner}\0${uid}`;

    const matched = table[uidOvnerKey];

    if (matched) {
      delete table[uidOvnerKey];
      result.push(matched.createdAt > createdAt ? matched : current);
    } else {
      table[ownerUidKey] = current;
    }
  };
  
  return Object.values(table).concat(result);
}

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