К основному контенту

Конференция C++ Russia 2016

Благодаря подкасту DevZen сходил на конференцию C++ Russia 2016 в Питере. Стоимость участия была небольшой, даже если оплачивать ее самостоятельно, но были сомнения в том, что о C++ (да о любом языке программирования) можно общаться в формате конференции. И даже прошлогоднее участие в PiterPy#2 не избавило меня от мнения, что "языковые" конференции - это сложно.
Подарочный билет отмел последние сомнения (за эту халяву мне стыдно перед Серегой) и вот очередной отчет с конфы.

Сразу о моих прогнозах: я ошибался и это даже обидно за эту ошибку. Объясню почему :)

Я участвовал во многих конференциях, и как участник, и как докладчик. И все они проходят отлично, если участники не просто слушают, а активно задают вопросы, "прессуют" докладчиков в кулуарах, спорят и соглашаются, учат и учатся.
А разве можно представить C++-разработчика, который бы не любил ну хотя бы поспорить :) В общем, никаких разработчиков "замкнутых в себе" обнаружено не было, и общения хватало.

Доклады были на разные темы, и хардкорчик, и достаточно простые. Все 3 потока были интересными и пару раз пришлось выбирать куда пойти. Надеюсь на видео. Update: и они уже доступны.

Первый день стартовал непростым 2-х часовым докладом Гора Нишанова, который голосом Сталика Ханкишеева рассказывал про C++ coroutines. Я люблю смотреть уроки Сталика по приготовлению всяких вкусностей на мангале, но теперь у меня шашлык будет ассоциироваться с корутинами, и наоборот )))
В общем под это самое слюноотделение корутины зашли, как по маслу. Суперский доклад и отличное мастерство докладчика. Видео (как появится) крайне рекомендовано к просмотру. Тем кому не терпится можно глянуть выступление Гора на CppCon2015. (Небольшое отступление: есть критика такого подхода к реализации корутин)
Еще Гор рассказал про то, как комитет по стандартизации принимает свои решения:
Аналогичная участь постигла interuption-ы в boost:thread при переносе его в стандарт. Я немного отвлек Гора от подготовки к докладу и помучал вопросами. Выяснилось, что MS планирует добавить в компилятор режим работы для указания стандарта, чтобы наконец отвязать старые фичи от новых и расширить поддержку стандартов. А своеобразный порядок реализации стандартов обусловлен как раз тем, как сейчас работает компилятор и необходимость поддерживать код написанный еще на C++98. Вроде как отдельная команда пишет новую версию компилятора, параллельно с текущей разработкой. 

Вообще здорово, когда на конфу приезжают такие докладчики. Я видел Гора на других докладах, в кулуарах он постоянно был окружен и даже на обеде его не оставляли в покое :)

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

Доклад Дмитрия Демчука про Google breakpad - про обработку крэшей. Докладчик в свое время написал свою библиотеку с подобной функциональностью, но вот нашел breakpad. Из плюсов: кроссплатформенность позволяющая на винде, linux и маке получать один формат дампов (в виде MS *.dmp), что можно использовать для автоматического анализа креш-дампов, поступающих с разных систем, например Soccoro. Мы в свое время много игрались с обработкой "падений", текущий вариант у нас работает, но мне не очень нравится. Надо будет на breakpad глянуть.

Следующий доклад Антона Наумовича был хорошим продолжением доклада про обработку крешей. Антон рассказал про то, как они автоматически обрабатывают возникающие дампы, ну и то, как они эти самые дампы генерят. Новое для себя: утилита ProcDump, которую можно настроить на автогенерацию дампа интересующего процесса по разным условиям (память, хендлы и тп), утилита cdb.exe, которая, несмотря на свою древность, удобно подходит для автоматического анализа дампа. Ребята сделали сервис, в который автоматом заливаются дампы из продакшена (в т.ч. заказчиков), дампы там анализируются и можно посмотреть место проблемы и статистику по похожим падениям. Дамп в анализатор можно залить и руками, и этим пользуется служба тех.поддержки, которая по результатам анализа может оценить проблему и, если повезет, найти фикс, если что то подобное уже случалось и фиксилось. Видимо получился аналог Soccoro.
Немного полезных ссылок по темам этих 2-х докладов:

На доклад Ильи Шишкова про создание тестируемого кода я пошел, потому что тема близка. Правда потом, первую половину доклада, я жалел о содеянном, но ближе к концу Илья исправился. В общем тем, кому тема интересна и хочется узнать о том, как можно применить закон Деметры к написанию тестов - велком. Но я так и не понял, зачем они написали свой тестовый фреймворк.
Дальше вещал Антон Семенченко про сравнительный анализ mock-фреймворков для C++. Итоговый отчет (в виде презентации) он обещал выложить на ресурсе С++ разработчиков Беларуси CoreHard.by
Но пока можно сказать, что чуда не случилось и победил Google Mock Framework.
Антон хороший рассказчик, но доклад получился несколько поверхностным. Зато были веселые истории про написание тестов ради тестов, которые они нагенирили автоматически по требованию заказчика на код, который работает уже десятилетие и не планировался даже изменятся, или история про то, как программисты благодаря тестам написали код без багов ;) (Гусары, молчать. Я сам еле сдерживался)

Мои пять копеек по теме тестирования в С++ и не только: "Разрабатываем без нянек" (с) или как минимизировать участие тестировщиков в вашей работе".

Второй день.
"Reactive programming in C++" Kirk Shoop. Я остро осознал, что а) моего английского недостаточно, б) шашлычная ассоциация с корутинами не повторится, в) надо пересматривать видео. Гор в кулуарах обмолвился, что на коротких примерах rxcpp смотрится хорошо, но в "продакшене" его никто не видел. Но ходят слухи, что его использует Netflix.

Алексей Кутумов "Вектор с нуля" или "осознай, что ты херово знаешь C++" :) Интересный (но близкий к харду) доклад, про то, как написать собственный vector.

Борис Сазонов "RAII потоки и CancellationToken в C++" про то, как правильно прерывать выполнение потока. Надо еще раз пересмотреть и попробовать библиотеку на винде. Мне понравилось.

Вот пожалуй и все. Мозг заряжен.  Душа отдохнула от менеджерского безобразия. Люди хотящие знаний в природе существуют :)
Завидуйте все, кто не был и ждите видео. А на следующий год надо планировать.

Отдельный пункт с благодарностями Сергею Платонову. Благодаря этому человеку у нас появилась эта конфа и она живет. Ты - молодец.
Что можно поправить: добавить контакты докладчиков в программе и помочь докладчикам в контроле за временем.

Немного фоток
Гора прижали к колоне и не отпускали даже кофе попить
Армия матрешек :)
Поредевшая армия и "автоматизация" от разработчиков :) (c)
Кстати, накануне конференции Яндекс организовал встречу с членами комитета по стандартизации. 3 города, 3 мега-специалиста, хорошие вопросы, интересные ответы. Запись должна быть здесь.
В питерском офисе Яндекса

В твиттере участники общались по хештегу #cpprussia, нечасто, но можно  найти интересные твиты.

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.