Макс Цепков - отчет о ADD-2010

Общее впечатление

Конференция Application Developer Days 2010 проходила 23-24.09 в Ярославле. Материалы конференции будут на www.addconf.ru. Многие презентации выложены на SlideShare.

Общее впечатление — конференция удалась. Она живая, было интересное общение, были доклады на которых я узнавал новое. И очень существенно — были доклады, натолкнувшие на размышления и новые мысли, которые дальше буду обдумывать, обсуждать и как-то применять в работе.

При этом в целом поле деятельности участников конференции и особенно докладчиков с сегментом работы нашей компании пересекается слабо. Разработки учетных систем — почти нет, в основном — всякая internet-разработка, немного игр. Но в рамках internet есть и большие проекты с нагрузкой. И конференция действительно преимущественно разработческая, а не менеджерско-тестировочная.

Кстати, интересно, а на какие конференции ездят разработчики корпоративных и банковских учетных систем, включая inhouse? Или таковых нет? На ЛАФ-2010 аналитики из inhouse и корпоративной разработки были, хотя и немного.

Что касается моего доклада, то слушали с интересом, просили распечатки презентации (немного). Но вопросы были о том, как нам, заказной разработке, удается конкурировать с решениями от вендоров. Я об этом немного рассказывал — про поддержку уникальных бизнес-процессов.

Дальше рецензии по докладам, группированные по моему интересу к ним. Ряд докладов слушал частично. И, увы, не все интересные смог послушать из-за пересечений по времени. Это относится к докладом Стаса Фомина и других сотрудников CUSTIS (благо есть информационный обмен внутри), а также докладов Андрея Бибичева и круглого стола «Java vs C#». И было мало моментов, когда выбирал доклад по далекой теме просто потому, что альтернатив особо не было — и это не смотря на слабое пересечение предметных областей. Так что в целом набор докладов был очень хорошим, спасибо Стасу и другим организаторам.

О круглых столах стоит сказать отдельно. Все-таки их надо жестче модерировать. Потому что по многим вопросам от отдельных участников был активно повторяющийся негатив в стиле «X плохо потому что не дает решения для Y». В одних случаях это было актуально, в других — относилось к устаревшим версиям, с которыми человек имел дело. Естественно, это актуальная информация, однако относительно часто подразумевался вывод — «а поэтому X не стоит обсуждать», поэтому тезис повторялся при почти каждом упоминании X уже в других аспектах. А это — мешало пойти дальше. В качестве позитивной идеи — наглядно фиксировать тезисы, с которыми участники согласились и дальше не давать повторяться, направляя дискуссию вперед.

Кратко о докладах

Краткие рецензии передают мои впечатления от докладов. Интересные доклады дальше изложены более подробно — что я записал. Я считаю, что это полезно, так как поможет оценить стоит ли смотреть презентации и доклады.

Интересно и полезно для моей работы 

• Константин Кичинский. Прототипирование приложений с Expression Blend + SketchFlow. Может быть, доклад и не интересен для знакомых с этими инструментами, но именно на нем мне пришла мысль о сфере возможного применения у нас в компании — макет на псевдореальных данных, который можно посмотреть на мониторах с разным разрешением и разными фонтами — чтобы все это приемлемо влезало на экран. И чтобы накидать формы за 2-4 часа. Спасибо докладчику за live coding, в котором все это было показано. И спасибо Сергею Пугачеву, у которого был доклад вечером на близкую тему и с которым мы обсуждали детали инструмента (Константина я не успел поймать для разговора).
• Андрей Майоров. Об удобстве иерархических структур данных. Описана интересная конструкция, сформулированная как архитектурный шаблон, используемый для приличного класса приложений. У них есть фреймворк для реализации этого под web, но доклад был именно об архитектуре. Мне она показалась интересной, у нас в некоторых системах был реализован частный вариант, а другие системы, на мой взгляд, оказались бы лучше при использовании идей этого архитектурного шаблона. Ну и в будущем буду держать этот шаблон в голове при проектировании новых систем. За что спасибо докладчику, надеюсь мы продолжим общение и сможем обмениваться опытом.
• Антон Овчинников. Деньги и внутренние часы разработчика. Рассказ не теоретиков, а практиков об управлении компанией с применением методик, регламентов и нормативов. Весьма высокого уровня. Этим и интересен, а некоторые мысли могут быть применимы у нас. Мне слушать доклад было очень интересно.
• Круглый стол SQL/NoSQL. Хотя с точки зрения концепций верхнего уровня ничего нового не узнал, возникло несколько частных идей по конкретным решениям, навеянных обсуждениями — по хранению разнородных атрибутов, ведению лога. За что спасибо участникам обсуждения.
• Андрей Аксенов. Как прекратить писать. В докладе эмоционально рассмотрено множество известных граблей. И это у меня вызывает рефлексию по поводу собственных неправильных действий и таким образом стимулирует меняться к лучшему. Понятно, что у некоторых людей доклад может вызвать раздражение — зачем рассказывать об известных граблях. Но периодическое повторение как раз помогает. Так что — спасибо докладчику.
• Олег Аксенов. Адаптивная архитектура. Предмет доклада очень близок к моей деятельности — речь шла про разнообразные шаблоны приложений, с различными примерами. Но основная мысль доклада, что архитектура может быть очень разной, решение может определяться как общими принципами, так и ситуацией — сроками, персоналом. Для меня эта мысль достаточно очевидна. И связанные мысли, про итеративность архитектуры — тоже понятны. Практики у них близки к нашим, но не раскрывались настолько детально, чтобы можно было критично сопоставить. В целом было интересно.
• Андрей Бибичев. Мастер-класс Domain-Driven Design. Реально был на фрагменте, когда Андрей говорил об общих положениях, хотя заходил и раньше, в процессе. Шаблоны мне достаточно известны, так как многое вынесено из работы внутри компании. Но в мастер-классе они позиционированы в контексте мировых представлений и это интересно.

