Касательно «Phpdbg намного быстрее Xdebug для подсчета покрытия» — есть сомнения, что результаты покрытия совпадают, о чем предупреждает сам автор Xdebug. Стоит отнестись с осторожностью:
В OS X использование mounted volumes в Docker for Mac крайне ресурсоемко — создание и изменение нескольких сотен файлов в такой директории загружает процессор на 100% на несколько секунд. Например, та же Magento 2 создает сотни симлинков на файлы или копирует сами файлы при первом рендеренге страницы в некоторых режимах, не суть. По сравнению с Docker Machine + docker-machine-nfs в результате общая производительность проекта меньше из-за того, что большая часть нагрузки на CPU идет из-за файловых операций. Вот такие грустные дела на маке с докером.
Ну, по идее, он как минимум будет ходить кругами вокруг полюса, потому что на него всегда будет указывать стрелка (условно). Он будет смещаться к востоку, а стрелка будет возвращать его ближе к северу, так и будет в районе полюса гулять
В реальной жизни прирост получается около 20%, проверено примерно на 5 проектах — нигде в два раза лучше не стало. Всему виной кастомный код расширений, который сам по себе не очень эффективен — ну, знаете, где коллекцию фильтруют на стороне PHP, а не через фильтры SQL или делают лоад модельки в цикле. Может быть на чистой Magento и можно на определенных запросах получить буст в 100% скорости, но на рабочем непустом проекте — очень вряд ли, хотя надежда всегда есть =)
Эта оценка верна только для первого запроса к приложению — в Magento 2 из коробки есть Varnish (и он действительно работает), что де-факто делает систему более производительной в большинстве случаев чем Magento 1. А в production mode фронт Magento 2 работает весьма шустро, а если добавить возможность масштабирования чекаута в версии ЕЕ, то даже этот проблемный участок можно похвалить. На данный момент сравнение с веткой 2.0.х не корректно, потому что между 2.0 и 2.1 приличная пропасть, в последней 2.1 все гораздо лучше и быстрее.
Docker — это два компонента, сам демон (dockerd) и клиент (docker). Клиент по дефолту работает через локальный сокет. В контейнере dind есть и демон и клиент — демон стартует как единственный процесс образа, в общем, как и должно быть.
Если зайти в запущенный dind контейнер и выполнить там какую-то команду через клиент, к примеру, docker ps — то клиент через локальный сокет внутри контейнера подключится к демону и будет с ним взаимодействовать — т.е. ps покажет контейнеры, запущенные внутри контейнера.
Если нужно, чтобы клиент внутри контейнера взаимодействовал с докер демоном хост машины, то внутрь контейнера нужно подключить сокет демона с хост машины как volume, например, запустить контейнер с параметром -v /var/run/docker.sock:/var/run/docker-on-host.sock. Затем внутри контейнера уже можно будет работать с этим сокетом как обычно. В случае использования клиента docker нужно указывать путь к кастомному сокету в параметре -H, например, команда docker -H unix:///var/run/docker-on-host.sock ps выполненная внутри такого контейнера будет взаимодействовать с демоном с хост машины — т.е. ps покажет контейнеры, запущенные не внутри контейнера, а в демоне докера на хосте.
То же самое с docker run — контейнер будет создан в том демоне, сокет которого будет использовать docker клиент. (или не сокет, а IP и порт, смотрите описание параметра -H клиента docker).
Для запуска докера в докере просто нужен контейнер с докером, запущенный в привилегированном режиме (--privileged): https://hub.docker.com/_/docker/
Отлично работает в CI для простых сценариев. Для экономии времени (хотя и в угоду небольшим рискам) объявляем /var/lib/docker как volume, чтобы кеш образов, скачанных при работе dind (docker-in-docker) сохранялся между запусками контейнера. Так работает Gitlab CI (один из режимов).
Пробрасывать сокет внешнего докера в контейнер нужно, например, для работы какого-то сервиса с вашим внешним же докером — например, https://github.com/chadoe/docker-cleanup-volumes или https://github.com/jwilder/docker-gen
Dockerfile это не более чем сценарий, по которому образ будет собран. Все хорошо, когда образ состоит только из условно локальных файлов, но когда какой-то пакет ставится извне, то в какой-то момент после пересборки образ уже не будет работать как должен. Или же, например, nginx конфиг будет примонтирован в образ, чтобы сделать его хоть сколько-то полезным — с этого момента поведение nginx может измениться и он либо не на том порту запустится, либо не тот ответ, что нужно будет отдавать.
Таким образом, можно не только тестировать образ после каждой пересборки (например, push в gitlab, запуск CI для билда образа, базовые тесты и push в docker registry), но и тестировать образ в рамках како-то проекта. Мне видится такой сценарий и особенно полезным применением как раз было бы тестирование в рамках Gitlab CI после билда образа.
по рукам сразу нужно линейкой давать. load моделей в шаблонах это очень грязно.
Неплохо помогают еще:
хранение кеша в redis, а не в файлах
добавление в свои блоки cache tag и cache lifetime
fullpage кеш как модуль или в виде Varnish
переход на более новую версию PHP
включение PHP opcache или apc
аудит обсерверов на самые частые действия и сужение зоны их вызова (например, бывает, что обсервер стоит слишком рано и ловит много generic событий и фильтрует их уже в обработчике)
А как же быть с фокусом? Я, конечно, все понимаю, но TAB никто не отменял — иногда проще и быстрее доклацать до инпута табом, если постоянно пользуешься страницей.
Наверное, было бы лучше не выкладывать полные листинги файлов, когда в них поэтапно дабвляются по одной-две строчки, а показывать только измененные места
* */1 * * * php… — это ведь раз в час, а не каждую минуту. как предлагает Magento
«Слушателей декларируют в config.xml. И там есть 3 варианта: global, admin, frontend.» — adminhtml, не admin
public function siteblocks_clear_cache() — camelCase для названий методов
Это замечания общего плана, не к конкретной реализации. Также, может лучше не писать, например, «можно сделать так, но это не рекомендуется» — большая проблема Magento в том, что одно и то же можно сделать разными способами, а правильный из них (наиболее правильный) только один. M2 в этом плане чуть лучше, там легче проверить эти практики.
Тяжело, особенно с таким форматированием примеров.
Поговорим о codePool. Всего их 3: local, community, core (и enterprise в Enterprise версии Magento).
enterprise — такого пула нет, есть namespace в core, которые называется Enterprise
Простите, но делать
Создадим модель Block.
это то еще запутывание читателя.
Указанный «альтернативный способ создания таблицы» как раз является основным и наиболее правильным, начиная с Magento 1.6 где-то, что было очень давно.
Роутеры лучше добавлять «after», а не «before». Вы же расширяете функциональность, а не меняете.
И такого еще много =( ваша статья хорошему не научит, особенно при таком размере. Magento большая и сложная система, уместить все в одну статью просто невозможно. А сделать все правильно без хорошего опыта еще сложнее. Набирайтесь опыта, следуйте best practices и только потом учите других.
Да, конечно, особенно если «программист знал, что время пробуждения сравнимо со временем нахождения клапана в открытом состоянии». В таких проектах, где хард и софт должны объединиться в готовое устройство, и эти части не разрабатываются на условном аутсорсе по сухим спецификациям, члены команды с разным профилем обычно проявляют интерес к соседним областям знаний, чтобы поменьше проблем потом вылезло. Да и расширить свой кругозор никогда лишним не бывает.
Получается, что проблема не в самом разделении труда, а в отсутствии конкретного опыта у членов команды, которые, в итоге, прошли тернистый путь в решении определенной задачи и присущих ей проблем. Хотя слабее всего тут выглядит программист, который «рассчитывал, что задержки приведут лишь к равномерному смещению момента». Странно слышать о том, что программист на что-то подобное рассчитывал при работе с устройством, ключевая функция которого зависит от подобных допущений.
hackernoon.com/generating-code-coverage-with-phpunite-and-phpdbg-4d20347ffb45
Если зайти в запущенный dind контейнер и выполнить там какую-то команду через клиент, к примеру, docker ps — то клиент через локальный сокет внутри контейнера подключится к демону и будет с ним взаимодействовать — т.е. ps покажет контейнеры, запущенные внутри контейнера.
Если нужно, чтобы клиент внутри контейнера взаимодействовал с докер демоном хост машины, то внутрь контейнера нужно подключить сокет демона с хост машины как volume, например, запустить контейнер с параметром -v /var/run/docker.sock:/var/run/docker-on-host.sock. Затем внутри контейнера уже можно будет работать с этим сокетом как обычно. В случае использования клиента docker нужно указывать путь к кастомному сокету в параметре -H, например, команда docker -H unix:///var/run/docker-on-host.sock ps выполненная внутри такого контейнера будет взаимодействовать с демоном с хост машины — т.е. ps покажет контейнеры, запущенные не внутри контейнера, а в демоне докера на хосте.
То же самое с docker run — контейнер будет создан в том демоне, сокет которого будет использовать docker клиент. (или не сокет, а IP и порт, смотрите описание параметра -H клиента docker).
Отлично работает в CI для простых сценариев. Для экономии времени (хотя и в угоду небольшим рискам) объявляем /var/lib/docker как volume, чтобы кеш образов, скачанных при работе dind (docker-in-docker) сохранялся между запусками контейнера. Так работает Gitlab CI (один из режимов).
Пробрасывать сокет внешнего докера в контейнер нужно, например, для работы какого-то сервиса с вашим внешним же докером — например, https://github.com/chadoe/docker-cleanup-volumes или https://github.com/jwilder/docker-gen
Таким образом, можно не только тестировать образ после каждой пересборки (например, push в gitlab, запуск CI для билда образа, базовые тесты и push в docker registry), но и тестировать образ в рамках како-то проекта. Мне видится такой сценарий и особенно полезным применением как раз было бы тестирование в рамках Gitlab CI после билда образа.
С шаблонами понятно, за по рукам сразу нужно линейкой давать. load моделей в шаблонах это очень грязно.
Неплохо помогают еще:
Из других замечаний:
Это замечания общего плана, не к конкретной реализации. Также, может лучше не писать, например, «можно сделать так, но это не рекомендуется» — большая проблема Magento в том, что одно и то же можно сделать разными способами, а правильный из них (наиболее правильный) только один. M2 в этом плане чуть лучше, там легче проверить эти практики.
Спасибо.
enterprise — такого пула нет, есть namespace в core, которые называется Enterprise
Простите, но делать
это то еще запутывание читателя.
Указанный «альтернативный способ создания таблицы» как раз является основным и наиболее правильным, начиная с Magento 1.6 где-то, что было очень давно.
Роутеры лучше добавлять «after», а не «before». Вы же расширяете функциональность, а не меняете.
И такого еще много =( ваша статья хорошему не научит, особенно при таком размере. Magento большая и сложная система, уместить все в одну статью просто невозможно. А сделать все правильно без хорошего опыта еще сложнее. Набирайтесь опыта, следуйте best practices и только потом учите других.
Спасибо)