Георгий Русецкий, CustIS

Отзыв от Георгия Русецкого

Общее впечатление: организовано на хорошем уровне, доклады читались в трёх секциях, места всем хватало (единственно — секция B располагалась в переходе между зданиями, не очень удобный зал). Обеды, кофе-брейки также без нареканий — всё на уровне. А вот качество докладов, на мой взгляд, хуже, чем на предыдущей конференции ADD.

День 1

Language Oriented Programming (LOP) в действии (или как мы это делаем в JetBrains)

Доклад читал человек из JetBrains — Максим Мазин, один из разработчиков YouTrack, активно участвующий в разработке предметно-ориентированных языков для нужд JetBrains.

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

В качестве решения, JetBrains предлагает свой продукт — среду языко-ориентированного программирования Meta Programming System(MPS). Эта среда предоставляет удобные механизмы для разработки собственного DSL и создания с его помощью программ в современном IDE. В частности, багтрекер YouTrack разработан именно с использованием MPS. В качестве иллюстрации своих слов, докладчик показал небольшое расширения для языка Java, добавляющее конструкцию для синхронизации доступа к разделяемым ресурсам — synchronized.

Работает это следующим образом:

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

Говоря о препроцессоре, докладчик отдельно упомянул, что, несмотря на текстовое представление внедряемых в язык узлов, они не является текстом (?!). Каждый узел «живёт» в своей ячейке, отображаемой с помощью текстового представления, а проекционный редактор MPS занимается изменением непосредственно абстрактного синтаксического дерева. В настоящий момент реализован ряд расширений языка Java с использованием MPS:

  1. Язык запросов к коллекциям
  2. Язык работы с датами
  3. Поддержка замыканий
  4. Язык описания регулярных выражений

MPS — опенсорсный бесплатный продукт, поэтому с его использованием можно разрабатывать свои DSL для любых задач. На вопрос одного из участников конференции о языковых расширениях для .NET/C# — сказали, что если в JetBrains будет разрабатываться проект на .NET, очень возможно, что они появятся, но пока нет ;(.

Уже после доклада, на стенде JetBrains разработчики продемонстрировали работу с MPS (в докладе этого не было, только слайды). Продукт выглядит интересно, наверное, имеет смысл посмотреть-изучить.

Кстати, хотелось бы отдельно отметить работу стенда JetBrains на конференции. Там присутствовали разработчики основных продуктов компании: Resharper, YouTrack, dotCover, Teamcity, можно было задать вопросы, получить ответы и скидку на лицензии Resharper и Teamcity. Разработчик Resharpera в ответ на мой вопрос о разрабатываемой в компании замене ставшего платным Reflector-а, по секрету ;) сообщил о том, что их бесплатный декомпилятор dotPeek почти готов и вот-вот (в течение одной-двух недель) появиться на сайте компании по программе Early Access. Показал его в работе (почти один в один Reflector) и пообещал тесную интеграцию с 6 м Resharper-ом.

Облачная инфраструктура AWS

Докладчик — Леонид Выговский.

Доклад посвящён крупнейшей облачной платформе — Amazon Cloud Service. Были кратко рассмотрена AWS, какие сервисы предоставляются, сколько чего стоит, выполнено сравнение с Google App Engine. AWS — пожалуй старейший облачный сервис (запущен в 2006 году — EC2, S3).

