Хм, я долгое время сидел на убунте, но вернувшись к Windows, всё-таки решил остаться на нем. Денвер как никак рулит, с ним удобно работать, с его настройкой особо играться не приходится. Но учитывая, что на проекте используется Gearman, для которого нет расширения под винду. Тут отлично помогла Лубунта, которую я поставил виртуально. Профит в том, что одновременно проект работает как под виндовсом так и под линукосм, и в зависимости от сложности задач я могу свободно переключатся. Если нет необходимости использовать Gearman, линукс я даже не запускаю… Да, есть нюансы: разные БД используются, но конфиги одинаковые.
Говорю к тому, что и Денвер и линукс под виртуалкой, всё вещи полезные и в хозяйстве нужные и могут отлично сосуществовать.
Ещё есть вариант хуков — редактировать core-файлы в отдельной git-ветке, а при обновлении сделать merge.
Да, я согласен с автором, что редактировать файлы в ядре это зло и лучше использовать Event Observer там где они есть, но вдруг что, можно использовать и этот метод.
Не знаю, какие там технологи, но вцелом оно достаточно примитивно: через Twilio шлют смски и принимают их. Это базовый функционал. Остальное — навески для разных мобильных платформ.
Впринципе плюсую. Обычно я вообще не помню как какой паттерн называется, но вполне уверен, что использую многие из них. Если нет необходимости вербально программировать, то и название паттернов знать не так обязательно, главное хорошо понимать принципы построения архитектуры и всякие там KISS и DRY.
А знание паттернов это если тимлид увлекается спортивным программированием на словах.
Я думаю для неспециалистов это как раз не аргумент. Для меня у Лисы основное конкурентное преимущество — Firebug, думаю как и для многих здесь. Хотелось бы увидеть у Лисы попытки стать лучше Хрома во всём, и быть более удобной для обычного пользователя. А без какой-то реальной killing feature у них вряд ли получится.
А всё-таки непонятно, какое будет у лисы конкуретное преимущество перед Хромом. Пока что в интерфейсе (а это ж то что бросается сразу в глаза, встречают по одежке) их не видно. Хотя Personas в новом дизайне и смотрятся очень даже неплохо, но «неунылые обои» это не аргумент.
Ох ты ж йо. При чем тут методология? Мы же вроде от неё абстрагировались.
Вернемся к простому.
Я пишу тест, он проходит.
Тестер тестирует фичу, она не срабатывает.
Я показываю ему тест, он его понимает и говорит, что то ли он не те данные вводил, то ли выполнял не те команды.
После того как мы с тестером согласны, что сценарий напиан правильно и у него он срабатывает, фича считается работающей и проверяется на каждой итерации тестирования.
Вот и всё что я хочу. Behat не нужен мне в плане методологии. Я ею не занимаюсь. А вот тестами и коммуникацией с тестировщиком и менеджером — постоянно.
Ну да, дяде васе с улицы тест понятен не будет, тут согласен. Впрочем, это и не нужно.
Мне, как было сказано, пофиг каким DD это будет называться. Есть сценарии описанные простым языком. В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.
Вроде же разобрались, что я говорю конкретно о функциональных тестах. Модель BDD просто помогает упростить их спецификацию.
Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. Он добавляет новую методологию, а с ней и присущие ей сложности. См. заголовок статьи.
Да, но не обязательно писать это именно на человеческом языке. Точно так же можно писать на PHP. ПРи этом совершенно не сложно сделать так, чтобы код был понятен обычному человеку. Хотя бы тестеру.
DirectX вообще поддерживается?
Говорю к тому, что и Денвер и линукс под виртуалкой, всё вещи полезные и в хозяйстве нужные и могут отлично сосуществовать.
А единственная утилита для редактирования хостов апача куда-то исчезла. Обидно.
Да, я согласен с автором, что редактировать файлы в ядре это зло и лучше использовать Event Observer там где они есть, но вдруг что, можно использовать и этот метод.
А знание паттернов это если тимлид увлекается спортивным программированием на словах.
Вернемся к простому.
Я пишу тест, он проходит.
Тестер тестирует фичу, она не срабатывает.
Я показываю ему тест, он его понимает и говорит, что то ли он не те данные вводил, то ли выполнял не те команды.
После того как мы с тестером согласны, что сценарий напиан правильно и у него он срабатывает, фича считается работающей и проверяется на каждой итерации тестирования.
Вот и всё что я хочу. Behat не нужен мне в плане методологии. Я ею не занимаюсь. А вот тестами и коммуникацией с тестировщиком и менеджером — постоянно.
Мне, как было сказано, пофиг каким DD это будет называться. Есть сценарии описанные простым языком. В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.
Вроде же разобрались, что я говорю конкретно о функциональных тестах. Модель BDD просто помогает упростить их спецификацию.
Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. Он добавляет новую методологию, а с ней и присущие ей сложности. См. заголовок статьи.