Интересно для общего развития 

• Евгений Кирпичёв. Многопоточное программирование. Много интересных проблем и шаблонов их решения. А еще после доклада мы обсудили, что такое монада, и как linq связан с функциональным програмированием. За что докладчику — отдельное спасибо.
• Дмитрий Завалишин. Фантом-ОС. Об этом интересном проекте знал раньше, сейчас актуализировал для себя текущее состояние.
• Елена Сагалаева. Искусственный интеллект в играх и C++0x. Узнал много интересного для себя по этим областям. Доклады — очень живые и это прекрасно.

Остальное — отчасти не запомнилось, а отчасти — по понятной причине отсутствия на докладах.

Интересно для работы

Андрей Майоров. Об удобстве иерархических структур данных

В докладе описана весьма интересная конструкция, которая сформулирована именно как архитектурный шаблон или фреймворк. Берем произвольную систему и представляем ее данные как файлы в иерархию разнотипных объектов. Очевидная конструкция — новости по темам или товары в классификаторе. Но есть и более сложные конструкции, например, клиенты, под ними — их договора, еще ниже — какие-то документы по договору. По этой иерархии — отношение часть-целое, права доступа. Помимо основной иерархии есть побочные двух видов — связи и агрегаты. Связи — например, разметка новостей тэгами. Или — взаимодействие между разными документами, например, есть клиент с документами-запросами и менеджер с документами-ответам, которые связаны с этими запросами. Агрегаты — это более сложный вид часть-целое, пример — ценник товара для магазина. У него предок — магазин, а агрегат — товар. Это все виды связей, а внутри вида могут быть связи разных типов.

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

Реализован фреймворк, в рамках которого подобные структуры из разнородных объектов можно хранить и с ними работать. Хранится все в SQL, под объекты заводятся таблицы с основными атрибутами, остальное — в xml-поле, БД позволяет работать с содержимым и его индексировать. Но суть не в реализации, а в архитектуре.

Мне лично показалась идея весьма перспективна, особенно в части справочников. Мы видели и делали честные реализации — каталог товаров и справочник комитентов — пример такого подхода. И мне лично кажется, что если бы мы так делали справочник субъектов, он бы взлетел. Смысл тут именно в гибкости, в нестрогой типизации и понятности пользователям. У пользователей часто возникает желание для начала — начать хранить что-нибудь в базе данных. При этом область может быть слабо формализована, например, договора какие-нибудь. И пользователь до конца не знает, какая структура будет правильной. Чтобы узнать, он должен достаточно много договоров туда положить, по ходу дела дорабатывая структуру. В описанном подходе такая возможность у него есть.

В общем, я вижу определенные перспективы применения такого подхода. Мы немного обсуждали с Игорем, у него такого мнения нет. Посмотрим, обсудим… Если свалится, например, реестр документов, можно будет попробовать применять…

Антон Овчинников. Деньги и внутренние часы разработчика

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

Решается несколько взаимосвязанных проблем. Во-первых, у сотрудников компании не должно возникать ощущения, что с их помощью кто-то в компании зарабатывает бешеные деньги, для чего они должны представлять, на какие цели уходит разница между внешней ставкой их часа и зарплатой, составляющей 25-30 % от нее. Во-вторых, в силу высокой конкуренции на рынке компания должна четко представлять себестоимость своей работы и уметь ее планировать. А в-третьих, формализация и организация процессов позволяет уменьшить эту самую себестоимость, а также риски компании.

Интересно, что первая задача, с точки зрения докладчика — действительно первая по приоритетам, поскольку снимает негативные настроения сотрудников. А негативные настроения — они разрушительным образом сказываются на производительности.

Первая задача решается через открытость и прозрачность информации о структуре расходов компании, включая структуру дополнительных работ, связанных с управлением проектом, а также резервов на дополнительные работы, которые возникают в каждом проекте но которые не принято предъявлять заказчику. Это же способствует решению второй задачи. Все эти данные есть в агрегированном виде, а также с детализацией — поскольку для прогноза и учета стоимости проекты декомпозируются и оцениваются, а потом фиксируется фактическое время выполнения. И все это доступно внутри компании всем сотрудникам через внутренний портал.

Информация не просто представляется на портале, а еще регулярно презентуется сотрудникам. Интересно, что при этом сотрудникам делят по психологическим типам. Используются следующие группы: Анализатор (50 %), Контролер (25 %), Мотор (10 %) и Поддержка (15 %).

