latteo

Да. Все верно.

Единственное что добавлю, пересылать токен лучше в заголовках. Причем желательно, поскольку механизм аутентификации нестандартный, в заголовке X-Authorization. Если вы решите хранить токен в куках и передавать его, это желательно должны быть http-only куки (хотя в случае JWT не обязательно) и на сервере должна быть защита от CSRF атак.

Так же поскольку у нас по сети гуляют по сути креденшелы, важно использовать SSL. Благо сегодня есть lets-encrypt что бы бесплатно получить сертификаты.

И последнее, что бы обезопасить себя еще, используйте refresh-токены. То есть наш уникальный токен который гуляет в каждом запросе будет иметь ограничение по времени жизни (скажем 5 минут) и для его обновления мы будем использовать refresh-токен. При получении refresh токена клиенту уходит новая пара токен + refresh-токен.

Таким образом у злоумышленника который перехватил токен пользователя будет окно всего в 5 минут что бы что-то сделать.

Упрощенно.

Вагрант — система управлением конфигурацией конкретной машины.
Докер — запуск изолированных процессов на машине.

Докер.
Это не виртуальная машина, а запуск изолированных процессов. Т.е., запущенный процесс думает, что он один единственный, и ничего вокруг нет. Это работает на уровне ядра Linux. Без использования виртуальных машин.

В терминологии Докера есть Images и Containers.
Image — образ, шаблон, на основе которого запускается Container.
Image строится на основе какого-либо базового образа ОС.

Container — сервис, запущенный и построенный на базе Image.

Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

Каждый из этих образов будет иметь у себя в базе какую-либо ОС. Т.е., происходит изолирование окружения, на котором работает Docker.
На базе построенных образов вы можете запускать Containers, т.е., непосредственно строить рабочее окружение. Каждый запущенный контейнер думает, что он запущен один, в образе наследуемой ОС. Но на самом деле, это всего лишь отдельный процесс, работающий на уровне ядра Linux, без виртуализации. Т.е., у вас нет накладных расходов на виртуальные машины. Изолирование контейнеров выполняется на уровне ядра.

При всем этом, ваша базовая система остается чиста от устанавливаемых пакетов, свободна от неразберихи с библиотеками, версиями и т.п.

Оба инструмента хороши. Но у каждого свое назначение.

Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.

Вы можете поставить срабатывание события для кнопки, несмотря на то, что там уже имеется js-код. Просто разделите их точкой с запятой. Получится таким образом:

<button class="btn btn-smal btn-block btn-success" type="button" onclick="order_product(1,'Фотошторы Волшебный лес');yaCounter37700435.reachGoal('ORDER'); return true;">Купить</button>

Потому что вы абстрагированы от управления запросами.

Если нужно обновить гридвью после сабмита формы, тогда можно просто перезагрузить PJAX-контейнер, например:

$('#driverPjax').on('pjax:end',   function() { 
	$.pjax.reload({
		container : '#notes', timeout: '5000',
	});		
});

Если же нужно обновлять гридвью непосредственно после выбора из выпадающего списка, тогда функцию перезагрузки контейнера нужно повесить на соответствующее событие выпадающего списка, например:

onChange = "$.pjax.reload({container : '#notes', timeout: '5000'});"

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

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

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

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

Что я сделал: дал понять, что опыт для меня выше денег. Написал потенциальным работодателям письмо, мол возьмите меня, я умею вот это {....}. для меня главное - опыт. Денег я не жду. но, если предложите - не откажусь.

Пусть не первый, но 2ой или 3ий заинтересуется по 2м причинам:

1. Всегда есть задачи, которые сделать может и джун, но его нет и этим занимаются более дорогие специалисты
   
2. Всегда есть задачи, которые нужно сделать, но они не срочные (как правило, это какие-то внутренние задачи). Их тоже можно поручить джуну, чтобы он постепенно их решал
   

Итог: работаю с декабря разработчиком

