Михаил Р.

Моё мнение - если тебе смысл переменной не очевиден, то нужно делать полноценное имя переменной.

Короткое, например, имеет смысл для параметра в лямбде (array.filter(x => x % 2 === 0)) или в какой-нибудь функции наподобие

function sum(a, b) {
 return a+b;
}

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

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

Экономить ресурс нажатий на кнопки клавиатуры не надо, как и не надо экономить буквы на экране.

Хорошо составленный вопрос содержит половину ответа :) По самой постановке вопроса, по описанию, по языку, который используется (не языку программирования, а именно языку общения, манерам, стилю, жаргону, фене), по его уместности в данной обстановке (особенно для вопросов типа "как сейчас заработать на фрилансе"), по полноте информации можно судить - стоит отвечать серьезно или же просто потроллить. Или вообще не тратить время :)

Вот тут датасеты разные есть https://datasetsearch.research.google.com/

Это называется open graph

Изучить оба языка, проанализировать js-код, вычленить алгоритм, реализовать его на Python.

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

1. Запрос первоначально поступает в node.js (конкретно в движок v8, отвечающий за сетевое взаимодействие). Здесь возможны уязвимости, при которых специальным образом сформированный запрос может привести к отказу в обслуживании (DoS), несанкционированному доступу к памяти (вспоминается эпичнейшая уязвимость heartbleed) и иным спецэффектам.

2. Далее запрос поступает в express, где он парсится и преобразовывается в объект req. Здесь так же могут быть уязвимости, эксплуатируемые путем отправки специально сформированного запроса.

Пункты 1 и 2 исполняются до вашего кода, поэтому всё что вы можете здесь поделать - это вовремя обновлять софт и библиотеки.

3. Далее ваш код занимается обработкой данных. Важный момент в этом - санация и валидация данных.

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

Валидация - это проверка данных на корректность. Например, вы ожидаете номер телефона в поле phone. После санации останется проверить, что длина номера не нулевая и не больше 15.

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

Либо если данные будут вставляться в базу данных, то необходимо экранировать данные (либо вставлять данные через подготовленные запросы) чтобы не получить SQL injection уязвимость.

Вот тут как раз и появляется зависимость от контекста. В контексте базы данных - один способ экранирования. В контексте json - другой. В контексте HTML (при выводе данных пользователю) - третий. В ещё каком-нибудь другом контексте будут свои способы обезопасить данные.

Если рассматривать конкретно пароль, то с ним всё просто. Как правило, пароли не хранятся на сервере в открытом виде и предварительно подвергаются преобразованию в криптографически стойкий хеш (например, argon2 или scrypt). Сам хеш уже имеет фиксированный размер и известный набор символов. Поэтому санировать пароль не нужно, а при валидации просто проверить минимально допустимую длину, несовпадение с логином, email и может ещё какие-нибудь проверки, навязанные бизнесом или применяемыми стандартами.

Реакт придерживается концепции "чистых" функций. Т.е. таких функций, которые всегда дают одинаковый, предсказуемый результат при одинаковых входных параметрах. В режиме разработки, с включенным strict-mode реакт помогает выявить непредвиденные эффекты и состояния, возникающие в результате нарушения концепции, вызывая дважды все функции, которые он считает "чистыми". Как это работает?
Предположим, вы написали функцию, которая по сигналу "свет" - включает свет. Но если свет уже включен - функция его выключает. Вы довольны и счастливы - послали сигнал "свет" - свет включился, послали еще один сигнал "свет" - выключился. Но в режиме strict-mode - вы обнаружите, что свет не включается, потому что реакт шлет второй сигнал "свет", который выключает после первого сигнала! И опять, возникает вопрос - да зачем это нужно? А затем, что вы не можете предсказать результат действия сигнала "свет", не зная текущего состояния! Возникнет острая необходимость - включить свет, а вы не знаете - включен он сейчас или нет... Пошлете сигнал "свет", когда он включен - получите выключение.
Примерно такие варианты поведения выявляет strict-mode.

11 миллионов inserts в день - это 127 в секунду. При такой нагрузке справится любая современная БД. Ну я не знаю таких чтоб не справлялись. Делайте только короткую буферизацию и batch-insert пачками по 100 - 1000 чтобы оптимизировать сетевой roundtrip.

Есть специализированные NoSQL системы такие как RocksDb, Tarantool в которых именно много оптимизаций сделано было для быстрой вставки. Они выдерживают и во много раз быстрее.

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

При такой постановке задачи лучшим вариантом СУБД будет та, которую знают и умеют обслуживать ваши админы.
С таким объёмом вставок справится любая мейнстримная на правильно подобранном железе. Что ещё вы собираетесь делать с этими записями нам неведомо, посему на выбор повлияеть не может.

Clip-path, но координаты опорных точек просто в процентах не надо делать, надежнее через calc(), тогда будут четкие значения. И всё будет адаптивно + контент обрезать не будет. Можно менять скос, как в примере, на разных разрешениях + можно анимировать процесс.

clip-path: polygon(0% 0%, 100% calc(0% + 60px), 100% calc(100% - 60px), 0% 100%);
/* calc(100% - 60px) -- вот тут задал четкую ширину скоса */

click

static init() // - make static method

async function bootstrap() {  // change main.ts
  if (!ConfigService.init()) {
    console.error('Invalid config');
    return;
  }
  const app = await NestFactory.create(AppModule);
  // тут как-то нужно запустить метод init из сервиса config модуля.
  await app.listen(3000);
}

Сетевое обнаружение работает по MAC на уровне широковещательных запросов Ethernet.
Соответственно, устройства должны быть в одном широковещательном домене сети.
Какие у них при этом IP-адреса для WinBox абсолютно всё равно.
Можно подключиться к любому микротику, вручную указав его IP-адрес, если до этого адреса настроена маршрутизация.

Привет.
1) Заводить баги и тест-кейсы/чек-листы надо отдельно от задач, так как правиться и проверяться они могут сильно позже, когда задачу давно уже закрыли. Например, регресс. Писать в комментах к задаче - плохая практика :)
2) Кейсы пишутся на документацию к задаче, а не на то, как реализовали. То есть тестовая документация пишется еще до того, как ты приступила к тестированию.
3) Написанные кейсы можно прилинковать к задачам и наоборот.
4) Тестовая документация, баги и задачи могут находиться в разных TMS. Например, кейсы/чек-листы в Allure, а задачи и баги в Jira. Или все в Jira, но в отдельном плагине. Тут уж как в компании заведено или какие вы используете TMS.
5) Баги заводятся как отдельные таски в бэклог. Если это новый функционал, который в работе, то может будет удобнее, если напрямую передашь разработчику и он сразу поправит.

P.S. Сходи к коллегам из других команд (если такие есть) и посоветуйся с ними. В дальнейшем разговоре с лидом можно будет ссылаться на их мнение. Но менять процесс определенно стоит.