Saboteur

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

> Я могу себе представить требования к backend, потому что backend сложнее.
Нет

> Там нужно учитывать количество пользователей, контролировать нагрузку, управлять памятью.
Во фронте тоже нужно это учитывать

> Там разного рода масштабирования, linux и sql.
Во фронте много js, json, xml, CS, много зрелых технологий на изучение которых требуется много времении сил, много новых технологий.

> А вот требования к frontend разработчику высокого уровня мне представить сложно. Тут один достаточно простой (по сравнению) ЯП, приходящие модные технологии вроде babel, webpack и TypeScript, которые еще сильнее упрощают работу и какой-нибудь фреймворк.
А как же webassembly, html5, RMTP, и другое медиа? Флэш сейчас уступил место JS и HTML5, но это только расширяет возможности использования.

> Есть особенности работы браузеров, но их не так много и они по большей части решаются тем же babel.
По большей, но мы же говорим про выдающегося, который может например написать сам babel?

> Фронтенд не масштабируется, не реплицируется.
Так можно говорить, если переложить всю работу на бэкенд. А правильно - грамотно распределять что делает фронтенд, что делает бэкенд и оптимизировать передачу данных. Это оба специалиста должны сотрудничать.

> В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%, что все работает на всех браузерах и на всех утройствах. Здесь не может быть ситуации, когда пришло слишком много пользователей или память на сервере закончилась.
Ну как это не может? Вы знаете все устройства, где запустится ваше вебприложение? А если на смарттв? А если на нонейм планшете? А если это голосовой чат в веб-приложении на 50 человек?

> Тут нет мониторинг систем.
Зато есть понимание метрик, их сбора, и отправки на бэкенд или куда-то еще?

Вдобавок фронтенд, в отличие от бэкенда, ОЧЕНЬ быстро прогрессировал за последние несколько лет. Настолько быстро, что хороших специалистов крайне сложно найти - они просто не успевают изучить все, что на них падает. Бэкенд постабильнее, там печатные книги успевают выйти в 10-м издании.

Приложить усилия. Нельзя выучить английский, просто заплатив куда-то денег.
Поэтому выделять нужно не просот 1.5к в месяца, а много времени и УСИЛИЙ, которые реально тратятся на изучение, а не просто полистать учебник полтора часа, не вникая в смысл.

Советую воспользоваться поиском и найти уже готовые ответы вроде
* онлайн-ресурсов (lingualeo и др игровые варианты для регулярных занятий).
* Посещение курсов (любых, где есть преподаватель и общение)
* Регулярный просмотр видео на английском

Опять же, если у вас сейчас уровень elementary, то 6 месяцев может оказаться недостаточно, если вы не живете в стране с носителями.

1.5 месяца очень мало.

Видимо вы принялись за питон, вообще не имея представления о том, как в принципе работает интернет и сайты.
Почитайте немного про HTML/HTTP/базовое понимание о сетях, что такое web API.

Либо решайте задачи не для веб, а для простеньких консольных приложений.

Знание чисто языка программирования - ничто без понимания, как работает система.

Нет такого успешного опыта.

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

Поэтому в случае чего - просто поднимаете приложение в том же датацентре, где сейчас мастер.

А вы уверены, что проблема именно в CPU, а не в скорости считывания файла с диска?
Особенно учитывая, что файлов очень много?

GPU достаточно специфичная вещь, смысл ее применять для подобной операции не слишком виден.

А как вы себе представляете сканировать "неизвестные ранее различные баги" в различном ПО?
Такого не существует, поэтому и не нашли.

Сканировать ПО можно на предмет известных багов. Например вы знаете о баге в популярном CMS или форумном движке. Тогда можно попробовать написать сканер, который будет бегать по списку сайтов с этим CMS или движком и сканировать их на предмет наличия этого конкретного бага (или списков багов).

Так можно писать сканер известных уязвимостей к различным ресурсам.

Анализ ПО можно также проводить по исходному коду, по использованию определенной версии библиотек.

Но все сводится к тому, что конкретные дыры вы должны заранее знать.

А вы кто по отношению к задаче - исполнитель? тимлид? менеджер? фрилансер?

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

Что значит "реализовать данный ip адрес"?

Тут указана небольшая подсеть /23 (512 адресов), возможно какой-то реальной организации. А может быть даже лажа админа 188.82.23.12, который вместо локальной подсети 172.16.1 прописал реальную 172.1.1

xenforo.com
invisionboard.com
vbulletin.com
phpbb.com

https://habr.com/ru/post/320082/

Если IP не меняется, то достаточно будет сохранить ключи хоста (/etc/ssh/ssh_host_*) и собственно ключи пользователей, под которыми идет ваша репликация.

Потому что программа на С++ выполняется непосредственно в операционной системе, а программа на java выполняется в java машине.