Анализ доклада Баруха Садогурского с JPoint 2015

Созрел ещё один разбор, в этот раз смотрим доклад Баруха jbaruch Садогурского «Как писать асинхронные многопоточные http-приложения» с JPoint 2015:

Слайды тут.

Про Java только разбираемый доклад, а не сама статья.

Сюжет

Тема

Рассказ Баруха посвящён тому, как в компании JFrog сделали качальщик файлов на Java, причём именно технической, а не организационной стороне процесса. Вероятно, по дороге разработчики узнали что-то неожиданное и хотят этим поделиться.

Это очень благодарная тема, и причин тому несколько:

1. Можно придерживаться хронологии: откуда взялась задача, как выбирали подход, что пробовали, что получалось, какие ошибки делали. Если рассказ — не ретроспектива проекта, часто головы сломаешь, пытаясь расставить его компоненты в правильном порядке.
2. Точно есть практическая польза, если её специально не прятать.
3. Легко найти поводы для самоиронии, потому что, конечно же, даже тривиальные вещи не все получились с первой попытки.

Выводы и польза

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

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

Само упоминание и сравнение свойств двух библиотек — NING и Apache HTTP components asyncclient) — может сэкономить людям время на изучение (слайды 34-49, фрагмент с 14:30 до 21:30).

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

История с длиной файла (фрагмент с 23:10 до 24:56) потенциально интересна. Мы теперь знаем, что по стандарту http/2 даже для сжатого файла надо указывать оригинальную длину. Мы знаем, что для реализации нарезки файла по чанкам это составляет проблему. Чего мы не знаем, так это как же данную проблему решили в компании JFrog, а ведь логично было бы рассказать.

На контрасте: история с редиректом на CDN (фрагмент с 24:57 до 26:26) и началом закачки с нуля освещена полностью, вплоть до решения. Всегда нелишне напомнить, что хедеры при редиректе теряются, если с этим ничего не делать целенаправленно. Я бы и все остальные кусочки в таком же духе рассказывал, будь моя воля.

Разговор о количестве коннекций в http/1.1 и http/2 озадачил: какие из этого знания практические выводы вообще и в контексте нашей задачи? Протокол http1.1 просит не открывать больше двух, все браузеры эту рекомендацию нарушают и открывают, если я тоже буду нарушать и открывать, чем мне это грозит?

Далее есть ещё грабли, по которым, очевидно, разработчики прошлись, не буду на каждом пункте останавливаться подробно, но отмечу, что проблемные ситуации изложены по-разному. Не всегда понятно, что будет, если делать «как сразу приходит в голову», и не всегда понятно, как решили проблему, и решили ли вообще, в проекте, о котором Барух говорит. Мне кажется, это упущение: грабли и способы их избежать — главное, что зрители должны унести домой с такого доклада.

В общем, польза в рассказе есть, но можно было бы подать её ещё более ясно.

Порядок изложения

Замечу, что здесь во многих местах можно применить детективный порядок изложения, и рассказ бы лучше запомнился. Приведу только один пример, чтобы не раздувать пост. Я как наивный зритель предполагаю, что в какой-то момент код был написан в духе слайда 67:

И на простых тестах оно, видимо, даже какое-то время работало, а потом сломалось. Если оно сломалось как-то красиво, то можно об этом рассказать, от симптомов перейти к расследованию и уже затем к слайду вида «у меня вопрос». Дело в том, что «починили проблему, запустили, упало в другом месте» — естественный процесс для разработчика, зрителям не придётся тратить силы, чтобы понять, как новый вопрос связан с предыдущими. И ещё полезно их хотя бы чуть-чуть заставить подумать, почему всё сломалось, прежде чем выдавать решение: так лучше запоминается.

Слайды

Текстовые слайды

Хочу обратить внимание на то, что разные классы слайдов в презентации оформлены по-разному. Идейно неплохо, когда «официальные» утверждения отличаются от всего остального текста. Это можно наблюдать на слайдах 8, 13, 16, 18 и т.д.:

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

Лирическое отступление, не относящееся к разбираемому выступлению: разное оформление текста в зависимости от роли слайда (здесь требования, здесь результаты, здесь проблемы и т.п.) можно особенно порекомендовать в случае, если все слайды состоят только из текста. Мой опыт подготовки докладчиков говорит, что от внешне одинаковых слайдов зрители всё-таки устают, и часто такие доклады получают низкие оценки даже при объективно интересном содержании. Возможно, будет чуть легче, если дать людям хотя бы суррогат разнообразия.

