Атомарности переключения вообще очень сложно добиться. Есть два варианта:
1) Разорвать текущие соединения (restart), при этом будет атомарность, но клиенты получат ошибки
2) Нормально завершить текущие соединения (reload), в этом случае атомарности не будет — параллельно будут работать и старые, и новые, но клиенты ошибок не получат.
В зависимости от требований, выбирается подходящий вариант.
Что касается кофигурации, решение со ссылкой решает одну очень важную проблему — права доступа. Для изменения ссылки не требуется привелегий, достаточно прав на запись в папку с проектом. Для перезапуска же сервера требуется привелегированный доступ (читай: root), да и возможности ошибиться там намного больше. Возможность отката сохраняется.
У php-fpm есть проблемы с reload: bugs.php.net/bug.php?id=60961, поэтому в любом случае приходится искать решение уровнем выше.
Чтобы сохранить окружение целым и не давать рутовых прав CI, для нас оптимальным вариантом стало отключать ноду на балансировщике, ждать завершения процессов, обновляться, включать ноду обратно.
Все намного проще. Сценарий получения ошибки такой:
Веб-сервер смотрит в папку /var/www/htdocs
Структура папки www следующая:
$ ls -al /var/www
htdocs -> version-71928
version-59189
version-71928
Новая версия кода выкладыватется в отдельную папку, ссылка htdocs переключается на новую версию.
В коде в новой версии добавляется инклюд (новая библиотека, класс, служебный файл, любая сущность на диске). PHP разрешил путь до /var/www/htdocs в виде /var/www/version-71928 и закешировал. После переключения ссылки старый кэш будет актуален вплоть до 2 минут (по умолчанию, в зависимости от realpath_cache_ttl) и все новые файлы будут искаться в прошлой версии.
Итого: версию выложили, переключили ссылки, и около 2 минут сыпятся фаталы Unknown: Failed opening required '/var/www/htdocs/include.php'
Хуже, если старая версия удалена — фаталы будут сыпаться гуще. А в случае, когда необходимо синхронное переключение, могут возникнуть неведомые ошибки, которые никогда больше не воспроизведутся и могут принести сильную попа головную боль.
Дергать миллион раз ничего не нужно, достаточно использовать Composer Autoload :)
Любая работа может быть интересной, это вопрос личного восприятия. Я сейчас с приятной ностальгией вспоминаю то, о чем говорит XanderBass.
А что касается VDS за 5 баксов — большинство по качеству (производительности) не далеко ушли от шареда, просто повышают ЧСВ за счет роста ответственности. И приходится так же заниматься оптимизацией, придумывать способы избавиться от лишнего балласта, писать свои узкоспециализированные решения вместо использования популярных библиотек-комбайнов.
Но вот за стандарты я готов горой стоять. И за тесты. Ничто не мешает применять современные техники даже в олдскульном стиле. Тем более, что трудозатраты на написание composer.json минимальные, а тесты еще тыщу раз сыграют на руку.
Да, вселенная оптимизации сайта под дешевые хостинги и бережливых клиентов существует где-то рядом. Быстро забывается и отсутствие ssh, и пляски с загрузками мегабайтных архивов с кодом через панель управления, поскольку ftp сутками прокачивает тонну мелких файлов.
Это очень, не побоюсь этого слова, нишевая разработка с другими подходами.
SplObjectStorage, вероятно, чтобы можно было удобно detatch'ить роуты. Но совершенно очевидно, что коллекция должна быть приватная.
Напрашивается ответная статья с исправлениями всех ошибок :)
С первого взгляда изяществом не блещут :) Здоровая дура, да еще и с цепью. И, кстати, механизм должен обладать определенной жесткостью в обе стороны. У меня в квартире, например, сквозняком закрывает открытые фрамуги.
Напрашивается механизм, подобный серве с длинным эластичным элементом, который бы цеплял/толкал створку. Чтобы можно было руками окно открыть и не бояться, что серву сорвёт от порыва ветра/случайного дёрга за ручку. У нас на окнах даже фиксаторы-«гребенки» уже гнутые вхлам, потому что про них забываешь и пытаешься с силой окно закрыть (или открыть).
Хорошо, если это клон какой-нибудь «нормальной» модели. По моему опыту владения китайским багги (одна из первых HIMOTO), там больше проблем с шасси, чем удовольствия от первых поездок. Это касается и конструкции, и запчастей.
Очень хотелось увидеть какой-то изящный механизм открытия/закрытия окна. А тут даже «серво-сейвера» нет :(
Вообще, за последние лет пять, все статьи как одна: тут приколхозили, там закостыляли. С одной стороны повторить хочется, с другой рука не поднимается сопли по окнам развешивать. Да и что касается автоматизации, большинство начинаний заканчивается на миганием светодиодом люстрой в прихожей и открытием/закрытием жалюзи.
Кстати, у вас на соседнем окне не клапан ли вентиляционный? Он со своей задачей не справляется?
Статью-то прочитал. Вопрос скорее не по описанному решению, а по гугловской рекомендации избавиться от блокирующих стилей в шапке. В теории это поможет быстрее отрисовать страницу, но на практике может привести к нежелательным последствиям.
А насколько в реальной разработке удобнее подгружать CSS скриптами?
Ну то есть, следует ли брать и бежать все <link rel="stylesheet"> менять на инъекцию js'ом?
Не сильно ли изменится user-experience в этом случае? Например, заторможенная отрисовка стилей при неважном соединении. При классическом подключении стилей браузер ждет загрузки css и рендерит уже стилизованную страницу, а при асинхронном подключении css браузер сначала отрисует «голый скелет», догрузит стили, мигнет и только потом выплюнет стилизованную страницу.
А не пробовали отключать Inspections в данном файле (мужичок в правом нижнем углу)? Бывает, что файл насыщен трудноперевариваемыми конструкциями, и подвисает проверки синтаксиса и другие Inspections.
Можно еще третьей кнопкой мыши (нажатым колесом) тащить курсор. Вообще, все это легко настраивается. А найти нужное действие (и подсмотреть клавиатурное сокращение) можно по ctrl+shift+a (вроде бы во всех стандартных раскладках).
Проще всего дебажить консольные скрипты (на локальной машине с xdebug) можно так:
включаем пассивный debug-режим (Run — Start Listening For PHP Debug Connections или соответствующей кнопкой на панели)
Запускаем скрипт с аргументами: php -d xdebug.remote_enable=1 -d xdebug.remote_autostart=1 my_script.php
xdebug.remote_enable=1 можно спокойно положить в php.ini, а remote_autostart я бы не советовал — пыха будет всегда ломиться в порт, даже когда не надо.
Более «правильный» способ с указанием IDE Key приведен выше.
А чтобы отлаживать по одной кнопке, достаточно создать debug-конфигурацию и запускать её, например, во встроенном терминале. Вообще без смены контекста будет.
Поиск в окне работает не только для дерева файлов, но и вообще в практически всех панелях. Classmap, VCS, Code Coverage и т.д.
Отдельно хочется упомянуть поиск по действиям (ctrl + shift + a) — если забыл как сделать CamelCase для выделенного текста или любое другое действие.
1) Разорвать текущие соединения (restart), при этом будет атомарность, но клиенты получат ошибки
2) Нормально завершить текущие соединения (reload), в этом случае атомарности не будет — параллельно будут работать и старые, и новые, но клиенты ошибок не получат.
В зависимости от требований, выбирается подходящий вариант.
Что касается кофигурации, решение со ссылкой решает одну очень важную проблему — права доступа. Для изменения ссылки не требуется привелегий, достаточно прав на запись в папку с проектом. Для перезапуска же сервера требуется привелегированный доступ (читай: root), да и возможности ошибиться там намного больше. Возможность отката сохраняется.
У php-fpm есть проблемы с reload: bugs.php.net/bug.php?id=60961, поэтому в любом случае приходится искать решение уровнем выше.
Чтобы сохранить окружение целым и не давать рутовых прав CI, для нас оптимальным вариантом стало отключать ноду на балансировщике, ждать завершения процессов, обновляться, включать ноду обратно.
Веб-сервер смотрит в папку
/var/www/htdocsСтруктура папки www следующая:
Новая версия кода выкладыватется в отдельную папку, ссылка htdocs переключается на новую версию.
В коде в новой версии добавляется инклюд (новая библиотека, класс, служебный файл, любая сущность на диске). PHP разрешил путь до
/var/www/htdocsв виде/var/www/version-71928и закешировал. После переключения ссылки старый кэш будет актуален вплоть до 2 минут (по умолчанию, в зависимости от realpath_cache_ttl) и все новые файлы будут искаться в прошлой версии.Итого: версию выложили, переключили ссылки, и около 2 минут сыпятся фаталы
Unknown: Failed opening required '/var/www/htdocs/include.php'Хуже, если старая версия удалена — фаталы будут сыпаться гуще. А в случае, когда необходимо синхронное переключение, могут возникнуть неведомые ошибки, которые никогда больше не воспроизведутся и могут принести сильную
попаголовную боль.Дергать миллион раз ничего не нужно, достаточно использовать Composer Autoload :)
А что касается VDS за 5 баксов — большинство по качеству (производительности) не далеко ушли от шареда, просто повышают ЧСВ за счет роста ответственности. И приходится так же заниматься оптимизацией, придумывать способы избавиться от лишнего балласта, писать свои узкоспециализированные решения вместо использования популярных библиотек-комбайнов.
Но вот за стандарты я готов горой стоять. И за тесты. Ничто не мешает применять современные техники даже в олдскульном стиле. Тем более, что трудозатраты на написание composer.json минимальные, а тесты еще тыщу раз сыграют на руку.
Это очень, не побоюсь этого слова, нишевая разработка с другими подходами.
Мое личное мнение: по-быстрому и по-простому отлично работают обычные php-шаблоны с минимальной обвязкой. В остальных случаях предпочитаю twig.
Чем ваше решение лучше, например, твига?
Напрашивается ответная статья с исправлениями всех ошибок :)
Можно еще в composer.json добавить требования к php.
Напрашивается механизм, подобный серве с длинным эластичным элементом, который бы цеплял/толкал створку. Чтобы можно было руками окно открыть и не бояться, что серву сорвёт от порыва ветра/случайного дёрга за ручку. У нас на окнах даже фиксаторы-«гребенки» уже гнутые вхлам, потому что про них забываешь и пытаешься с силой окно закрыть (или открыть).
Вообще, за последние лет пять, все статьи как одна: тут приколхозили, там закостыляли. С одной стороны повторить хочется, с другой рука не поднимается сопли по окнам развешивать. Да и что касается автоматизации, большинство начинаний заканчивается на миганием
светодиодомлюстрой в прихожей и открытием/закрытием жалюзи.Кстати, у вас на соседнем окне не клапан ли вентиляционный? Он со своей задачей не справляется?
PHP вообще страшненький :(
Ну то есть, следует ли брать и бежать все
<link rel="stylesheet">менять на инъекцию js'ом?Не сильно ли изменится user-experience в этом случае? Например, заторможенная отрисовка стилей при неважном соединении. При классическом подключении стилей браузер ждет загрузки css и рендерит уже стилизованную страницу, а при асинхронном подключении css браузер сначала отрисует «голый скелет», догрузит стили, мигнет и только потом выплюнет стилизованную страницу.
php -d xdebug.remote_enable=1 -d xdebug.remote_autostart=1 my_script.phpxdebug.remote_enable=1можно спокойно положить в php.ini, а remote_autostart я бы не советовал — пыха будет всегда ломиться в порт, даже когда не надо.Более «правильный» способ с указанием IDE Key приведен выше.
А чтобы отлаживать по одной кнопке, достаточно создать debug-конфигурацию и запускать её, например, во встроенном терминале. Вообще без смены контекста будет.
Отдельно хочется упомянуть поиск по действиям (ctrl + shift + a) — если забыл как сделать CamelCase для выделенного текста или любое другое действие.