Аналіз доповіді Сергія Куксенко з JPoint 2016

Сьогодні відкриваємо нову рубрику: розбір технічних виступів. Якщо взяти в цілому вдалий доповідь з IT-конференції та формалізувати в ньому ті моменти, завдяки яким він хороший, то можна багато чому навчитися в плані виступів. А якщо в тій же доповіді формалізувати ще й моменти, які можна поліпшити, то користь буде подвійна. Тим, хто збирається виступати на конференціях, це стане в нагоді. Та й тим, хто давно і успішно там виступає, це теж не зашкодить.

Сьогодні вашій увазі пропонується доповідь Сергія Walrus Куксенко на JPoint 2016: «Quantum Performance Effects II: Beyond the Core».


Слайди тут

Дисклеймер: про Java тільки сам доповідь, якщо ви його ще не бачили. Стаття під катом   про доповідь.

Сюжет
Від складу і якості сюжетних елементів у доповіді залежить дуже багато, тому з них і почнемо.

Детективний порядок
Дуже швидко (слайди 5-9, час 02:00-05:00) Сергій застосовує прийом, який можна вважати візитною карткою (є ще один чоловік, який застосовує його так само віртуозно, це Олексій Шипилев). Я називаю цей прийом «детективний порядок викладу» і всім рекомендую до вивчення і застосування. Хороший, годний порядок виглядає так:

  1. Спостерігаємо дивні симптоми у програмі (скоєно вбивство).
  2. Намагаємося щось підкрутити і подивитися, що зміниться (поліція збирає докази).
  3. Начебто знайшли правдоподібне пояснення (підозрюємо герцогиню).
  4. Знаходиться новий тест, що руйнує нашу гіпотезу (у герцогині алібі).
  5. Нарешті, прояснюється дійсна причина проблеми (вбивця   дворецький).
Очевидно, що така побудова сюжету, якщо сильно не затягувати, захоплює увагу аудиторії, слухати цікаво, можна пробувати себе у ролі детектива, і взагалі хочеться дізнатися, чим же все закінчиться. «Пограти в детектива» — дуже важливий аспект, тому що ми залучаємо аудиторію і провокуємо її думати, причому думати саме на тему нашої розповіді. Сергій це добре розуміє і регулярно демонструє.

