PHP конференция в Москве 23-24сентября

>экстремальное программирование в PHP

Это точно. В таком ужасе, как PHP могут программировать только экстремалы.

Для него хотя бы компиллятор есть. В отличии от Ruby.

А на чем ты предлагаешь програмиировать? На Perl? Так под ним комерческие проекты нельзя раздавать с закрытым кодом.
На Java? Дык для нее значительно больше ресурсов нужно и далеко не все проекты по деньгам могут это потянуть...
Остается PHP так как под ним все что нужно есть. И по скорости он Perl не уступает если конечно очень объектно не программить...
А если проект доростает до определенного уровня то обычно все переписывается уже на Си....

Каждый язык занимает свою нишу...

блин... вот это да! Собирался на ИнфоСекьюритиМоскоу 21-23, а теперь еще и сюда можно сьездить :) отлично!

>А на чем ты предлагаешь програмиировать?

Знающие меня люди знают и мой ответ: Zope, CherryPy, Quixote...

>А если проект доростает до определенного уровня то обычно все переписывается уже на Си....

Отличная шутка!

О каком ужасе речь? Жизнь продолжается ...

Экстремальное программирование - мастер-класс как и Постгрес - будет проводиться для желающих в отдельном зале.

А что-то Юрка заскучал.

Что это с ним?

> Знающие меня люди знают и мой ответ: Zope, CherryPy, Quixote...

Ясно.

И много ты заработал на Zope, CherryPy, Quixote?

> Это точно. В таком ужасе, как PHP могут программировать только экстремалы.

Эээ... Я не заметил эту реплику. Извините. Можете не отвечать на последний попрос. Я догадываюсь об ответе.

Сразу видно, - ПИОНЭР.

>Сразу видно, - ПИОНЭР.

Можете не беспокоиться. С методологией господина Мартина Фаулера я знаком.

>>экстремальное программирование в PHP >Это точно. В таком ужасе, как PHP могут программировать только экстремалы.

Мсье первый раз этот термин услышал?

> В таком ужасе, как PHP могут программировать только экстремалы.

Не нужно путать єкстремальное программирование с экстремизмом. Это всего лишь обобщенный и сконцентрированный опыт поколений программистов. Так что не нужно обижать нас, экстремалов. Мы всего лишь хотим доказать, что бил гейтс был не прав, предложив концепцию "достаточно хорошего программного продукта" (к коим, в общем, относится и ПХП).

>О каком ужасе речь? Видимо, о ПХП, в котором на каждый пук создается "на коленке" функция (а то и две), нет нормальной поддержки пользовательских модулей с изолироваными пространставми имен (приходится обходить, используя классы)... Могу продолжить, но мне это не интересно.

>Это всего лишь обобщенный и сконцентрированный опыт поколений программистов.

шутка да такая? Это не "опыт поколений" а всего лишь бред воспаленного разума Кента Бека и Ко. Окромя рефакторинга придуманного в незапамятные времена, я ничо полезного из их идей и не припомню.

>>Это всего лишь обобщенный и сконцентрированный опыт поколений программистов. > шутка да такая?

Нет. Кента Бек и Ко действительно ничего нового не придумали. Они просто взяли хорошо известные методы, позволяющие повысить качество программного продукта, и довели их до экстрима.

Типа "если тестировать - это хорошо, то мы будем запускать тесты так часто, как только это возможно". А разработка, ведомая тестированием была и до них.

Типа "если обмен занниями - это хорошо, то мы будем обмениваться знаниями все время", "если долгие совещания - это плохо, то мы будем совещаться стоя". А мониторинг кода и рабочие совещания были и до них.

И т.д.

В общем, суть XP не в том, _ЧТО_ применяется для обеспечения качества процесса разработки и конечного продукта, а в том _КАК_ это применяется.

There is no "silver bullet" ;)

Возможно есть области где ЭТО работает, хотя я плохо себе их представляю (возможно какие-то мелкие проекты), но рассматривать как нечто выдающееся ТДД не стоит.

>> Посетителям Linux.org.ru - скидки на участие в PHP-конференции.

Предлагают заплатить за то, что бы послушать чужую рекламу? Даю голову мальчика-флеймера tester_b_teste на отсечение, что ничего нового (по сравнению с инфой, которую можно достать в инете и из книг) там не скажут.

> There is no "silver bullet" ;) > Возможно есть области где ЭТО работает, хотя я плохо себе их представляю (возможно какие-то мелкие проекты), но рассматривать как нечто выдающееся ТДД не стоит.

