WbICHA

Тут все ответы одновременно верные, не верные и противоречащие самой задаче.

1. "Ничего не изменилось" противоречит концепции самой задачи: по условиям задачи уже что-то изменилось. Ничего не изменилось в дизайне странице. Изменился объём страницы и увеличилось потребление трафика, а так же объём вычислительных ресурсов необходимых для обработки данной страницы.
   
2. Расходы снизились, т.к. после пересборки и деплоя проекта запустился механизм очистки кэша предыдущей версии проекта и которая занимала больший объём, чем текущая. Расходы увеличились, потому что объём проекта увеличился.
   
3. Скорость - аналогично: проект пересобрался чуток по-другому из-за других хэшей в названиях файлов, которые архиватор пережал чуть более эффективно. Или сжатие страниц не использовалась и скорость отображения страниц замедлилась.
   
4. Износ НЖМД относится к пункту 2, т.к. это часть расходов на обслуживание сервера.
   
5. Электропитание - то же самое: больше байт для обработки - больше затраты на электричество, архиватор сжал эффективнее - меньше байт, меньше затраты.
   
6. Так же и с уязвимостью: дополнительные 43 байта привели к возможности использовать атаку при переполнении буфера в такой странице памяти (ну, условно, конечно). Или наоборот избавили.
   
7. По любому пункту выше (и даже ниже) можно получить как взыскание, так и премию.
   
8. То же самое с выбросами: пользователи получили замедление страницы и со злости очень активно и экспрессивно высказались в адрес владельцев и разработчиков сайта, что привело к более активному дыханию и дополнительным выбросам. Ну или наоборот - пользователи уснули в ожидании загрузки страницы и меньше надышали.
   

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

Знание конкретно Пролога не монетизировать, а вот знание логического программирования можно. Разбирающемуся в этом предмете легче даётся функциональное программирование, type-level программирование, языки запросов, типа Datalog, разработка экспертных систем и т.п.

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

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

Если твой код иногда работает, то поздравляю - ты Junior. Если понимаешь, почему не работает, то ты уже на пути в Middle'ы. А если уже ненавидишь себя за выбор пути и задумываешься о домике на берегу реки - добро пожаловать в Senior'ы

твой уровень программирования "школьник 9го класса, изучающий полгода java"

Прям совсем без математики не обойтись одному программисту на десятки, а то и сотни тысяч. Можно построить блестящую карьеру, применяя только арифметику, да и ту для того, чтобы деньги считать. Да и от высшего образования, если это не MIT или Беркли, польза только в том, чтобы прорваться через первичные фильтры при отборе на должность джуна. Так что если нравится программировать и хочешь связать с этим жизнь, ничего не бойся, не обращай внимания на условности, не слушай гейткиперов, становись тем, кем хочешь.

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

Твоя цель - оффер, и все посторонние мысли о справедливости, какая компания, какое тестовое и т.д. Они только отвлекают и мешают.

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

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

Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?

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

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.

Инкапсуляция защищает не от хакеров, а от неправильного использования объектов.
Как пример - у тебя может быть класс "Заказ" и у него может быть какой-то статус (оплачен/ждёт оплаты/отменён итд).
При этом у тебя могут быть правила типа: уже оплаченный заказ не может стать вдруг неоплаченным, а отменённый заказ нельзя взять обратно в работу.
Тогда логично будет сделать поле статуса приватным (не доступным для изменения извне напрямую), а менять его только через методы, где будет происходить вся валидация.
(В некоторых языках такие правила принято описывать на уровне типов, чтобы даже валидаций никаких было делать не нужно)

Приватные поля объекта - это его состояние.
Методы объекта - это способы его использования.

Если у тебя в объекте появляется поле x и методы getX / setX (или авто геттеры/сеттеры в C#), то значит, что у тебя и нет явных причин делать это поле приватным, кроме соблюдения общепринятых соглашений.

А ведь и правда есть термин для них (но не тип, конечно): Well-Known Intrinsic Objects

Если же вы спрашиваете как затипизировать что-то, что может быть "RegExp, Array, Function и другим" (и не указывая при этом каждый тип явно), то должен, наверное, подойти только object (не смог в доке TS найти отличается ли TS-тип object от базового JS-объекта; например, в TS есть явная типизация функций, но можно ли её заменить на object?). Но это максимально странная задача, которую явно надо решить каким-то другим способом.

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

По моим личным наблюдениям для более стабильной работы лучше бы взять минимум 1 гб, но и на 0,5 должен работать. Я заметил, что чем больше скорость вашего интернета - тем сильней нагружается процессор.

Для личных целей держу для себя - 1 ядро, 1 гб озу. Этого в целом достаточно что бы пользовалась вся семья - 5-6 человек.

Решим задачу в общем виде - сделаем функцию, находящую количество совпадающих элементов у любых итерируемых объектов. Причём под совпадением будем понимать не обязательно непосредственное равенство (оставим это как вариант по умолчанию), а равенство некоторых производных значений. Так что к чёрту filter (а ещё Safari - говорят, яблочные уроды пока не реализовали поддержку методов итераторов; впрочем, сделать обычный for...of вместо reduce не проблема):

function countIntersections(data1, data2, key = n => n) {
  const getKey = key instanceof Function ? key : n => n[key];
  const keys = new Set(Array.from(data2, getKey));
  return data1[Symbol.iterator]().reduce((acc, n) => acc + keys.has(getKey(n)), 0);
}

В вашем случае применять так: const result = countIntersections(newWord, glas);.

Другие примеры использования:

countIntersections(Array(7).keys(), Array(4).keys()) // 4
countIntersections('abCdE', 'ACe', n => n.toLowerCase()) // 3
countIntersections([ { id: 1 }, { id: 2 }, { id: 3 } ], [ { id: 3 } ], 'id') // 1

Потому что для рабочей версии сайта чаще всего используют минифицированные версии файлов.

Если там хитрая логика, то лучше вынести в отдельную функцию и к ней наколбасить тестов через чистый jest. Эта функция должна получать все данные, с которыми работает, через параметр. Например, твой handleChangeRoadCosts сейчас берет некую data из замыкания, а надо это передавать доп. параметром. Тогда ты легко напишешь тесты.

В самом компоненте остаётся обезжиренный вариант, не требующий тестов:

import {myFunc} from '....';

........
const handleChangeRoadCosts = (id: number, keyVal: string, val: string) => {
    return myFunc(id, keyVal, val, data);
};