latteo

Половина ответа в вопросе, но дьявол в мелочах.
Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
Далее личный опыт на примере Java.
Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
Frontend-инструментов больше, backend-инструменты сложнее.

BASE=`pwd`/..
for DIR in `seq 1 100` ; do
    mkdir "$BASE/$DIR" && { find -type f | head -n 10 | xargs -d"\n" -I{} mv {} "$BASE/$DIR" ; }
done

popel-studio.com/blog/article/preloader-saita-svoi...
hello-site.ru/preloader
и т.д. по запросу в гугле - прелоадер

Спалю свою интересную фишку: лайкаю посты в ленте, мой скрипт берёт каждые 10 секунд мои закладки и раз в час добавляет в паблик группы первую/все фотографии(-ю) лайкнутых постов в паблик.
И, конечно, как же без этого, само собой прикрепляет к посту ссылку на источник :D
Да-да, плохо, но так уж получилось что ВКонтакте лишь единицы генерируют исключительно уникальный контент, остальные только берут.

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

Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на crl и ocsp?
Ответ: Корневой самоподписанный сертификат не должен содержать ссылок на crl и ocsp

А вот что касается любого (ну почти любого) подчиненного сертификата - в нем д.б. ссылка на crl. Ссылка на ocsp - опционально, по Вашему желанию или требованию информационной системы (ИС).
Соответственно, как в сертификатах подчиненных УЦ (Проекта 1, Проекта 2, VPN и т.д.) обязательно должна быть ссылка на crl. Уже не говоря о клиентских сертификатах, выпущенных УЦами Проекта 1, Проекта 2, VPN и т.д.

Ссылка на crl в сертификатах УЦов Проекта 1, Проекта 2, VPN и т.д. будет одна и та же и будет содержать список отзыва, выпускаемый Корневым УЦ. С помощтю этого СОС можно управлять сер-тами подчиненных УЦ.

В сер-тах, выпускаемых УЦами Проекта 1, Проекта 2, VPN и т.д. будет содержаться ссылка на crl, соответствующий каждый определенному УЦ и управлять отзывом сер-тов клиентов можно с каждого подчиненного УЦ, на котором сер-т этого клиента был выпущен.

Не совсем понятно, что означает фраза "получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному на УЦ CompanyName Security CA".
Судя по всему ответ "нет" - получить доступ к CompanyName Project 2 CA по сер-ту, выпущенному из под CompanyName Security CA, не получится.

Что же касается ИС, в которых используются сертификаты, то реализация функции доверия этой ИС к сер-ту целиком и полностью ложится на плечи разработчика ИС и ее архитектуры.
Самый простой способ ограничить использование сер-тов выпущенных только CompanyName Project 2 CA - это установить корневой сер-т CompanyName Project 2 CA в систему и проверять эту цепочку. При этом сер-т CompanyName Security CA в ИС должен отсутствовать

https://www.sitemaps.org/ru/protocol.html

www.w3resource.com/javascript-exercises
https://www.freecodecamp.com
rmurphey.com/blog/2016/02/13/exercises-for-js-beginners
Codewars.

https://balsamiq.com/products/mockups/ и ninjamock.com
Так же можно порисовать логику тут: https://www.draw.io/

Так же как и всегда. Либо добавить стили в head

//это во view
$this->registerCss('
body {background-color:#fff;}
');

либо как файл.

//это во view
$this->registerCssFile('path/to/myfile');

Если зависимостей много и их еще где-то в таком же наборе надо подключить, то можно создать AssetBundle, подробнее тут www.yiiframework.com/doc-2.0/guide-structure-asset...
Как правило в самом view не подключают css и js, так как при правильной верстке все должно быть виджетами, а у виджетов есть свой метод подключения зависимостей. И если есть необходимость во view прописать какой-то css, то скорее всего это ошибка глобальная в структуре.

Когда у меня возникает такое, я иду на Reverso Context
Пишешь что хочешь сказать на русском, он ищет совпадения (я так понял, что в субтитрах и книгах). Я так формирую предложения для переписки.

Немного теории + практика + теория + практика + углубленная теория + практика + практика + практика.

это значит событие вызвано юзером, а не программно т.е. это не какой-то JS скрипт пытается trigger запустить и спарсить ваш сайт например.

Можно сделать что-нибудь в таком роде:

const stream = require('stream');
const fs = require('fs');

class PercentWatcher extends stream.Duplex {
  constructor(fd) {
    super();
    this.size = fs.fstatSync(fd).size;
    this.handled = 0;
  }
  _read() {}
  _write(chunk, encoding, callback) {
    this.push(chunk);
    this.handled += chunk.length;
    console.log(`\n\n${Math.round(this.handled / this.size * 100)}%\n\n`);
    callback();
  }
}

const fd = fs.openSync('file.txt', 'r');

fs.createReadStream(null, {fd}).pipe(new PercentWatcher(fd)).pipe(process.stdout);