К моторам относятся в основном — менеджеры, а к Поддержке — творческие люди, например, дизайнеры. Проценты показывают соотношение в компании.

• Самая большая группа — анализаторы, и, собственно, на них нацелен основной формат представления через формулы, графики и картинки с большим количеством фактологии. Предполагается, что они сами смогут провести анализ и сделать выводы, и даже если им эти выводы представить — все равно будут проверять и убеждаться. Главное для них — понять, что нет подвохов.
• У контролеров аналитическое мышление не столь развито, с одной стороны, а с другой — им нужны более четкие обоснования рациональности расходов.
• Моторов расходы особо не интересуют, они сосредоточены на доходной части и их доле в ней, а также — на возможностях увеличить доходы.
• А сотрудников поддержки больше интересует их ценность для компании как сотрудников. Таким образом, хотя представляются общие факты, аргументация и акценты — различны, и важное для одних менее важно другим. Кроме того, надо, чтобы информацию представляли сотрудники, обладающие достаточным авторитетом.

Что касается организации процессов компании, то она достаточно высокая и формальная. Они сертифицированы по ISO 9001:2000 и относятся к этому не как к формальности — они верят, что это сильно помогает работе. Процессы меняются, и достаточно активно, поэтому раз в год сотрудники проходят аттестацию, при подготовке к которой они как раз и должны актуализировать свои представления о процессах. Что касается профессионального роста, то для основного потока задач есть нормативные часы «абстрактного разработчика», и для сотрудников меряется индивидуальный коэффициент по отношению к нему. Ну и оценивается сроки и качество исполнения работ.

Новый персонал нанимают не столько за знания и профессиональные умения, сколько за правильную жизненную позицию и отношение к работе. Потому что умения можно приобрести, тем более что у них относительно формализованная область, а жизненная позиция — она изменяется слабо. Благодаря этому вместе с формализацией процессов им удалось сократить срок внедрения нового сотрудника на полную мощность с 6 до 1-3 месяцев. В целом отношение к людям взаимное, они полагают, что человеку правильно искать «своего работодателя», которым он был бы удовлетворен. И готовы выступать в этой роли. Интересно. что у них есть понятие целевого срока найма на работу — 3 года. Если разработчик проработал этот срок (и уходит без скандала), то они готовы дать любые рекомендации, а если он потом вернется — то принять обратно. Испытательный срок не проходит 20-40 %. Платить стремятся +20 % к рынку.

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

Это — то, что я успел записать. В презентации много слайдов с деталями, цифрами и подробностями, поэтому ее интересно посмотреть.

Если говорить о нашей компании (CUSTIS), то в целом презентация экономики Володей находится примерно на том же уровне. И представления о стоимости у нас есть. Но у нас более уникальные, длительные и технологические проекты, это накладывает много особенностей. А про индивидуальную презентацию — это актуально. Ну или общую, но с учетом аспектов восприятия разных людей.

Круглый стол SQL/NoSQL

К сожалению, большого конструктива не получилось. Резюмирую, что было. Было признано, что противопоставление в принципе NoSQL имеет два аспекта. Первый - это повышение производительности, выход из ограничений реляционных БД. Здесь признали, что нынешние NoSQL базы не является серебряной пулей - для этого они слишком новые, а реляционки уже давно борются за производительность. Но на конкретных задачах эффект может быть. А во-вторых, тут вопрос языка. NoSQL базы сейчас предлагают собственные языки работы, разной степени удобства, но все они - объектные и этим отличаются от SQL, этим близки разработчиком. Любопытно, что linq в этом контексте, как развитие объектных языков и нагрузку их реляционной семантикой никто не упоминал (а может, я пропустил это).

Еще из интересного. Акцентировали внимание, что NoSQL == Not only SQL, и использование объектных возможностей реляционных ОС вполне под это попадает. В частности, использование xml-полей для хранения дополнительных атрибутов - это применяется многими. Это напоминает наш финт в полем prm, но выгодно отличается тем, что конкретные значения из такого поля можно прозрачно использовать в запросах и индексировать — это поддерживается на уровне базы данных. Правда, там в основном MS SQL, но вроде у Oracle тоже все это есть. Так что стоит в эту сторону подумать.

Что касается конкретных задач, для которых подходит NoSQL, то упоминалось хранение исторического лога. Из конкретики, куда стоит посмотреть - http://hadoop.apache.org/pig/ (это по разговорам потом).

Олег Аксенов. Адаптивная архитектура

Предмет доклада очень близок к моей деятельности — речь шла про разнообразные шаблоны приложений, с различными примерами. Основная мысль доклада - что архитектура может быть очень разной, решение может определяться как общими принципами, так и ситуацией — сроками, персоналом. Для меня эта мысль достаточно очевидна. Особенно в рамках небольших проектах (как у них), а также небольших доработок и временных решений.

