Михаил Р.

Это называется 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. Сходи к коллегам из других команд (если такие есть) и посоветуйся с ними. В дальнейшем разговоре с лидом можно будет ссылаться на их мнение. Но менять процесс определенно стоит.

Выбирай PhpStorm, в нем практически все тоже самое что и в WebStorm + собственно поддержка php, фреймворков и некоторых cms на нем написанных.

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

По делу без брюзжания:
Писать под винду моветон - лицензии дорогие
Вин формс зачем? - делайте веб апи с фронтом на вью/реакте/ангуляре. Нужна кроссплатформенность, чтобы хоть с телефона можно было зайти и нажать нужную кнопку в системе.
Апи нужно, потому что будет много интеграций с другими системами, загрузка/выгрузка в 1с, не дай бог будете телефонию подключать
Внутренняя сеть решается с помощью впн сервера.
Помимо функциональных требований существуют еще технические, должен быть мониторинг, вы должны всегда знать сколько ресурсов потребляет ваш сервер, сколько данных занимает на дисках, логи и трейсы - гуглится по слову Observability, обычно не закладывается в смету, но к этим вопросам приходят рано или поздно
Что еще, ну, по функционалу тут проще, открываете презентации в популярных CRMках, смотрите, что они могут, выписываете списком и идете к заказчику, чтобы он указал галочками, что будете делать, что не будете
потом прикидываете по трудозатратам и озвучиваете сроки из которых можно понять примерную стоимость проекта. Часто одно маленькое предложение, типа того же "выгрузить данные в 1с" грозит несколькими десяткми часов работы, потому что другой отдел, с ними нужно договориться и сделать интеграцию. Или "должен быть отчет такой-то", а там как начнешь разбираться, еще 5 раз посовещаться сначала надо ))

Это тернарный оператор (не страшное слово, просто от числа «3»)

условие ? выражение1 : выражение2

Частая ошибка, открыв для себя этот чудесный синтаксис, пихать его везде, где есть условие.
Но это не замена if .. else, где нужны разные действия.
Тернарный оператор — для получения значения.

- DrawerProps.items
+ DrawerProps['items']