Думаю было бы лучше из этих файлов сделать модуль который доавбляет команды в Magento CLI. Тогда можно сразу использовать с помощью php bin/magento
Плохое решение. Скрипты из статья, насколько я понял, выполняют развертывание приложения и настройку окружения. Magento CLI работает с развернутым приложением.
Я про работу с инфраструктурным уровнем не в тесте, а в самом тестируемом модуле. Если модуль регистрации должен отправлять нотификацию в виде email`а, то не думаю, что при запуске вашего теста должны уходить письма, скорее вы используете в своем модуле сервис из инфраструктуры, который при unit тестировании надо замокать и ожидать, что метод отправки будет вызван. Так же схема и для базы данных.
Файлы копятся, база обрастает кучей мусора и в системе появляются толпы фейковых пользователей. Старайтесь сохраняйте в чистоте не только своё рабочее место, но и рабочее окружение.
Неужели вы работаете с БД, файловой системой напрямую в своем тестируемом модуле? Непонятна ситуация, когда в базе появляются толпы фейковых юзеров. Если они появляются, значит вы тестируете модуль создания/регистрации пользователей, а не модуль для работы с базой данных. Почему тогда не использовать мок низкоуровнего модуля?
Не совсем понятен воркфлоу в ситуации, когда правят тесты сами тестировщики.
Правильно ли я понимаю, что разработчик не прогоняет тесты, этим занимается тестер, попутно определяя тест упал, условно, из-за изменений в верстке либо из-за бага? Или разработчик фиксит тесты упавшие по багам, а требующие апдейта тестов падения оставляет тестировщику?
И поскольку Вы пишите, что ранее тесты фиксились от релиза до следующего релиза, то в продакшен код попадал с красными тестами (возможно неработающим функционалом)?
Помимо вышеперечисленных полей, в таблицу было добавлено новое – код ошибки. Этот код формируется на основе трейса упавшего теста. Например, в задаче А тест упал на строке 74, где он вызвал строку 85, где был вызван UI-класс на строке 15. Почему бы нам не склеить и не записать эту информацию: 748515?
line 1 -> line 2 -> line 3 = 123
line 12 -> line 3 = 123
может разделители? или такое опущено за маловероятностью?)
я возможно упустил один абзац, либо он был добавлен
клиент электронной почты покажет ссылку с возможностью клика
Поскольку URL-адрес отображается после доставки, шлюз безопасности электронной почты не может найти и проверить вредоносный url, поскольку на момент доставки его нет.
я о том, что вот эти два предложения вместе несовместимы, тут обязательно оговорка, что урл будет некликабельным(составлен из отдельных символов-элементов) и только тогда его пропустит «шлюз безопасности».
Поскольку URL-адрес отображается после доставки, шлюз безопасности электронной почты не может найти и проверить вредоносный url, поскольку на момент доставки его нет. Для этого потребуется интерпретация CSS файлов, а это выходит за рамки функциональности существующих систем безопасности электронной почты.
С текстом все ясно, а вот про ссылки не совсем.
Есть возможность средствами css изменить атрибут элемента (ссылка в данном случае)?
Насколько я понял, на момент доставки урл уже должен присутствовать в письме, только меняются его настройки видимости. Следовательно спам фильтры определят вредоносный адрес.
Промахнулся
Это у меня наверное травма, что, при виде репозитория такого формата в Magento2, перед глазами появляется новое системное поле в бд(is_notification_sended), которое добавляется в DTO интерфейс и уже доступно к сохранению через репозиторий (или может сетаться и сохраняться эксплуатируя имплементацию дто через AbstractModel с магическими сеттерами).
Для примера SourceInterface::setEnabled, если возникнет требование выполнения каких-либо бизнес-процессов по отключению/включению источника, то как в данном модуле это будет разруливаться? Наверное на уровне репозитория сравнение current/new field value.
Понятно, что единые подходы на всех слоях системы способствуют скорости и приятностям в разработке, но по-хорошему тот же круд-интерфейс в сторонней системе может быть заменен на CQ и уже ему на уровне операционного слоя предется мапить все команды на круд-апишки.
По вопросу гридов, в Magento2 насколько я видел дата провайдеры гридов не работают с репозиториями, они, пропуская слой репозитория, работают напрямую с коллекциями (сортинг, фильтры, массэкшены). Не тот ли это SmartUI, который Эванс называет антипаттерном для применения в контексте DDD?
Thx
Спасибо за статью и пояснения. Для меня, который все время видел только результат каких-то решений (релизы Magento), интересно понять что стоит за конкретными решениями и направление развития системы. Продолжайте, получается круто.
Мы анализируем какие зависимости между модулями Magento использует внутри себя. А также мы анализируем какие зависимости используются экстеншенами на Marketplace (non api dependency). И если зависимости валидны, т.е. такой результат нельзя получить используя текущие API модуля — мы помечаем сущность как api
как устроен этот процесс? я так понимаю зависимости вы собираете в автоматическом режиме, а что с определением валидности?
Во время разработки часто встречаются дырявые абстракции, из-за чего приходится юзать приватные части модулей. Причем простым просмотром кода обычно не определить, что использование приватных моделей вместо API это вынужденная необходимость, а не недостаток квалификации разработчика.
Как вы определяете (на основе данных с маркетплейса) сущности, которые необходимо пометить тегом api?
извиняюсь, упустил в ридми File->Import Settings->Choose «snakeskin.jar»
но в релизы добавить не помешало бы, чтобы в один клик скачать, не клонируя репозиторий (View Raw не считаю за правильный метод)
справедливости ради в джарке удобочитаемые xml исходники конфигов которые можно было бы и версионировать ;)
думаю будет удобнее в репозитории хранить исходники плагина, а джарку можно загружать во вкладке releases, так в ваш плагин смогут контрибьютить
извиняюсь, если скопитанил :)
1. да, механизм безусловно работает, но данные сохраняются в дефолтном неймспейсе, из-за чего может быть конфликт с другими модулями
2. регистр очень близок к глобальным переменным и лучше избавляться от его использования, изменив архитектуру.
Например на контроллере вью какой-то энтити вместо того, чтобы в экшене ее загрузить, засеттать в регистр и вытащить из регистра в блоке (или темлейте) можно загрузить энтити, взять из лейаута блок для отогбаражения, засеттать в него эту энтити, не прибегая к регистру. Таким образом если у вас появится потребность вывести на странице 10 таких же блоков с разными сущностями, то вам не напо попеременно в регистр подсовывать разные сущности, а всего-то сетать разные сущности в один блок и его рендерить
В Вашем примере с сессиями данные засетаются в дефолтный неймспейс, что не совсем правильно.
Более прикладной пример был бы
— с использованием существующих менеджеров (Checkout, Customer...)
— либо декларацией виртуального типа стореджа черезе di.xml с кастомным неймспейсом и подкидывание этого стореджа вашему session Manager `у и уже использование его в коде
нет, дело в другом. у контакта есть ограничение в 3 запроса к апи в секунду, через метод execute вы в один запрос можете включить 20 вызовов апи, таким образом увеличив скорость на долгих задачах примерно в 20 раз
делал такую же штуку. По видео видно, что работает получение общих друзей очень медленно. Я использовал написанный на VKScript скрипт через метод execute, что позволило поднять скорость получения общих друзей в ~20 раз. Будете допиливать свою версию — подумайте над этим :)
согласен, количество статей постоянно увеличивается и понятно что графики использования слова в 2006м и 2013м будут существенно различаться, даже если не было никакого всплеска популярности языка/технологии
github.com/magento/magento2devbox-web
github.com/paliarush/magento2-vagrant-for-developers
Плохое решение. Скрипты из статья, насколько я понял, выполняют развертывание приложения и настройку окружения. Magento CLI работает с развернутым приложением.
Неужели вы работаете с БД, файловой системой напрямую в своем тестируемом модуле? Непонятна ситуация, когда в базе появляются толпы фейковых юзеров. Если они появляются, значит вы тестируете модуль создания/регистрации пользователей, а не модуль для работы с базой данных. Почему тогда не использовать мок низкоуровнего модуля?
Правильно ли я понимаю, что разработчик не прогоняет тесты, этим занимается тестер, попутно определяя тест упал, условно, из-за изменений в верстке либо из-за бага? Или разработчик фиксит тесты упавшие по багам, а требующие апдейта тестов падения оставляет тестировщику?
И поскольку Вы пишите, что ранее тесты фиксились от релиза до следующего релиза, то в продакшен код попадал с красными тестами (возможно неработающим функционалом)?
line 1 -> line 2 -> line 3 = 123
line 12 -> line 3 = 123
может разделители? или такое опущено за маловероятностью?)
я о том, что вот эти два предложения вместе несовместимы, тут обязательно оговорка, что урл будет некликабельным(составлен из отдельных символов-элементов) и только тогда его пропустит «шлюз безопасности».
С текстом все ясно, а вот про ссылки не совсем.
Есть возможность средствами css изменить атрибут элемента (ссылка в данном случае)?
Насколько я понял, на момент доставки урл уже должен присутствовать в письме, только меняются его настройки видимости. Следовательно спам фильтры определят вредоносный адрес.
Это у меня наверное травма, что, при виде репозитория такого формата в Magento2, перед глазами появляется новое системное поле в бд(is_notification_sended), которое добавляется в DTO интерфейс и уже доступно к сохранению через репозиторий (или может сетаться и сохраняться эксплуатируя имплементацию дто через AbstractModel с магическими сеттерами).
Для примера SourceInterface::setEnabled, если возникнет требование выполнения каких-либо бизнес-процессов по отключению/включению источника, то как в данном модуле это будет разруливаться? Наверное на уровне репозитория сравнение current/new field value.
Понятно, что единые подходы на всех слоях системы способствуют скорости и приятностям в разработке, но по-хорошему тот же круд-интерфейс в сторонней системе может быть заменен на CQ и уже ему на уровне операционного слоя предется мапить все команды на круд-апишки.
По вопросу гридов, в Magento2 насколько я видел дата провайдеры гридов не работают с репозиториями, они, пропуская слой репозитория, работают напрямую с коллекциями (сортинг, фильтры, массэкшены). Не тот ли это SmartUI, который Эванс называет антипаттерном для применения в контексте DDD?
как устроен этот процесс? я так понимаю зависимости вы собираете в автоматическом режиме, а что с определением валидности?
Во время разработки часто встречаются дырявые абстракции, из-за чего приходится юзать приватные части модулей. Причем простым просмотром кода обычно не определить, что использование приватных моделей вместо API это вынужденная необходимость, а не недостаток квалификации разработчика.
Как вы определяете (на основе данных с маркетплейса) сущности, которые необходимо пометить тегом api?
но в релизы добавить не помешало бы, чтобы в один клик скачать, не клонируя репозиторий (View Raw не считаю за правильный метод)
справедливости ради в джарке удобочитаемые xml исходники конфигов которые можно было бы и версионировать ;)
извиняюсь, если скопитанил :)
2. регистр очень близок к глобальным переменным и лучше избавляться от его использования, изменив архитектуру.
Например на контроллере вью какой-то энтити вместо того, чтобы в экшене ее загрузить, засеттать в регистр и вытащить из регистра в блоке (или темлейте) можно загрузить энтити, взять из лейаута блок для отогбаражения, засеттать в него эту энтити, не прибегая к регистру. Таким образом если у вас появится потребность вывести на странице 10 таких же блоков с разными сущностями, то вам не напо попеременно в регистр подсовывать разные сущности, а всего-то сетать разные сущности в один блок и его рендерить
Более прикладной пример был бы
— с использованием существующих менеджеров (Checkout, Customer...)
— либо декларацией виртуального типа стореджа черезе di.xml с кастомным неймспейсом и подкидывание этого стореджа вашему session Manager `у и уже использование его в коде
Например:
И по регистру, если вы его используете, то, возможно, стоит посмотреть на код и подумать «Возможно здесь что-то не так?»