суббота, 20 марта 2010 г.

Джоел и Subversion, Mercurial, Git. Действительно антибиотик?

Progg it
Недавно в блоге Джоела Спольски была опубликована последняя статья – «Distributed Version Control is here to stay, baby», по крайнее мере сам Джоель называет её последней. Статья, как понятно из заглавия посвящена распределенным системам контроля версий. После прочтения статьи возникло желание немного её прокомментировать. Сначала я выложу краткий обзор содержания, при этом постараюсь не упустить важных моментов. Делать полноценный перевод нет ни времени, ни желании. Итак, Джоел пишет следующее…
В распределенных системах контроля версий их распределенность не является самой интересной особенностью. Наиболее интересным является изменение модели – распределенные системы контроля версий работают с изменениями (changes), а не с версиями. Если централизованная система контроля версий «думает»: у меня есть версия 1, после этого будет версия 2, после этого версия 3 и так далее. В распределенной системе все по другому: сначала не было ничего, потом добавлены эти изменения, потом добавлены те, и т.д. Изменение программной модели должно изменить модель пользователя. Теперь пользователю тоже придется мыслить в терминах изменений. Если раньше было: «Я хочу получить версию номер Х», или «Я хочу последнюю версию», то теперь: «Хочу получить набор изменений Пети».
Это смена парадигмы! Именно поэтому, когда вы переходите с Subversion на Mercurial, у вас вроде бы все получается, но вас новая система все время расстраивает, вы не можете к ней привыкнуть, и начинаете её ненавидеть. Только когда вы начнете мыслить в терминах «изменении», и выбросите из головы «версии» все встанет на свои места. Именно изменение модели работы системы контроля версий привело к существенному упрощению слияния (merge) кода. И соответственно к более активному использованию ветвления, использованию его там, где оно необходимо. Теперь можно не думая о сложностях последующего слияния создавать долгоживущие ветви для команд тестирования и поддержки и создавать короткоживущие ветви для экспериментов.
Если вы все еще используете SVN – перестаньте. Mercurial и Git – это антибиотики. Теперь существуют технология лучше.
И, вы знаете, я с Джоелом согласен почти полностью. Джоел смог объяснить то, что понимает каждый, кто освоился в распределенных системах. Но не каждый сможет выразить это словами. Это действительно смена основной концепции системы контроля версий, и именно из-за этого DVCS так туго входят в коллективы программистов. Наблюдаю это на личном опыте. Все привыкли мыслить категориями Subversion, и как только человек видит новую ветку в репозитории, даже ту, которая по идее скоро сольется с основной – он почему то пугается.
Продолжая пугаться, и не совсем понимая основных принципов системы, человек продолжает делать коммиты «раз в сутки», вместо того, чтобы делать коммиты по необходимости, по завершению каждой связной частички.
Однако распределенные системы контроля версий – это отнюдь не антибиотики. Главная проблема, как и всегда, в головах. И без решения этой проблемы никакой Hg, Git или Bazaar не спасет. Да, они гораздо больше соответствуют workflow разработки ПО, и большинство действий в этих системах легко объясняется логической необходимостью и разумностью. Но способов выстрелить себе в ногу в них значительно больше, хотя они и не очевидны. Наблюдал однажды картину, когда 4 разработчика постоянно работали каждый в своей ветке – в этом случае никакая смена парадигмы контроля версий не поможет.
Распределенные системы контроля версий – это отличная вещь, это действительно шаг вперед, который открывает каждому разработчику новые возможности и новую функциональность. И это действительно происходит за счет смены модели взаимодействия, Джоэл, безусловно, прав. Но, мне кажется, воспринимать их как серебряную пулю неправильно. Они избавляют от значительной части головной боли связанной с контролем версий, ветвлениями и слиянием. Однако от кривых рук они все равно не вылечат. Поэтому все равно необходимо нормально разбивать задачи, думать головой, и мержиться не раз в месяц с десятком изменений в каждом файле от каждого автора. Тут уж никакой Mercurial не спасет.

вторник, 9 марта 2010 г.

Известные баги System.Net.Mail.SmtpClient в .NET 3.5

Progg it
Сегодня открыл для себя некоторые глюки класса System.Net.Mail.SmtpClient в .net framework 3.5. (Я уже не говорю что творилось с System.Web.Mail.*, но оно уже obsolete и слава небесам. RIP).
1. Некорректная реализация команды EHLO протокола SMTP. Согласно RFC#821 ещё лохматого года необходимо передавать FQDN хоста-отправителя, причем по RFC это правило строгое. Вместо этого в MS решили, что хватит и NetBIOS-имени компа. Соответственно сервера, не отклоняющиеся от стандарта посылают ентот SmtpClient лесом, как пытающийся разослать спам. Решения нет. Есть только очень неочевидный WorkAround через Reflection.
2. Вытекает из первого. MS хотела как лучше, и разрешила называть компьютеры в NetBIOS сетях именами с символами из национальных алфавитов. Мало того, собсно Windows 7 RU предлагает подобное имя при установке! (Правда при попытке сменить руками, уже после установки, честно предупреждает что нехорошо использовать символы русского алфавита). И, как я уже говорил выше, это NetBIOS-имя использует SmtpClient в качестве имени хоста, правда никак не кодируя символы национальных алфавитов. После чего сам же валится с исключением "недопустимый знак в заголовке электронной почты". Собственно исключение то другое, но вот InnerException именно такой. Решения нет. Есть только очень неочевидный WorkAround через Reflection.
3. Очень интересный взгляд на стандарты почтовых протоколов со стороны MS. Все уже привыкли, что MS если и читает чужие стандарты, то как то очень избирательно. Вот и стандарт на SMTP также ими был прочитан. И, соответственно, также реализован. Что привело к тому, что некоторые SMTP сервера напрочь не работают с SmtpClient от MS. Например Kerio. Решения нет. WorkAround'ов нет.
Обиднее всего то, что все это хозяйство тянется ещё с .net 2.0, все эти баги давно зарегистрированы, но MS плевало на отправку почты. Надо бы их SmtpClient с hotmail'ом проверить. Интересно, заработает ли?