Доступны следующие основные услуги: IaaS (Infrastructure as a service http://ru.wikipedia.org/wiki/Infrastructure_as_a_service, предоставление инфраструктуры), PaaS (Platform as a service, предоставление интегрированной платформы для разработки, тестирования, развертывания и поддержки веб-приложений как услуги, http://ru.wikipedia.org/wiki/PaaS) и SaaS (Software as a Service, http://ru.wikipedia.org/wiki/SaaS). Платформы: *nix и Windows. Всё за деньги, хотя бесплатно доступна минимальная конфигурация.

Докладчик рассказал о территориальном делении амазоновских облаков на регионы и зоны, о доступных способах хранения данных в облаке и поделился соображениями о выборе конфигурации для создании отказоустойчивого решения. Оказывается, предоставляемый VPS instance — весьма ненадёжная штука, может быть потушен в любой момент, при этом пользовательские данные, сохранённые на HDD instance-а будут потеряны (?!).
Стас Фомин 21:56, 30 мая 2011 (MSD): Комментарий Леонида Выговского: «Instance on Demand может сломаться, что есть в любом хостинге. При определенных, заранее обговоренных, условиях может быть потушен instance снятый на аукционе (hot spot)»

Для большей надёжности рекомендовал использовать минимум 2 инстанса, инстансы в 2х различных зонах или 2х различных регионах (с соответствующем ростом надёжности). Надёжное хранение данных достуно с использованием Elastic Block Storage (EBS) или Simple Storage Service (и то и другое — платно, в отличие от HDD инстанса). Также, докладчик упомянул про службу балансировки нагрузки между пользовательскими инстансами (Elastic Load Balancer) и службу автоматического управления количеством запущенных экземпляров в зависимости от нагрузки. В целом, очень интересный сервис для хостинга приложений.

Из плюсов:

  • не нужна своя инфраструктура, её поддержкой и обеспечением надёжности занимаются специалисты Amazon-а.
  • полный доступ к запущенным в облаке экземплярам.
  • готовые средства для управления экземплярами — их масштабированием, нагрузкой и т. п.
  • высокая надёжность и отказоустойчивость (да, тут докладчик упомянул про недавний fail амазона в одной из зон ;)

Минусы:

  • буквально за всё приходится платить (трафик, процессор, память, место для данных, балансировка и т. п.)

Интерфейсы: битва за право влияния

Докладчик — Ольга Павлова из Usability Lab.

Рассказ про проектирование взаимодействия. Мне показались знакомыми основные идеи, озвученные в докладе — читал их в книжке Алана Купера «Об интерфейсе. Основы проектирования взаимодействия». Укажу основные моменты доклада.

  • В начале процессе проектирования взаимодействия происходит выделение персонажей (ролей) и проектировании интерфейса взаимодействия для них. Персонаж — некий собирательный образ одного из пользователей интерфейса (кстати, по мнению Купера важен полный портрет — пол, возраст, образование, профессия, семейное положение и т. п. Этот персонаж даже получает собственное имя). Затем юзабилисты пытаются построить модель взаимодействия персонажа с разрабатываемой системой.
  • Ряд проблем при проектировании:
  1. Избыток контролов
  2. Тексты на интерфейсе (формулировки). Считает, что самовольные правки текстов — преступление.
  3. Сообщения об ошибках
  4. Интерфейсное хамство
  • Недоделанную работу показывать нельзя — можно отвратить пользователя. Если всё-таки приходится — нужно обставить это «ритуалами».
  • Бесконечные согласования неважных деталей интерфейса с заказчиком — зло. Но в процессе согласований можно получить и действительно важную для проектирования информацию (?)
  • Результаты обсуждения необходимо фиксировать в модели, а не в виде «бантиков сбоку».

Time management для программиста

Пошёл на доклад, полагая, что будет доклад о персональном time-management-е. Однако, докладчик рассказал об управлении рабочим временем с позиции менеджера. По докладу показалось, что автор придерживается авторитарного стиля управления. Часть обозначенных проблем и их решений банальны, тем не менее, есть интересные мысли/советы.

Проблемы:

  1. Разноплановые работы
  2. Работа под давлением
  3. Ограниченность человеческих возможностей
  4. Непредвиденные задачи
  5. Тяжёлые задачи
  6. Нелюбимые вещи (которыми приходиться заниматься)

Пожиратели времени:

  1. Болтовня (устная и письменная)
  2. Отсутствие краткосрочного планирования
  3. Неточные цели (нет чёткой постановки задачи)
  4. Много почты
  5. Митинги
  6. Рутина
  7. Синдром откладывания

Принципы эффективной работы:

  1. Быть в потоке
  2. Расставлять приоритеты
  3. Быть проактивным — видеть потенциальные проблемы и устранять их до проявления
  4. Декомпозировать задачи
  5. Ожидать форс-мажора
  6. Фокусироваться на результате
  7. Анализ и ревью своей работы

Советы:

  1. Email
    1. Сразу отвечать
    2. Читать всё
    3. Сортировать почту
    4. Проверять присланную информацию
    5. Помечать письма как задачи
    6. Заполнять Out of Office
    7. Представляться в письме
  2. Телефон
    1. Не бояться позвонить
    2. Думать, прежде чем звонить
    3. Записывать результаты обсуждений
    4. Ограничивать во времени
    5. Поддерживать телефонные контакты
  3. Задачи
    1. Должны быть прогнозируемы, выполнимы и т. п.
    2. При планировании должен быть буфер времени или ресурсов
    3. При делегировании исполнения ответственность не делегируется(?)
    4. Должен быть один ответственный за задачу
    5. Использовать напоминалки
  4. Планы
    1. Реалистичность
    2. Включение рисков
    3. Не держать только в голове — записывать
    4. Показывать планы другим (share plan)
    5. Регулярно обновлять
  5. Личностное развитие
    1. Не бояться говорить «нет»
    2. Не быть ленивыми, скучными — делиться с коллегами новинками
    3. Не останавливаться в образовании
    4. Постоянно практиковаться в навыках
    5. Обучать других
    6. Гармония (семьи и работы)

Взаимодействие дизайнера и программиста

Докладчик — Александр Черный, разработчик программ для iPhone.

Его доклад — описание проблем, возникших у разработчиков с приходом дизайнера и описание, как они их решали. Честно говоря, скучновато. Автор приводит названия софтин, которые использовались для разработки внешнего вида интерфейса, говорит о специфических проблемах при разработке UI под iPhone (разрешения, шрифты, цвета и т. п.). Также даёт немного советов из собственного опыта по инструментам проектирования UI:

  1. Бумажные заготовки
  2. Трафаретки
  3. Balsamiq mockups
  4. Adobe

Считает, что дизайн по почте — отстой (подтверждаю, тоже был такой негативный опыт).

Свободные лицензии: улыбнитесь тому, кто сидит в пруду

Докладчик — Михаил Шигорин, участник ALT Linux Team.

Цель доклада — прояснить текущее положение дел с лицензиями на ПО.

Софтверная лицензия включает в себя:

  1. Договор оферты
  2. Определённый объём прав
  3. Определённые обязательства

Различные лицензии отличаются набором прав и ограничений.

Проприетарная

  1. Можно купить
  2. Нельзя свободно применять
  3. Нельзя модифицировать
  4. Нельзя распространять

Shareware

  1. Отличается от проприетарной отсутствием запрета на распространение

Non-free/freeware

  1. Разрешается использовать и распространять
  2. Можно заплатить авторам (donation)
  3. Нельзя модифицировать

Public Domain

  1. Можно всё (однако, работает не во всех юрисдикциях)

С исходными кодами — вид СПО

Free/permissive

  1. Минимальные обязательства (однако, не всёгда ясно, можно ли распространять ПО)

Free / Copyleft

  1. Можно модифицировать и распространять только под той же лицензией

Докладчик отметил, что Open Source — всего лишь исходники, с ними могут не передаваться права («бесплатный != свободный»). Интересная аналогия Free Software с общественно-полезными сущностями (дороги и т. п.) Касательно отношения бизнеса к свободным лицензиям. По мнению докладчика, часто применяемая парадигма «закрыть, а то сопрут» неверна, спереть можно код, а не опыт и знания.

Улучшение взаимодействия между разработкой и тестированием

Доклад немного маркетинговый, про использование ПО от HP для управления процессом разработки. Добрую треть доклада рассказывалось про эволюцию процесса разработки с ростом компании. Сначала просто отдел разработки, затем появление отдела QA, в котором в свою очередь появляются подразделения ручного тестирования, автоматизации тестирования и т. п. В общем, делается вывод, что с ростом компании увеличивается сложность процессов => сложность управления компанией => нужна автоматизация. Были отмечены тенденции:

  • Agile
  • Самоорганизующиеся команды
  • Упрощение архитектуры
  • Автоматизация процесса

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

MongoDB

MongoDB — современная нереляционная документо-ориентированная база данных. Eё можно считать золотой серединой между реляционными DB и чистыми хранилищами key-value (как memcached).

Основные качества:

  • Документо-ориентированность (документы хранятся в JSON-подобном формате)
  • Индексы по любому или нескольким атрибутам
  • Удобная репликация с автоматическим failover
  • Богатый язык запросов
  • Поддержка Map/Reduce
  • Подсистема хранения файлов любого размера — GridFS
  • Автоматический sharding

Масштабирование:

  • Автоматическое (нужно выбрать shard key)
  • Определить распределение данных
  • Трудно изменить ключ после назначения

Данные разбиваются на блоки (chunks) размером < 64Mb или 100000 объектов. В фоновом режиме работает балансировщик.

Где использовать:

  1. Статистика
  2. Богатое key-value хранилище
  3. Прототипирование
  4. Динамические данные (CMS, опросы)

Взаимоотношения заказчика и исполнителя на проекте

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

Несмотря на то, что любой проект — совместное детище заказчика и разработчика, и никто не может сказать заранее, где возникнут проблемы, часто заказчик требует указания сроков и бюджета («Я не знаю, что мне нужно сделать, но мне нужны точные сроки и бюджет.»). Отсюда:

Цель разработчика — сделать заказчика счастливым за определённые срок и бюджет (при этом, как ни странно, не столь важна реализованная функциональность).

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

  1. Кто клиент? А кто будет пользоваться? Часто это разные люди
  2. Есть ли у него опыт заказной разработки?
  3. Кто платит, кто ставит задачу, кто проверяет
  4. Понимает ли он, зачем ему это?

В процессе разработки нужно активно взаимодействовать с заказчиком, стремясь достичь единого понимания целей, рисков, точности оценок. Крайне желательно знать, что можно урезать при необходимости, что можно перенести на потом (но при этом всё же сделать), то есть иметь представление о приоритетах задач. Также является важным документирование в процессе работы над проектом.

  1. Vision — идея проекта (1 страница)
  2. Требования (формируются в начале работы, страниц на 100, необходимо провести review с разработчиками и заказчиком), а также эскизы и use-cases.
  3. Тест-план. По признанию докладчика, они сами обычно его не делают, если требования прописаны детально
  4. План проекта
  5. Deployment — диаграмма (чтобы не было проблем за день до сдачи, когда выясниться, что написанный софт не ставиться на оборудование заказчика)

Для контроля процесса разработки применяются различные инструменты. Некоторые из них, которые применяются в компании докладчика:

  1. Трекинг прогресса разработки. Два прогресс-бара, один показывает готовность проекта по плану, другой — расход бюджета.
  2. Регулярные релизы, ревью с клиентом
  3. Сперва сделать вчерне всё, поскольку 30 % окажется не нужно, и нет риска застрять на полировке какой-нибудь фичи.

Если клиент не верит в предъявленные трудозатраты, можно:

  1. Показать внутреннюю отчётность
  2. Показать багтрекер
  3. Распечатать код — по утверждению докладчика, он однажды так и поступил ;)

Что касается вопросов применяемой архитектуры и компонентов:

  1. Знакомый инструментарий лучше, поскольку всё новое — непредсказуемо
  2. Готовый сторонний код снижает стоимость и увеличивает риски
  3. Повторное использование компонентов. Велика вероятность, что клиенту подойдёт ранее разработанное решение (его часть)
  4. Интеграция с существующими системами — огромный риск

Сделать больше, чем просили — напрашиваться на проблемы. Особенно этого не любят западные заказчики («зачем вы сделали, то, что мы не просили, и кто за это заплатит?»)

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

Оригинал отзыва
http://lib.custis.ru/ADD_2011:_Отчёт_Русецкого_Георгия

Партнеры конференции

Заметили ошибку?