Интересная мысль была про то, что не надо слепо следовать авторитетам и рекомендациям. Во-первых - потому что там много чистой теории. не подтвержденной практикой. Во-вторых - потому что рекомендации давались в определенном контексте, а сейчас контекст изменился. Например, много рекомендаций по стилю написания программ (не использовать goto, единственный return) имели цель обеспечить возможность автоматической проверки правильности кода. Поскольку автоматической проверки так и не случилось, смысла в этих рекомендациях - нет. Хотя некоторые из них имеют и другую ценность, облегчают понимание и сопровождение кода. Таким образом, к авторитетам надо относиться аккуратно, а не как в известном эксперименте, в ходе которого жертвы доводили до смертельного удара током потому что авторитетный спец уверенно говорил, что все в порядке. Тоже самое дублирование кода - не всегда плохо, так как позволяет независимо изменять, и надо смотреть по ситуации.

А еще современная архитектура должна учитывать динамику проекта и быть к ним адаптивна. Были ссылки на статью Фаулера «Проектирования больше нет?» и на Кокберна «Каждому проекту своя методология». А еще - не надо думать вперед. Хотя я тут с ним не согласен - не надо делать, а вот думать - надо, чтобы в случае чего сделать было можно. У него был пример, про безопасность, которую вписали потом, рассыпав по тексту - и ничего страшного. Но по моему опыту - им или повезло, или из опыта система оказалась удачно спроектирована, что получилось вписать. А могло оказаться и не так, когда безопасность накладывается поперек сделанной объектной структуры.

Но при этом, что важно - архитектура внутри проекта должна быть, и она должна быть однородна, то есть для одних целей применяться один инструмент. То есть делать в одном проекте формы на MS, а интеграцию на Java - можно. А вот делать половину форм на MS, а половину на Java, и в интеграции применять всего понемногу - не следует. И то, что ключевой спец по определенной технологии заболел или уволился тут тоже не может служить оправданием для смеси. Или пытаемся завершить в том же ключе, или переписываем целиком.

Стоит повторно использовать технические решения, собирая архитектуру проекта по кусочкам из имеющихся наработок. Например, сделали удачную технику отправки почты в одном проекте - тиражируем и не заморачиваемся однородностью с другими участками проекта, если совместимость имеется. Также с ведением лога и с другими задачами. То есть однородность - в рамках задачи (аспекта), а не по проекту целиком.

Было много примеров архитектуры, но, к сожалению, они не были систематизированы и из них не было особых выводов кроме того, что «так тоже можно». Тем не менее, перечислю.

• Проект на Oracle+APS.NET, в котором всю логику вписали триггерами на базе данных, а интерфейсная часть получилась простая. Да, так обычно не делают, для поддержки и развития нужен опытный спец по БД (он был на разработке), зато уложились по срокам и бюджетам, и даже сильно опередили, и в целом оно довольно стройно выглядит.
• Требования от заказчика были на переписывание старой системы с mainfraim'а на новую платформу, при этом выписана куча if'ов и частных случаев. Классическая послойная реализация привела бы к тому, что все частные случаи пришлось бы протаскивать сверху-вниз по всем слоям, 5-6 методов вызывают друг друга. В результате на слои плюнули с сделали некоторый монолит. На вопрос из зала "а если бы самим сопровождать - все равно бы так сделали?" ответил, что "да", и вообще с удовольствием бы сопровождали, но заказчик сам разобрался в системе и за сопровождение платить не хочет.
• В проекте заказчик потребовал пару отчетов - быстро сделали на Excel с жестким кодом запроса. Ему понравилось, он захотел еще десяток и прицелом дальше на развитие - озаботились написанием библиотеки, теперь ее используют во многих проектах. Но если бы осталась пара отчетов - то Excel - лучшее решение.

Это, кстати, у нас хромает - мы или сразу пытаемся написать общее решение, или, наоборот, тиражируем частное без выделения библиотек без меры. Увы!

Практики компании сильно похожи на наши, хотя сама компания и проекты - меньше. Компания 20 человек, средние проекты - 3-4 человека, бывает - 2, бывает 8-16. 3-4 человека составляют архитектурный комитет компании, вырабатывают и проводят аудит решений. Проектную документацию ведут в wiki, при этом важная часть актуализируется по ходу, это примерно 20%, а остальное - разовое, то есть написано и лежит дальше как есть. Взрывной неоднородности архитектуры не возникает. Про обучение новых его личное мнение - что парное программирование здесь эффективно, но по факту применяют редко, обычно бросают в плавание. Однако, поскольку разработка в рамках некоторого фреймворка, определенная однородность сохраняется.

В рамки и бюджеты они не укладываются, но заказчик обычно удовлетворен проектом, и они именно это считают целью. На риск закладывают 1.4, и прерасход обычно в пределах статистики. Проекты все были успешными, кроме одного спорного - они писали замену 1С, но с выходом 9 версии заказчик решил, что не надо (оплатив сделанное).

Андрей Аксенов. Как прекратить писать

В общем, с названием доклад соотносится слабо. И формально в нем нет ничего нового, о чем докладчик сразу предпредил. В нем собраны много дилемм, в которых надо держать баланс программисту. Типа не оптимизируй заранее, но при этом — пиши оптимально. Или не пиши лишних комментариев, вообще их не пиши, но где надо — комментируй. И так далее. Все это очень энергично, с примерами и историями. Потом — несколько императивов. Типа, оптимизируй время разработки. Выбрасывай ненужный код, не жалей его. Учи классику — алгоритмы и программы, то, где работаешь надо знать хорошо, а остальное — представлять по верхам, экспериментируй, а не только учи по книгам — если задача — писать запросы, то покрути их денек на разных объемах данных, пойми, как это себя ведет. Изобретение велосипедов — неправильно в продакшен, но очень полезно для учебных целей, стоит это делать раз в несколько лет — и узнаешь много нового про современный уровень компов. Парадоксальный тезис, что программист не должен работать головой — надо технично использовать шаблоны, строить из кубиков, кубики — да, знать, но это ремесло, а не творчество. И это 90-99 %. А с оставшимся — тоже головой не думаешь, а идешь к техлиду. Но мастерство ремесленника — надо нарабатывать, тренировать. А еще любопытная аналогия, что программисты — они как проститутки, работают для удовлетворения клиента, цель в этом, и тоже часто на почасовой оплате.

В целом мне понравилось. И послушать, вспомнить все эти вопросы, по которым надо держать баланс и желательно на автомате — очень полезно. Хотя подсознательно возникает некоторое раздражение, потому что когда он рассказывает — вспоминаешь собственные ляпы по тем же причинам… Я надеюсь, что презентация и выступление будут в записи — я не с начала слушал…

Константин Кичинский. Прототипирование приложений с Expression Blend + SketchFlow

Может быть, доклад и не интересен для знакомых с этими инструментами, но именно на нем мне пришла мысль о сфере возможного применения у нас в компании — макет на псевдореальных данных, который можно посмотреть на мониторах с разным разрешением и разными фонтами — чтобы все это приемлемо влезало на экран.

Инструменты показывались в паре. Expression Blend - средство сделать визуальный прототип конкретной формы, в него можно показать данные. При этом можно делать некоторые базовые экраны, с элементами, используемыми на большом количестве форм. и конкретные формы делать на их основе. SketchFlow - средство для описания навигации между формами, а также навигации (изменения вида) внутри самой формы. В целом получается сделать модель интерфейса с реальными данными. Был live coding модельной социальной сети, в котором все это было показано. Правда, в несколько другой области, это web-разработка и основные фишки были с анимацией и динамическим изменением формы. Образцы данных вводятся вручную или импортируются из xml, есть какие-то инструменты генерации по характерным данным.

Сам доклад понравился, а к инструментам - я бы присмотрелся, если возникнет задача проектирования. Может, конечно. не именно к этим, а аналогам...

Андрей Бибичев. Мастер-класс Domain-Driven Design

Мастер-класс был очень длинный, я несколько раз заходил пока шло моделирование, а потом - слушал достаточно большую теоретическую часть. И это было интересно. Было достаточно много нашего народа, которые активно связывали модели мирового опыта, излагаемые Андреем с практиками CisUni.Net. Дальше некоторая структурированная выжимка - что я зафиксировал.

Выделяют несколько типов доменных моделей.

• Rich domain model. Логика базы данных внутри объекта, унаследованного от базового класса. При этом чем получается, что бизнес-объекты зависят от класса, обеспечивающего persistent-хранение, что как-то плохо ложится на стройную картину мира. Поменять реализацию хранения практически нельзя, мы не знаем, как ее поиспользвоали в бизнес-объектах. И вообще, жирный класс внизу - это минус.
• Pure domain model. То же самое, но с Injection of Control. Сервер реализует тот интерфейс, который нужен клиенту. При этом реализацию хранения можно легко менять, например, тестировать в памяти. И эта реализация - сбоку от бизнес-объектов. Однако получается больше кода и больше классов, в этом смысле pure-модель тяжелее.
• Entity Framework, с точки зрения Андрея, завис посередине между rich и pure подходами, унаследовав минусы (а вовсе не плюсы) от обоих. Но подробно не разбирали.
• Anemic domain model. Имеем типизированные записи, а вся логика уносится в сервисы, написанные в процедурном стиле. Практически при этом отсутствует инкапсуляция и целостность объекта. Если эти сервисы как-то объединены в домен, то еще можно говорить об объектах, а если они уровня приложения. то объектов - нет. Сервисы плодятся, что именно они делают с объектом и какой объект является консистентным - неизвестно.

Реально, эта классификация не общепринятая. Деление на Rich и Pure и схему в презентации Андрей взял из описания приложения в продакшн (перевоз грузов), считающегося "классической" реализацией на основе методологии DDD, и она отличается от схемы в теоретической книжке по DDD. А именно, на ней инфраструктура показана сбоку, а не внизу. На чем его и поймали.

Другим источником является Фаулера «Патерны корпоративных приложений», там идет противопоставление rich и anemic моделей, anemic трактуется как антипатерн, а pure-модель не упоминается и вопросами сохранения объектов - не занимаются.

С точки зрения Андрея, использовать anemic можно, процедурный подход был весьма продвинутым до ООП, там есть свои методологии. Просто надо быть к этому готовым.

Если говорить об области применения, то, по мнению Андрея:

