|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Максим Цепков - отчет об ADD-2011Материал из CustisWikiВерсия от 11:08, 18 мая 2011; StasFomin (обсуждение | вклад) Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений. В статье Максим Цепков - отчет об ADD-2011/Заметки по докладам - полные заметки, которые я делал на конференции - сохранил для себя Содержание
ADD-2011 и другие конференцииБыл на второй конференции ADD-2011. Первая была в сентябре в Ярославле, а вторая — в Питере чуть больше, чем через полгода. Конференция понравилась первый раз (смотри отчет) и совершенно не разочаровала второй. И организацией и уровнем докладов и, главное, обстановкой общения. Я этой весной был и выступал на многих конференциях (AgileDays, SoftwarePeople, ReqLabs) и потому могу сравнивать, и, на мой взгляд, для разработчиков, которые едут на конференцию за профессиональными контактами и обменом мнениями она, на мой взгляд, лучшая. Я сейчас попробую объяснить — почему. У организаторов и программного комитета вполне определенная позиция — это конференция для того, чтобы разработчики общались и обменивались информацией по вопросам разработки. При этом конференция должна быть доступна, и интересна для широких слоев разработчиков, а не только для каких-то продвинутых гуру. И эту позицию выдерживают — по многим пунктам.
Да, про другие конференции, чтобы не было обид. Они тоже хорошие, но у них другие позиции.
Возвращаюсь к ADD-2011. Конференция проходила 2 дня, было 3 трека по 9 слотов в первый день и 10 во второй. Первые доклады второго дня начинались в 9, и это было очень тяжело. Но, в конце концов, мы же не отдыхать приехали. К тому же, можно было разместиться в той же гостинице, где проходила конференция, что в целом делало ранний подъем достаточно комфортным — хотя сама гостиница была не просто на отшибе, но и далеко от метро. В целом организация была четкой. WiFi работал хорошо и можно было быть online — в отличие от гостиницы, где точек доступа было много, но вот выйти с них в инет получалось очень плохо. Как и на прошлой конференции, шла видеосъемка и запись докладов, и это будет опубликовано. Кстати, запись большинства докладов с ADD-2010 уже опубликована Стасом на сайте конференции — если перейти на конкретный доклад, то можно увидеть запись. Правда, там нельзя посмотреть по каким докладам видео опубликовано, а по каким нет, поэтому даю еще одну ссылку — на сайт нашей компании. Кстати, по части докладов опубликовано не только видео, но и расшифрованная стенограмма. Отдельная благодарность Стасу Фомину, председателю программного комитета, за отбор докладов и планирование треков — оно, на мой взгляд, было удачным и каждый мог найти доклад по интересам почти все время конференции. Хотя определенные недовольства тем, что два доклада по одной технологии идут параллельно и потому надо выбирать я на конференции слышал. Стас Фомин 15:56, 17 мая 2011 (MSD): Пример?
Первый день конференции был, на мой взгляд, сильнее второго. Хотя я могу и ошибаться — возможно, дело в том, что на второй день был мой доклад и и доклад Коли Гребнева из нашей компании, которые, естественно, я не могу оценить с позиции слушателя, а впечатления от большого набора слотов по Nemerle смазывалось потому, что основной разработчик недавно приезжал к нам в CUSTIS на встречу Alt.Net и 4 часа об этом рассказывал. Надо отметить, что часть докладов относятся к относительно начальному уровню использования тех или иных инструментов и технологий. И, например, для меня — не представляют ничего нового, даже по тем технологиям, которые я не использовал — я это знаю за счет общего информационного фона в нашей компании. Но я тут в тепличных условиях — у нас в компании очень хороший информационный фон даже по тем технологиям как по используемым технологиям (C# и .Net, Java, Oracle), так и по другим, которые напрямую не используются, в том числе современным. А еще — когда рассказывают практический опыт — это всегда полезно и это не мое умозрительное представление, это я слышал по отзывам других участников. После таких докладов у части всплывают их собственные задачи, где можно было бы попробовать те или иные решения. Было также несколько доклады-обобщений собственного опыта по какому-либо аспекту разработки, например, по граблям, возникающим на внешних взаимодействиях — внедрении, интеграции и т. п. И даже если не узнаешь ничего нового, получение такого списка в докладе заставляет задуматься, заново вспомнить и осмыслить свой опыт, что полезно. А еще — вспомнить о том, что в компании опыт — есть, а check list — отсутствует, а тут в презентации его заготовка, которую можно взять. И это относится только к части докладов. Было много докладов от разработчиков, которые находятся на острие технологий, например, от JetBrains по Language Oriented Programming и от основного разработчика по Nemerle. И даже спонсорские доклады, были не традиционной пропагандой своих продуктов, а представляли интерес, например, Андрей Кощеев HP рассказывал, как у них устроено взаимодействие между разработкой и тестированием, а заглянуть внутрь такой крупной компании — интересно и полезно. Дальше — обзор докладов. И я его не буду ранжировать по оценкам, потому что почти все, что я слушал — мне нравилось. Правда, в обозрении не все слоты — в основном потому, что кулуарное общение на конференции было столь интенсивным и интересным, что отвлекало от докладов. Что я вынес с конференцииПлатформы для DSL интенсивно развиваются. Я немного обсуждал с Мазиным из JetBrains. На платформе MS есть графический MS DSL и Nemerle для языковых расширений. А на Java — JetBrains MPS. Еще можно на MPS сделать универсальный автономный DSL для обеих платформ, а поскольку в .Net есть Java, то, возможно, на MS DSL можно делать кросс-платформенный графический DSL. А вот Simonyi никак не выпустит свой софт (http://www.intentsoft.com), идеями которого был вдохновлен MPS. Графический DSL обычно лучше с маркетинговой точки зрения, но, возможно, хуже для программистов, здесь интересен опыт JetBrains в YouTrack. Идея — что картинки рисовать точечно, потому что область, где они лучше текста — ограничена. Идея Раскина — графически представляем, но описываем, правим и вводим текстом. Например, имеем набор дел, выбрали конкретное и командами меняем, а не gui. Программисты пользуются. А hr — учат их, но осваивают плохо, преимущественно gui. Кстати, сейчас выходит YouTrack-3 с workflow, и они внутри компании на нем делают всякие приемы на работу и увольнения. Настройка workflow пока не графическая, но есть в планах. Так что, возможно, через некоторое время появится MPS с графикой — YouTrack сделан на нем, ограниченная версия используется для точек расширения. С доклада Чашкина по HTML5. Сейчас туда заложены механизмы, который вроде как позволяет сделать web-приложение работающим как online, так и автономно, с синхронизацией с центральным репозиторием по кнопке. Это, в целом, демонстрировалось в реальном продукте. В основном это дают два механизма — локальные базы данных и настраиваемое кеширования запросов на сервер, включая ответы скриптов. При этом кеширование запросов настраивается поверх работающего приложения. Но, естественно, это не для любого приложения, есть ограничения на архитектуру. По-моему, сочетание технологий может дать некоторый технологический прорыв. Но пока еще есть технические ограничения — большинство больших броузеров не поддерживают html5 в нужном объеме, а вот на Safari iPhone уже все есть. Наблюдается отчетливая общественная тенденция — один человек пишет фреймфорк (или продукт), который многие используют и это в рамках некоммерческой деятельности. Примеры с конференции — mvp4g, nemerle, средство для лога у Кирпичева. По разговорам со Стасом Давыдовым о фрилансе. Мне пришла мысль, что бурное развитие общения в социальных сетях, в котором многие сейчас чувствуют себя комфортно, постепенно меняет мир и, в частности, работа в распределенных командах самоорганизующихся фрилансеров может быть будущим ИТ. Этот тренд стоит учитывать. Антон Белоусов рекомендовал книгу Michael Nygard — Release It! и, наверное, я ее прочту. Доклады CUSTIS по DDDНачну я отчет с двух докладов по Domain Driven Design — моего и Коли Гребнева, который тоже работает в нашей компании. Несмотря на работу в одной компании, у нас весьма различаются взгляды на DDD, что выяснилось в процессе подготовке. При этом мы оба считаем, что находимся в согласии с Эвансом и его книгой по DDD, и имеют место быть просто разные интерпретации. Поэтому доклады представляют собой разные точки зрения. К тому же они разнесены по темам: Коля рассказывал об основах применения DDD при объектном программировании и объектных моделях предметной области, а я — о необъектных моделях предметной области, которые могут реализовываться в рамках DDD, в том числе и на объектных языках программирования. Оба доклада вызвали интерес, вопросы и обсуждения участников. А я кратко остановлюсь на общем в наших взглядах и на различных точках зрения — быть может, это побудет читателей посмотреть доклады и сформировать свою точку зрения или, во всяком случае, лучше представлять спектр представлений о DDD. Итак, поскольку мы оба опираемся на концепцию DDD и, прежде всего на концептуальную книгу Эванса, которую оцениваем высоко, то имеется много общего. Это, прежде всего — модель, которая строится как модель предметной области, а потому становится моделью системы. Модель должна прослеживаться как в предметной области, так и в программном коде. Для построения модели используется единый язык, понимаемый как заказчиками и пользователями, так и аналитиками и разработчиками. И этот единый язык должен включать графические диаграммы для представления модели, например, диаграммы классов. Самой распространенным способом построения модели является объектно-ориентированная парадигма. При этом DDD — не тоже самое, что ООП. В рамках ООП мы, вообще говоря, можем иметь дело с любыми объектами, например, экранными формами и их областями или объектами работы с базой данных — DataSet и RecordSet. А DDD говорит о том, что объекты должны соответствовать реальным бизнес-объектам предметной области. А дальше начинаются различия. Коля полагает, что отражение модели в код должно быть прозрачным переводом с языка модели на язык программирования и именно об этом говорил в своем докладе. То есть классы модели должны быть отражены в классы на языке, описания действий в модели должны быть отражены в их реализацию и так далее. А если потребности эффективной работы требуют внутренней реорганизации методов, появления каких-то промежуточных сущностей или действий, то они должны появиться в модели. Таким образом, пределы и способ работы на DDD существенно определяется имеющимися средствами реализации. И, если говорить о приложениях с базой данных, то применение DDD означает использование шаблона «Модель предметной области» описанного у Фаулера. Обо всем этом Коля рассказывал в своем докладе. Я же полагаю, что отражение в реализацию может быть гораздо более сложным. Важно лишь, чтобы оно было регулярным, и элементы модели можно было проследить в коде. Что достигается применением шаблонов для этого отражения. Например, можно использовать DDD при реализации работы с базой данных через DataSet/RecordSet. Надо лишь договориться, что каждой бизнес-сущности будет соответствовать свой единственный RecordSet и свой TableAdapter, записи в котором суть элементы класса, а каждый бизнес-метод реализуется как метод в этом RecordSet. Может быть другое отражение, важно лишь, чтобы оно было одинаковым по всей системе и соответствие не нарушалось. Такой подход дает возможность применять необъектные модели предметной области в DDD, несмотря на реализацию на объектных языках программирования — надо лишь построить шаблоны. О двух из них, применяемых в нашей компании, я рассказывал — документооборот на основе диаграммы состояний с использованием шаблона State Entity и реализация учета с собственными диаграммами учета и шаблоном отображения. Краткие резюме докладовРезюме докладов идут в том порядке, в котором я их слушал на конференции — поскольку практически все доклады мне понравилось, я не стал их делить по оценкам. Максим Мазин, JetBrains. Language Oriented Programming (LOP) в действииОчень хороший и интересный доклад. Про концепцию не только реализации собственных DSL для классов задач, но, что интереснее, про реализацию расширений к языкам общего назначения, обеспечивающих те или иные типовые конструкции, применяемые при разработке в виде шаблонов. Смысл расширений — они позволяют скрыть громоздкие языковые конструкции, например, оформление определенных фрагментов кода в с блоками finaly и перехватом исключений. С помощью расширений можно комфортно использовать фреймфворки, которые требуют не только кода на Java, но, например, конфигураций в xml — описывая все на языке. У JetBrains есть инструмент для реализации DSL и расширений — MPS. Получается компилятор и IntelliSense в редакторе. Пока поддерживается 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 для программистаДоклад был про управление проектов менеджером. В целом — правильные, понятные и известные вещи. Известные — мне, из различных книг по организации разработки.
Единственное — они находятся в противоречии с современными трендами по самоорганизации команд, автономности и творческому подходу разработчиков, но это — каждый выбирает для себя. Более того, я примерно представляю, где работает такой подход — он позволяет делать проекты силами не очень квалифицированных, начинающих исполнителей, которые при этом учатся. Но получив опыт те, кто не станут менеджерами — уйдут. А еще стиль доклада — авторитарно-директивный. Делайте так! А когда в этом стиле излагаются даже правильные вещи — они вызывают отторжение, увы! Потому что это такое зомбирование идеологическое, хоть и правильное. Я немного послушал и ушел. Иван Чашкин, Дзенмани.ру. Веб-приложения на HTML5, как альтернатива нативным приложениямЯ пошел потому, что хотел больше узнать про тренды и концепции. А также в целом про личный опыт. А доклад — больше про технические детали, содержание самого html5. Во многом я слышал это на других докладах. С другой стороны, рассказ был с интересными деталями, за ним стоит много личного опыта и, что очень интересно — разработка реального проекта. Но я решил, что Виталий, который там был — адекватно воспримет. Вернулся в конце на вопросы вовремя. Обсуждение механизмов кеширования наводит на любопытные мысли. Похоже получается сделать web-приложение работающим как online, так и автономно, с синхронизацией с центральным репозиторием по кнопке. Это, в целом, демонстрировалось в реальном продукте. При этом кеширование запросов настраивается поверх работающего приложения, включая ответы скриптов. Еще важны локальные базы данных. Но, естественно, это не для любого приложения, есть ограничения на архитектуру. По-моему, сочетание технологий может дать некоторый технологический прорыв. Но пока еще есть технические ограничения — большинство больших броузеров не поддерживают html5 в нужном объеме, а вот на Safari iPhone уже все есть. Александр Черный, Студия Михаила Кечинова. Взаимодействие дизайнера и программистаВзаимодействие — в веб разработке и в мобильной. Доклад начался с достаточно понятных, общих тезисов. Таких как понимания скоупа, сотрудничество, соседство, лучше сидеть в одной комнате. Но потом перешло к конкретным практикам для дизайнеров. И это интересно.
Евгений Кирпичёв, 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 ты можешь подменять, в том числе для целей тестирования, а интерактив презентеров сохраняется. Еще интересное.
Дальше было про 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. Наращиваются механизмы фоновой оптимизации. Например, балансировка чанков в фоновом режиме. Был интересный пример, как сжать таблицу без остановки — включаем вторую ноду-реплику, перелдиваем, сжимаем, переливаем изменения мастера, мастер выключаем. Рекомендации по быстродействию — в целом понятные, известные и по реляционным базам данных.
Интересно, что бывает использование совсем не по назначению — просто Server side jscript… Дмитрий Завалишин, Digital Zone. Взаимоотношения заказчика и исполнителя на проектеДмитрий Завалишин на этой конференции рассказывал не про Фантом ОС (которая постепенно развивается, это из разговоров в кулуарах), а про менеджерскую часть своей деятельности. Которая, думаю, весьма успешна — если остается время и силы на Фантом ОС. Их компания занимается заказной разработкой, и Дмитрий обобщал опыт. Как он сказал, это первый его доклад по такой теме. В целом мои впечатления — это очень сокультурно нам, нашим мыслям. И — мы соразмерны по уровню, что редкость. В докладе был определенный экстремизм, хотя очень мне импонирующий — когда мы делаем не так (что бывает не часто), в меня скребут кошки. Хотя у них компании — несколько другая бизнес-модель, при этом проекты — сопоставимые с нашими, 20-30 человеко-лет. Они делают ставку на точные спецификации, исполняемые разработчиком. Мы так работали примерно лет 6-7 назад, а потом — сменили парадигму, приняв что квалифицированный разработчик сам способен сделать приличную часть постановки, если понимает бизнес-часть, а понимать ее в многолетних проектах он будет. Дальше я оставляю практически все заметки в исходном виде. Начало — традиционное, 80 % провалов.
Ответ программерский — виноват заказчик. Заказ по умолчанию — «на сайте должен быть форум». Когда дальше работают аналитики — у него просыпается фантазия, он хочет многое. Только потом — у него нет денег, и вообще это ему не нужно. Они стараются урезать хотелки, направить на важное, решение реальных проблем. Российский заказчик склонен снимать ответственность. Реально проект — совместная деятельность. Гарантировать от проблем не может никто. Цели.
Бывают проекты только со счастьем клиента — сам проект провалился, зато дал заказчику альтернативное видение ситуации, с которым он развивается дальше. Функциональность в списке целей отсутствует — потому как реально это самая гибкая часть. Всегда что-то уходит, что-то приходит, в общем случае не нужно ничего. Заказчик должен сказать, как он будет на проекте зарабатывать деньги (или как проект сделает его счастливым, это синонимы!). Если уяснив бизнес-задачу поняли, что можно сделать проще — не скрывайте. Надо выйти в бизнес-минимум реализации, на котором можно пробовать. Если клиент хочет неоправданно сложный проект — отказывайтесь. Важно — нужны конечные пользователи, стейкхолдеры, а не только директор. Ситуация: «директор посмотрел и сказал — все переделать» +30 % переработки. И Менеджер не может принять проект. Реально, это проблема Разработчиков — надо на входе понять, кому сдавать. Но даже если пользователи принимать не будут — они потом будут пользоваться и вас материть — оно вам надо? Лезьте в бизнес-схемы клиента. Понимайте зачем. Узнайте бюджет. В России тяжело, вопрос про деньги «не приличный». Ты хочешь узнать, сколько у меня денег и потратить? Да, хочу — все равно проект будет дороже и дольше, и эти деньги мы потратим — так что скажи сразу, мы разумнее спланируем. Коммуникации
Если про цели как-то есть, то 2 и 3 — реже. Желательно
Пример. Интеграция, задача — положить файл куда надо. Казалось бы, понятно. Выяснилось — у них vpn и по нему нет админа, это настроено когда-то и живет. Они очень долго доносили ситуацию до клиента. Надо донастроить vpn, но некому. Им не дают и понятно почему — люди с улицы будут достраивать безопасность сети. Пример. Отложить оплату части проекта — на поддержку. Бумажки
Важно. Клиенту требования надо структурировать по бизнес-областям. А программист часто хочет получить кусок на код, а остальное не слишком читать. Я: Это видение у нас было лет 5 назад. Работает и востребовано когда программисты не погружаются в бизнес-область. На их потоке проектов это оправдано. Инструменты.
Я: Это правильно — делать по фрагментам надо вчерне, а не до совершенства. Но делать, а не прототипы. Что делать когда клиент не верит. Например, две задачи, он считает, что оно почти одно и то же, а стоимость — разная. У них разработчики в конце недели пишут лог (тайсминг) в свободной форме. Их можно предъявить, и нельзя подделать, это в крупном. А сейчас научились фиксировать время на баги. Это все можно показать клиенту, объяснить и убедить. Архитектура и компоненты
Больше — не есть лучше. Беда российских разработчиков — сделать больше. Нет, если за те же деньги — не вопрос. Но больше-то не нужно. А иногда и мешает. Плюс усложнили реализацию — усложнили использование. И это может выйти боком. А убить сделанное — только расстраиваться. После 90 % бюджета получается нормальный продукт. Хороший — будет после еще 90 %. А третьи 90 % позволят сделать блестящим. Поэтому надо сделать вчерне за 30 % времени и бюджета — тогда есть шанс получить блестящее за остатки. Хотя у них не слишком работает. Очень важно — постанализ по проекту.
Оценка одного «за три дня» — значит за 5-6. А другого — за 2 сделает что нужно, еще день будет развивать и надо остановить. Это можно понять только на опыте постфактум, и надо это делать. Сравнение с инхаузом. В том числе — коэффициент года. Налоги. Инхауз обычно не считает затраты админов, которые часто закрывают деплоймент. Почитать документацию — тоже реальная работа. Как выбирают подрядчика.
Вопрос — фикс или тм. У них в основном фикс. ТМ — мечта, но расслабляет. А еще при ТМ клиент тоже начинает париться на тему, что он действительно хочет. Стас Давыдов. Фриланс: будущее IT-разработки (уже наступило)Мы с ним беседовали накануне в обед. Фриланс. Он становится коллективным. Коллективная работа — как общение в социальных сетях, но в результате продукт. В современном мире совместная жизнь в сети, без реальных встреч становится для многих комфортным и эффективным способом общения, и это — новый тренд, которого не было, когда формулировался agile. Это дает новые возможности. И создает базу новых реалий коллективной работы. К сожалению, доклад, на мой взгляд, был несколько менее интересным, чем живое общение. Было много общих слов про возможности, которые дает фриланс, в то время как слушателям было бы более интересна конкретика, реальный опыт. Например, понятно, что фриланс в принципе дает возможность регулировать свое рабочее время. Но то, что можно обеспечить комфортный доход при в среднем 20 часах в неделю, и Стас некоторое время так работал, при этом когда нужны деньги можно дойти до 60 (и будет втрое больше) — это уже было после доклада, в общении. Но при этом есть работодатели, которые нанимают фрилансеров для экономии на зарплате, и требуют присутствия — это надо учитывать, и есть нюансы — требуют ли реального присутствия или просто доступности для каких-то консультаций. А еще — не смотря на гибкий график, эффективность часто меряется довольно жестко, через счетчик времени, и за этим следят. Так же как подходы к выборке задач — когда надо трезво оценивать трудоемкость, учитывая что часто хотят сэкономить, но иногда бывают подарки, когда деньги большие. По работе есть oDesk — интегратор фрилансеров. Еще важно, что фрилансер сам планирует свое развитие, это и возможность и обязанность. Так что в целом — это альтернативный способ работы, со своими плюсами, которых много, но за которые надо платить. Максим Игнатов e-Legion. Разработка приложений с использованием Windows Workflow FoundationЭто был рассказ про внутренний проект компании — сопровождение найма сотрудников на WWF. Сделан в свободное время (правило 20 %), реально используется. Доклад полезен для тех, кто хочет познакомиться с возможностями WWF, однако они представлены там на начальном уровне — это лично я и так представляю, тем более что часть иллюстраций были на примерах из документации. Из практического — они реально работают с очень изменяющимся процессом и им успешно удается вносить изменения при наличии незавершенных процессов. Они не используют подписание сборок, чтобы для незавершенных циклов использовался старый вариант (и тут я с ними согласен), а применяют миграцию или предусматривают старый вариант просто в бизнес-логике, и то и другое работает. Павел Белоусов. Пример разработки высоконагруженной реляционной базы данныхНа доклад я пришел почти в конце, потому что общался после своего доклада. Доклад был о приложении по синхронизации объектной оперативной базы данных в реляционную. В объектной базе данных хранятся оперативные данные, она хорошо масштабируется. В реляционную передается только часть, обеспечивающая поиски и запросы, и она существенно меньше по объему. При этом есть разные требования по оперативности передачи для разных данных — от минут до часов. Проект был начат семь лет назад, и сейчас стадия — доработка по требованиям на изменения. А также оптимизация — за время эксплуатации в реляционной части накоплены большие объемы данных. Для меня лично содержание доклада большого интереса не представляло, так как по своему опыту работы с базами данных я эти механизмы хорошо представляю. Это Этап решение проблем в тяжелыми запросами, блокировками и deadlock.Однако, доклад будет интересен тем, у кого такие задачи встают в первые. Механизмы, упомянутые в докладе.
Михаил Антонов, Magenta Development. Особенности масштабирования систем планирования и управления поставкамиСистемы управления поставками для крупных американских и некоторых европейских ритейлеров. Сырье — Вендор — Ритейлер — Покупатель. Товар вперед, по заказам. Без возвратной логистики. Очень интересный для меня доклад, поскольку наша компания, в числе прочего, занимается именно проектами управления снабжением магазинов для Спортмастера. Сам доклад — очень удачный. Михаилу удалось в кратком докладе рассказать о бизнес-задаче управления цепочкой поставок, о технических сложностях ее решения и о методах оптимизации. Задача, по моему опыту, весьма сложная и то, что они деляют — впечатляет. Бизнес-задача — снабжение магазинов на основании текущих остатков и прогнозов продаж.
Особенности работы с заказчиком.
Система обеспечивает решение следующей задачи. Надо ежедневно получать данные о продажах, конвертировать, валидировать, загружать. Далее — обрабатывать, обеспечивая создание заказов и корректируя имеющиеся прогнозы, долгосрочный и краткосрочный. При этом время на обработку ограничено — после получения всех данных и до первой стадии бизнес-процесса обработки заказов, обычно на это 1-1.5 часа. А объемы данных большие, оценка — 2К маг * 50К товаров (продаж в день) * 500 дней = 50 млрд строк продаж. Реально 5-10 млрд. Пользователей системы мало, десятки-сотни они эксперты в предметной области. И они наблюдают за процессом и тушат пожары. Обнаруживать и тушить надо быстро, для этого им надо быстро и наглядно представить данные. Система работает для нескольких заказчиков. У них есть общее ядро и дальше — настройка на заказчика. При этом граница системы проходит по-разному, различна и степень вмешательства пользователей — в одних случаях пользователи подтверждают каждый заказ, в других работает почти автомат. Алгоритмы прогнозирования они делают сами, однако существует учебный режим, в котором пользователи формируют статистику для работы алгоритмов или тестируют. Но реальная проверка — все равно на боевых данных. Технологии.
Задачии оптимизации
Большие таблицы — Partitioning. Если пара таблиц имеет одинаковый partitioning, то join это учитывает. Загрузка — SQL*loader, с использованием различных ускоряющих приемов.
Оптимизация запросов по планам решения. Реально оптимизатор — улучшается. Сейчас они удаляют хинты, написанные 3-4 года назад. Oracle Grid Control. Вкладки мониторинга запросов — он показывает еще и динамический план: сколько записей в запросе и столько он уже вытащил. И известный способ — трассировка sql_trace, tkprof. Оптимизация пользовательского интерфейса
Пакетная обработка — цепочка engines. Масштабы впечатляют — 10К одновременных тасков, 2M всего в таблице. И это — наиболее критичная задача.
Александр Календарев, ISOEMO. Увеличиваем производительность MySQL в десятки раз используя HandlerSocketЛюбопытный доклад. HandlerSocked — это такая прокладка дял доступа к MySQL-базе данных минуя собственно MySQL, по индексам. Обеспечивается очень высокая производительность. Эффект — не парсим запросы, очень маленькая коммуникация в сети. Оптимизация запросов, буфера — все мимо, работаем на нижнем уровне. Еще — один поток может принимать несмколько потоков. Но имеем только keyvalue доступ по индексам БД, например, выбрать все города региона. При этом можно использовать не только на чтение, но и на запись. Блиц ФилипповаВиталий рассказывал про внутреннее устройство MediaWiki и возможности расширений. Мне эта тема интересна, так что я пошел послушать. К сожалению, доклад получился в формате потока информации, к тому же выдаваемой ровным голосом. Но информация для меня была ценной. Основное — про то, что в MediaWiki на базовом уровне заложено очень много механизмов для реализации точек расширения, что позволяет делать доработки, не правя основной текст и достаточно комфортно обновляя версии. Это же породило множество (более 1700) готовых расширений от различных авторов. Антон Белоусов, EasyFinance.ru. Заднее чутье разработчика, или как избежать проблем эксплуатации?Антон вырос от разработчика до менеджера проектов, это был его первый доклад на конференции и удачный. Большинство участников в этот слот пошли слушать доклада Орлова и Панкратова, с которыми я знаком по различным конференциям, и потому решил послушать неизвестного мне докладчика. И не пожалел. Доклад, по сути, представляет собой некоторый список мест, где в проекте потенциально могут быть грабли и, чтобы проект был успешным, на эти места следует обращать внимание. Неизвестных для себя мест я не обнаружил. Однако, по мере рассказа вспоминал, что о некоторых из них — рассказывал новым разработчикам. А списка в компании — нет. Приведенный в докладе вполне можно взять за основу, потому что все пункты — по делу. Ну и кто-то вполне может обнаружить и новое. неизвестное для себя. Основные места, в которых возникают грабли.
Сбои — потери — разгребание проблем. Как избежать?
Кто отвечает за это? Разработчик. А то он будет и расхлебывать. Что такое «заднее чутье»?
Прототип системы: нужен минимум — диагностика. В первой боевой версии — желателен максимум защиты. И далее надо постоянно поддерпживать Дальше много частных решений.
Работа с пользователем.
Релиз
Поддержка
Минимальный набор
В заключении была рекомендация книги Michael Nygard — Release It!
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
 |
 |
 |
