По поводу data providers в phpunit: советую указывать суть кейсов не в виде комментариев, а в виде ключей ассоциативного массива. То есть не

return [
 // email isValid
 ['test@test.ru', true ],
 ['invalidEmail', false],
 // ...
 ];

… а вот так:

return [
 'valid e-mail' => ['test@test.ru', true ],
 'email without @' => ['invalidEmail', false],
 // ...
 ]

Так phpunit еще и выведет название проблемного dataset'а, если тест зафейлится — найти его будет проще, чем что-то типа «dataset #1», и смысл проблемы будет сразу понятен прямо из отчета phpunit.

Действительно. Прочитал еще раз статью и не понял, почему я решил, что речь шла не только о добавлении в ISP-базу.
В общем, всё равно молодцы :-)

Стал использовать сразу после появления в релиз-нотисах для аутентификации 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 минут назад.

Всё сделано с тонким расчётом на то, что зелёный будет гореть очень редко :)
Ну, или как вариант, этот же человек может утром, приходя на работу, ломать билд.

Та же ситуация.
Ubuntu, Firefox 18.
Чекбокс куда-то уехал: