Конференция 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 % к рынку.

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

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

Круглый стол 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

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

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

• 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 (ArchLabs-2009#Дмитрий Завалишин. Архитектурные детали ОС нового поколения Phantom), если кому интересно про идеи, можно там почитать. Сам проект весьма интересный, и мне хотелось узнать, что изменилось почти за год (в аннотации этого не было). Основных достижений два. Во-первых, они заработали на реальном железе и почти неделю система на нем живет, а, во-вторых, они провели лицензионную очистку софта, сейчас у них чужой только 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#.