Шрифты

К сожалению, в выложенный .pdf не включился шрифт, поэтому там эти выделенные слайды выглядят хуже. Я часто вижу накладки, связанные с потерей кастомного шрифта. Неприятная вещь, которая часто случается, — буквы перестают влезать в отведённое место, и весь красиво отформатированный слайд едет. Поэтому потрачу ещё пару абзацев текста на вроде бы капитанские рекомендации.

1. Если вы используете нестандартный шрифт, то вам надо либо выступать со своего компьютера, либо распространять презентацию вместе со шрифтами, либо делать .pdf. В данном случае это не помогло, вывод: созданный .pdf перед распространением полезно проверить.
2. Если вы готовите слайды на корпоративном компьютере, то там могут быть предустановлены и включены по умолчанию шрифты из корпоративного брендбука, и вы можете вообще не догадываться, что они какие-то нестандартные. А потом всё сломается из-за того, что в другом месте их нет.

Картинки

Я верю, что на слайдах должно быть как можно меньше элементов. Полезное упражнение: смотреть на каждый слайд и думать, что на нём можно выбросить без потери смысла. Даже не так: сначала смотреть, нельзя ли выбросить весь слайд целиком, и если всё-таки нельзя, то дальше уже его минимизировать. Так вот, поля вокруг картинки — тоже элемент слайда, притом почти всегда лишний. Если у вас на слайде по сути только картинка (заголовок или одна короткая фраза сути не меняют), нет ни одной причины, по которой она не должна занимать весь экран.

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

Картинку во весь экран придётся искать в высоком разрешении, первая попавшаяся не подойдёт, но реальную трудность тут составляют только фото Уилера. В разбираемом же докладе очень на многих картинках, даже маленьких, видны пиксели. Это усиливает ощущение небрежности.

Евангелисту, для которого выступления — хлеб, возможно, стоит выбить из работодателя подписку на платный сток. Многие предупреждают, и по делу, что нельзя брать стоковые фотографии на темы «офис», «сотрудничество», «разозлённый пользователь перед компьютером», «работник колл-центра» и им подобные, поскольку они одинаковые и всем уже надоели. Но незаезженных атомных электростанций и медведей с поднятыми лапами там ещё много, а когда медведи кончатся, останутся панды. Человеку, который не выступает профессионально, вряд ли захочется тратить сто-двести долларов на оформление одной презентации, значит, придётся больше гуглить.

Есть ещё один аспект, добавляющий к ощущению того, что подготовка происходила второпях. Хорошо, когда у оформления слайдов во всей презентации есть какая-то общая тема, общая идея. Чем более узкая концепция, тем сложнее её увязать с рассказом: не всё так запросто выразишь, скажем, персонажами из «Звёздных войн». Но можно концепцию расширить, например, взять не только «Звёздные войны», а более широкий набор культовых фантастических фильмов, в эти ограничения уложиться проще. Но это в любом случае требует значительного времени на обдумывание. Однако изображения в выступлении Баруха пришли к нам из совсем разных миров:

Если приглядеться, то даже на указанных выше примерах можно также заметить, что часто проиллюстрирован не смысл того, что говорится, а только какое-то отдельное слово, встречающееся в речи. Яркие, смешные картинки люди, конечно, хорошо запоминают, но это не совсем то, что нам надо. Нам надо, чтобы они смысл запомнили.

Скриншоты

Вообще я противник скриншотов на слайдах. Когда-нибудь кто-нибудь подставится и предложит для разбора доклад с плохими скриншотами, тогда я всё подробно и объясню. Но здесь они использованы к месту и оформлены хорошо, например:

Если вам очень хочется добавить скриншоты, то берите пример с Баруха по трём пунктам:

1. Делайте скриншоты только с известных страниц: поисковики, stackoverflow, github и т.п. Ваше внутрикорпоративное приложение для мониторинга кластера всё равно никто не поймёт, да и некрасивое оно.
2. Перед тем, как делать скриншот, увеличьте картинку в браузере и показывайте только важную часть экрана. Это более правильно, чем растягивать сам скриншот, поскольку в браузере хотя бы текст не портится.
3. То, на что нужно смотреть, обведите рамкой.

Регулярные разборы

Если вы хотите получить обратную связь по своему выступлению, то я с радостью вам её предоставлю.

Автор: JUG.ru Group

Источник