Так phpunit еще и выведет название проблемного dataset'а, если тест зафейлится — найти его будет проще, чем что-то типа «dataset #1», и смысл проблемы будет сразу понятен прямо из отчета phpunit.
Стал использовать сразу после появления в релиз-нотисах для аутентификации Thunderbird в GMail и даже подумать не мог, что эта радость — дело рук mail.ru :-)
Спасибо большое!
Изначальным планом было отпровиженить машину с гостевым Debian'ом, на которой не было бы самого ansible (сама идея, состоящая в том, что на конфигурируемой машине нет ничего, кроме sshd, достаточно привлекательна) и попытка запустить всё это дело под Windows имела скорее академический интерес и долго не прожила (впоследствии на виртуалку для разработчиков был-таки поставлен ansible и вместо удаленного провиженинга стали использовать локальный — на виртуалке выполняется ansible-playbook и она сама себя настраивает).
int int_koJIu4ecTBo6ykB;
float float_rJly6uHa6acceuHA;
bool bool_ectbJIu7Ku3HbHaMapce;
Так Вы же сами пишете, что программист может не знать английского! Предлагаю однозначно более лучший универсальный вариант, который подойдет действительно всем:
int LIeJIoe_koJIu4ecTBo6ykB;
float Dpo6Hoe_rJly6uHa6acceuHA;
bool JIOru4eckoe_ectbJIu7Ku3HbHaMapce;
Прежде, чем добавлять какой-то уровень абстракции, хорошо бы получить работающий (и покрытый тестами) Proof of Concept, а уже после, видя более-менее полную картину, избавляться от нее более осознанно, чем в самом начале.
Linux-сисадмины скажут спасибо, если конфиги будут в /etc/myapp, логи в /var/log/myapp и т.д. Другими словами, храните файлы в общепринятых для OS директориях.
Любой лог-файл потенциально может бесконтрольно вырасти. На стадии проектирования планируйте жизненный цикл лог-файлов и данных, которые они содержат.
Мне кажется, в качестве еще более интересной практики можно продвигать использование уже готовых инструментов для сбора/записи/маршрутизации логов (начать можно просто с записи в syslog) — тогда сисадмины сами выберут, куда им складывать файлы (если вообще записывать логи в текстовые файлы), а разработчикам не придется в который раз изобретать ротацию и, возможно, инструменты для работы с самими логами.
Почему же не получится? С той же VM можно запустить ansible на прод. Делается в 2 команды.
Я подумал сразу про такую же схему для продакшена/QA/whatever — запихнуть туда Ansible и провиженить локалхост. Это решение из той же категории, что и описанное в статье — так делать не стоит, поэтому и ответил сразу, что неполучится.
Решал подобную задачу проще. Использовал config.vm.provision.
В смысле, шелл-провиженинг с командой, которая запускает Ansible на целевом хосте?
Вообще говоря, при условии, что ансибловские рецепты лежат рядом с проектом и монтируются на гостевую систему вместе с ним и в гостевой системе установлен Ansible (что для девелоперского окружения вполне допустимо) — отличный вариант.
Разве что провиженить так что-то кроме dev-окружения на вагрантовской виртуалке не получится (ну, или получится, но будет решительно неудобно).
Ну и да, целью тут было скорее поделиться опытом, а не рассказать, как надо делать. Потому что если бы я что-то такое прочитал в самом начале, то вряд ли бы пошел тем путем, которым пошел :-)
Именно так.
Разве что, насколько я знаю, хорошей практикой считается не перечислять домены, а аутентифицировать запрос по заголовку Origin. Если Origin свой, в ответ в Access-Control-Allow-Origin отправляем содержимое Origin из запроса. В противном случае не отправляем Access-Control-Allow-Origin вообще.
По-моему тут всё просто.
Если ревьюер может объяснить, почему бы он так сделал, и его точка зрения командой принята как верная/приемлемая — код нужно изменить. Если нет — его менять не нужно.
Есть две мысли на этот счет.
Во-первых, для совершенно случайных лиц даже запустить эти скрипты будет проблематично.
Во-вторых, а есть ли что-то плохое в том, что система может стать менее доступной для ботов?
По-моему, кардинально против могут быть только те, кто занимается этим в промышленных масштабах и имеет с этого деньги (нет, я Вас не обвиняю, это исключительно мои рассуждения для общего случая). А если качественно отсечь ботов, то одну-две-три анкеты для своей семьи зарегистрировать будет не так уж и трудно, разве нет?
Не всегда.
В debian-based дистрибутивах из коробки вероятность запуска сборщика старых сессий установлена в 0, а время жизни сессии выгрепывается-выседывается из глобальных конфигов и используется cronjob'ом, который при помощи find удаляет файлы сессий, к которым последний раз к ним обращались больше, чем session.gc_maxlifetime/60 минут назад.
Всё сделано с тонким расчётом на то, что зелёный будет гореть очень редко :)
Ну, или как вариант, этот же человек может утром, приходя на работу, ломать билд.
… а вот так:
Так phpunit еще и выведет название проблемного dataset'а, если тест зафейлится — найти его будет проще, чем что-то типа «dataset #1», и смысл проблемы будет сразу понятен прямо из отчета phpunit.
В общем, всё равно молодцы :-)
Спасибо большое!
Изначальным планом было отпровиженить машину с гостевым Debian'ом, на которой не было бы самого ansible (сама идея, состоящая в том, что на конфигурируемой машине нет ничего, кроме sshd, достаточно привлекательна) и попытка запустить всё это дело под Windows имела скорее академический интерес и долго не прожила (впоследствии на виртуалку для разработчиков был-таки поставлен ansible и вместо удаленного провиженинга стали использовать локальный — на виртуалке выполняется ansible-playbook и она сама себя настраивает).
Так Вы же сами пишете, что программист может не знать английского! Предлагаю однозначно более лучший универсальный вариант, который подойдет действительно всем:
Мне кажется, в качестве еще более интересной практики можно продвигать использование уже готовых инструментов для сбора/записи/маршрутизации логов (начать можно просто с записи в syslog) — тогда сисадмины сами выберут, куда им складывать файлы (если вообще записывать логи в текстовые файлы), а разработчикам не придется в который раз изобретать ротацию и, возможно, инструменты для работы с самими логами.
Я подумал сразу про такую же схему для продакшена/QA/whatever — запихнуть туда Ansible и провиженить локалхост. Это решение из той же категории, что и описанное в статье — так делать не стоит, поэтому и ответил сразу, что неполучится.
А с девелоперской виртуалки — да, можно, конечно.
В смысле, шелл-провиженинг с командой, которая запускает Ansible на целевом хосте?
Вообще говоря, при условии, что ансибловские рецепты лежат рядом с проектом и монтируются на гостевую систему вместе с ним и в гостевой системе установлен Ansible (что для девелоперского окружения вполне допустимо) — отличный вариант.
Разве что провиженить так что-то кроме dev-окружения на вагрантовской виртуалке не получится (ну, или получится, но будет решительно неудобно).
Ну и да, целью тут было скорее поделиться опытом, а не рассказать, как надо делать. Потому что если бы я что-то такое прочитал в самом начале, то вряд ли бы пошел тем путем, которым пошел :-)
Разве что, насколько я знаю, хорошей практикой считается не перечислять домены, а аутентифицировать запрос по заголовку
Origin
. ЕслиOrigin
свой, в ответ вAccess-Control-Allow-Origin
отправляем содержимое Origin из запроса. В противном случае не отправляемAccess-Control-Allow-Origin
вообще.Если ревьюер может объяснить, почему бы он так сделал, и его точка зрения командой принята как верная/приемлемая — код нужно изменить. Если нет — его менять не нужно.
Во-первых, для совершенно случайных лиц даже запустить эти скрипты будет проблематично.
Во-вторых, а есть ли что-то плохое в том, что система может стать менее доступной для ботов?
По-моему, кардинально против могут быть только те, кто занимается этим в промышленных масштабах и имеет с этого деньги (нет, я Вас не обвиняю, это исключительно мои рассуждения для общего случая). А если качественно отсечь ботов, то одну-две-три анкеты для своей семьи зарегистрировать будет не так уж и трудно, разве нет?
В debian-based дистрибутивах из коробки вероятность запуска сборщика старых сессий установлена в 0, а время жизни сессии выгрепывается-выседывается из глобальных конфигов и используется cronjob'ом, который при помощи
find
удаляет файлы сессий, к которым последний раз к ним обращались больше, чемsession.gc_maxlifetime/60
минут назад.Ну, или как вариант, этот же человек может утром, приходя на работу, ломать билд.
Ubuntu, Firefox 18.
Чекбокс куда-то уехал: