https://mtsepkov.org/index.php?action=history&feed=atom&title=ArchLabs-2009 2026-04-21T11:58:15Z История изменений этой страницы в вики MediaWiki 1.26.4 https://mtsepkov.org/index.php?title=ArchLabs-2009&diff=1148&oldid=prev 2010-01-13T20:24:23Z

<p>оформление, орфография/пунктуация</p> <p><b>Новая страница</b></p><div>[[Категория:Конференции]]<br /> <br /> = Общее впечатление =<br /> <br /> Общее впечатление — конференция гниловата, в отличие от AgileDays. Живых докладов мало, выбирать конкретно приходилось не по принципу интересующей темы, а по принципу живого доклада. Хотя, может, я пристрастен…<br /> <br /> Доклады, которые слышал, можно разделить на три группы.<br /> * Собственно, про архитектурные решения в том или ином виде.<br /> * Про великую и прекрасную архитектуру вообще и ее описание.<br /> * Про конкретные продукты, который можно использовать — от вендоров этих продуктов.<br /> Собственно, в этом порядке и буду делиться впечатлениями.<br /> <br /> А еще я выиграл сертификат на 12 часов online-курсов в Люксофт до 31.03.10. Если кому нужен — у HR.<br /> <br /> = Доклады про архитектурные решения =<br /> <br /> В эту группу попадает четыре доклада из числа услышанных.<br /> * Михаил Заборов. Аналитические планы счетов как архитектурный артефакт<br /> * Дмитрий Завалишин. Архитектурные детали ОС нового поколения Phantom<br /> * Дмитрий Завалишин. Архитектура высоконагруженных java-приложений (отчасти условно)<br /> * Сергей Горицкий. Использование MS BizTalk Server для разработки приложения с потоковой, сервисо-ориентированной архитектурой для реорганизации работ предприятия.<br /> По словам Игоря Беспальчука, о том же должно было быть «Сергей Ваганов. Tree в одном. ОС, метод, архитектура», но он пересекся с докладом Заборова, так что не знаю.<br /> <br /> == Михаил Заборов. Аналитические планы счетов как архитектурный артефакт ==<br /> <br /> Безусловно, сильно отличается от всех докладов конференции. Единственный, где был представлен реальный шаблон архитектуры, использованный более чем в одном проекте, как артефакт. Слушали заинтересованно, задавали вопросы. Но доклад был последним, с 16:35 — много народу сочло, что рабочий день уже можно закончить и просто ушли.<br /> <br /> Доклад пересказывать не буду. В целом — очень хорошо получилось, не только на фоне данной конференции, а в целом.<br /> <br /> Были вопросы, чем отличаемся от 1С — разные подходы, у них свой язык, а мы на общих платформах. Было удивление, что у нас есть АБС а мы ее не продаем, занимаясь вместо этого заказной разработкой — Миша объяснил позиционированием компании. Был вопрос про пересчет баланса — надо было увереннее отвечать, что особых проблем нет, а возникающие трудности — преодолеваются по месту (с примерами). У этого вопроса, кстати, может быть минимум 3 уровня проблем, в принципе такие вопросы надо собирать и рефлексировать.<br /> <br /> == Дмитрий Завалишин. Архитектурные детали ОС нового поколения Phantom ==<br /> <br /> Это проект новой, с чистого листа разрабатываемой ОС. На отличных от Unix принципах. Есть ли принципы у Windows, я не знаю, но. возможно, они примерно туда мигрируют…<br /> <br /> Идея — приложения живут вечно, то есть вечно открыты. Система обеспечивает их прозрачное сохранение в виде консистентного образа памяти, причем в случае сбоев восстанавливается имеющийся консистентный слепок. В такой архитектуре становятся не нужны файлы — вообще, разве что как вид транспорта данных. А весь диск тоже превращается в одну большую память.<br /> <br /> Возникают интересные эффекты — сборку мусора начинает работать не только в памяти, но и на диске, в том числе — удаляя всякие временные файлы (вернее, аналогичные им объекты), старые версии приложений и тому подобный мусор :). Сменные носители можно рассматривать как транспорт, либо как образ памяти отдельных «компьютеров», для которых включается свой версия ядра.<br /> <br /> Правда, со сборкой мусора на терабайтном пространстве есть проблемы, но тут помогает то, что у нас есть консистентный ''snapshot'', а мусор — он не может стать нужным. Поэтому собирать в фоне можно на нем, и это не будет влиять на текущую производительность. если ресурсов в целом достаточно.<br /> <br /> Правда, аппаратные ресурсы при перезагрузке теряют свое состояние, их сохранить нельзя. Но это проблема драйвера, и архитектурно обеспечивается обязательность решения: ресурсы к аппаратному обеспечению предоставляются как пограничные объекты, которые заведомо пропадают при перезагрузке, и драйверы должны обрабатывать соответствующие исключения. Плюс — такая архитектура хорошо поддается автоматическому тестированию.<br /> <br /> Вторая идея — защита не на уровне процесса, а на уровне объекта, объекты и ссылки на них можно легко передавать между приложениями. Включая передачу по сети и организацию прокси-объектов. Правда, это порождает задачу сборки мусора уже в рамках совокупности компьютеров, но это тоже решаемо…<br /> <br /> Проекту примерно год. Нынешнее состояние — ядро в целом как-то работает на эмуляторе в Windows и почти запустилось на голом железе (проблемы драйверов), есть основные драйверы, есть некоторое GUI (TinyGL), в каком-то виде TCP-стек, есть ограниченное портирование байт-кода JVM в байт-код этой машины. Планы — запуститься на железе, обеспечить OpenGL и поддержать JVM в хорошем объеме, избавиться от остатков GPL-лицензии и выложить все в OpenSource, но под другой лицензией.<br /> <br /> Все. Вполне интересно. Хотя пошел потому, что альтернативы — гнилые. <br /> <br /> == Дмитрий Завалишин. Архитектура высоконагруженных java-приложений ==<br /> <br /> Тот же автор, что и проект ОС Phantom. Пошел потому, что тяжело было с альтернативами.<br /> <br /> Основная мысль — надо думать. Потому что язык многое делает за тебя, скрывает сложность конструкций. Но если не думать — то приложения будут медленные. У них — позитивный опыт, в том числе — система судовождения ''Gardemarine'', которая должна жить в realtime независимо от сборки мусора и прочего самочувствия системы. Ну и детали — где именно надо думать. И местами — как они преодолели трудности. Например, отрисовку фона с градиентами — через кеш, который встроили на базовом уровне в отрисовку, а не в конкретный объект. Хотя лично я бы просто убрал градиенты — но стремления эстетов — понятны.<br /> <br /> == Сергей Горицкий. Использование MS BizTalk Server ==<br /> <br /> Вроде выступал раньше на других конференциях, но я слушал в первый раз — потому что с альтернативами было трудно. Это начальник IT-отдела на ФГУП Воткинский завод (Искандер, Тополь и многое другое). Производство — уникальное и сложное. И оборонное, поэтому сами разрабатывают модули вокруг Паруса.<br /> <br /> Они не могут позволить централизованное решение на СУБД. Моя интерпретация — потому что не получается сделать команду поддержки проекта. Поэтому режим — человек-проект, модули — небольшие. И дальше они пытаются использовать современные технологии интегрирования для их объединения, наступая на многочисленные грабли. Но идут вперед. О чем и был рассказ. Правда, самые большие грабли — не получается у них читать английскую документацию, а по-русски всего очень мало. Но это, во многом, тоже объективные условия — Удмуртия.<br /> <br /> Я слышал два проекта. Первый — заявленный в названии, BizTalk. У них быстро получилось взлететь на текстовых файлах. А вот построить взаимодействие через сообщения вместо файлов — почему-то не выходит… Второй — связать несколько модулей через SharePoint. Выставить web-сервисы — получилось быстро, а вот заставить взаимодействовать с помощью какого-то дизайнера бизнес-процессов в VS — не получается. Максимум — один к одному, просто коммутация, а хочется — более сложные схемы. Пока научили нопрямую вызывать сервисы модулей друг друга без SharePoint — так оно работает. Но они борьба продолжается…<br /> <br /> Такие вот романтики. В целом — вполне понятно желание выступить, но архитектура…<br /> <br /> = Про конкретные продукты, который можно использовать — от вендоров этих продуктов =<br /> <br /> Из этого заходил только на один доклад — «Александр Хельвас. Adobe LiveCycle. Какие гвозди подходят к этому молотку», опять-таки по отсутствию альтернатив, и слушал частично. Вообще эту секцию проводили в одном из больших залов, но народ шел сильно неохотно, с третьего доклада ее перевели в маленький зал…<br /> <br /> == Александр Хельвас. Adobe LiveCycle ==<br /> <br /> Рассказывали про решения на основе AdobeReaderExtention. Это как создаешь в этой штуке форму, которую дальше пользователь обычного AdobeReader может заполнять. При этом в форму можно вставить справочники, включая ОКАТО (но это — предел сложности). И проверку логики на JavaScript или чем-то похожем. Анонсируемая область применения — сбор всякой информации, если у отправителя нет доступа к инету. Правда, если формы не тривиальные, то у них должен быть достаточно мощный комп, чтобы все шевелилось. А в российских условиях там, где проблемы с инетом, и компы стоят не новые, типа P3… Передача результата — заполненный xml, который при необходимости можно зашифровать и электронно подписать.<br /> <br /> А еще, если инет все-таки есть, то это приложение может обращаться к серверу, получать и принимать данные оттуда. Можно делать формы с индивидуальной настройкой на клиента и прочее. И результаты получать поверх инета, тоже зашифрованные и подписанные.<br /> <br /> А лицензируется все это — на одну изготовленную форму, плюс отдельно — инструмент изготовления.<br /> <br /> В целом — неинтересно. Такая примитивная платформа для простых и кривых приложений…<br /> <br /> = Про великую и прекрасную архитектуру вообще и ее описание =<br /> <br /> В эту группу попадает три доклада из числа услышанных.<br /> * Олег Боев. Документирование архитектуры ПО: обеспечение потребностей заинтересованных лиц.<br /> * Андрей Вербицкий. Что такое «хорошая архитектура». Субъективные и объективные критерии.<br /> * Дмитрий Безуглый. Как добиться понимания Архитектуры заинтересованными лицами проекта. (Презентация архитектуры)<br /> <br /> == Олег Боев. Документирование архитектуры ПО: обеспечение потребностей заинтересованных лиц ==<br /> <br /> Был аншлаг. А получился отстой. Докладчик рассказывал про то, как надо описывать по стандартам. Учитывая, что архитектуру — читают разные люди и им нужна разная информация. Показывал ER-схему, где есть система, архитектура, лица, представления (view) для них сделанные с помощью viewpoint — шаблонов, описывающих интересную этим категориям информацию. Эта схема, кстати, была еще у Безуглого, но в более авторсокй интерпретации. а тут — взята из стандарта, причем квадратики большие, а надписи маленькие.<br /> <br /> Все это было в таком ужасающе медленном темпе подачи содержательной информации, что я не выдержал и ушел.<br /> <br /> Но в начале был перл: «Лучше описывать архитектуру кратко, а то потом замучаешься все это поддерживать». Такая вот авторская интерпретация, почему описание архитектуры должно быть небольшим…<br /> <br /> == Андрей Вербицкий. Что такое «хорошая архитектура». Субъективные и объективные критерии ==<br /> <br /> Весьма живой и интересный докладчик. В докладе много аналогий программной архитектуры и архитектуры реальной. Выводы — что архитектура определяется не технологиями, что красивое решение не гарантирует хорошей архитектуры, равно как и функциональное. Что архитектура должна учитывать ландшафт, окружение.<br /> <br /> Описание архитектуры должно быть кратким, включать только главное — чтобы это можно было держать в памяти. Что если вы проектируете птицу, то надо следить за способностью к полету, а то может получиться пингвин, для запуска которого нужна катапульта. И что многие проекты напоминают такого пингвина с катапультой. В вопросах сказал, что Linux совершенно не имел ввиду, это случайно.<br /> <br /> Говорил о компромиссе между универсальностью и функциональностью — универсальность ограничивает функциональность в конкретных условиях. О том, что сравнивая и выбирая решения надо рассчитывать на послезавтра, когда приложение будет работать: сегодня проектируем, завтра разрабатываем, послезавтра выпускаем. Упоминал ТРИЗ, в частности метод маленьких человечков, принцип Парето.<br /> <br /> Очень позитивно оценивает Agile — ориентация на результат по каждой итерации и вообще итеративная разработка, во-первых, уменьшает основной риск — время устаревания требований, а, во-вторых, препятствует появлению в принципе неработоспособных решений. На него наезжали из зала, некоторое время он возражал, но конструктива не получилось и рефери из организаторов это прервал.<br /> <br /> В качестве текущих вызовов архитектуры выделил ''Identity'' (единая авторизация и система прав), CRM (ориентация на клиента в самом широком смысле) и SelfCare (самообслуживание клиентов, тоже в широком смысле, когда им доступны те же интерфейсы, что и сотрудникам с точностью до прав). Но конкретика у него не слишком убедительная.<br /> <br /> Сожалел по поводу того, что в отличие от реальных архитекторов, программисты не могут посмотреть и пощупать другие успешные решения: нет библиотек, внутри все весьма закрыто. Шаблоны — это да, но это — наработки, а не готовые решения. Тут у него была дискуссия с аудиторией, но она не слишком получилась — все-таки уровень у него и у аудитории был сильно разный.<br /> <br /> В целом — интересный взгляд сверху.<br /> <br /> == Дмитрий Безуглый. Как добиться понимания Архитектуры заинтересованными лицами проекта ==<br /> <br /> Впечатления — смешанные. Не понравилась позиция автора — Гуру, который учит зеленых технарей, определенное высокомерие. Правда, на определенные амбиции он имеет право, это видно из информации (крупный проект — 50 чел, 30 чел-лет, большой бюджет — 2.5 млн$), и вообще из уровня мышления. Но надо уважать слушателей. <br /> <br /> Если отстраниться от позиции, то доклад — эклектичен.<br /> <br /> Первая компонента доклада — про описание архитектуры в целом. Описание должно быть коротким и не включать большие заумные схемы. И вообще стремление программиста поместить все на одну большую схему — не для презентации. Потом в авторском варианте была ER-диаграмма из стандартов — система, архитектура, лица, представления (view) для них сделанные с помощью viewpoint — шаблонов, описывающих интересную этим категориям информацию. Определения архитектуры и обязанностей архитектора он не дал, хотя из зала хотели. И про описание тоже, была триада <br /> * Проблематизация — выявление проблем, <br /> * Тематизация — набор решений, <br /> * Метафоризация — упаковка решения, <br /> но попытки как-то конкретизировать не получились.<br /> <br /> Вторая компонента доклада — о том, что архитектура — это не очередная модная технология или серебряная пуля, она должна быть связанна с потребностями заказчика и отвечать его вызовам по цепочке «Вызовы — Цели — Преимущества — Проект — Архитектура». Почему Вызовы, а не Проблемы? Потому что наличие проблем означает сомнение в качествах менеджера от бизнеса, а он не любит, если в нем сомневаются. Поэтому сейчас и можно говорить, что проблем нет, есть вызовы. При движении по этой цепочке для архитектуры были упомянуты некие Сценарии атрибутов качества, связывающие архитектуру с бизнесом.<br /> <br /> Докладчик ссылался на подход Microsoft по поводу продажи архитектуры, вроде, что в презентации должны быть ссылки.<br /> <br /> Из зала попробовали зайти с другой стороны — с обязанностей архитектора, указав на то, что связь с бизнесом — это, скорее, бизнес-аналитик. В ответ было пренебрежение бизнес-аналитиком. А определение архитектора он дал вполне интересное: «тот, кто связывает точки зрения».<br /> <br /> Но в целом на всем этом лежит несмываемая печать RUP и твердая уверенность в его правильности. Отсюда же — крайне негативное отношение к Agile вообще, и к его способности производить архитектуру в частности.<br /> <br /> И третья компонента доклада — про подготовку презентации, восприятие. О том, что проект дают под людей, а не под технологии. О том, что надо задействовать все каналы восприятия, потому что 55 % картинки, 30 % слух, 3 % чтение и 12 % соучастие (действие). Стили восприятия — 35 % обсуждение (вопрос почему?), 22 % логика (нужна первичка), 18 % практический опыт, 25 % самообучение. Принципы принятия решений — сфокусированный, логический, креатив, эмоции. Соответственно, когда готовите презентацию, то надо иметь ввиду все группы. Это сложно, но можно, и потому — нужно. Интересный факт, по статистике для обычных людей в 80 % случаев достаточно уверенно сказать «причина есть», можно даже ее не обсуждать.<br /> <br /> В целом все.</div>

StasFomin