• pure - это web 2.0, относительно бедная предметная область;
• rich - это enterprise-приложения со сложными объектами;
• anemic - это классический ORM, у объектов нет своей логики.

Если говорить предметно о взаимодействии с базой данных, то есть несколько подходов.

• Модель active record, в которой save - метод объекта. Семантически означает, что сохранение объекта - это тоже часть его бизнес-логики. Что как-то странно. А может, и нет - все от объектов зависит и их взаимодействия. Но возникает вопрос согласованности объектов в базе данных. Потому что консистентность проверяли в памяти, а потом один сохранили, другой - нет - это как?
• Модель Unit Of Work (не путать с транзакциями) означает, что изменения объектов накапливаются, а потом, все вместе сбрасываются отдельным методом в тот момент, когда операция полагается законченной. Это лучше с точки зрения консистентности, позволяет использовать групповые операции с объектами. Это хорошо, но только когда нет неявных изменений и сбросов состояния, срабатывающих в произвольный момент (а во многих ORM они есть). Иначе процесс получается неконтролируемым.
• Explicit State Transition. На логическом уровне есть только методы. Их можно применять как к объектам в памяти. так и к объектам базы данных и вы пишете журнал применения этих методов. Возникает хорошая инкапсуляция, система выдерживает высокие нагрузки, но требуется очень много кода - например. нет атрибутов, только свойства.

О ссылках. Их можно делать через lazy load, можно загружать сразу, но это тяжело, и можно вообще не делать, получаешь ключ и сам грузишь.

О блокировках. Есть три метода

• Happy day. Игнорируют конфликты ради производительности, делают всякие отчеты по сверке.Разбираться тяжело, особенно в распределенных системах. но другие подходы там тоже не легкие.
• Пессимистичные блокировки - конфликтов нет, но занятые ресурсы.
• Оптимистичные блокировки - с конфликтами разбираются при записи, есть варианты - блокировки на уровне интерфейса или бизнес-логики.

Интересно для общего развития

Сергей Пугачев. Продвинутая разработка Silverlight-приложений

Это снова был Expression Blend, уже без SketchFlow. Вокруг web-разработки. И отдельно по анимации - идея в том. чтобы не строить каждый раз движущееся изображение, а кешировать и двигать как целое. Фича Expression Blend - можно посмотреть, что будет на плохом железе. Доклад живой и для тех, кто этим занимается - интересный, судя по реакции зала.

Дмитрий Завалишин. Фантом-ОС

Доклад про Фантом-ОС я слышал на ArchLabs-2009, и мне хотелось узнать, что изменилось почти за год (в аннотации этого не было). Для тех, кто не в курсе, про проект (это было в докладе). Это проект новой, с чистого листа разрабатываемой ОС. На отличных от Unix принципах. Есть ли принципы у Windows, я не знаю, но, возможно, они примерно туда мигрируют…

Идея — приложения живут вечно, то есть вечно открыты. Система обеспечивает их прозрачное сохранение в виде консистентного образа памяти, причем в случае сбоев восстанавливается имеющийся консистентный слепок. В такой архитектуре становятся не нужны файлы — вообще, разве что как вид транспорта данных. А весь диск тоже превращается в одну большую память.

Возникают интересные эффекты — сборку мусора начинает работать не только в памяти, но и на диске, в том числе — удаляя всякие временные файлы (вернее, аналогичные им объекты), старые версии приложений и тому подобный мусор :). Сменные носители можно рассматривать как транспорт, либо как образ памяти отдельных «компьютеров», для которых включается свой версия ядра.

Правда, со сборкой мусора на терабайтном пространстве есть проблемы, но тут помогает то, что у нас есть консистентный snapshot, а мусор — он не может стать нужным. Поэтому собирать в фоне можно на нем, и это не будет влиять на текущую производительность. если ресурсов в целом достаточно.

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

Вторая идея — защита не на уровне процесса, а на уровне объекта, объекты и ссылки на них можно легко передавать между приложениями. Включая передачу по сети и организацию прокси-объектов. Правда, это порождает задачу сборки мусора уже в рамках совокупности компьютеров, но это тоже решаемо…

Теперь - что произошло за год. Основных достижений два. Во-первых, они заработали на реальном железе и почти неделю система на нем живет, а, во-вторых, они провели лицензионную очистку софта, сейчас у них чужой только TCP-стек, но он с хорошей лицензией. Еще покрывали ядро тестами. Над компилятором байт-кода Java к себе по-прежнему работают. И сборку мусора в полном объеме тоже не написали, пока работает сборка за счет счетчиков ссылок. Зато появился новый проект — POSIX (это такой UNIX) внутри Phantom, причем в двух вариантах — простом (когда он гаснет вместе с машиной) и persistent, когда перезагрузки машины прозрачны для него, как и для остальных задач. Сохранение/восстановление состояния работает достаточно успешно, и, по их оценкам, если ядро собрать без отладки, то запаздывание сохраненного образа памяти будет в пределах 5 секунд. Работа продолжается.

Елена Сагалаева. Искусственный интеллект в играх

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

