Каждый выбирает тот дистр, в котором лучше всего разбирается ;-) Лично меня всегда огорчало отсутствие предложений Dedicated servers с предустановленной Slackware Linux.
Согласитесь, мало найдется проектов объемом больше трех человеко-месяцев, которые, несмотря на изначальное подробное описание и проектирование "до последней кнопки", не вызывали бы ощущения общирного "костылизма" и мыслей "всю эту хрень переделать". Проектная документация, как правило, устаревает на полпути к дедлайну, после чего на нее (документацию) вообще забивают по причине нехватки времени ;-) Так что подробное проектирование дизайна системы в начале проекта обычно вредит самому проекту, потому что позже команда не может найти в себе силы перекроить дизайн. И чем больше проект - тем хуже результат. Я наблюдал это многократно в разных софтверных компаниях.
Спасти положение может либо рефакторинг, либо переделка "с нуля". А теперь скажите, какой рефакторинг возможен без TDD? Вы лично подпишетесь рефакторить систему с 2МБ пхп-шного кода без наличия тестов на код? ;-) Сила TDD как раз-таки в том, что использование TDD позволяет измененять дизайн системы (читай делать перепроектирование системы) без ущерба качества системы в тот момент, когда разработчик посчитает это нужным. Т.е. фактически не думать о проектировании "на потом". Ключевое слово в TDD рефакторинг.
Зато полно конкретики, а это как раз то, что ценно в данном случае. В отличие от обтекаемых рассуждений ведущего программиста Рамблера о highload-архитектуре на конференции, когда он толком ни на один вопрос не ответил.
Категорически против. Никогда не тратьте время на предварительное проектирование: в определенный момент разработка встает колом по причине "недостаточно проработанной архитектуры системы". Код должен сам говорить, где хорошо, а где плохо. TDD вам в руки. ;-)
зато PDO позволяет малой кровью перейти, например, с PostgreSQL на MySQL. К тому же мне особо импонирует возможность параметризованных запросов (SELECT * FROM t1 WHERE foo = ?), чего нет в нативном mysql_*, и, как следствие, голова не болит о http request parameters escaping.
Есть такое понятие, как синоним тега. Например теги "web2.0", "web 2.0", "веб-2.0" являются синонимами. Право определения "синонимности" тегов принадлежит админу либо доверенному лицу (модератору). При появлении схожих тегов админ должен выбрать базовый тег и привязать к нему ряд синонимов, причем система может значительно автоматизировать эту неблагодарную работу. По мере роста базы синонимов, полезность облака тегов повышается. Мы реализовали такую систему еще в 2005 и какое-то время система вела себя очень хорошо.
Согласитесь, мало найдется проектов объемом больше трех человеко-месяцев, которые, несмотря на изначальное подробное описание и проектирование "до последней кнопки", не вызывали бы ощущения общирного "костылизма" и мыслей "всю эту хрень переделать". Проектная документация, как правило, устаревает на полпути к дедлайну, после чего на нее (документацию) вообще забивают по причине нехватки времени ;-) Так что подробное проектирование дизайна системы в начале проекта обычно вредит самому проекту, потому что позже команда не может найти в себе силы перекроить дизайн. И чем больше проект - тем хуже результат. Я наблюдал это многократно в разных софтверных компаниях.
Спасти положение может либо рефакторинг, либо переделка "с нуля". А теперь скажите, какой рефакторинг возможен без TDD? Вы лично подпишетесь рефакторить систему с 2МБ пхп-шного кода без наличия тестов на код? ;-) Сила TDD как раз-таки в том, что использование TDD позволяет измененять дизайн системы (читай делать перепроектирование системы) без ущерба качества системы в тот момент, когда разработчик посчитает это нужным. Т.е. фактически не думать о проектировании "на потом". Ключевое слово в TDD рефакторинг.
Никогда не тратьте время на предварительное проектирование: в определенный момент разработка встает колом по причине "недостаточно проработанной архитектуры системы". Код должен сам говорить, где хорошо, а где плохо. TDD вам в руки. ;-)