Василий Банников

https://github.com/v8/v8

Фокус в оптимизации логических операций.
Если первый операнд AND имеет значение false, то результат будет false независимо от значения второго операнда. Соответственно, вычислять второй операнд смысла нет.
Аналогично, если первый операнд OR имеет значение true, то результат будет true независимо от значения второго операнда.
Если вам нужно, чтобы выполнялись обе функции, то решением, как ни странно, будет явный вызов обоих функций в теле цикла с записью результатов выполнения в переменные.

Это не просто блоки кода. Это блоки статической/нестатической инициализации. Соответственно, статическая инициализация выполняется один раз при первом обращении к классу, нестатическая - каждый раз при создании объекта класса.

Когда юзер находится в вашем веб приложении, он создает определенные действия. Действия связаны с состоянием. А redux это набор утилит для глобального хранения состояния(state) в приложении.
Таким образом, вы создаете какие-то объекты и они меняются в зависимости от состояния. Пользователь это видит как некие различные реакции на его действия.

поделитесь источником, как быстро настроить для VS Code

ОК, гугл: eslint vscode
Не благодари )) Ну реально нет смысла копипастить.
А вот то, что при компиляции нет ошибок, это плохо и надо настроить сборщик.

лишь ошибки типизации которые не мешают компиляции

Если проект компилируется - то все типы сошлись. Если проект компилируется, а ошибка все таки есть - значит типы криво описаны.

Как проверять все файлы проекта на правильность типизации?

Скомпилировать проект.

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

И это хорошо. Если TypeScript LSP будет перепроверять весь проект на каждый чих, а не только открытые файлы, то писать что-то сложнее todo листа будет невозможно...

Знаю, существуют ESLint, TSLint.

Они тоже для статического анализа, но для немного другого. В VSCode они так же чекают только открытые файлы, из тех же соображений производительности.
TSLint устарел. ESLint ставьте отсюда: https://marketplace.visualstudio.com/items?itemNam...

или просто совпадение, или рассчет на то что люди будут ошибаться и писать ему.

поддержка молчит ибо сказать ей нечего, кроме как вежливо послать.

В тот момент когда он сам изъявил данное желание

Стейт менеджер нужен для консистентного управления состоянием приложения, внезапно.
Если вы не пользуетесь менеджером состояния в реакт-приложении, то либо используете контекст (вот хорошее объяснение, почему на проде так делать не нужно), либо пишете заведомо неподдерживаемое приложение. Ну или ваше приложение — это игра в крестики-нолики с двумя полями в стейте корневого компонента.

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

Всегда, когда это возможно, нужно использовать неизменяемые коллекции, и неизменяемые переменные/проперти(val, а не var). Это нужно для того, чтобы сделать интерфейсы и код чище. Хорошо видно, где могут изменяться те или иные данные, а где - не могут, именно для этого иерархия коллекций в котлине разделена на две части. В джаве этого нет, и приходилось делать проверки в рантайме(см Collections.unmodifiableList, например).

Что значит "гуляет"? Где они находятся постоянно?
Правильная постановка много значит, между набором не должно быть поиска клавиши.
Насколько я понимаю такое возможно только если пальцы находятся на базовой позиции постоянно.
У меня по крайней мере так.
Попал указательными на метки, и они постоянно слегка касаются фываоолдж.
Для повышения скорости - упражнения на ритм и постоянная практика.
Для повышения точности - упражнения на ритм на малой скорости.
По поводу скорости - как показывает практика 200-250 это вполне нормальная скорость и в большинстве задач быстрее не надо.
Если вы конечно стенографистом не собрались работать - им да, чем больше тем лучше.
Лично для меня в слепой печати важна не скорость, а тот факт, что печать не отвлекает, и идет в фоновом режиме. Обычная скорость порядка 250. Если набиваю что-то большое, разгоняюсь до 300, быстрее уже ошибки массово.

You-Dont-Need-jQuery

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

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

Однако, GPU может работать только с теми данными, что загружены в видеопамять и результат записывает тоже только в видеопамять, а ее, как правило, меньше чем обычной RAM.

Отсюда следует, что выиграть, считая на GPU, можно только тогда, когда данные независимы, хорошо умещаются в память видеокарты и успевают перекачиваться.