Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри

Только в официальной документации об этом не написано, нужен консультант, желательно от самого Microsoft. Вызов консультанта с предварительным утверждением бюджета – это ещё неделя простоя. Поэтому вариант отвергается.

Принято решение ставить все на один виртуальный сервер. Администраторы кисло морщат лбы, потому что кластер уже настроен под регулярные процедуры поддержки баз данных, а так они получат ещё один сервер в обслуживание, хоть и виртуальный. Но нехотя соглашаются.

Переустанавливаем на него: SQL Server, Reporting Service, Analysis Services. СУБД и все компоненты настроены и работают. Ухожу заниматься собственно делами проекта.

Вскоре у коллег начинаются новые проблемы: не ставится TFS с неким сообщением об ошибке, на которое в гугле находится всего 2 записи, и кода прохождения этого уровня занимательной игры в них нет.

Начинается переписка с экспертами по TFS уже нашей родной конторы. Находим, что вручную и строго предварительно нужно было ставить Sharepoint не ниже 3.0 Service Pack 1. Потому что под Windows 2008 Server установщик TFS этого не делает. Выясняется, что в Windows 2008 Server стандартной версии при попытке добавить роль AppServer искомые службы Sharepoint в списке отсутствуют. Надо её скачивать и устанавливать. Что и было в итоге сделано.

Чуть позже обнаружилось, что при инсталляции служб Sharepoint был выбран полный режим, что неправильно, потому что при этом установщик ставит собственный экземпляр SQL Server Express, игнорируя уже имеющийся на сервере.

Сносим службы Sharepoint, но оказывается, что созданный экземпляр SQL Server инсталлятор Sharepoint не удаляет. Ну что же, удаляем сервис руками, чистим каталоги и реестр.

Дальше работа возобновляется без моего участия, и к вечеру четверга приходит радостная весть: TFS встал, можно попытаться к нему присоединиться.

У всех пользователей похожие имена типа tfs_userNN. На моей локальной виртуальной машине есть проблема: не могу добавить файлы в репозиторий. Права у всех одинаковые. Сообщение об ошибке, связанное с « cloaked folder », также в гугле встречается редко. Ищем корень проблем в виртуальной машине (VitrualBox вместо VPC 2007), потом в виртуальном диске – проекции ( subst ) директория. Подозрения не подтверждаются. Проходит полдня, создаётся новый пользователь с аналогичными правами. Заработало, но причины так и остались неясны.

В этот момент администраторы прописывают имя нашего сервера в корпоративной DNS [123], теперь можно отказаться от использования прямого адреса.

Первое же действие выдаёт окошко регистрации, которая проходит нормально, но все последующие операции дают ошибку 401 not authorized.

На удивлённый вопрос «Что случилось?» от администраторов приходит «письмо счастья» с прикреплённым файлом конфигурации для proxy , который надо поместить в корневой каталог локального (!) Internet Information Server, вот такая неочевидная связь. Проблема была в том, что сервер запрашивал авторизацию всякий раз, тогда как клиент TFS делает это только при первом обращении. Файл хитрым образом проблему решает.

Новая проблема, папка Documents в Visual Studio заблокирована, хотя на веб-портале проекта она видна и можно добавлять туда файлы. Ладно, это не фатальная проблема. Главное – репозиторий исходников работает. Почти как на SVN.

Идея разрабатывать программы, минимизируя стадию кодирования на конкретных языках под заданные платформы, появилась достаточно давно. Прежде всего в связи с неудовлетворительной возможностью языков высокого уровня третьего поколения (3GL) описывать решаемые прикладные задачи в соответствующих терминах. За последнее время к этой причине добавилась ещё и поддержка независимости от целых платформ, ведь прогресс, как мы знаем, неотвратим, особенно «прогресс».

В управляемой моделями разработке [124](УМР) и в программной фабрике [125]в частности наиболее интересной возможностью является генерация кода, скомпилировав который, можно сразу получить работающее приложение или его компоненты. Мы проектируем и сразу получаем нечто работающее, пусть даже на уровне прототипа. Уточняя модели, мы на каждом шаге имеем возможность видеть изменения в системе. Проектирование становится живым процессом без отрыва от разработки.

Историю управляемой моделями архитектуры и разработки, обобщаемой под термином УМИ – управляемой моделями инженерии [126], можно вести с 1970-х годов. Именно тогда появились первые языки спецификации требований к программам и целые стандарты, типа упоминавшегося IDEF, включающего в себя ряд языков и нотаций. Однако реальная и доступная многим пользователям автоматизация моделирования появилась лишь вместе с персональными компьютерами. Не случайно форматы IDEF-диаграмм исторически сохранили рамки с ячейками информации, столь необходимыми при бумажной технологии анализа проектирования.

Первые инструменты CASE, выросшие из редакторов графических примитивов, были представлены в 1980-х годах, а одним из пионеров был небезызвестный Эдвард Йордон, соавтор, в компании с Томом ДеМарко, популярной методологии SADT [127]. В начале 1990-х годов наблюдалось возникновение множества языков, нотаций, подходов к анализу и проектированию и, как следствие, пик многочисленных CASE-инструментов, их реализующих.

У программистов «от сохи» отношение к CASE, как правило, негативное на уровне «я не верю, что какие-то картинки генерируют код лучше написанного руками». В таком отношении есть своя сермяжная правда, действительно, экскаватор, в отличие от мужика с лопатой, может вырыть не всякую яму. Доказывать обратное – бесполезная потеря времени.

У более продвинутых программистов, имевших опыт написания и сопровождения тысяч строк однотипного рутинного кода, претензии становятся обоснованными и касаются, как правило, следующих сторон применения CASE-средств:

• Если ручное написание кода принять за максимальную гибкость, то CASE может навязывать каркас, стиль кодирования и шаблоны генерации частей программ, ограничивающие не столько полёт фантазии программиста, сколько возможность тонкой настройки генерируемого кода. Неважно, что такая настройка не требуется в большинстве случаев, но если её нет, то менять придётся непосредственно сгенерированный код.

• CASE работает только в условиях дисциплины, когда ручные изменения генерируемого кода исключены или автоматизированы (пост-обработка). Как только программист залезает руками в код каркаса, модель оказывается рассинхронизированной по отношению к исходным текстам программ и процесс разваливается.

В качестве решения перечисленных проблем появились так называемые двусторонние CASE-инструменты ( two way tools ), позволяющие редактировать как модель, непосредственно видя изменения в коде, так и, наоборот, менять код с полу– или полностью автоматической синхронизацией модели. Зачастую, такой инструмент был интегрирован прямо в среду разработки.