Текущая версия на 13:06, 30 января 2017

ADD-2011 и другие конференции

Был на второй конференции ADD-2011. Первая была в сентябре в Ярославле, а вторая — в Питере чуть больше, чем через полгода. Конференция понравилась первый раз (смотри отчет ADD-2010) и совершенно не разочаровала второй. И организацией и уровнем докладов и, главное, обстановкой общения. Я этой весной был и выступал на многих конференциях (AgileDays, SoftwarePeople, ReqLabs) и потому могу сравнивать, и, на мой взгляд, для разработчиков, которые едут на конференцию за профессиональными контактами и обменом мнениями она, на мой взгляд, лучшая. Я сейчас попробую объяснить — почему.

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

Да, про другие конференции, чтобы не было обид. Они тоже хорошие, но у них другие позиции. AgileDays нацелен на гибкие методологии и организацию процесса разработки. У него был интересный технический трек, но все-таки основной предмет — именно организация процесса и общение преимущественно шло по этим вопросам. SoftwarePeople — это большая конференция, на которой было много интересных докладов по очень разным вопросам, но вот общения — сильно меньше. На ReqLabs было много интересных докладов, но он нацелен на аналитиков, а не разработчиков.

Возвращаюсь к ADD-2011. Конференция проходила 2 дня, было 3 трека по 9 слотов в первый день и 10 во второй. Первые доклады второго дня начинались в 9, и это было очень тяжело. Но, в конце концов, мы же не отдыхать приехали. К тому же, можно было разместиться в той же гостинице, где проходила конференция, что в целом делало ранний подъем достаточно комфортным — хотя сама гостиница была не просто на отшибе, но и далеко от метро. В целом организация была четкой. WiFi работал хорошо и можно было быть online — в отличие от гостиницы, где точек доступа было много, но вот выйти с них в инет получалось очень плохо. Как и на прошлой конференции, шла видеосъемка и запись докладов, и это будет опубликовано. Кстати, запись большинства докладов с ADD-2010 уже опубликована Стасом на сайте конференции — если перейти на конкретный доклад, то можно увидеть запись. Правда, там нельзя посмотреть по каким докладам видео опубликовано, а по каким нет, поэтому даю еще одну ссылку — на сайт нашей компании. Кстати, по части докладов опубликовано не только видео, но и расшифрованная стенограмма.

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

Первый день конференции был, на мой взгляд, сильнее второго. Хотя я могу и ошибаться — возможно, дело в том, что на второй день был мой доклад и и доклад Коли Гребнева из нашей компании, которые, естественно, я не могу оценить с позиции слушателя, а впечатления от большого набора слотов по Nemerle смазывалось потому, что основной разработчик недавно приезжал к нам в CUSTIS на встречу Alt.Net и 4 часа об этом рассказывал.