Если кратко, то искусственным интеллектом в играх называют систему принятия компьютером решений за персонажей. И методов искусственного интеллекта там реально не применяется, а применяются всякие конечные автоматы и вероятностный выбор. Хотя встречаются исключения и самообучающиеся персонажи на нейронных сетях. Просто, если такой персонаж обучился и уровень стал плохо проходимым, то разработчик не может подкрутить поддавки. А именно это регулярно делают. программируя игру — иначе люди не будут получать удовольствие. Игра должна быть сложной, но проходимой. Из примеров. Если вероятность выигрыша 1/2, то комфортно для человека первый бросок делать действительно с такой вероятностью, второй — 0.7, а третий — почти 1. Если человек с силой 3 нападает на комп с силой один, то выиграть должен почти наверняка. А вот в обратную сторону — у человека должен быть приличный шанс… Гонки — гонщик не должен ехать один. а если просто случайным образом разбросать характеристики машин, то так получается, и с этим специально борются. Это можно увидеть, там интересные эффекты возникают. И, собственно, в этом профессионализм программиста — правильно подобрать эффекты. Например, чтобы при обходе препятствий не было телепортации объекта. Или нефизичного поведения в гонках — ты тормозишь, и все — тоже. Было много примеров из конкретных игр.

Елена Сагалаева. C++0x

В первый день слушал ее доклад по играм, поэтому заглянул послушать, хотя C++ вне моих интересов. Узнал для себя, откуда такая странная аббревиатура — оказывается, вместо «x» хотели поставить цифру года выхода, но теперь уже не успели… Что C++ фактически живет по стандарту 98 года, в 2003 только ошибки исправили. Что обсуждение медленно потому что максимально демократично, в рабочей группе 160 человек, на встречах — 60 и более. Но надежды есть, в марте 2010 вышел финальный draft. И под конец начали спешить, причем не логично — сначала от многого отказались ради некоторых концепций, потом — решили, что концепции все равно по-хорошему не сделать, от них тоже отказались, но ранее удаленное — не вернули.

В докладе были много деталей. Чего не будет — сборка мусора, проверка типов в template, threads будет урезан. Что будет — автотип переменных, лямбда-функции и прочее, известное по C#) и другим современным языкам. С примерами — потому что часть этого уже реализована в GCC, MSVC-2010 и у Intel.

А еще я с удивлением узнал, что C++ сложен, и новый стандарт, в числе прочего, должен его упростить :)

Евгений Кирпичёв. Многопоточное программирование

Доклад длинный, я был только на части. Много интересных проблем и шаблонов их решения. Общая идея состоит в том, что если у вас многопоточная система, то логику взаимодействия надо уносить вниз, объект должен сам отвечать за свою консистентность.

• Если есть выделения счетчика, то не должно быть присваивание значения, должен быть метод «выдай следующее».
• Если есть пул объектов, то вместо api получения объекта, его изменения, а потом записи, когда в промежутке объект неконсистентен и непонятно, что выдавать другим потокам, надо делать метод получения временного объекта другого класса для редактирования, у которого есть отдельный метод консистентной записи в исходный.

Полезно также абстрагирование.

• Не блокировка индекса на чтение/запись, а монопольная и разделяемая блокировка (или абстрактная блокировка чтения/записи).
• Не Очередь email'ов, а отказоустойчивая очередь.

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

Еще приемчики:

• Вместо асинхронной обработки сообщений - делаем синхронный процесс обработки сообщений из очереди.
• Вместо ответа на сообщение передаем callback, который надо вызвать. На этом построены некоторые языки, например, Haskel, но это - тяжело, так как возникает нелинейный поток управления и сложная отладка.

Остальное

Олег Царев, Кирилл Коринский. Сравнительный анализ хранилищ данных

Профессионально это — интересная тема. Но очень медленно. Доклад - на два слота, в модельных примерах начали от того, что если есть бинарное отношение (друг), то хранить полную матрицу (N*N) - дорого и так далее. Я не выдержал и ушел. После перерыва зашел, речь шла о характеристиках хранилищ данных, таких как методы доступа (odbc/telnet/встроенный), средствах написания запроса (api/dsl/sql), и так далее. Тоже все подробно, медленно, куча сравнительныхз таблиц с плюсами и минусами, которые не успеваешь воспринять... Увы.

Дмитрий Ханецкий. IBM Rational Jazz

Доклад посвящен новой платформе от IBM, сделанной для ведения проектов во всех методологиях — от RUP до Agile и SCRUM. Включает в себя несколько (около десятка) продуктов, которые интегрированы между собой: Team Concept для управления командой и распределения задач, средство описания требований, платформу функционального тестирования, а также нагрузочных тестов, средство управления версиями и так далее. Доклад был в стиле «все можно», преимуществ по сравнению с конкурентами — не рассказано. Отдельные функциональные возможности, например, в части тестирования — впечатляют. С другой стороны, сбор фиксация требований, скорее, выглядит как возможность загрузить разноформатные документы и объекты, связав их ссылками. При этом можно собрать различные представления для разных пользователей, но — вручную.

