AlexNew22

const sum5 = (...args) =>
  args.length > 4
    ? args.slice(0, 5).reduce((acc, n) => acc + n, 0)
    : sum5.bind(null, ...args);
//  или
//  : (...args2) => sum5(...args, ...args2);

ну исправьте это досадное недоразумение один раз)
давайте лучше радоваться, что это не запрещено)

Object.prototype.keys = function(){
      return Object.keys(this);
}
Object.prototype.keysToString = function(){
      return Object.keys(this).join(' ');
}
 const obj = {
     one: true,
     two: true
  }
  console.log(obj.keys());
  console.log(obj.keysToString());

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

В качестве гипотезы: поскольку Object традиционно является базовым классом для всяких других классов (иными словами, цепочки прототипов заканчиваются на Object.prototype), то весьма желательно ничего туда (в Object.prototype) не добавлять, чтобы не было пересечения с полями классов-наследников. Например, в твоём классе будет свой метод keys, и не получится воспользоваться стандартным. А так, натравливаешь Object.keys, и - нет проблем.

function sortTickets(tickets) {
    const map = new Map();
    const transits = new Set();
    
    tickets.forEach((t) => {
        map.set(t.from, t);
        transits.add(t.to);
    });

    const start = tickets.find(t => !transits.has(t.from));

    const result = [];
    
    for (let t = start; t; t = map.get(t.to)) {
        result.push(t);
    }

    return result;
}

const sorted = sortTickets([
  {from: 'Sochi', to: 'Paris'},
  {from: 'Moscow', to: 'Sochi'},
  {from: 'London', to: 'Moscow'},
  {from: 'Berlin', to: 'Kamchatka'},
  {from: 'Paris', to: 'Berlin'},
]);

Топорное решение с временным свойством для сортировки.

Сначала найти самый первый город – тот, который есть только в from, но отсутствует в to. От него пляшем по цепочке, добавляя инкрементируемое свойство для сортировки.
Сортируем, и удаляем временное свойство.

const allFrom = tickets.map(item => item.from);
const allTo = tickets.map(item => item.to);
let city = allFrom.filter(item => !allTo.includes(item)).pop(); // первый город
const w = Symbol(); // чтобы случайно не затереть существующее свойство
let i = 0;
let ticket;
while (ticket = tickets.find(t => t.from === city)) {
  ticket[w] = i++;
  city = ticket.to;
}

// ура! сортировка!
tickets.sort((a, b) => a[w] - b[w]);

tickets.forEach(t => delete t[w]);

Если забыть про текстовый язык (JS) и перейти к графическому, то очевидные преимущества будут налицо: пример Stateflow из MatLab/Simulink. Обычно используется автоматчиками.

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

Конечный автомат — это ограниченное количество состояний, входные сигналы для перехода между состояниями и выходящие при этих переходах, а также сигналы текущего состояния. В теории их делят по выработке сигналов, но на фронтенде всё смешивается всё равно.
И важно помнить, что для фронтенда "конечный автомат" применяется в большей степени для процесса, а не значений. То есть, состояниями будут, например, являться:
• инициализация/загрузка документа — что до события download,
• открытое модальное окно,
• передача данных из формы,
а сигналами будут как раз события:
• ondowload сигнал для перехода из состояния загрузки в состояние готовности,
• клик по определённой кнопке — это сигнал для закрытия модального окна, например.
• submit формы
• response или reject — ответ на форму,
ещё сигналы из таймеров подойдут:
• таймаут загрузки, как самое очевидное,
• циклическая подгрузка, типа для новостей.
И по теории автоматов должно быть так, чтобы переход из одного состояния в другое всегда сопровождался определённым сигналом. Например, бесконечная лента записей из состояния просмотра по сигналу "докрутили до конца" переходит в состояние "подгрузка". Но ведь пользователь может крутануть назад и вперёд, что опять породит сигнал "докрутили до конца", но из состояния "подгрузка" не должно быть переходов по этому сигналу, а потому не должно быть и повторного запроса на сервер.

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



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

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

В качестве примера можно привести Reducer.
Если есть опыт работы с Redux, то я думаю, поймешь о чем речь.
Если нет, то:
Представь, что в приложении есть некий общий объект, который хранит в себе некие данные этого приложения. Например произошёл запрос на бэкенд, получен ответ, и данные сохранились в этом объекте. К этому объекту есть доступ у всех компонентов приложения. Т.е. отпадает потребность туда сюда из компонента в компонент передавать эти данные в виде props.
Данные в этом объекте может менять определенная функция. И этой функцией является редьюсер. И этот редьюсер и должен быть конечным автоматом.
Т.е. в редьюсер передаются данные, он эти данные принимает, распознает не при помощи if else, а при помощи switch case, так как это удобнее, и меняет данные в объекте. И, в следующий раз при передаче этому редьюсеру этих же данных, он поменяет данные в объекте абсолютно точно также.

const reducer = (state, action) => {
 switch(action.type) {
  case "new value":
  return{...state, value: action.payload}
}
}

Зависит от того, массив это у вас, или, карта, или дек.
Удаление из массива занимает O(N) в худшем случае
Из карты - O(1)
Из дека O(bucket_size)

Вот и выбирайте

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

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

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

Electron

Вот тут вся идея и алгоритм

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

а зачем нужен pgadmin для управления базой?

Ну а помимо этого, pgadmin не только умеет подключаться удалённо куда ему скажут, но и самостоятельно запускать для этого ssh туннель.

Вы на какой сети сидите? 2.4 Ггц ?
Да. соседский вифи может мешать, это норма. Там очень много факторов

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

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

Помимо технической стороны есть и психологическая.
Поэтому некоторые сайты могут нанести вред вашей психике.