ADD 2011: Отчёт Русецкого Георгия

Материал из CustisWiki
Перейти к: навигация, поиск


Конференция проводилась 29-30 апреля 2011 в Санкт-Петербурге.

Гостиница (бизнес-отель «Карелия»): Весьма неплохая (на фоне отстойной гостинице в Ярославле, где проводилась ADD-2010, просто отличная). Правда, обещанный WiFi работал только в холле гостиницы, в номере не работал.

Организация: Общее впечатление: организовано на хорошем уровне, доклады читались в трёх секциях, места всем хватало (единственно — секция 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. Интеграция с существующими системами — огромный риск

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

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

День 2

Разработка приложений с использованием Windows Workflow Foundation

Докладчик — Максим Игнатов, руководитель проектов компании e-Legion.

Windows Workflow Foundation (WWF) удобно применять при разработке приложений, автоматизирующих длительные бизнес-процессы (документооборот и т. п.). Для таких процессов характерны набор состояний, в каждом из которых процесс может находиться неопределённо долгое время и ограниченный набор переходов между этими состояниями. Состояние процесса сохраняется в БД. В компании докладчика WWF была применена для разработки приложения, автоматизирующего какие-то процессы в отделе персонала. Целью доклада было заявлено показ узких мест WWF и решений возникших проблем. Вначале докладчик рассказал про разработанную систему, затем немного рассказал про подходы к использованию WWF при разработке приложений.

  • Разделить процесс на подпроцессы
    • Плюсы:
      • Часто проще соотносится с моделью данных
      • Менее тяжеловесный Workflow
    • Минусы
      • Требуется логика маршрутизации к к нужным Workflow
  • Единый процесс на всё
    • Плюсы
      • Не нужна маршрутизация
    • Минусы
      • Модель размазана
      • Тяжеловесный Workflow

Далее был рассказ про возникшие при использовании WWF проблемы, связанные с миграцией сохранённых процессов при изменении Workflow. В целом, ИМХО, технология заслуживает внимания и изучения.

Эффективная разработка бизнес-приложений на Silverlight и WPF

Доклад оказался посвящён использованию фреймворка Prism 4 для разработки бизнес-приложений.

Отмеченные особенности Prism:

  • Модульный подход
  • Независимые расширения
  • Применение шаблона MVVM
  • Независимое тестирование (?)

Prism позволяет строить приложения с использованием компонентного подхода — из независимых единиц (модулей). Модули не ссылаются друг на друга. Prism использует подход Dependency Injection для инстанциирования модулей (и применят MS-овский IoC-контейнер Unity). Далее было интересно: докладчик порекомендовал начинать разработку приложения с UI (???), рассказал немного про связывание UI с модулями и конфигурацию контейнера Unity. Затем продемонстрировал приложение Asteros Contact, на примере которого рассказал о реализации Master-Details формы с использованием View Injection (честно говоря, не впечатлило). И, наконец, указал главный, по его мнению, недостаток MVVM — «всё взаимодействие идёт через ViewModel, на которую ложиться слишком много ответственности».

В общем, за исключением некоторых базовых вещей о MVVM и Prism — доклад ни о чём.

Техника и проблемы пэкеджинга бизнес-приложений для Windows

Доклад об организации процесса разработки и выпуска готовых к развёртыванию пакетов программ.

Не зацепило. Были какие-то рекомендации, вроде:

  • планировать развёртывание вместе с проектированием приложения
  • не откладывать создание пакета на последний день
  • тестировать развёртывание

и т. п. В конце доклада продемонстрировал утилиту собственной разработки (на базе Excel 2010), позволяющую просматривать содержимое msi-пакета.

Первый опыт внедрения WPF в сложной системе (С++ и COM)

Докладчик — Михаил Павлов.

Цель доклада — рассказать о проблемах на этапе внедрения WPF и сформулировать рекомендации по повышению эффективности разработки.

В начале своего рассказа, автор немного рассказал о проекте, которым занимался. Приложение — тренажёр рубки корабля, было написано на C++/COM/MFC/ATL/WTL/OpenGL. На слайде была обозначена какая-то плюшевая структура, судя по которой и по перечню используемых технологий, приложение чуть менее чем на 100 % состояло из сказочного кода.

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

  • Устаревший дизайн (в смысле внешний вид приложения)
  • Низкая скорость разработки UI
  • Ограничения в расширяемости

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

Попробовали, и, почему то решили делать визуалку на WinForms + WPF. Объяснение такое: на WPF сложно и долго делать простые окошки (?), на WinForms наоборот — почти нереально сделать сложные кастомные интерфейсы. Плюс к этому, выяснилось, что Expression Blend, который пытались применять, генерирует на выходе XAML, который содержал много лишнего(?). Ну и хотелось использовать имеющиеся нативные наработки в областе интерфейса (решили на WPF формы кидать WinFormsHost, а в нем через Interop использовать нативный контрол). Конечно, не видя приложения трудно делать какие-то выводы, но подобная архитектура как минимум настораживает. В результате, после первой попытки огребли проблем. Тогда решили следовать православным рекомендациям MS. В результате, скорость разработки упала в 3 раза. После этого были предприняли следующие шаги:

  • Ограничили изменения в интерфейсе
  • Выработали баланс обязанностей дизайнера и программиста
  • Сформулировали пожелания заказчика

Проблемы перевода:

  • Наследие прошлого
  • Правильная интерпретация 3D-визуализации на WPF интерфейсе
  • Недостатки WPF

Ну и в конце докладчик посоветовал с самого начала разработки сформировать библиотеку WPF стилей. Хотел задать автору вопросы о том, чем ему не угодил Expression Blend и какие недостатки в WPF он обнаружил, но, поскольку доклад затянулся, а я не хотел опоздать на следующий, пришлось убежать раньше времени. Жалею, что в презентации отсутствовали эпические скриншоты нового WPF интерфейса, очень хотелось на них посмотреть.

Nemerle Deep Dive

Докладчик — ведущий программист проекта Nemerle Владислав Чистяков.

Доклад длился 3 часа, но, по-моему, почти всё, что было прочитано и показано на 2х последних докладах — специфика разработки, интересная тем, кто уже программирует на Nemerle. По словам докладчика, Nemerle — гибридный язык, отчасти императивный, отчасти функциональный, отчасти метаязык, расширяемый с помощью макросов. Создан как язык, на который несложно перейти программистам, разрабатывающим приложения на C#.

Ядро языка

Типы: C# и ML.

Выражения: ML

Операторы: C (C#)

Макросы: LISP

Поддерживается indent-стиль кодирования.

Макросы языка служат для:

  • Создания встроенного DSL
  • Расширения языка
  • Автоматизации программирования
  • Контроля за кодом

Существующие макро-библиотеки:

  • Computation Expressions
    • Yield
    • Асинхронное программирование
  • Xml-литералы (Nemerle.Xml)
  • Nemerle.Peg — быстрый парсер
  • Nemerle.Web.Reactive — расширения для создания web-приложений (c поддержкой MVVM)
  • Nemerle.Rails

Расширения:

  • Автоматическая реализация Dependency Properties в WPF
  • Record — автоматическое создание конструкторов
  • Автоматизация паттернов проектирования ООП (abstract factory, aggregate, proxy, singleton)
  • Позднее связывание (?)
  • Surround with
  • Lisp comprehensions
  • Regexp math

Во второй части автор рассказал про тип variant — аналог union в C. Основную часть оставшегося времени подробно рассказал про pattern matching — технологию, которая позволяет, если я правильно понял, реализовать двойную диспетчеризацию. Язык интересный, но неясны перспективы развития (поддерживается де-факто сообществом, но что будет завтра — непонятно). Вероятно, поэтому ничего не слышно про применение Nemerle в коммерческих проектах. По словам автора, язык будет развиваться. Посмотрим.

Nemerle.Peg — .NET генератор парсеров шаговой доступности

Доклад начался долгим рассказом про то, как докладчик делал какой-то опрос на хабре. Затем, ближе к теме, рассказал немного о парсерах, упомянул ANTLR — основной конкурент Nemerle.Peg (Peg — Parser Expression Grammar). Привёл для сравнения, статистику по количеству строк кода, необходимых для реализации парсера на ANTLR и Nemerle.Peg, по которой получилось, что последний в 4 раза лаконичнее. Дальше начался livecoding, от простых примеров написания парсера с использованием Nemerle.Peg до парсера JSON. Поскольку про Nemerle я знаю только то, что рассказал Чистяков на предыдущих докладах, понял только, что Nemerle.Peg действительно позволяет написать лаконичный и эффективный парсер.


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

Источник — «http://lib.custis.ru/index.php?title=ADD_2011:_Отчёт_Русецкого_Георгия&oldid=25923»