Посмотрел несколько роликов с игрой кого-то там на гитаре/барабанах/балалайке/органе. Господа, это не музыка! Это какое-то унылое гавно, которое даже школьник на синтезаторе наиграет за 3 минуты.
О вкусах конечно не спорят, и всегда найдется фанатик, с пеной у рта доказывающий обратное… Но, экскюземуа, это безвкусный набор шумов под струнный/ударный/клавишный ритм. И все! Это не музыка…
Надо внимательнее было читать. Пропустил «или же вы сможете сгенерировать код с помощью мобильного приложения на Android, BlackBerry или iPhone.». Это решает проблему, конечно.
Я поехал в другую страну на конференцию/в коммандировку БЕЗ роуминга. Находясь там, открываю ноут, подключаюсь к WiFi и обнаруживаю, что истекли эти заветные «30 дней». Почту свою я уже не посмотрю?
Вы все намешали в одну кучу. BDD — это эволюция TDD в полном смысле этого слова.
На определенном этапе, чтобы привлечь больше разработчиков к тестированию своих продуктов, было решено пересмотреть объект тестирования. Отсюда появился BDD и так называемые «Specification Tests» или просто «specs». Это обычные юнит-тесты со слегка измененным синтаксисом, позволяющим представлять описанные тесты в виде спецификаций тестируемых объектов. Примерами specs фрэймворков являются RSpec/JSpec. И к примеру, RSpec вполне себе заменяет классический TestUnit, которым с каждым днем пользуется все меньше и меньше Ruby разработчиков…
Немногим позже, родилось еще одно ответвление от BDD — так называемые «Scenario Tests». Это тесты, строящиеся вокруг понятия «сценарий» и последовательностей выполняемых шагов для достижения тестируемого состояния системы. Примерами сценарно-ориентированных BDD фрэймворков являются Cucumber/Behat/JBehave. И да, вот scenario-тесты больше подходят для acceptance тестирования, нежели для юнит-тестов.
Вообще, BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP. BDD фрэймворки успешно пытаются объединить эти 3 техники в одну систему и ветвятся на 2 самодостаточных стэка: specs тесты и scenario тесты. Первые призваны заменить классические unit тесты, добавив туда описательную часть. Вторые заменяют собой acceptance тесты, превращая функциональные тесты в «поведенческие» сценарии.
У меня просто взгляд человека, который понимает, что не язык развивает коммьюнити, а коммьюнити развивает язык.
Я просто стараюсь сделать мир лучше с теми знаниями, что имею ;-)
«Bad parts» есть в каждом языке и это ровным счетом ни о чем не говорит.
Не PHP плох из-за ухода людей, а люди уходят, потому что PHP плох.
Люди уходят потому что склонны верить в сказки об идеальных языках и фреймворках. Люди считают, что вот сейчас на PHP они пишут гавно, а перейдя завтра на Ruby они станут штамповать конфетки. Такого нет и не будет. Человеку, неспособному писать красиво на PHP будет в 1000 раз легче писать некрасиво и на Ruby. На node.js сейчас пишутся красивые библиотеки не оттого, что javascript не позволяет писать гавно. В JS гавна на порядки больше, чем в PHP и возможности писать гавно там на порядки выше, да и «bad parts» там в разы больше! Но красивые библиотеки для node.js пишут. Все дело в том, что пишут их вчерашние Ruby девелоперы с опытом «писать код красиво»! Вот и все. Коммьюнити решает, а не язык. PHP уже неоднократно доказал свою состоятельность как языка, на котором можно писать красиво. Мне этого достаточно.
Зачем использовать неудобный язык, если есть удобный
Понятие удобства каждый определяет для себя сам. Для меня удобно все, где с минимальными затратами я могу написать красивый код, который будет работать стабильно. Мою компетенцию в красивом и стабильном коде можете оценить по Behat, jade.php и другим моим проектам.
А многим людям приходится для своего удобства писать новый язык программирования. Но это не значит, что все старые языки сразу становятся ужасными. Это лишь значит, что понятия удобства каждый из нас определяет для себя сам.
Любую задачу можно качественно решить и на ASM'е, но отчего-то никто на нем вебы не программирует.
Ну давайте не будем сравнивать красное с деревянным. Вы же прекрасно понимаете, что драйвера и микроконтроллеры на Ruby/PHP тоже не напишешь. Мы говорим про языки одного уровня. В данном случае, повторюсь: в Ruby нет ничего, что бы было невозможно использовать/написать в PHP!
Ruby банально удобнее PHP, тут даже холиварить не нужно.
Дела вкуса. Я не питаю иллюзий. PHP в достаточной степени ужасен, чтобы его ненавидеть. Но в нем есть все, что нужно чтобы писать и использовать красивые приложения. Нужен синтаксический сахар? Так опять же, есть языки и покрасивее/полаконичнее Ruby.
Практически все, что появляется нового в PHP уже давно есть в Ruby.
Это достоинство коммьюнити, а не языка. Смотрите мой коммент выше! Если бы с Ruby все в свое время многие начали переходить на более интересный язык — ничего бы из того что «уже давно есть в Ruby» не было!
При этом зачастую один и тот же функционал выглядит в Рельсах гораздо красивее в плане синтаксиса (посмотрите, например, на валидации в Yii и в Рельсах).
Не могу спорить, что PHP и его фреймворки когда-то дорастут до RoR.
Посмотрите на Symfony2+Doctrine2. PHP не надо «дорастать до RoR», чтобы писать на нем фрэймворки уровня, а то и лучше (а мне действительно многое в sf2 нравится больше) рельс.
Мы только в 2010 увидим «правильные» веб фреймворки, ORM, BDD-фреймворки. Возможно, потому, что это стало возможно только с появлением PHP 5.
Это случается как раз потому, что нашлись люди, которые осознали, что «нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку»». Вместо того, чтобы скакать с языка на язык, эти люди делают по максимуму в том сообществе, в котором они выросли и учились.
Начни в свое время рубисты переходит на более интересные языки (а такие были) — не было бы того Ruby коммьюнити, что есть сейчас. Да и рельс бы не было!
Проблема не в языках, а в том, что мы на них пишем и насколько хорошо мы это делаем!
Сейчас многие языки разиваются в сторону распараллеливания и тредов. Можно ли это в пхп написать и использовать? Нет, никто не будет писать.
У многих языков (включая Ruby) давно есть поддержка тредов. Все проекты их примененяют? Нет? А почему? Потому что это не серебряная пуля! Потому что сложность и затратность разработки проектов с активным параллелизмом на основе тредов перекрывает большинство итоговых плюсов подобных проектов. Дешевая альтернатива тредам — событийные системы на основе евент-лупов, а они в Ruby точно так же не развиты, как и треды в PHP! Но это не значит, что Ruby — плохой язык и что всем надо срочно переходить на node.js. Это лишь значит, что для некоторого набора задач node.js с его event-driven натурой подходит больше, чем Ruby.
Ну и по поводу
никто не будет писать
Не так давно многие думали, что и красивого BDD под PHP быть не может и никто его не будет писать!
Какая разница на чем писать, если ты делаешь это качественно?
Я вас уверяю, нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку».
Да, у PHP есть недостатки и их море, но у Ruby и рельс нет ничего такого, что бы нельзя было написать или использовать в PHP.
Проблема не в языках и фреймворках, а в нашем коде и том, как мы его пишем!
В Ruby on Rails для тестирования страниц традиционно используется связка cucumer+webrat+nokogiri. В мире PHP все оказалось несколько сложнее…
Ну вообще-то, Webrat уже доживает свое и на смену ему давненько пришел Capybara.
Написанием альтернативы Capybara для php 5.3 я сейчас и занимаюсь полным ходом ;-)
>> Через некоторое время, было замечено…
>Да что вы, необходимость интеграционного тестирования была очевидна задолго до того, как слово «юнит-тесты» появилось на свет.
Я говорил не про интеграционное тестирование вообщем, а про интеграционное тестирование на основе behavior тестов. И оно уж никак не могло появиться раньше TDD ;-)
> То есть: «BDD — это техника… которая улучшает взаимодействие между программистами, тестеровщиками и не-техническими людьми в проекте. <...> BDD расширяет TDD путём написания тест-кейсов на естественном языке, который могут читать и не-программисты.»
Да, тут Вы правы. Я смешал понятия Outside-In Development с BDD, т.к. BDD сейчас чаще всего применяется именно при OIN разработке и я до сих пор не увидел смысла применять синтаксис BDD для написания юнит-тестов. В TDD практически не возникает коммуникативных проблем, которые существуют в Outside-IN ориентированной разработке, которые и породили необходимость в новом DSL.
Вообщем, извините за укол в Вашу сторону, виноват я.
— использование BDD — это не переход, а добавление к юнит-тестам behavior тестов
— верная работа отдельных модулей не гарантирует верную работу системы в целом, но верная работа системы в целом не гарантирует верную работу отдельных модулей ;-)
— sfBehatPlugin — это набор шагов-оберток поверх sfTestFunctional (https://github.com/everzet/sfBehatPlugin/tree/master/features/steps/). EverzetBehatBundle — это набор шагов, использующих стек HTTP компонентов Symfony2 для эмуляции браузинга и тестирования аутпута (http://dl.dropbox.com/u/282797/BehatBundle_results.html). У EverzetBehatBundle более тесная интеграция с фрэймворком за счет того, что Symfony2 как и Behat используют DIC.
О вкусах конечно не спорят, и всегда найдется фанатик, с пеной у рта доказывающий обратное… Но, экскюземуа, это безвкусный набор шумов под струнный/ударный/клавишный ритм. И все! Это не музыка…
На определенном этапе, чтобы привлечь больше разработчиков к тестированию своих продуктов, было решено пересмотреть объект тестирования. Отсюда появился BDD и так называемые «Specification Tests» или просто «specs». Это обычные юнит-тесты со слегка измененным синтаксисом, позволяющим представлять описанные тесты в виде спецификаций тестируемых объектов. Примерами specs фрэймворков являются RSpec/JSpec. И к примеру, RSpec вполне себе заменяет классический TestUnit, которым с каждым днем пользуется все меньше и меньше Ruby разработчиков…
Немногим позже, родилось еще одно ответвление от BDD — так называемые «Scenario Tests». Это тесты, строящиеся вокруг понятия «сценарий» и последовательностей выполняемых шагов для достижения тестируемого состояния системы. Примерами сценарно-ориентированных BDD фрэймворков являются Cucumber/Behat/JBehave. И да, вот scenario-тесты больше подходят для acceptance тестирования, нежели для юнит-тестов.
Вообще, BDD — это практика, объединяющая в себе TDD, DDD и Acceptance TDP. BDD фрэймворки успешно пытаются объединить эти 3 техники в одну систему и ветвятся на 2 самодостаточных стэка: specs тесты и scenario тесты. Первые призваны заменить классические unit тесты, добавив туда описательную часть. Вторые заменяют собой acceptance тесты, превращая функциональные тесты в «поведенческие» сценарии.
Я просто стараюсь сделать мир лучше с теми знаниями, что имею ;-)
«Bad parts» есть в каждом языке и это ровным счетом ни о чем не говорит.
Люди уходят потому что склонны верить в сказки об идеальных языках и фреймворках. Люди считают, что вот сейчас на PHP они пишут гавно, а перейдя завтра на Ruby они станут штамповать конфетки. Такого нет и не будет. Человеку, неспособному писать красиво на PHP будет в 1000 раз легче писать некрасиво и на Ruby. На node.js сейчас пишутся красивые библиотеки не оттого, что javascript не позволяет писать гавно. В JS гавна на порядки больше, чем в PHP и возможности писать гавно там на порядки выше, да и «bad parts» там в разы больше! Но красивые библиотеки для node.js пишут. Все дело в том, что пишут их вчерашние Ruby девелоперы с опытом «писать код красиво»! Вот и все. Коммьюнити решает, а не язык. PHP уже неоднократно доказал свою состоятельность как языка, на котором можно писать красиво. Мне этого достаточно.
Понятие удобства каждый определяет для себя сам. Для меня удобно все, где с минимальными затратами я могу написать красивый код, который будет работать стабильно. Мою компетенцию в красивом и стабильном коде можете оценить по Behat, jade.php и другим моим проектам.
А многим людям приходится для своего удобства писать новый язык программирования. Но это не значит, что все старые языки сразу становятся ужасными. Это лишь значит, что понятия удобства каждый из нас определяет для себя сам.
Ну давайте не будем сравнивать красное с деревянным. Вы же прекрасно понимаете, что драйвера и микроконтроллеры на Ruby/PHP тоже не напишешь. Мы говорим про языки одного уровня. В данном случае, повторюсь: в Ruby нет ничего, что бы было невозможно использовать/написать в PHP!
Дела вкуса. Я не питаю иллюзий. PHP в достаточной степени ужасен, чтобы его ненавидеть. Но в нем есть все, что нужно чтобы писать и использовать красивые приложения. Нужен синтаксический сахар? Так опять же, есть языки и покрасивее/полаконичнее Ruby.
Это достоинство коммьюнити, а не языка. Смотрите мой коммент выше! Если бы с Ruby все в свое время многие начали переходить на более интересный язык — ничего бы из того что «уже давно есть в Ruby» не было!
Посмотрите на Symfony2+Doctrine2. PHP не надо «дорастать до RoR», чтобы писать на нем фрэймворки уровня, а то и лучше (а мне действительно многое в sf2 нравится больше) рельс.
Это случается как раз потому, что нашлись люди, которые осознали, что «нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку»». Вместо того, чтобы скакать с языка на язык, эти люди делают по максимуму в том сообществе, в котором они выросли и учились.
Начни в свое время рубисты переходит на более интересные языки (а такие были) — не было бы того Ruby коммьюнити, что есть сейчас. Да и рельс бы не было!
Проблема не в языках, а в том, что мы на них пишем и насколько хорошо мы это делаем!
У многих языков (включая Ruby) давно есть поддержка тредов. Все проекты их примененяют? Нет? А почему? Потому что это не серебряная пуля! Потому что сложность и затратность разработки проектов с активным параллелизмом на основе тредов перекрывает большинство итоговых плюсов подобных проектов. Дешевая альтернатива тредам — событийные системы на основе евент-лупов, а они в Ruby точно так же не развиты, как и треды в PHP! Но это не значит, что Ruby — плохой язык и что всем надо срочно переходить на node.js. Это лишь значит, что для некоторого набора задач node.js с его event-driven натурой подходит больше, чем Ruby.
Ну и по поводу Не так давно многие думали, что и красивого BDD под PHP быть не может и никто его не будет писать!
Я вас уверяю, нет никакой разницы на чем писать говно и никакой разницы на чем писать «конфетку».
Да, у PHP есть недостатки и их море, но у Ruby и рельс нет ничего такого, что бы нельзя было написать или использовать в PHP.
Проблема не в языках и фреймворках, а в нашем коде и том, как мы его пишем!
Ну вообще-то, Webrat уже доживает свое и на смену ему давненько пришел Capybara.
Написанием альтернативы Capybara для php 5.3 я сейчас и занимаюсь полным ходом ;-)
>Да что вы, необходимость интеграционного тестирования была очевидна задолго до того, как слово «юнит-тесты» появилось на свет.
Я говорил не про интеграционное тестирование вообщем, а про интеграционное тестирование на основе behavior тестов. И оно уж никак не могло появиться раньше TDD ;-)
> То есть: «BDD — это техника… которая улучшает взаимодействие между программистами, тестеровщиками и не-техническими людьми в проекте. <...> BDD расширяет TDD путём написания тест-кейсов на естественном языке, который могут читать и не-программисты.»
Да, тут Вы правы. Я смешал понятия Outside-In Development с BDD, т.к. BDD сейчас чаще всего применяется именно при OIN разработке и я до сих пор не увидел смысла применять синтаксис BDD для написания юнит-тестов. В TDD практически не возникает коммуникативных проблем, которые существуют в Outside-IN ориентированной разработке, которые и породили необходимость в новом DSL.
Вообщем, извините за укол в Вашу сторону, виноват я.
— верная работа отдельных модулей не гарантирует верную работу системы в целом, но верная работа системы в целом не гарантирует верную работу отдельных модулей ;-)
— sfBehatPlugin — это набор шагов-оберток поверх sfTestFunctional (https://github.com/everzet/sfBehatPlugin/tree/master/features/steps/). EverzetBehatBundle — это набор шагов, использующих стек HTTP компонентов Symfony2 для эмуляции браузинга и тестирования аутпута (http://dl.dropbox.com/u/282797/BehatBundle_results.html). У EverzetBehatBundle более тесная интеграция с фрэймворком за счет того, что Symfony2 как и Behat используют DIC.