IMHO, в наше стремительно летящее время приложения должны разрабатываться в том виде, в каком девелоперу удобно их создавать и изменять (второе даже важнее первого). И если девелоперу удобнее создавать и изменять (второе важнее) приложение с использованием JS — он будет это делать с использованием JS. Более того, этого будет требовать сам заказчик разработки. Ну а пользователи… 80% пользователей приложения проапргрейдятся, 20% будут выкинуты на обочину курить бамбук.
Я не имею в виду, что JS «захватит мир», я имею в виду, что «одноядерный 32-битный Pentium 4 Northwood» это если и не 20%, то уже очень близко к нему.
У меня были проблемы с запуском скриптов на post-install'е (вернее, результатом их работы, сейчас уже не помню, что именно), пришлось вынестись в отдельный файл, запускаемый «ручками». Я в этом примере поэтому сразу в отдельный скрипт и вынесся. Если будет работать с post-install — так даже лучше будет, минус одна ручная команда. При реальной разработке модуля мне иногда приходится убивать базу и разворачивать с нуля, поэтому отдельным скриптом удобнее было.
К сожалению, я, имея дело с Magento, пока не сталкивался с использованием Phing'а для развертывания web-приложений на базе этой платформы. Это не значит, что этого нет, это значит, что я не сталкивался. Судя по всему, вы тоже. Возможно, кто-то из читающих статью сталкивался — было бы любопытно взглянуть на.
// тесты
LoginService.setForTest(new MockLoginService()); // разве эта операция не дает возможность подменить настоящий LoginService на мок?
AdminDashboard adminDashboard = new AdminDashboard();
assertTrue(adminDashboard.isAuthenticatedAdminUser(user));
// нет способа подменить LoginService, будет использован настоящий
// жизнь боль
Это все дело на уровне PHP-кода отрабатывает, там нет зависимости от web-сервера. У нас приложения и под nginx разворачиваются, и под apache'м — логирование работает в обоих случаях.
Есть подобный web-интерфейс на python'е — pypi.python.org/pypi/damvitool/0.1.2 Работает через SQLAlchemy, поэтому может цепляться ко всему, к чему цепляется SQLAlchemy. Есть также github.com/jeffknupp/sandman, тоже работает через SQLAlchemy, но уже за деньги.
Второй день проблемы с работой домена, который зарегистрирован через GoDaddy. Их DNS не возвращает IP для нашего домена. Для mail-хоста возвращает, а для самого домена — нет. В web-интерфейсе GoDaddy вижу, что IP-шники указаны — но DNS'ом (ns69.domaincontrol.com) не возвращаются! Звонили в support, там сказали, что у них запарка — тысячи доменов обрабатываются, и протолкнуть ручками наш домен они не могут. Не в этот раз, говорят.
Почему я сюда об этом постанул? А вот что-то сразу вспомнилась эта статья, вот и постанул.
Спасибо за статью, присматриваюсь краем глаза к этой теме, а тут вот. Сразу полез в пример для нетерпеливых и вдруг не обнаружил trace'а запросов между браузером и сервером. Я в WebSoсket'ах не копенгаген, но при разработке web-приложений мне очень полезна бывает информация о том, что за данные ходят между клиентом и сервером, ходят ли вообще, а если ходят, то как выглядят.
Увидел ничего, испугался и полез для проверки на www.websocket.org/echo.html — там меня успокоили тем, что trace обнаружился. В связи с чем вопрос — простое демо работает, как и задумывалось или не совсем? Потому что ответ «I'm delayed 2 seconds» я получаю, а вот в логах этого не вижу. Раз в минуту браузер отправляет запрос на сервер:
Нашел в интернетах, как создавать собственные пакеты с Magento Core — github.com/WeareJH/magento-skeleton/wiki/Creating-a-Core-Package Т.е., если нужно разворачивать свой модуль на EE-платформе, то создается соответствующий модуль, который и используется вместо
Я об этом не знал, поэтому до сих пор разрабатываю модули на рабочей станции под Win7 :) Да и последний production-сервер под Windows мы убрали буквально пару месяцев назад — мигрировали на linux'овый. Версия 1.9.0.1 CE вполне добротно стояла под wind'ой. Посмотрел системные требования — действительно, минимум с ноября 2013 года указана платформа Linux x86, x86-64. Ну мы, по крайней мере, не сталкивались с проблемами, вызванными тем, что Magento была развернута в win-среде. Там разворачивались одни из первых наших проектов (2-3 года назад), потом начали разворачивать на linux-серверах. Хотя разработка, как я уже отметил, идет на рабочих станциях под Windows.
Как минимум, Magento Composer предполагает возможность развертывания под Windows, в то время, как modman сообщает:
Windows (including cygwin) is not supported by this script, but there is a PHP-port of modman which works on Windows. I am not affiliated with the authors and do not provide support for the PHP port, only a link here for reference.
Плюс, сам Composer является более универсальным инструментом (уровень PHP-сообщества), чем modman (уровень Magento-сообщества). Эти два пункта и побудили нас рассматривать Magento Composer вместо modman'а.
К сожалению, с чистым modman'ом не работали. На данный момент мы разворачиваемся из SVN'а с использованием самописных shell-скриптов, монтируя узлы репозитория в дерево Magento-приложения на уровне каталогов.
Прошу прощения за задержку с ответом — Новый Год и все такое…
На данный момент мы только рассматриваем возможность перехода на использование Magento Composer для развертывания наших проектов. Поэтому я не могу сказать, насколько удачно выбранное решение — нет опыта использования по полному циклу, от создания проекта, до его развертывания и внесения изменений. Что же касается предполагаемой структуры репозитория, то ее можно увидеть на github'е:
Деплой на CE платформу описан в статье, к сожалению по поводу ЕЕ ничего не могу сказать — мы просто не сталкивались с таким вариантом. Похоже, что в репозитории нет такого модуля.
По поводу развертывания проекта для различных задач (у нас это 4 варианта: девелоперская, тестовая, пилотная и production) я планирую написать отдельную статью. Когда доберусь до этого вопроса и разберусь в нем. Если доберусь и разберусь. Пока что только понятно, что стратегия развертывания для production-версии должна быть copy, а не symlink — т.е., там должен быть очень сильно другой composer.json.
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте...
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
Спасибо за развернутый ответ. Для сборки prodcton-версии проекта я смотрю в сторону PHP Composer, сборку девелоперской версии без монтирования в проект исходников всех зависимых модулей, участвующих в разработке, я пока не представляю. Допустим, я могу отказаться от субмодулей gt'а, Но от монтирования в девелоперскую версию модулей, находящихся в различных репоизиториях (как того ожидает тот же composer) я уж точно не смогу отказаться. Это сильно затормозит (да что у ж там — остановит) проекты в которых я участвую — разработка e-commerce приложений на базе Magento. Я не представляю, каким образом эмулировать Magento для разработки Magento-модуля в «чистой среде», а особенно, когда у меня есть код, общий для всех наших проектов, и специализация кода под конкретный проект. А это минимум два модуля, которые должны девелопиться параллельно. А потом до общего модуля «докручивается» функционал специализированных модулей и в других проектах.
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
А у нас архитектура такая — есть модуль, в котором лежит функционал для всех наших проектов (задает поведение), есть модуль в котором идет реализация поведения для связанной группы проектов, есть модуль специализирующий поведение для конкретного проекта. И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
IMHO, в наше стремительно летящее время приложения должны разрабатываться в том виде, в каком девелоперу удобно их создавать и изменять (второе даже важнее первого). И если девелоперу удобнее создавать и изменять (второе важнее) приложение с использованием JS — он будет это делать с использованием JS. Более того, этого будет требовать сам заказчик разработки. Ну а пользователи… 80% пользователей приложения проапргрейдятся, 20% будут выкинуты на обочину курить бамбук.
Я не имею в виду, что JS «захватит мир», я имею в виду, что «одноядерный 32-битный Pentium 4 Northwood» это если и не 20%, то уже очень близко к нему.
уж если есмь, то тогда уж и аз — аз есмь
</зануда></зануда>
Почему я сюда об этом постанул? А вот что-то сразу вспомнилась эта статья, вот и постанул.
Увидел ничего, испугался и полез для проверки на www.websocket.org/echo.html — там меня успокоили тем, что trace обнаружился. В связи с чем вопрос — простое демо работает, как и задумывалось или не совсем? Потому что ответ «I'm delayed 2 seconds» я получаю, а вот в логах этого не вижу. Раз в минуту браузер отправляет запрос на сервер:
и получает ответ:
И так — каждую минуту. Похоже, пример не рабочий.
Плюс, сам Composer является более универсальным инструментом (уровень PHP-сообщества), чем modman (уровень Magento-сообщества). Эти два пункта и побудили нас рассматривать Magento Composer вместо modman'а.
На данный момент мы только рассматриваем возможность перехода на использование Magento Composer для развертывания наших проектов. Поэтому я не могу сказать, насколько удачно выбранное решение — нет опыта использования по полному циклу, от создания проекта, до его развертывания и внесения изменений. Что же касается предполагаемой структуры репозитория, то ее можно увидеть на github'е:
Деплой на CE платформу описан в статье, к сожалению по поводу ЕЕ ничего не могу сказать — мы просто не сталкивались с таким вариантом. Похоже, что в репозитории нет такого модуля.
По поводу развертывания проекта для различных задач (у нас это 4 варианта: девелоперская, тестовая, пилотная и production) я планирую написать отдельную статью. Когда доберусь до этого вопроса и разберусь в нем. Если доберусь и разберусь. Пока что только понятно, что стратегия развертывания для production-версии должна быть copy, а не symlink — т.е., там должен быть очень сильно другой composer.json.
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)