По внедрениям. В мире — более 4 тысяч внедрений, по России — более 10 комплексных внедрений, в частности у вендора, обслуживающего Мегафон и в Лаборатории Касперского. Правда, из зала сразу сказали. что у Касперского Jira (в Питере), на что докладчик ответил. что они с Москвой работают. Они сами используют свой продукт для управления проектом, про другие подразделения IBM (Lotus, например) сказал, что не в курсе. TeamConcept до 10 разработчиков — бесплатно, все доступно в trial-ах, а про вопросы о цене сказал, что все индивидуально.

Общее впечатление — все-таки это больше реклама, чем анализ продукта.

Михаил Кокорев. Дополненная реальность через веб-камеру

Смотрел маленький фрагмент, потому что тема — посторонняя. Но интересно.

Андрей Карпов. Устаревание стандартов кодирования и статический анализ кода

Доклад посвящен статическим анализаторам кода для C/C++, которые эвристически находят опасные места кода и таким образом помогают поймать потенциальную ошибку. Про языки докладчик сразу оговорился, что наиболее востребовано это именно на C/C++, где потенциал ошибок намного больше, чем, например, на C#. В начале была весьма спорное противопоставление статического анализа и code review, который был позиционирован как очень дорогая практика, увеличивающая стоимость разработки в 3-4 раза (sic!) — так как с точки зрения докладчика code review — это когда пара человек плотно смотрят код, въезжают в него, что занимает столько же времени, сколько его писали, а потом — еще вместе обсуждают.

Дальше шел рассказ о негативном отношении к статическим анализаторам, которое объясняется устаревшими проверками, в них встроенными, а также пристальным вниманием к форматированию текста программы вместо поиска потенциальных ошибок. С тезисом о том, что часть проверок по форматированию устарела благодаря современным средам программирования, подкрашивающим комментарии и обеспечивающим навигацию по коду я согласен, однако не считаю, что вопросы оформления кода и именования переменных стали не актуальны. А тезис, что если анализатор настроить под себя, он становится полезен — поддерживаю.

Дальше шли примеры выявляемых потенциальных ошибок, в основном связанных с работой с указателями. И обзор различных существующих анализаторов, включая разрабатываемый компанией докладчика. При этом особенно отмечались возможности, связанные с потенциальными ошибками, проявляющимися при смене платформы, например, при переходе на 64-разрядные платформы или в многопоточные среды.

Общее впечатление — наверное, для пишущих на C/C++ — интересно. Но на уровне общих положений слишком много перегибов — о code review, форматировании.

Круглый стол по системам контроля версий

Был на фрагменте. Сильно разочарован. потому как один из участников обсуждения svn сводил к их провалу в использовании ныне устаревшей версии - они решили воспользоваться некоторой новой фичей слияния, которая по факту оказалась в неработоспособном состоянии, но выяснилось это уже когда ветвистый лес вырос, сливались они полтора месяца. Понятно, что сами прокололись - надо было эту фичу попробовать. И, в любом случае, это ж проблема прошлого, а он о ней вспоминал каждый раз, когда речь заходила про svn.

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

Максим Лапшин. Разработка видеохостинга на Erlang

Фичи Erlang - акцент не на типах данных, а на содержимом, полностью динамическая типизация. И гарантированная смерть объекта. Правда, динамическая типизация не дает делать автоподсказки в средах разработки - тип неизвестен. Зато писать проще, семантика типа более простая, чем в C# и Java. Но синтаксис чудовищен - perl отдыхает (или я с чем-то путаю?).

Михаил Черномордиков. HTML5, CSS3 и новый Internet Explorer 9

Слушал чуть-чуть, потом убежал потому что скучно. Из запомнившегося - IE9 слизан с Chrome.

Что еще хотелось послушать

• Стас Фомин. Золотая середина Открытые системы поддержки разработки. Не пошел сознательно, так как предмет доклада хорошо представляю. Решил сходить на IBM Rational Jazz. Выбор неочевиден: что лучше — послушать креативный рассказ об известном, или по докладу о неизвестном убедиться, что ничего особо интересного.

• Андрей Бибичев. На пороге дополненной реальности: к чему готовиться разработчикам. Поскольку тема — не моя, решал сначала заглянуть к Антону Овчинникову, и сильно заинтересовался докладом. Поэтому на Андрея не попал.
• Яков Сироткин. Как стать героем. Судя по аннотации, доклад мог быть интересным. Но я несколько раньше зашел на Мастер-класс по DDD, Андрей как раз рассказывал различные альтернативы объектных паттернов, и этот доклад я пропустил.

Что такое монады

Это - бонус, из обсуждения с Евгением Кирпичёвым после его доклада о многопоточном программировании. Обсудили, что такое монада, и почему linq связан с функциональным программированием. За что докладчику — отдельное спасибо. Фиксирую как понял, за детали не отвечаю.

Монада представляет собой некоторое замыкание с определенными свойствами, которое надо понимать на примерах, а не от общей теории. В монаде есть единица (unit) и итератор (bind). Некоторое количество примеров было нарисовано, если интересно - я воспроизведу плакаты и готов порассуждать (но писать - нет). Механизм linq дает возможность для типов реализовать примитивы, которые превращают тип в эту самую монаду: unit суть select, а bind суть select many. И таким образом появляется возможность создавать монады в C#.