Ничего выдающегося - просто еще один "инструмент" разработчика. Причем работает и для больших проектов (в отличие от всего комплекса правил XP, который ориентирован больше на компактные группы разработчиков). И как любой инструмент, его возможно использовать неправильно :(.

Единственный выдающийся инструмент разработчика - голова ;).

дык преподносится тем же Беком и Фаулером как панацея от всех бед. Ну возможно в "системе бронирования космических путешествий" (с):D так оно и есть. Но в реальности есть масса куда более важных вещей для разработчика, которые увеличивают кпд в разы, в отличии от ХР технологий.

вот например мнение Джоэля Спольски: http://russian.joelonsoftware.com/Articles/FiveWorlds.html

> Но в реальности есть масса куда более важных вещей для разработчика, которые увеличивают кпд в разы, в отличии от ХР технологий. Например?

> вот например мнение Джоэля Спольски Мне кажется что спор здесь смысла не имеет по одной простой причине. Оба (и Дж. Спольски и К. Бек) абсолютно правы, но выдвигают свои предположения исходя из разных предпосылок.

Далее моя интерпретация этих двух точек зрения. К.Бэк. ----- Любая пользовательская история описывает некоторые исходные условия, некоторое действие, и ожидаемые результаты. Если мы создаем тест, имитирующий исходные условия, запускаем код, выполняющий некоторое действие, и на выходе получаем ожидаемые результаты, то считаем что код работает без ошибок. Наличие теста позволяет в любой момент проверить, правильно ли функционирует данный код при любых изменениях кода. Если же обнаруживаются условия, при которых код ведет себя не так, ка ожидалось (проблема с польской клавиатурой), то очевидно, что это не недостаток кода, а недостаток пользовательской истории, которая недостаточно описала условия, в которых может работать наш код. Это нормальная ситуация, ведь невозможно предусмотреть абсолютно все! В таком случае в дополнение к первой истории записывается вторая, в которой описываются условия, в которых наш первоначальный код функционирует не совсем так, как нам хочется. Мы пишем тест для второй пользовательской истории, и в процессе модификации кода периодически запускаем тесты дабы убедиться, что мы ничего не сломали для первой пользовательской истории, одновременно добиваяь того, чтобы заработали тесты для второй истории. Таким образом, Кент Бек абсолютно прав, утверждая, что ТДД дает 100% гарантию от багов (естественно, если программер не халтурит в описании условий для тестов). Я считаю, что при использовании ТДД ошибкой (багом) считается некоррекная работа кода по сравнению с тем, что описано в пользовательской истории.

Джоел Спольски -------------- Заказчик (пользователь) ожидает получить идеально работающую программу, удовлетворяющую его нуждам. Если же вдруг обнаруживаются условия, при которых пользователь оказывается обманутым в его ожиданиях (польская клавиатура), то он считает это ошибкой. Ошибка записывается в систему отслеживания ошибок (bug tracking), и далее разработчик исправляет эту ошибку. Таким образом, Джоел Спольски абсолютно прав, утверждая что ТДД не дает 100% гарантию от багов, так как невозможно предусмотреть все возможные условия, в которых может работать наш код.

Таким образом, я наблюдаю всего лишь терминологические расхождения (пользовательская история - bug report) на этапе подготовки к кодированию. Он этом же говорит и Джоел, ставя знак равенства между "ошибкой" и "пользовательской историей". И очевидно, что автоматизированное тестирование позволяет максимально контролировать уже созданный код, и обнаруживать любые поломки в системе ASAP.

Что касается, парного программирования, то я рассматриваю его скорее как инструмент обмена информацией, знаниями, опытом. Именно по-этому рекомендуется не создавать постоянных пар, а меняться партнерами после завершения каждой пользовательской истории. Кроме того, при работе в паре гораздо труднее занятся какими-то "левыми" задачами ;), что в целом ведет к повышению производительности коллектива.

Вот что пишет Mcconnell (Rapid Development) >Testing's effectiveness varies enormously. Unit testing can find anywhere from 10 to 50 percent of the defects in a program. System testing can find from 20 to 60 percent of a program's defects. Together, their cumulative defect-detection rate is often less than 60 percent

да и вообще говорить о 100% гарантии от багов это уж черезчур :)

> да и вообще говорить о 100% гарантии от багов это уж черезчур :) Но стремиться к этому нужно ;)