Возможно у вас включен кеш для RBAC, поищите строку "'authManager' => [" в проекте, если имеет подобный вид:

'authManager' => [
    'class' => 'yii\rbac\DbManager',
    'cache' => 'cache'
],

Значит кеш RBAC включен, удалите на деве 'cache' => 'cache' и будет норм или инвалидируйте кеш:
Yii::$app->authManager->invalidateCache();

Только что создал паблик, у него был айди 121 миллион что-то там. При помощи groups.getById за раз можно получить 500 групп. Благодаря execute за запрос можно получить 25*500, т.е. 12 500 групп. 3 запроса в секунду - 3*12500 = 37500 групп в секунду. Всего 122 миллиона групп - 122 000 000 делим на 37 500 = 3253 секунды или около часа работы. А если разделить на несколько пользователей, то вообще не вижу проблемы спарсить весь вк.

Я смотрю адрес нужного по ipv4 сайта здесь chrome://net-internals/#dns
И далее заношу его диапазон /32 сюда: superuser.com/questions/436574/ipv4-vs-ipv6-priori...
Для линукса https://version6.ru/deprefer-ipv6
Ну и так до кучи drtr0jan.livejournal.com/229199.html
Для хрома поставил плагин ipvfoo, чтобы наблюдать через что зашел.

Это помогло в частности гонять ютуб через ipv4, где он быстрее.

Используются в проектах в основном по 4-5 штук максимум:

Raw HTML
Duplicator
Reveal IDs
Tab Override
Cyr to Lat enhanced
Custom Post Type UI
Custom Post Type Permalinks (taxonomy also)
Intuitive Custom Post Order
Advanced Custom Fields
Advanced Custom Fields: Repeater Field
Advanced Custom Fields: Options Page
Breadcrumb NavXT
Remove Category URL
TinyMCE Advanced
Easy FancyBox
Plugin Organizer
MinQueue
BJ Lazy Load
Device Theme Switcher
Contact Form 7
Contact Form 7 Redirect
Contact Form DB
TablePress
Easy Watermark
Regenerate Thumbnails
WP-PostViews
Infinite-Scroll
Hide-n-Disable-comment-url-field
Шорткоды
Откл. комментарии
Menu Icons
UpdraftPlus - Backup/Restore
WP Super Cache
WP-Polls
Yoast WordPress SEO и All in one Seo
Yet Another Related Posts Plugin

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

1) nginx-proxy
2) копируйте исходники в образ (в dockerfile), собирайте либо локально либо на CI-сервере эти образы и пушьте их в docker/distribution (либо платный docker-hub либо разверните свой, это с докером делается за минут 10).
3) Прямо в контейнере с PHP. Либо заведите отдельный контейнер для php-cli и зачедите отдельный контейнер для исходников, и через volumes_from расшарьте между ними. Вариант с cron на хосте тоже достоен существования, но это не ок в большинстве случаев.
4) обновлять базовый образ. А там уж как организуетесь.
5) Можно, смотрим пункт 2.
6) Вообще тут можно схитрить. Вы можете же хранить зависимости прямо в репозитории, в смысле коммитить вендоры. Но вы этого не делаете. На момент когда запускается docker build ваших образов, все зависимости уже должны поставиться. И для каждого из перечисленных вами средств разработки уже есть свой контейнер, готовый. Берем и юзаем.
7) как мы выяснили в пункте 6 - композера на проде быть не должно. вообще как, вы оттещенный образ со стэйджинга должны просто "мувать" на продакшен. В этом плане риски при релизе минимальны.
8) тут опять же по разному. Мне удобнее прямо из контейнера коннектиться например в sentry или graylog и скидывать туда логи. Ну или мы должны пихать логи в stdout/stderr контейнера и далее агрегировать их снаружи, тут так же есть куча вариантов.
9) все это отдельные контейнеры, все это вместе связывается башем и docker-compose. Все это разварачивается либо через docker-machine и CI либо просто через CI. Docker-machine будет "удобным" только с версии 0.7 или 0.8.