Изменения
Новая страница: «= ADD-2011 и другие конференции = Был на второй конференции [http://addconf.ru/ ADD-2011]. Первая была в сен...»
= ADD-2011 и другие конференции =
Был на второй конференции [http://addconf.ru/ ADD-2011]. Первая была в сентябре [http://addconf.ru/add_2010 в Ярославле], а вторая — в Питере чуть больше, чем через полгода. Конференция понравилась первый раз (смотри [[отчет]]) и совершенно не разочаровала второй. И организацией и уровнем докладов и, главное, обстановкой общения. Я этой весной был и выступал на многих конференциях (AgileDays, SoftwarePeople, ReqLabs) и потому могу сравнивать, и, на мой взгляд, для разработчиков, которые едут на конференцию за профессиональными контактами и обменом мнениями она, на мой взгляд, лучшая. Я сейчас попробую объяснить — почему.
У организаторов и программного комитета вполне определенная позиция — это конференция для того, чтобы разработчики общались и обменивались информацией по вопросам разработки. При этом конференция должна быть доступна, и интересна для широких слоев разработчиков, а не только для каких-то продвинутых гуру. И эту позицию выдерживают — по многим пунктам. Это проведение в пятницу и субботу, используется один рабочий день — в ряде организаций не охотно отпускают на конференции, а получить один день проще чем два. Это более низкая цена, чем на других конференциях, особенно если бронировать место заранее. И главное — это отбор докладов. Они — о практическом опыте разработчиков. При этом, что интересно, в ряде докладов предметом является использование тех или иных технологий, в том числе вендорских, например, MS Workflow Foundation, но когда об этом рассказывает не вендор, а разработчик реального проекта — это звучит по-другому.
Да, про другие конференции, чтобы не было обид. Они тоже хорошие, но у них другие позиции. [http://agiledays.ru/ AgileDays] нацелен на гибкие методологии и организацию процесса разработки. У него был интересный технический трек, но все-таки основной предмет — именно организация процесса и общение преимущественно шло по этим вопросам. [http://softwarepeople.ru/2011/ SoftwarePeople] — это большая конференция, на которой было много интересных докладов по очень разным вопросам, но вот общения — сильно меньше. На [http://www.req-labs.ru/ ReqLabs] было много интересных докладов, но он нацелен на аналитиков, а не разработчиков.
Возвращаюсь к ADD-2011. Конференция проходила 2 дня, было 3 трека по 9 слотов в первый день и 10 во второй. Первые доклады второго дня начинались в 9, и это было очень тяжело. Но, в конце концов, мы же не отдыхать приехали. К тому же, можно было разместиться в той же гостинице, где проходила конференция, что в целом делало ранний подъем достаточно комфортным — хотя сама гостиница была не просто на отшибе, но и далеко от метро. В целом организация была четкой. WiFi работал хорошо и можно было быть online — в отличие от гостиницы, где точек доступа было много, но вот выйти с них в инет получалось очень плохо. Как и на прошлой конференции, шла видеосъемка и запись докладов, и это будет опубликовано. Кстати, запись большинства докладов с ADD-2010 уже опубликована Стасом на [http://addconf.ru/list.sdf/ru/add_2010/reports сайте конференции] — если перейти на конкретный доклад, то можно увидеть запись. Правда, там нельзя посмотреть по каким докладам видео опубликовано, а по каким нет, поэтому даю [http://lib.custis.ru/Категория: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, средство для лога у Кирпичева.
По разговорам со Стасом Давыдовым о фрилансе. Мне пришла мысль, что бурное развитие общения в социальных сетях, в котором многие сейчас чувствуют себя комфортно, постепенно меняет мир и, в частности, работа в распределенных командах самоорганизующихся фрилансеров может быть будущим ИТ. Этот тренд стоит учитывать.
Антон Белоусов рекомендовал книгу [http://www.pragprog.com/titles/mnee/release-it 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) про супер-большую доску, на которой видно все.
* Видеосценарии.
* Именования файлов. Правильное и общее. Я: это как именование идентификаторов, нужно.
* Механизмы массовых обновлений. Связано с именованием файлов.
* [http://ilovepsd.ru/ Правила хорошего тона в фотошопе] — надеюсь, я правильно нашел ссылку. Правила просты и для опытных людей — подразумеваемы, но их прочтение заставляет задуматься об уровне новичков и наборе сообщаемых сведений.
* Дизайнеры должны представлять ТТХ устройств, под которые проектируют. Например, для мобильников. И есть нюансы. Пример. Дизайнер знал про высоту 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
* автоматический накат обновлений
* автобекапы — и не забыть проверить, что восстанавливается
* разделение доступа: база данных, ОС, сама система логины
* при интеграции — логи запрос-ответ, промежуточные
* контракты где уместно
* уведомления о сбоях
* аварийные каналы данных
* инструментарий решения задач поддержки
В заключении была рекомендация книги [http://www.pragprog.com/titles/mnee/release-it Michael Nygard — Release It!]
[[Категория:Конференции]]
Был на второй конференции [http://addconf.ru/ ADD-2011]. Первая была в сентябре [http://addconf.ru/add_2010 в Ярославле], а вторая — в Питере чуть больше, чем через полгода. Конференция понравилась первый раз (смотри [[отчет]]) и совершенно не разочаровала второй. И организацией и уровнем докладов и, главное, обстановкой общения. Я этой весной был и выступал на многих конференциях (AgileDays, SoftwarePeople, ReqLabs) и потому могу сравнивать, и, на мой взгляд, для разработчиков, которые едут на конференцию за профессиональными контактами и обменом мнениями она, на мой взгляд, лучшая. Я сейчас попробую объяснить — почему.
У организаторов и программного комитета вполне определенная позиция — это конференция для того, чтобы разработчики общались и обменивались информацией по вопросам разработки. При этом конференция должна быть доступна, и интересна для широких слоев разработчиков, а не только для каких-то продвинутых гуру. И эту позицию выдерживают — по многим пунктам. Это проведение в пятницу и субботу, используется один рабочий день — в ряде организаций не охотно отпускают на конференции, а получить один день проще чем два. Это более низкая цена, чем на других конференциях, особенно если бронировать место заранее. И главное — это отбор докладов. Они — о практическом опыте разработчиков. При этом, что интересно, в ряде докладов предметом является использование тех или иных технологий, в том числе вендорских, например, MS Workflow Foundation, но когда об этом рассказывает не вендор, а разработчик реального проекта — это звучит по-другому.
Да, про другие конференции, чтобы не было обид. Они тоже хорошие, но у них другие позиции. [http://agiledays.ru/ AgileDays] нацелен на гибкие методологии и организацию процесса разработки. У него был интересный технический трек, но все-таки основной предмет — именно организация процесса и общение преимущественно шло по этим вопросам. [http://softwarepeople.ru/2011/ SoftwarePeople] — это большая конференция, на которой было много интересных докладов по очень разным вопросам, но вот общения — сильно меньше. На [http://www.req-labs.ru/ ReqLabs] было много интересных докладов, но он нацелен на аналитиков, а не разработчиков.
Возвращаюсь к ADD-2011. Конференция проходила 2 дня, было 3 трека по 9 слотов в первый день и 10 во второй. Первые доклады второго дня начинались в 9, и это было очень тяжело. Но, в конце концов, мы же не отдыхать приехали. К тому же, можно было разместиться в той же гостинице, где проходила конференция, что в целом делало ранний подъем достаточно комфортным — хотя сама гостиница была не просто на отшибе, но и далеко от метро. В целом организация была четкой. WiFi работал хорошо и можно было быть online — в отличие от гостиницы, где точек доступа было много, но вот выйти с них в инет получалось очень плохо. Как и на прошлой конференции, шла видеосъемка и запись докладов, и это будет опубликовано. Кстати, запись большинства докладов с ADD-2010 уже опубликована Стасом на [http://addconf.ru/list.sdf/ru/add_2010/reports сайте конференции] — если перейти на конкретный доклад, то можно увидеть запись. Правда, там нельзя посмотреть по каким докладам видео опубликовано, а по каким нет, поэтому даю [http://lib.custis.ru/Категория: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, средство для лога у Кирпичева.
По разговорам со Стасом Давыдовым о фрилансе. Мне пришла мысль, что бурное развитие общения в социальных сетях, в котором многие сейчас чувствуют себя комфортно, постепенно меняет мир и, в частности, работа в распределенных командах самоорганизующихся фрилансеров может быть будущим ИТ. Этот тренд стоит учитывать.
Антон Белоусов рекомендовал книгу [http://www.pragprog.com/titles/mnee/release-it 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) про супер-большую доску, на которой видно все.
* Видеосценарии.
* Именования файлов. Правильное и общее. Я: это как именование идентификаторов, нужно.
* Механизмы массовых обновлений. Связано с именованием файлов.
* [http://ilovepsd.ru/ Правила хорошего тона в фотошопе] — надеюсь, я правильно нашел ссылку. Правила просты и для опытных людей — подразумеваемы, но их прочтение заставляет задуматься об уровне новичков и наборе сообщаемых сведений.
* Дизайнеры должны представлять ТТХ устройств, под которые проектируют. Например, для мобильников. И есть нюансы. Пример. Дизайнер знал про высоту 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
* автоматический накат обновлений
* автобекапы — и не забыть проверить, что восстанавливается
* разделение доступа: база данных, ОС, сама система логины
* при интеграции — логи запрос-ответ, промежуточные
* контракты где уместно
* уведомления о сбоях
* аварийные каналы данных
* инструментарий решения задач поддержки
В заключении была рекомендация книги [http://www.pragprog.com/titles/mnee/release-it Michael Nygard — Release It!]
[[Категория:Конференции]]