Зворотний порядок, коли ми спочатку даємо теоретичне обґрунтування проблеми, а потім наводимо приклад її маніфестації, в більшості випадків виходить нудніше і менше залучає глядачів. Звичайно, і в цьому жанрі є відносно успішні твори (хто-небудь пам'ятає лейтенанта Коломбо?..), але при інших рівних «детективний порядок» краще утримує увагу. Тільки не треба обманюватися, легкість тут   удавана. Код, ілюструє поки що невирішену проблему, потрібно писати набагато ретельніше, ніж код, в якому зустрічається проблема вже відома. Дозувати хінти, не видаючи раніше часу головну таємницю, важко. При підготовці конференцій я часто пропонував доповідачам переробити розповідь саме в такому порядку, але з першої спроби з цим мало хто справляється. Так що за простим детективним викладенням ховається значна робота.

Зазначимо, що майже всі приклади в доповіді побудовані за тим же принципом.

Проблематизація
Але підемо далі. Після пари привертають увагу прикладів, все ще десь на початку доповіді, я очікував побачити розповідь про те, що проблеми навколо кешу процесора в житті пересічної людини зустрічаються частіше, ніж можна подумати (наприклад, ...), і тому про них знати повинен кожен, хто не хоче рано чи пізно серйозно від них постраждати. Підозрюю, що такої розповіді не було, тому що середньостатистичний програміст Java (це, нагадаю, JPoint) зустрічається з проблемами кешу процесора значно рідше одного разу в житті. Зазвичай розуміння того, що «це з кожним може статися» дає ще трохи уваги глядачів. У Сергія практичні відсилання вперше зустрічаються в секції «Demo 6», починаючи з 33:20, слайд 43, але до того часу доповідь вже досить міцно сприймається як науково-популярна екзотика.

Є багато (що часто суперечать один одному) цитат на тему того, на скільки рівнів абстракції вниз від поточного повинен вільно проникати розум програміста. Можливо, варто звернутися до авторитету когось із великих. У будь-якому разі, хоч якусь відповідь на питання гіпотетичного глядача «чому це може бути важливо особисто для мене» варто мати близько до початку кожної доповіді, а тут такої відповіді немає.

Висновки
Кінцівка цілком ударний. Є і список конкретних проблем, які глядач повинен знати, і світоглядний посил: вивчайте весь ландшафт, не робіть висновків з результатів вимірювань, поки точно не розібралися, чому вони такі. Тут, як мені здається, все добре.

Слайди
Коментарі з оформлення слайдів в основному стосуються витрати батарейки. Уявімо, що у кожного глядача в голові є батарейка, яка сідає в міру того, як він думає. Він може бути згоден або не згоден з нашою ідеєю, він може думати про те, як її спростувати, про те, як застосувати у своїй роботі, про те, як перекаже її колегам, про те, які ще питання, пов'язані з темою, він хоче поставити, піймавши доповідача у кулуарах,  — все це корисні думки, і на них батарейку не шкода. Але ніколи, ні за яких обставин ми не хочемо, щоб глядач намагався зрозуміти, в чому ж наша ідея полягає. «Що тут написано? Про який рядку таблиці він зараз говорить? Що-що він мав на увазі?»,   непродуктивні витрати. Матеріал у Сергія не найпростіший для зображення, тому кілька місць, які можна поліпшити, повинні були знайтися. Ну і знайшлися, звичайно. А сбереженного заряду глядачам як раз вистачить, щоб краще зрозуміти, як влаштовані кеш-лінії.

Код
Але насамперед хочу похвалити фрагменти коду, які зустрічаються в доповіді. Код адже, як відомо, тільки писати просто, а читати   складно. Тому під фрагменти коду, які ми демонструємо, треба вкладати дуже багато праці: вони повинні бути прості і мінімалістичні. В даному випадку вони саме такі, і вкладений працю окупається.

Окремо хочу зазначити, що код правильно демонструвати саме на білому фоні:



Звичайно, багато програмують vim іншій кольоровій гамі, з чорним фоном. На слайдах її не варто відтворювати: сірий, червоний і темно-синій на чорному запросто може бути зовсім не видно на проекторі. Дивно, як багато опору я зустрічаю, коли говорю про це доповідачам, з якими працюю. У хід йдуть аргументи від «я у нас вже показував ці слайди, все було видно» до «організатори повинні надати нормальне обладнання». На мій погляд, це те ж саме, що писати код, не обробляє ніякі помилки, під приводами типу «просто нехай вони мені в сервіс валідні дані передають» або «так воно на тестинге тиждень нормально крутилося».

Указка
Код у Сергія простий, і навігація по ньому не потрібно. А ось там, де навігація потрібно, в хід йде лазерна указка. В моїй картині світу, якщо ви скористалися нею один раз за доповідь, це вже на один раз більше, ніж треба. Дуже помітно при цьому страждають ті, хто дивиться відеозапис, як ми з вами. Подивіться уривок з 50:24 по 50:35. Проблема не в цьому записі і в цьому читанні, а ось у цьому записі і ось в цьому читанні. Все зрозуміло, ага.

Звичайно, працювати треба для людей, які прийшли в зал, вони важливіші, ніж ті, хто буде дивитися запис. Але багатьом з тих, хто бачив доповідь наживо, теж не пощастило. Ось як виглядає зал, в якому все відбувалося. Я обвів людей, у яких навряд чи був шанс побачити указку (доповідач застосовував указку тільки на екрані ліворуч від себе):



При цьому конфігурація з двома дублюючими екранами — не екзотика, вона буває на конференціях дуже часто.

А ось приклад екзотикиЕкзотика — це, наприклад, зал «Сінгапур» бізнес-школи " Сколково, де в цьому році проходили РІТ++ і Highload++. Там взагалі нікуди бластером не потрапиш, круглий зал, доповідач дивиться в торець спарених екранів:




Я прихильник того, щоб раз і назавжди заліпити на кликере лазерну указку пластиліном і жити так, як ніби її ніколи не було, а підсвічування робити з допомогою рамок, стрілок, послідовного появи елементів на схемах або зміни кольору. На слайді 64, скажімо, є стрілочки, і вони нормально виконують свою функцію:



Таблиці і діаграми
Але на слайді 64, як і на кількох інших, є таблиці. Так зручніше для аналітики (можна сортувати, робити підвибірки тощо), але гірше для демонстрації. Треба ж, щоб відразу було видно, що ми хочемо показати. Стовпчики різної довжини набагато простіше порівнювати, ніж числа, більш того, вони відразу показують співвідношення (щоб не треба було ділити в голові, у скільки разів 86 більше, ніж 35). Вважаю, таблиці в багатьох випадках можна перемалювати у вигляді діаграм, від цього стане легше розшифровувати. Порівняйте два варіанти слайда 46:

Оригінальний:



Перероблений:



Зрозуміло, діаграму можна розбити на два слайди і спочатку показати сині смужки, а потім додати до них помаранчеві, як це зроблено з таблицею в оригінальній презентації.

Якщо говорити про діаграмах, то варто змінити графік зі слайда 26:



На відео він виникає на 13:41. Подивіться приблизно хвилину з цього місця: мені здається, потрібно деяке зусилля, щоб зрозуміти, де на графіку хороший випадок, а де поганий, так як на слайді багато даних і важка для сприйняття легенда. Розібратися, звичайно, можна, але набагато простіше було б це робити, якби графіки з'являлися не всі відразу, а по черзі, і кожний з них доповідач міг би пояснювати і коментувати окремо в момент показу.

Лінії краще підписати прямо на графіку і позбутися від легенди зовсім. Про те, що легенди   зло, я вже писав ось тут, але не втомлюся повторювати.

Кольору
Цікава з точки зору сприйняття точкова діаграма на слайді 65, яка з'являється на відео на 52:53. Ось вона:


Що з цією картинкою не так? Кольори на ній відсортовані в порядку веселки, від червоного, який символізує хороший випадок (швидке копіювання), до фіолетового, який відповідає поганого. Однак, сортування «по веселці» відбувається лише на свідомому рівні, тому для того, щоб розібратися, який колір краще, жовтий або, наприклад, блакитний, доводиться або бігати за легендою очима, або згадувати історію про мисливця і фазана. Це все не дуже складно, але можна зробити простіше.

В голові кольору не відсортовані автоматично, якщо тільки це не співвідношення світліше-темніше. Вирішивши нескладну задачу соціальної інженерії, я отримав ісходник діаграми і став перемальовувати її одним кольором. Кількість відтінків довелося скоротити до п'яти (можна і до чотирьох, 50+ навряд чи заслуговує окремого кольору), але в підсумку вийшов варіант, який здається мені більш наочним (світле   добре, темне   погано):



Звичайно, перед демонстрацією варто протестувати, чи буде це видно на проекторі.

Регулярні розбори
Якщо ви хочете отримати зворотний зв'язок щодо свого виступу, то я з радістю вам її дарую.

Що для цього потрібно зробити?
  1. Відео виступу, доступне на youtube, vimeo і т. п.
  2. Слайди.

  3. Заявка від автора. Без згоди самого виступаючого нічого розбирати не будемо.
Все те треба відправити хабраюзеру p0b0rchy, тобто мені. Зі свого боку обіцяю, що критика буде конструктивною і ввічливою, а також фокус на особливо вдалих елементах, а не тільки на тих, які варто покращувати.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.