Надо отметить, что часть докладов относятся к относительно начальному уровню использования тех или иных инструментов и технологий. И, например, для меня — не представляют ничего нового, даже по тем технологиям, которые я не использовал — я это знаю за счет общего информационного фона в нашей компании. Но я тут в тепличных условиях — у нас в компании очень хороший информационный фон даже по тем технологиям как по используемым технологиям (C# и .Net, Java, Oracle), так и по другим, которые напрямую не используются, в том числе современным. А еще — когда рассказывают практический опыт — это всегда полезно и это не мое умозрительное представление, это я слышал по отзывам других участников. После таких докладов у части всплывают их собственные задачи, где можно было бы попробовать те или иные решения. Было также несколько доклады-обобщений собственного опыта по какому-либо аспекту разработки, например, по граблям, возникающим на внешних взаимодействиях — внедрении, интеграции и т. п. И даже если не узнаешь ничего нового, получение такого списка в докладе заставляет задуматься, заново вспомнить и осмыслить свой опыт, что полезно. А еще — вспомнить о том, что в компании опыт — есть, а check list — отсутствует, а тут в презентации его заготовка, которую можно взять.

И это относится только к части докладов. Было много докладов от разработчиков, которые находятся на острие технологий, например, от JetBrains по Language Oriented Programming и от основного разработчика по Nemerle. И даже спонсорские доклады, были не традиционной пропагандой своих продуктов, а представляли интерес, например, Андрей Кощеев HP рассказывал, как у них устроено взаимодействие между разработкой и тестированием, а заглянуть внутрь такой крупной компании — интересно и полезно.

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

Что я вынес с конференции

Платформы для DSL интенсивно развиваются. Я немного обсуждал с Мазиным из JetBrains. На платформе MS есть графический MS DSL и Nemerle для языковых расширений. А на Java — JetBrains MPS. Еще можно на MPS сделать универсальный автономный DSL для обеих платформ, а поскольку в .Net есть Java, то, возможно, на MS DSL можно делать кросс-платформенный графический DSL. А вот Simonyi никак не выпустит свой софт (http://www.intentsoft.com), идеями которого был вдохновлен MPS.

Графический DSL обычно лучше с маркетинговой точки зрения, но, возможно, хуже для программистов, здесь интересен опыт JetBrains в YouTrack. Идея — что картинки рисовать точечно, потому что они область где они лучше текста — ограничена. Идея Раскина — графически представляем, но описываем, правим и вводим текстом. Напрмиер, имеем набор дел, выбрали конкретное и командами меняем, а не gui. Программисты пользуются. А hr — учат их, но осваивают плохо, преимущественно gui. Кстати, сейчас выходит YouTrack-3 с workflow, и они внутри компании на нем делают всякие приемы на работу и увольнения. Настройка workflow пока не графическая, но есть в планах. Так что, возможно, через некоторое время появится MPS с графикой — YouTrack сделан на нем, ограниченная версия используется для точек расширения.

С доклада Чашкина по HTML5. Сейчас туда заложены механизмы, который вроде как позволяет сделать web-приложение работающим как online, так и автономно, с синхронизацией с центральным репозиторием по кнопке. Это, в целом, демонстрировалось в реальном продукте. В основном это дают два механизма — локальные базы данных и настраиваемое кеширования запросов на сервер, включая ответы скриптов. При этом кеширование запросов настраивается поверх работающего приложения. Но, естественно, это не для любого приложения, есть ограничения на архитектуру. По-моему, сочетание технологий может дать некоторый технологический прорыв. Но пока еще есть технические ограничения — большинство больших броузеров не поддерживают html5 в нужном объеме, а вот на Safari iPhone уже все есть.

Наблюдается отчетливая общественная тенденция — один человек пишет фреймфорк (или продукт), который многие используют и это в рамках некоммерческой деятельности. Примеры с конференции — mvp4g, nemerle, средство для лога у Кирпичева.

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

Антон Белоусов рекомендовал книгу Michael Nygard — Release It! и, наверное, я ее прочту.

Доклады CUSTIS по DDD

Начну я отчет с двух докладов по Domain Driven Design — моего и Коли Гребнева, который тоже работает в нашей компании. Несмотря на работу в одной компании, у нас весьма различаются взгляды на DDD, что выяснилось в процессе подготовке. При этом мы оба считаем, что находимся в согласии с Эвансом и его книгой по DDD, и имеют место быть просто разные интерпретации. Поэтому доклады представляют собой разные точки зрения. К тому же они разнесены по темам: Коля рассказывал об основах применения DDD при объектном программировании и объектных моделях предметной области, а я — о необъектных моделях предметной области, которые могут реализовываться в рамках DDD, в том числе и на объектных языках программирования.

Оба доклада вызвали интерес, вопросы и обсуждения участников.

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

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

А дальше начинаются различия. Коля полагает, что отражение модели в код должно быть прозрачным переводом с языка модели на язык программирования и именно об этом говорил в своем докладе. То есть классы модели должны быть отражены в классы на языке, описания действий в модели должны быть отражены в их реализацию и так далее. А если потребности эффективной работы требуют внутренней реорганизации методов, появления каких-то промежуточных сущностей или действий, то они должны появиться в модели. Таким образом, пределы и способ работы на DDD существенно определяется имеющимися средствами реализации. И, если говорить о приложениях с базой данных, то применение DDD означает использование шаблона «Модель предметной области» описанного у Фаулера. Обо всем этом Коля рассказывал в своем докладе.

Я же полагаю, что отражение в реализацию может быть гораздо более сложным. Важно лишь, чтобы оно было регулярным, и элементы модели можно было проследить в коде. Что достигается применением шаблонов для этого отражения. Например, можно использовать DDD при реализации работы с базой данных через DataSet/RecordSet. Надо лишь договориться, что каждой бизнес-сущности будет соответствовать свой единственный RecordSet и свой TableAdapter, записи в котором суть элементы класса, а каждый бизнес-метод реализуется как метод в этом RecordSet. Может быть другое отражение, важно лишь, чтобы оно было одинаковым по всей системе и соответствие не нарушалось. Такой подход дает возможность применять необъектные модели предметной области в DDD, несмотря на реализацию на объектных языках программирования — надо лишь построить шаблоны. О двух из них, применяемых в нашей компании, я рассказывал — документооборот на основе диаграммы состояний с использованием шаблона State Entity и реализация учета с собственными диаграммами учета и шаблоном отображения.

Краткие резюме докладов

Резюме докладов идут в том порядке, в котором я их слушал на конференции — поскольку практически все доклады мне понравилось, я не стал их делить по оценкам.

Максим Мазин, JetBrains. Language Oriented Programming (LOP) в действии

Очень хороший и интересный доклад. Про концепцию не только реализации собственных DSL для классов задач, но, что интереснее, про реализацию расширений к языкам общего назначения, обеспечивающих те или иные типовые конструкции, применяемые при разработке в виде шаблонов. Смысл расширений — они позволяют скрыть громоздкие языковые конструкции, например, оформление определенных фрагментов кода в с блоками finaly и перехватом исключений. С помощью расширений можно комфортно использовать фреймфворки, которые требуют не только кода на Java, но, например, конфигураций в xml — описывая все на языке.

У JetBrains есть инструмент для реализации DSL и расширений — MPS. Получается компилятор и intelisense в редакторе. Пока поддерживается Java и интернет-стек — jscript, css, xml, а также можно делать автономные языки. Проект YouTrack делается на основе MPS, там ограниченная версия MPS используется, чтобы пользователь создавал расширения. Что важно, MPS обеспечивает контроль по синтаксису и по системе типов, а также проверяет совместимость различных расширений, если их хочется использовать совместно. Лицензия apache 2.0 — бесплатно для коммерческого использования.

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

В перерывах между докладами обсуждал с Мазиным идеи интерфейса YouTrack. Весьма интересно. Он говорит, что воплотили идеи Раскина — графически представляем, но описываем, правим и вводим текстом. Например, имеем набор дел, выбрали конкретное и командами меняем, а не gui. Программисты пользуются. hr они тоже учат их, но те предпочитают gui.

Никита Прокопов, Xored. Философия простоты, или еретическая лекция о программировании

Интересный доклад. Основная мысль — о том, что программисты часто реализуют сложные решения по разным причинам. И часто — внутренне тяготеют к сложным решениям. А правильно — стремиться к простоте. Поэтому лекция — еретическая, против культа сложности программиста (используешь сложный редактор — крут).

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

Экстремизм в проблемной части не мешает предлагаемым решениям быть вполне конструктивными:

• Вопросы Почему и Зачем
• Забота о пользователе
• Использовать шаблоны только когда они нужны, а не тотально по коду
• Коллего-ориентированное программирование — думайте о своих товарищах

Да, многие решения очевидны. Только в реальном мире почему-то не слишком используется :(

Я: Решение могут быть в синтезе и за плоскостью, типа общезначимых конфигов, отделенных от конкретных систем в примере с конфигами и настройками. Об этом в докладе не было. Еще было достаточно много спорных примеров улучшения решений. Однако сам доклад — безусловно интересно слушать, он будет собственные мысли.

Антон Котенко, iPark Ventures. Processing и Fluxus

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

А доклад был про язык описания трехмерных объектов, которые что-то делают на экране, например, визуализация под музыку. Язык на основе Schema, внизу OpenGL.

Ольга Павлова, UsabilityLab. Интерфейсы: битва за право влияния

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

Что касается практических советов, то я услышал один — выделяйте роли, для которых проектируете интерфейс. Хорошо, если они выделяются в исследовании бизнеса, но даже если такой возможности нет, роли «с потолка» лучше, чем их отсутствие. Наверняка были и другие советы — раньше чем я пришел.

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

Яков Сироткин, Академический университет. Разработка программного обеспечения для маленьких

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

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

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

Послушав некоторое время я ушел на другие доклады — поскольку примерно понял, о чем доклад и эти вещи мне известны. А потом вернулся, посмотрев других… Потому что приятно слушать со-культурного человека. Вообще этот слот — пример хорошего планирования. Якова поставили одновременно с Гедзбергом из Luxoft и каждый мог выбрать доклад по своей культуре, а технари — уйти на html5.

Михаил Гедзберг, Luxoft. Time Management для программиста

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

• Не перебрасывайте между задачами. И не беспокойте — если сказал 2 дня — не дергайте внутри, но на стендап-митинге — слушайте как дела, сопоставляйте с планами.
• Работайте с приоритетами. Люди часто делают то, что интересно, а не важно. В том числе внутри задачи. Не используйте сразу новый фреймворк в продакшн.
• Проактивность. Не ждите проблемы, кризиса, а интересуйтесь. Например, когда будет следующая версия у соседней команды.
• Декомпозиция, мелкие задачи — чтобы перекидывать оперативно.
• Упущенное время — невосполнимо.
• Фокус на результате. Пример. Попросил позвонить, узнать — результат в том, что дозвонился, а не раз позвонил и забыл.
• И так далее…

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

Иван Чашкин, Дзенмани.ру. Веб-приложения на HTML5, как альтернатива нативным приложениям

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

Вернулся в конце на вопросы — во-время. Обсуждение механизмов кеширования наводит на любопытные мысли.

Похоже получается сделать web-приложение работающим как online, так и автономно, с синхронизацией с центральным репозиторием по кнопке. Это, в целом, демонстрировалось в реальном продукте. При этом кеширование запросов настраивается поверх работающего приложения, включая ответы скриптов. Еще важны локальные базы данных. Но, естественно, это не для любого приложения, есть ограничения на архитектуру. По-моему, сочетание технологий может дать некоторый технологический прорыв. Но пока еще есть технические ограничения — большинство больших броузеров не поддерживают html5 в нужном объеме, а вот на Safari iPhone уже все есть.

Александр Черный, Студия Михаила Кечинова. Взаимодействие дизайнера и программиста

Взаимодействие — в веб разработке и в мобильной. Доклад начался с достаточно понятных, общих тезисов. Таких как понимания скоупа, сотрудничество, соседство, лучше сидеть в одной комнате. Но потом перешло к конкретным практикам для дизайнеров. И это интересно.

• Карта экранов. Напечатать все, развесить. Я: очень сильно пересекается с Мейденом (я его слушал на Software People) про супер-большую доску, на которой видно все.
• Видеосценарии.
• Именования файлов. Правильное и общее. Я: это как именование идентификаторов, нужно.
• Механизмы массовых обновлений. Связано с именованием файлов.
• Правила хорошего тона в фотошопе — надеюсь, я правильно нашел ссылку. Правила просты и для опытных людей — подразумеваемы, но их прочтение заставляет задуматься об уровне новичков и наборе сообщаемых сведений.
• Дизайнеры должны представлять ТТХ устройств, под которые проектируют. Например, для мобильников. И есть нюансы. Пример. Дизайнер знал про высоту 320x480 — разделил на 6 квадратных частей 160*160. Но 20 пикселей — верхняя планка, дизайнеру не сказали, программист как-то адаптировал. Но элементы перестали быть квадратными и это привело к сильному нарушению дизайна.

Евгений Кирпичёв, Mirantis. Швейцарский нож аналитика — визуализируем логи одной строкой!

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

Антон Котенко, iPark Ventures. Мастер-класс веб-разработка на GWT и mvp4g

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

Идеология GWT состоит в том, что пишем приложения на Java, а он на лету компилирует в Javascript с учетом конкретного броузера. Очень много вложено в прозрачную передачу броузер-сервер. Это имеет обратную гримасу — любой имеющийся кусок на JS, например, визуальный редактор или google maps можно обернуть в Java и и тогда использовать внутри GWT наряду с остальным. Единственное, кроссброузерным сам не становятся, это на вас.

Model-View-Controller концепция сменилась на Model-View-Presenter — вместо единственного действия «сохранить» активное взаимодействие, интерактив по событиям. Как следствие — появляется концепция Event Bus — шины событий, на которые предполагается подписка. Именно она обеспечивает интерактив, взаимодействие презентеров. При этом View ты можешь подменять, в том числе для целей тестирования, а интерактив презентеров сохраняется.

Еще интересное.

• Deferred Binding — взамен reflection. Динамическое создание интерфейсов. Они сами используют это для кроссброузерных вещей, и примеры были об этом, но в принципе идея понятна — блоки кейсов под случаи, reflection во многом так используется. Это при компиляции (но по месту?)
• Dependency Injection — через GWT Injection/Guice — в динамике. Централизация настроек фабрик и прочего. Я: вообще это важная концептуальная идея, в сторону конфигурационно-ориентированного программирования и решения проблемы настроек.
• Remote Service — для общения с серверами, асинхронное.
• Сейчас нет ориентации на не-java сервер, но можно через request-builder, например, с php.
• Верстальщикам тоже надо использовать gwt, а не html-разметку. Конечно, они могут использовать html и самому обеспечивать кроссброузерность. Но gwt все равно делает div и прочее для своей обвязки, и получается не слишком комфортно — ни разработчику, ни самому дизайнеру, когда он смотрит результаты.
• Есть проблема, что js-ошибка может покрешить все приложение. Но они дорабатывают, можно перехватывать и обрабатывать.

Дальше было про mvp4g — фреймворк. Заложено мультимодульное программирование, шина событий. Он многое облегчает и активно развивается. Код сильно проще полного gwt-кода. Система аннотаций для кода.

Андрей Кощеев, HP. Технологии улучшения взаимодействия между разработкой и тестированием

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

Началось все понятной логикой. Тестирование эволюционирует. От интерактива и проверки по месту к автотестам по скриптам и нагрузочному тестированию. Постепенное разделение труда, выделение тестировщиков между разработкой и заказчиком, постепенно — сотделом тестирования. Прокладка приводит к фиксации требований как отдельный документ — иначе всегда надо звать заказчика. А потом — метрики и прочее. В общем, разделение труда плюс бюрократия приводит к тому, что эффективность падает… Где-то там возникает еще система управления проектами.

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

Дальше доклад пошел в описание видов взаимодействия и тулы HP ALM, которая эти задачи решает и интегрируется со всеми платформами и средствами разработки (среды, системы контроля версий и прочее).

Сергей Туленцев, 42bytes. MongoDB

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

MongoDB очень удобно для прототипирования. Обеспечивает изменение структуры на лету. А еще можно использовать для динамических данных, настраиваемых при конфигурировании продукта. Например, сайт с опросами или CMS. По его оценке сайт для опросов — пара таблиц и 1200 строк, с mysql будет больше.

Очень быстрый доступ по keyvalue. Но не только так — есть 15-20 операций чтобы строить запросы, включая существование элемента в массиве, соответствие всех элементов заданному множеству и т.п. Для конкурентной работы — команда find and modify — документ ищем и сразу меняем, что задано. База данных — кластерная. И в кластер сразу заложено, что есть мастер и дубль, который в случае чего подхватит. А еще есть журнал и лог транзакций — на случай падения. Из инструментов отладки — встроенный профилятор, плюс логирование запросов. К сожалению, есть ограничение — 16М на документ.

При проектировании важно правильно расшарить данные, это ключ к масштабированию. Shard key — идентифицирует данные в кластере, он не изменяется — только копирование, а если для коллекции — надо сохранить на диск и загрузить, только так. Пример — user по email. Другой пример — пусть есть ленты пользователей. Можно расшаривать по постам (событиям). А можно — по пользователям. В первом случае лента — распределенная, запрос ленты пользователя пойдет на много серверов. А при падении сервера получается лента с дырками. Во втором случае — вся лента с одного сервера, это эффективно по нагрузке. При проблемах — система не работает с одного сервера. Еще пример с фотками. timestamp в ключе фотки приведет к тому, что все фотографии, загруженные в один момент времени, ложаится в один кластер — не эффективно, потому лучше timestamp+user или timestamp+hash.

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

Рекомендации по быстродействию — в целом понятные, известные и по реляционным базам данных.

• Когда делаете начальный импорт, лучше заранее сделать нужное количество чанков — чтобы это не делать в динамике на импорте.
• Cached Counter. Атрибуты-массивы, но нет операции, выдающей длину. Патерн — храним с каждым списокм counter.
• Covered index — чтобы быстро получать данные из индекса.
• специальные индексы — для более быстрого доступа именно к последним данным.
• Держать часть документов (временные) только в памяти.
• Индексация документов при записи: больше индексов — медленнее.

Интересно, что бывает использование совсем не по назначению — просто Server side jscript…

Дмитрий Завалишин, Digital Zone. Взаимоотношения заказчика и исполнителя на проекте

Дмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности. Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС.

Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 20-30 человеко-лет. Они делают ставку на точные спецификации, исполняемые разработчиком. Мы так работали примерно лет 6-7 назад, а потом — сменили парадигму, приняв что квалифицированный разработчик сам способен сделать приличную часть постановки, если понимает бизнес-часть, а понимать ее в многолетних проектах он будет.

Дальше я оставляю практически все заметки в исходном виде.

Начало — традиционное, 80 % провалов.

• Исполнитель не умеет вынимать требования
• Заказчик не знает, что ему нужно
• Проект реально сложен и действительно не поддается оценке заранее

Ответ программерский — виноват заказчик.

Заказ по умолчанию — «на сайте должен быть форум». Когда дальше работают аналитики — у него просыпается фантазия, он хочет многое. Только потом — у него нет денег, и вообще это ему не нужно. Они стараются урезать хотелки, направить на важное, решение реальных проблем.

Российский заказчик склонен снимать ответственность. Реально проект — совместная деятельность. Гарантировать от проблем не может никто.

Цели.

• Счастье клиента
• В срок
• В бюджет

Бывают проекты только со счастьем клиента — сам проект провалился, зато дал заказчику альтернативное видение ситуации, с которым он развивается дальше.

Функциональность в списке целей отсутствует — потому как реально это самая гибкая часть. Всегда что-то уходит, что-то приходит, в общем случае не нужно ничего.

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

Если клиент хочет неоправданно сложный проект — отказывайтесь.

Важно — нужны конечные пользователи, стейкхолдеры, а не только директор.

Ситуация: «директор посмотрел и сказал — все переделать» +30 % переработки. И Менеджер не может принять проект. Реально, это проблема Разработчиков — надо на входе понять, кому сдавать.

Но даже если пользователи принимать не будут — они потом будут пользоваться и вас материть — оно вам надо?

Лезьте в бизнес-схемы клиента. Понимайте зачем.

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

Коммуникации

• единое понимание целей
• единое понимание рисков
• единое понимание точности оценки

Если про цели как-то есть, то 2 и 3 — реже.

Желательно

• знать, что можно урезать
• знать, что можно перенести попозже
• иметь представление о приоритетах задач

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

Пример. Отложить оплату части проекта — на поддержку.

Бумажки

• Vision одна страница в первые 2 дня. Вехи
• Требования. В начале, 100 страниц, ревью с клиентом и разработчиком. Эскизы и usecase
• Тест-план, если требования детальны может отсутствовать
• План проекта. Реально работает при детализации 2-3 часа на задачу, но полезен даже если в нем 3 строки
• Деплоймент-диаграмма — чтобы не было сюрпризов на сдаче

Важно. Клиенту требования надо структурировать по бизнес-областям. А программист часто хочет получить кусок на код, а остальное не слишком читать. Я: Это видение у нас было лет 5 назад. Работает и востребовано когда программисты не погружаются в бизнес-область. На их потоке проектов это оправдано.

Инструменты.

• Трекинг процесса. Два ползунка — сколько съели объема (фич, например) и сколько бюджета.
• Регулярные релизы, ревью с клиентом, прогоны.
• Сначала сделать все, потом полировать. Все равно, треть не нужно — зачем его полировать. И нет риска застрять на полировке и не сделать минимального ядра.

Я: Это правильно — делать по фрагментам надо вчерне, а не до совершенства. Но делать, а не прототипы.

Что делать когда клиент не верит. Например, две задачи, он считает, что оно почти одно и то же, а стоимость — разная. У них разработчики в конце недели пишут лог (тайсминг) в свободной форме. Их можно предъявить, и нельзя подделать, это в крупном. А сейчас научились фиксировать время на баги. Это все можно показать клиенту, объяснить и убедить.

Архитектура и компоненты

• Знакомый инструмент — лучше. Незнакомый инструмент снижает предсказуемость, а это важнее сроков.
• Готовый код третьей стороны снижает стоимость, но повышает риск — если компонента не знакомая. Объясните это клиенту.
• Клиенту никогда не нужно именно то. Ему нужно «нечто похожее». Если есть наработки — можно использовать готовое. Использование своего кода — снижает и цену и риск.
• Интеграция с существующими системами — отдельный проект. Лучше не пытайтесь fixprice.

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

После 90 % бюджета получается нормальный продукт. Хороший — будет после еще 90 %. А третьи 90 % позволят сделать блестящим. Поэтому надо сделать вчерне за 30 % времени и бюджета — тогда есть шанс получить блестящее за остатки. Хотя у них не слишком работает.

Очень важно — постанализ по проекту.

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

Оценка одного «за три дня» — значит за 5-6. А другого — за 2 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать.

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

Как выбирают подрядчика.

• Опыт. Внятность по видам проекта
• Адекватность. Решение задачи клиента, а не свою
• Надежность как предсказуемость итогов. Очень важно.
• Цена. Хотя это в разных проектах по-разному.

Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет.

Стас Давыдов. Фриланс: будущее IT-разработки (уже наступило)

Мы с ним беседовали накануне в обед. Фриланс. Он становится коллективным. Коллективная работа — как общение в социальных сетях, но в результате продукт. В современном мире совместная жизнь в сети, без реальных встреч становится для многих комфортным и эффективным способом общения, и это — новый тренд, которого не было, когда формулировался agile. Это дает новые возможности. И создает базу новых реалий коллективной работы.

К сожалению, доклад, на мой взгляд, был несколько менее интересным, чем живое общение. Было много общих слов про возможности, которые дает фриланс, в то время как слушателям было бы более интересна конкретика, реальный опыт. Например, понятно, что фриланс в принципе дает возможность регулировать свое рабочее время. Но то, что можно обеспечить комфортный доход при в среднем 20 часах в неделю, и Стас некоторое время так работал, при этом когда нужны деньги можно дойти до 60 (и будет втрое больше) — это уже было после доклада, в общении. Но при этом есть работодатели, которые нанимают фрилансеров для экономии на зарплате, и требуют присутствия — это надо учитывать, и есть нюансы — требуют ли реального присутствия или просто доступности для каких-то консультаций. А еще — не смотря на гибкий график, эффективность часто меряется довольно жестко, через счетчик времени, и за этим следят. Так же как подходы к выборке задач — когда надо трезво оценивать трудоемкость, учитывая что часто хотят сэкономить, но иногда бывают подарки, когда деньги большие. По работе есть oDesk — интегратор фрилансеров. Еще важно, что фрилансер сам планирует свое развитие, это и возможность и обязанность. Так что в целом — это альтернативный способ работы, со своими плюсами, которых много, но за которые надо платить.

Максим Игнатов e-Legion. Разработка приложений с использованием Windows Workflow Foundation

Это был рассказ про внутренний проект компании — сопровождение найма сотрудников WWF. Сделан в свободное время (правило 20 %), реально используется. Доклад полезен для тех, кто хочет познакомиться с возможностями WWF, однако они представлены там на начальном уровне — это лично я и так представляю, тем более что часть иллюстраций были на примерах из документации.

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

Павел Белоусов. Пример разработки высоконагруженной реляционной базы данных

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

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

Механизмы, упомянутые в докладе.

• Избегание tablock
• Чтобы избегать deadlock — стройте обработку с циклом по одному индексу.
• Учите матчасть — индексы, блокировки, планы выполнения.

Михаил Антонов, Magenta Development. Особенности масштабирования систем планирования и управления поставками

Системы управления поставками для крупных американских и некоторых европейских ритейлеров. Сырье — Вендор — Ритейлер — Покупатель. Товар вперед, по заказам. Без возвратной логистики. Очень интересный для меня доклад, поскольку наша компания, в числе прочего, занимается именно проектами управления снабжением магазинов для Спортмастера.

Сам доклад — очень удачный. Михаилу удалось в кратком докладе рассказать о бизнес-задаче управления цепочкой поставок, о технических сложностях ее решения и о методах оптимизации. Задача, по моему опыту, весьма сложная и то, что они деляют — впечатляет.

Бизнес-задача — снабжение магазинов на основании текущих остатков и прогнозов продаж.

• Содержание SCM
  • demand planing — предсказание объема продаж,
    • статистический долгосрочный прогноз
    • эвристический краткосрочный прогноз
  • order management — реальные заказы, опираясь на прогнозы
  • transportation — транспортная логистика
  • исполнение
• Прибыль ритейлеров — 1-4 % от оборота даже в успешные годы. Поэтому очень важна точность прогнозов.
• Региональные центры дистрибуции, по 2 на штат. Заказ в магазины и пополнение центров дистрибуции. Тысячи магазинов, до 15 тыс. у одного европейского ритейлера
• Прогнозирование — data mining. Эвристики, которые дорабатываются по прецедентам в процессе эксплуатации. Оно живет, но неудачи — опасны.

Особенности работы с заказчиком.

• Процесс прогноза и заказа идет автоматом, но должны быть механизмы наблюдения, анализа и корректировки.
• Процессы у заказчика — медленные. Например, получить одну нужную колонку в данных — 4 месяца.
• Консервативность заказчика к технологиям. Поэтому Oracle + Java. Используют Groove для бизнес-логики не афишируя — все равно Java-платформа.

Система обеспечивает решение следующей задачи. Надо ежедневно получать данные о продажах, конвертировать, валидировать, загружать. Далее — обрабатывать, обеспечивая создание заказов и корректируя имеющиеся прогнозы, долгосрочный и краткосрочный. При этом время на обработку ограничено — после получения всех данных и до первой стадии бизнес-процесса обработки заказов, обычно на это 1-1.5 часа. А объемы данных большие, оценка — 2К маг * 50К товаров (продаж в день) * 500 дней = 50 млрд строк продаж. Реально 5-10 млрд.

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

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

Технологии.

• Oracle 10g/11g RAC
• Java 1.6 Jboss AS 4.2. Jboss используется исторически и как общая платформа с другими проектами.
• Собственный Cache и grid-manager
• Клиент JSP, JavaScript.
• Для бизнес-логики используют Groove

Задачии оптимизации

• Хранение больших таблиц
• Быстрая загрузка
• Оптимизация запросов
• Оптимизация БД в целом
• Оптимизация интерфейса
• Оптимизация engines — расчетных частей

Большие таблицы — Partitioning. Если пара таблиц имеет одинаковый partitioning, то join это учитывает.

Загрузка — SQL*loader, с использованием различных ускоряющих приемов.

• direct mode, отключение индексов, constraint, редкие commit, увеличение буфера
• отключение redo-log,
• параллельная загрузка по внешних процессов
• Загрузка во временную таблицу, потом merge для разрешения ссылок. Разбивают на части.
• flat table — монтировать csv-файлы как таблицы

Оптимизация запросов по планам решения. Реально оптимизатор — улучшается. Сейчас они удаляют хинты, написанные 3-4 года назад.

Oracle Grid Control. Вкладки мониторинга запросов — он показывает еще и динамический план: сколько записей в запросе и столько он уже вытащил. И известный способ — трассировка sql_trace, tkprof.

Оптимизация пользовательского интерфейса

• materialized view, вынос в них тяжелых частей запроса, обновление по ночам или несколько раз в сутки
• обеспечивают отклик 5 сек.
• принудительная фильтрация ui как мера предосторожности — например, не показывать средние продажи по всему восточному побережью — запрос уйдет в БД и многим помешает.

Пакетная обработка — цепочка engines. Масштабы впечатляют — 10К одновременных тасков, 2M всего в таблице. И это — наиболее критичная задача.

• В каждом engines — параллельно запускаем задачи обработки, для чего выделяем группы данных, обрабатываемых.
• Oracle масштабировать дороже, чем Java/JBoss. Поэтому расчет на сервере приложений. 4-6 серверов Java на каждый сервер Oracle.
• Проблемы ввода-вывода на уровне базы данных
• Трафик между БД и Сервером приложений — меньше, чем проблема ввода-вывода самой БД — на сервер приложений идут агрегированные данные. Задержки по БД-app их не волнуют, потому что параллельно идет много задач, ограничение — целиком
• Железо — в datacenter, тестируют, предпочитают стандартное, так как легче масштабируется.
• Облака — использовать начинают. Но amazone — использует сервера общего назначения, а они — оптимизированные под БД. Так что пока осторожно.
• Пишут запросы вручную, не через ORM.
• Используют HP и др. storage device
• Используют flash памиять, Увеличивают размер памяти.
• В 11 Oracle используют сжатие данных на exologic и др — на storage

Александр Календарев, ISOEMO. Увеличиваем производительность MySQL в десятки раз используя HandlerSocket

Любопытный доклад. HandlerSocked — это такая прокладка дял доступа к MySQL-базе данных минуя собственно MySQL, по индексам. Обеспечивается очень высокая производительность. Эффект — не парсим запросы, очень маленькая коммуникация в сети. Оптимизация запросов, буфера — все мимо, работаем на нижнем уровне. Еще — один поток может принимать несмколько потоков. Но имеем только keyvalue доступ по индексам БД, например, выбрать все города региона. При этом можно использовать не только на чтение, но и на запись.

Блиц Филиппова

Виталий рассказывал про внутреннее устройство MediaWiki и возможности расширений. Мне эта тема интересна, так что я пошел послушать. К сожалению, доклад получился в формате потока информации, к тому же выдаваемой ровным голосом. Но информация для меня была ценной. Основное — про то, что в MediaWiki на базовом уровне заложено очень много механизмов для реализации точек расширения, что позволяет делать доработки, не правя основной текст и достаточно комфортно обновляя версии. Это же породило множество (более 1700) готовых расширений от различных авторов.

Антон Белоусов, EasyFinance.ru. Заднее чутье разработчика, или как избежать проблем эксплуатации?

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

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

Основные места, в которых возникают грабли.

• Пользователи — они могут портить даные из-за ошибок в системе.
• Интеграция с внешними сервисами
• Работа после наката обновлений

Сбои — потери — разгребание проблем.

Как избежать?

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

Кто отвечает за это? Разработчик. А то он будет и расхлебывать.

Что такое «заднее чутье»?

• Источники: Люди, ПО, Железо, Процессы
• Возможные проблемы
• Решения для них
• Проверка, что решения работают (например, из бэкапа — можно поднять систему). Это — важно.

Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать

Дальше много частных решений.

• Таких как мониторинг или бэкапы.
• Протокол взаимодействия при интеграции; Проверка по контрактам входа-выхода
• Повторение запросов, рассчитывать протоколы на это.
• Резервные каналы синхронизации. Ннапример, с мобильного девайса, когда штатно не получается.
• Вести логи, уметь их передавать.
• Изоляция внешней системы — шлюз.

Работа с пользователем.

• Механизмы восстановления. Напрмиер при ошибочном удалении или редактирвоании
• Предусматривать возможность срезать углы, позволяя нарушать правила. Например, сохранять неконсистентные черновики.
• Сохранять простой вариант UI
• Обработчик ошибок верхнего уровня. Пользовательская диагностика. Интерфейс пользователя дляы ошибок.
• Глюки из-за проигнорированной ошибки: Кидайте исключения, а не код возврата. Проверяйте контракт.
• Уведомлять разработчика автоматически, отслеживать действия пользователя.
• Изолировать объекты разных пользователей (usec-spec)

Релиз

• Автоматический накат по одной кнопке
• Блокировать работу на время релиза.
• Порча базы патчами: бэкапы до и после, сравнение базы до и после, альфа-тест на отдельной площадке.
• Бета-тестирование — использование новой версии частью пользователей в продакшн, пока остальные на старой версии

Поддержка

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

Минимальный набор

• исключения — throw
• автоматический накат обновлений
• автобекапы — и не забыть проверить, что восстанавливается
• разделение доступа: база данных, ОС, сама система логины
• при интеграции — логи запрос-ответ, промежуточные
• контракты где уместно
• уведомления о сбоях
• аварийные каналы данных
• инструментарий решения задач поддержки

В заключении была рекомендация книги Michael Nygard — Release It!