Comments 47
UFO just landed and posted this here
Приложение и сайт — синонимы. Возможно термин сайт не самый удачный. Трестируемое приложение не обязательно должно быть сайтом в общем смысле это слова, вообще говоря это любой веб сервис, что-то к чему можно сделать запрос по http протоколу. Просто термин сайт звучит по-короче и более привычен. Хотя впринципе вопрос с терминологией ещё открыт, проект ещё в стадии активной разработки.
UFO just landed and posted this here
Как вариант, но хотелось бы чего то более лаконичного, ну по крайней мере в смысле команд sparrow клиента, в случае в веб сервисом, будет выглядеть как то так —
sparrow project foo add_web_srv… .?
Не длинновато? :-)
sparrow project foo add_web_srv… .?
Не длинновато? :-)
UFO just landed and posted this here
Насчёт термина service, неплохо, надо подумать ;-))
Насчёт «возможность брать проект из контекста» вот тут просьба разъяснить. Проект то все равно надо указывать всегда явно, откуда его брать? или…?
Насчёт «возможность брать проект из контекста» вот тут просьба разъяснить. Проект то все равно надо указывать всегда явно, откуда его брать? или…?
UFO just landed and posted this here
Я так и подумал что это вы и имели ввиду, идея неплохая надо будет подумать, но тогда придётся воркфлоу менять, типа плагины чекаутить из гита, переходить в контекст, но в смысле в папку с зачекаученным плагином и там уже создавать проекты и сайты, но тогда у на получается плагиноцнгтричная архитектура, а не проектная как сейчас, надо короче думать…
UFO just landed and posted this here
UFO just landed and posted this here
Хороший вопрос. Сейчас схема довольна простая. Единого репозитария, наподобие того же cpan, нет. Схема добавления нового плагина такова. Вы создаёте плагин, размещаете код плагина в удаленном гит репозитарии и добавляете «ссылку» на плагин в файл списка плагинов на машине где установлен sparrow (~/sparrow/sparrow.list) в в виде:
plugin-name git-repo-url
Причём имя плагина выбираете на своё усмотрение, это просто некий идентификатор, по которому вы потом его можете установить и запустить через sparrow:
sparrow plg install plugin-name
Существует список готовых к использованию плагинов, с которым можно ознакомится тут — github.com/melezhik/sparrow-hub. Вы так же можете кинуть мне пул реквест или написать и я добавлю ваш плагин в этот список, если конечно гит репозитарий, где лежит плагин публично доступен. Скорее всего данный список аналог централизованного репозитария для комьюнити плагинов. Сейчас он состоит из плагинов, написанных только мной. Одной из целей данной статьи было как раз привлечение разработчиков для новых плагинов.
Вообщем, вопрос с централизованным репозитарием для плагинов и доступом к нему через sparrow пока открытый, пока не определился с лучшим решением. Предлагайте :-)
plugin-name git-repo-url
Причём имя плагина выбираете на своё усмотрение, это просто некий идентификатор, по которому вы потом его можете установить и запустить через sparrow:
sparrow plg install plugin-name
Существует список готовых к использованию плагинов, с которым можно ознакомится тут — github.com/melezhik/sparrow-hub. Вы так же можете кинуть мне пул реквест или написать и я добавлю ваш плагин в этот список, если конечно гит репозитарий, где лежит плагин публично доступен. Скорее всего данный список аналог централизованного репозитария для комьюнити плагинов. Сейчас он состоит из плагинов, написанных только мной. Одной из целей данной статьи было как раз привлечение разработчиков для новых плагинов.
Вообщем, вопрос с централизованным репозитарием для плагинов и доступом к нему через sparrow пока открытый, пока не определился с лучшим решением. Предлагайте :-)
UFO just landed and posted this here
Читаете мои мысли :) Это была первая идея, которая пришла мне в голову, и я кстати от неё пока окончательно не отказался.
Плюс конечно основной, что вся готовая инфраструктура дистрибуции уже сущесвует и понятно всему perl сообществу.
Минус в том, что sparrow плагины, не совсем cpan модули, хотя очень похожи на них. Если посмотреть в документацию по swat, там так же могут зависимости от обычных cpan модулей. Сейчас я решаю это использованию локальной установкой через carton, добавляя в корень проекта cpanfile. Короче, что бы не быть многословным, накладные расходы на дистрибуцию через cpan все же есть, два минуса вижу здесь — затруднительно будет распространять приватные плагины, несмотря на существующие решения ввиде pinto или minicpan, второй минус хочется максимально сузить цикл поставки новых версий, а в случае с вокалом через cpan, имеем задержку, а что может быть быстрее git commit, git push и git pull? :-)
Но с другой стороны если sparrow плагины рассматривать как паблик модули, то здесь без версиоонирования будет сложно.
Плюс конечно основной, что вся готовая инфраструктура дистрибуции уже сущесвует и понятно всему perl сообществу.
Минус в том, что sparrow плагины, не совсем cpan модули, хотя очень похожи на них. Если посмотреть в документацию по swat, там так же могут зависимости от обычных cpan модулей. Сейчас я решаю это использованию локальной установкой через carton, добавляя в корень проекта cpanfile. Короче, что бы не быть многословным, накладные расходы на дистрибуцию через cpan все же есть, два минуса вижу здесь — затруднительно будет распространять приватные плагины, несмотря на существующие решения ввиде pinto или minicpan, второй минус хочется максимально сузить цикл поставки новых версий, а в случае с вокалом через cpan, имеем задержку, а что может быть быстрее git commit, git push и git pull? :-)
Но с другой стороны если sparrow плагины рассматривать как паблик модули, то здесь без версиоонирования будет сложно.
Да кстати на каком то этапе swat «умел» запускать тесты поставляемые через спан модули, я использовал для этого фичу file::sharedir, но потом решил от этого отказаться.
UFO just landed and posted this here
>Для чего нужно привязывать плагин к проекту?
Проект сущность необходимая для логической группировки тестируемых приложений ( aka сайтов ). Прикрепив плагин к проекту мы делаем возможным запускать плагин для приложений. Просто так запустить плагин нельзя. Плагин — это набор тестовых сценариев относительно какого-то приложения, приложение содержится внутри проекта. Впринципе сущность как проект можно было бы не вводить, но обычно подобная группировка оказывается очень полезной, даже если прямо сейчас этого явно не видно. Да и кстати «Для запуска пакетного тестирования проекта всеми плагинами сразу» хорошая идея.
>Каждый сайт в проекте будет тестироваться каждым плагином?
Сайты проекта и плагины, прикреплённые к проекту никак явно не соотносятся. Связь возникает когда вы запускаете плагин. Делая отсылку к ответу на ваш предыдущий вопрос — плагин всегда запускается для конкретного сайта, а сайт берётся из проекта. Почему полезно было ввести такую сущность как сайт, не заменив её просто на входной параметр запускаемого плагина? Опять таки да для удобства. Один из важных моментов вы можете определить настройки запускаемого плагина ( swat settings ) на уровне сайта командой «swat project project-name site-name swat_setup». Настройки плагина как правило определяют различные заранее неизвестные входные данные для ваших тестовых сценариев, наприм логин и пароль для аутентификации в веб приложении, которые конечно же нельзя оставлять в гит репозитории, ну и так далее. Подробнее о swat settings, можно прочитать на странице документации swat — DSL, используемом при написании тестовых сценариев в sparrow плагинах, github.com/melezhik/swat
Проект сущность необходимая для логической группировки тестируемых приложений ( aka сайтов ). Прикрепив плагин к проекту мы делаем возможным запускать плагин для приложений. Просто так запустить плагин нельзя. Плагин — это набор тестовых сценариев относительно какого-то приложения, приложение содержится внутри проекта. Впринципе сущность как проект можно было бы не вводить, но обычно подобная группировка оказывается очень полезной, даже если прямо сейчас этого явно не видно. Да и кстати «Для запуска пакетного тестирования проекта всеми плагинами сразу» хорошая идея.
>Каждый сайт в проекте будет тестироваться каждым плагином?
Сайты проекта и плагины, прикреплённые к проекту никак явно не соотносятся. Связь возникает когда вы запускаете плагин. Делая отсылку к ответу на ваш предыдущий вопрос — плагин всегда запускается для конкретного сайта, а сайт берётся из проекта. Почему полезно было ввести такую сущность как сайт, не заменив её просто на входной параметр запускаемого плагина? Опять таки да для удобства. Один из важных моментов вы можете определить настройки запускаемого плагина ( swat settings ) на уровне сайта командой «swat project project-name site-name swat_setup». Настройки плагина как правило определяют различные заранее неизвестные входные данные для ваших тестовых сценариев, наприм логин и пароль для аутентификации в веб приложении, которые конечно же нельзя оставлять в гит репозитории, ну и так далее. Подробнее о swat settings, можно прочитать на странице документации swat — DSL, используемом при написании тестовых сценариев в sparrow плагинах, github.com/melezhik/swat
Ну и ещё в догонку — чисто теоретически, хотя пока сложно придумать конкретный пример приложение может тестироваться больше чем одним плагином, ну например можно разбить сложную логику тестов на несколько плагинов и гонять их отдельно для одно и того же приложения. Но как правило связь конечно же более простая — одни плагин одно трестируемое приложение.
Но в любом случае сейчас нет никакой валидация того какие приложения какими плагинами можно тестировать, мы исходим из того, что человек запускающий плагин владеть этим знанием и на собирается запускать плагин написанный для mongodb-http для проверки какого-нибудь nginx сервера.
Хотя конечно же такую валидация при необходимости можно будет обеспечить, и вот здесь как раз будет очень полезной такая сущность как сайт. Надеюсь это так же поможет больше понять идеи, заложенные в дизайн
Но в любом случае сейчас нет никакой валидация того какие приложения какими плагинами можно тестировать, мы исходим из того, что человек запускающий плагин владеть этим знанием и на собирается запускать плагин написанный для mongodb-http для проверки какого-нибудь nginx сервера.
Хотя конечно же такую валидация при необходимости можно будет обеспечить, и вот здесь как раз будет очень полезной такая сущность как сайт. Надеюсь это так же поможет больше понять идеи, заложенные в дизайн
UFO just landed and posted this here
Зашёл на метаспан, поискал в модулях swat, вот ссылка metacpan.org/pod/distribution/swat/lib/swat.pm, pod прекрасно отображается, тоже самое по sparrow — metacpan.org/pod/distribution/Sparrow/lib/Sparrow.pm
У местаспана кстати бывают проблемы со ссылками на pod если выходишь на модуль не через поиск модулей, а через ссылку в разделе recent — свежее, может в этом дело, не знаю, проверьте мои ссылки, pod читается?
У местаспана кстати бывают проблемы со ссылками на pod если выходишь на модуль не через поиск модулей, а через ссылку в разделе recent — свежее, может в этом дело, не знаю, проверьте мои ссылки, pod читается?
UFO just landed and posted this here
UFO just landed and posted this here
Все верно, как я уже сказал, нужно идти по другому.
Идём на metacpan.org, в форме поиска вводим Sparrow или swat, соответсвенно на следующей странице открываем самую верхнюю, выделенную жирным ссылку (lib/swat.pm ) и жмём на неё, попадаем на страницу именно документации — metacpan.org/pod/distribution/swat/lib/swat.pm, там pod рендерится. Еже ли идти по другому маршруту, по которому вы скорее всего шли, получается так: metacpan.org/recent, затем выбираем ссылку ссылку Sparrow-0.0.6, попадаем на страницу, указанную вами — metacpan.org/release/Sparrow, все ссылки в блоке provides там будут давать ссылки на код, без рендеринга pod документации, эта особенность местаспана, я тоже уже с ней сталкивался…
Идём на metacpan.org, в форме поиска вводим Sparrow или swat, соответсвенно на следующей странице открываем самую верхнюю, выделенную жирным ссылку (lib/swat.pm ) и жмём на неё, попадаем на страницу именно документации — metacpan.org/pod/distribution/swat/lib/swat.pm, там pod рендерится. Еже ли идти по другому маршруту, по которому вы скорее всего шли, получается так: metacpan.org/recent, затем выбираем ссылку ссылку Sparrow-0.0.6, попадаем на страницу, указанную вами — metacpan.org/release/Sparrow, все ссылки в блоке provides там будут давать ссылки на код, без рендеринга pod документации, эта особенность местаспана, я тоже уже с ней сталкивался…
Ну или на крайняк можно воспользоваться старым добрым search.cpan.org :-) но у него через раз вывяливается ошибка связанная с прокси, по крайней мере в меня, когда им пытаюсь воспользоваться.
Да посмотрел в других модулях, похоже это все таки моя недоработка, хотя все выше сказанное про разные способы навигации верно, просто у мня по ходу не хватает в спан дистрибутиве места информации, описывающей именно модули, поэтому и нету соответствующих ссылок, надо будет посмотреть повнимательней на мейк файл, а пока воркэраунд предложенный выше — идти через форму поиска.
UFO just landed and posted this here
странно. привожу свои скрины:
PS. ну уж если и так не заработает юзайте доку прямо с гитхаба в маркдауне:
* github.com/melezhik/swat
* github.com/melezhik/sparrow
PS. ну уж если и так не заработает юзайте доку прямо с гитхаба в маркдауне:
* github.com/melezhik/swat
* github.com/melezhik/sparrow
UFO just landed and posted this here
согласен, будем посмотреть ;-)
Provides — это package, в одном .pm файле может быть задекларировано несколько package.
UFO just landed and posted this here
Perl module — это Module/Name.pm — .pm или .pl файл относительно @ INC.
Модуль может содержать несколько package (неймспейсов) — это provides в терминологии metaspan, т.е. какие неймспейсы предоставляет данный дистрибутив (набор модулей).
Модуль может содержать несколько package (неймспейсов) — это provides в терминологии metaspan, т.е. какие неймспейсы предоставляет данный дистрибутив (набор модулей).
UFO just landed and posted this here
Видимо потому, что у него неправильно встроен POD.
Нет =pod метки — поэтому pod не парсится и не отображается. Может поэтому metacpan не показывает эти файлы, как модули.
Это имеет смысл, т.к. pod может относиться только к модулю а не к package внутри модуля. И нет смысла показывать файлы без pod.
Нет =pod метки — поэтому pod не парсится и не отображается. Может поэтому metacpan не показывает эти файлы, как модули.
Это имеет смысл, т.к. pod может относиться только к модулю а не к package внутри модуля. И нет смысла показывать файлы без pod.
Да, да все верно, спасибо за уточнение!
UFO just landed and posted this here
Не знаю, надо эксперементировать.
Но лучше всего сделать стандатный дистрибутив с помощью Dist::Zilla, если напрямую не получается.
Возможно, что надо использовать META.json вместо META.yml (давно признан устаревшим).
TODO:
1. META.yml -> META.json;
2. добавить cpanfile чтобы можно было устанавливать только зависимости (cpanm --installdeps .);
3. Сделать POD как надо;
Больше ничего быть не может.
Но лучше всего сделать стандатный дистрибутив с помощью Dist::Zilla, если напрямую не получается.
Возможно, что надо использовать META.json вместо META.yml (давно признан устаревшим).
TODO:
1. META.yml -> META.json;
2. добавить cpanfile чтобы можно было устанавливать только зависимости (cpanm --installdeps .);
3. Сделать POD как надо;
Больше ничего быть не может.
package # This is JSON::backportPP
JSON::PP;
Неймспейс JSON::PP спрятан от индексации — в provides не отображается, т.к. metacpan не видит его.
Но модуль JSON/backportPP.pm содержит POD.
Этот POD отображается как Documentation без привязки к модулю. Название берется из =head1 NAME ...;
Provides — это ссылка на декларацию package в исходнике модуля, ЕСЛИ имя модуля не совпадает с этим package;
Modules — ссылки на POD для модулей с POD;
Documentation — все остальные POD, которые не могут быть связаны с модулем, или из отдельных .pod файлов;
JSON::PP;
Неймспейс JSON::PP спрятан от индексации — в provides не отображается, т.к. metacpan не видит его.
Но модуль JSON/backportPP.pm содержит POD.
Этот POD отображается как Documentation без привязки к модулю. Название берется из =head1 NAME ...;
Provides — это ссылка на декларацию package в исходнике модуля, ЕСЛИ имя модуля не совпадает с этим package;
Modules — ссылки на POD для модулей с POD;
Documentation — все остальные POD, которые не могут быть связаны с модулем, или из отдельных .pod файлов;
UFO just landed and posted this here
Всем спасибо за советы. Похоже решил проблему с отображением pod документации на метаспане — metacpan.org/release/MELEZHIK/swat-0.1.71 alaska332 — спасибо в частности, =pod помог
Да, собственно центральный репозитарий sparrow плагинов — sparrowhub.org уже запущен, последняя версия sparrow работает уже с ним, есть пост на blogs.perl.org об этом.
Sign up to leave a comment.
Sparrow — perl фреймворк тестирования и мониторинга web приложений