Шрифт Sans Forgetica
Тут учёные разработали специальный шрифт для того, чтобы люди лучше запоминали прочитанное. Применяли знания поведенческой психологии, ставили эксперименты. Получилось нечто очень необычное под названием Sans Forgetica.
Я не обладаю навыками дизайнера, чтобы грамотно раскритиковать шрифт, поэтому отправлю его специалистам. Сообщу вам, что получится.
Сайт шрифта: http://www.sansforgetica.rmit/
Статья на сайте RMIT University: https://www.rmit.edu.au/news/all-news/2018/oct/sans-forgetica-news-story
Статья на Хабре про шрифт: https://habr.com/post/425529/
Для примера — Agile Manifesto (http://agilemanifesto.org/) шрифтом Sans Forgetica:
Тут учёные разработали специальный шрифт для того, чтобы люди лучше запоминали прочитанное. Применяли знания поведенческой психологии, ставили эксперименты. Получилось нечто очень необычное под названием Sans Forgetica.
Я не обладаю навыками дизайнера, чтобы грамотно раскритиковать шрифт, поэтому отправлю его специалистам. Сообщу вам, что получится.
Сайт шрифта: http://www.sansforgetica.rmit/
Статья на сайте RMIT University: https://www.rmit.edu.au/news/all-news/2018/oct/sans-forgetica-news-story
Статья на Хабре про шрифт: https://habr.com/post/425529/
Для примера — Agile Manifesto (http://agilemanifesto.org/) шрифтом Sans Forgetica:
На вопрос о начальнике и новой структуре документации» дали несколько хороших ответов. С разрешения авторов публикую эти ответы.
Как «продать» начальнику новую структуру документации, ответ Андрея Гаврилова, системного аналитика в СМСФинанс:
Начальство всегда покупает варианты, в которых есть деньги. В идеале — посчитанные, но и простого понимания, что там есть деньги — может быть достаточно.
В работе с документацией деньги бывают от сэкономленного времени и от избежания ошибок. Соответственно нужно собрать статистику по типовым поисковым задачам, сколько времени на это тратится, и насколько это упростится новой структурой.
Аналогично можно собрать статистику по тому, как часто сотрудникам не удаётся найти информацию, которая реально в документации есть, и, опять же, прикинуть, насколько новая структура улучшит ситуацию.
Начальство всегда покупает варианты, в которых есть деньги. В идеале — посчитанные, но и простого понимания, что там есть деньги — может быть достаточно.
В работе с документацией деньги бывают от сэкономленного времени и от избежания ошибок. Соответственно нужно собрать статистику по типовым поисковым задачам, сколько времени на это тратится, и насколько это упростится новой структурой.
Аналогично можно собрать статистику по тому, как часто сотрудникам не удаётся найти информацию, которая реально в документации есть, и, опять же, прикинуть, насколько новая структура улучшит ситуацию.
Как «продать» начальнику новую структуру документации, ответ Максима Лапшина (CTO в Flussonic):
Я думаю, что лучше всего, когда есть какие-то метрики. Например, среднее время пребывания клиента в разделе документации или метрики удовлетворенности клиентов, когда поддержка кидает им ссылку на документацию. Или поиск суппортерами документации и т.п.
Bот если есть метрики, дальше гораздо проще говорить об измеряемых изменениях.
Я думаю, что лучше всего, когда есть какие-то метрики. Например, среднее время пребывания клиента в разделе документации или метрики удовлетворенности клиентов, когда поддержка кидает им ссылку на документацию. Или поиск суппортерами документации и т.п.
Bот если есть метрики, дальше гораздо проще говорить об измеряемых изменениях.
Как «продать» начальнику новую структуру документации, ответ Сергея Лысцева (VP Development в Plesk):
«Продать» это всегда про объяснить выгоду клиенту на его собственном языке. Иногда это деньги, иногда это метрики, но совсем не обязательно ими ограничиваться.
Из текста мы видим, что решение уже ищется, причем ищется самим начальством, то есть продавать саму необходимость решения уже не надо. Надо продать только именно свое решение (против всех остальных). Это скорее всего отсекает деньги и метрики как аргументы — ни то, ни другое не получится уверенно сравнить между разными вариантами решений.
Что остается? Для начальника всегда работает аргумент избавиться от проблемы для него самого — то есть предложить самой заняться вопросом и решить его своим способом. Изложить предлагаемый способ понадобится только для того, чтобы продемонстрировать cdj. компетентность и внушить начальнику уверенность, что у тебя получится. Хотя самого решения будет мало — будет влиять как тебя сейчас видят в организации, доверяют ли и т.п. Никогда не будет лишним заручиться поддержкой коллег. Если кто-то еще считает ваш план хорошим, весы будут легче склоняться в вашу сторону.
Упростите начальнику принятие правильного решения снятием возможных сомнений — подумайте заранее, что его может удержать и отработайте каждый пункт. Если вопрос для вас очень важен, проиграйте разговор с товарищем — пусть он принципиально сомневается во всем. Вам надо собрать все возможные свои слабые места и что-то с ними делать.
Есть тонкий момент с эго начальника. Если оно великовато, то начальник может возбудиться, что делаться будут не его идеи, а какие-то другие. И тогда найдутся причины почему нет. Тогда надо аккуратно продать начальнику, что это все его собственные идеи. Или подписаться внедрить его идеи, протащить за ними следом свои собственные и затем всем (и самому начальнику) рассказать, что это были идеи начальника. 🙂
«Продать» это всегда про объяснить выгоду клиенту на его собственном языке. Иногда это деньги, иногда это метрики, но совсем не обязательно ими ограничиваться.
Из текста мы видим, что решение уже ищется, причем ищется самим начальством, то есть продавать саму необходимость решения уже не надо. Надо продать только именно свое решение (против всех остальных). Это скорее всего отсекает деньги и метрики как аргументы — ни то, ни другое не получится уверенно сравнить между разными вариантами решений.
Что остается? Для начальника всегда работает аргумент избавиться от проблемы для него самого — то есть предложить самой заняться вопросом и решить его своим способом. Изложить предлагаемый способ понадобится только для того, чтобы продемонстрировать cdj. компетентность и внушить начальнику уверенность, что у тебя получится. Хотя самого решения будет мало — будет влиять как тебя сейчас видят в организации, доверяют ли и т.п. Никогда не будет лишним заручиться поддержкой коллег. Если кто-то еще считает ваш план хорошим, весы будут легче склоняться в вашу сторону.
Упростите начальнику принятие правильного решения снятием возможных сомнений — подумайте заранее, что его может удержать и отработайте каждый пункт. Если вопрос для вас очень важен, проиграйте разговор с товарищем — пусть он принципиально сомневается во всем. Вам надо собрать все возможные свои слабые места и что-то с ними делать.
Есть тонкий момент с эго начальника. Если оно великовато, то начальник может возбудиться, что делаться будут не его идеи, а какие-то другие. И тогда найдутся причины почему нет. Тогда надо аккуратно продать начальнику, что это все его собственные идеи. Или подписаться внедрить его идеи, протащить за ними следом свои собственные и затем всем (и самому начальнику) рассказать, что это были идеи начальника. 🙂
WTD Moscow #2: Антон Телин, видеоинструкции.
Наконец-то анонсируем доклады на предстоящем митапе Write the Docs в Москве 14 октября.
Лучше поздно, чем никогда.
Начнём с доклада Антона Телина про документацию в формате видеоинструкций.
Антон руководит отделом технической документации в компании, которая делает систему электронного документооборота. Видеоинструкции помогают обучать пользователей системы. Антон расскажет об опыте их создания, о проблемах и их решениях:
Признаемся себе, пользователи действительно не хотят читать наши инструкции. Как бы хорошо ни был написан текст, чтению клиенты предпочтут звонок в поддержку. Отличный способ рассказать обо всем — сделать инструкции в формате видео. Расскажем о том, как заставить видео работать на вас, о неизбежных проблемах в производстве и их решении.
Приходите послушать Антона уже в это воскресенье. Зарегистрируйтесь здесь: митап Write the Docs #2.
#writethedocs #writethedocs_moscow
Наконец-то анонсируем доклады на предстоящем митапе Write the Docs в Москве 14 октября.
Лучше поздно, чем никогда.
Начнём с доклада Антона Телина про документацию в формате видеоинструкций.
Антон руководит отделом технической документации в компании, которая делает систему электронного документооборота. Видеоинструкции помогают обучать пользователей системы. Антон расскажет об опыте их создания, о проблемах и их решениях:
Признаемся себе, пользователи действительно не хотят читать наши инструкции. Как бы хорошо ни был написан текст, чтению клиенты предпочтут звонок в поддержку. Отличный способ рассказать обо всем — сделать инструкции в формате видео. Расскажем о том, как заставить видео работать на вас, о неизбежных проблемах в производстве и их решении.
Приходите послушать Антона уже в это воскресенье. Зарегистрируйтесь здесь: митап Write the Docs #2.
#writethedocs #writethedocs_moscow
WTD Moscow #2: Константин Валеев, Foliant.
Продолжаем анонсировать доклады на митапе Write the Docs в Москве 14 октября.
Константин Валеев из компании Рестрим расскажет о Foliant — их собственной реализации docops workflow на основе языка Markdown. Год назад Константин уже рассказывал про Foliant, и с тех пор поменялось очень многое.
Расскажу про Foliant — наш Markdown-based инструмент для ведения документации, который мы написали (и выложили на гитхаб) потому что нам не подошёл ни один готовый. Расскажу почему и как мы стали собирать своё решение, а не взяли Sphinx или AsciiDoctor (скорее всего вам так делать не нужно); как мы его развивали и чему научили; как мы им пользуемся и как планируем развивать дальше.
Foliant на гитхабе: https://github.com/foliant-docs/foliant.
Митап будет в Москве, 14 октября, с 13:00. Зарегистрируйтесь здесь: митап Write the Docs #2.
#writethedocs #writethedocs_moscow
Продолжаем анонсировать доклады на митапе Write the Docs в Москве 14 октября.
Константин Валеев из компании Рестрим расскажет о Foliant — их собственной реализации docops workflow на основе языка Markdown. Год назад Константин уже рассказывал про Foliant, и с тех пор поменялось очень многое.
Расскажу про Foliant — наш Markdown-based инструмент для ведения документации, который мы написали (и выложили на гитхаб) потому что нам не подошёл ни один готовый. Расскажу почему и как мы стали собирать своё решение, а не взяли Sphinx или AsciiDoctor (скорее всего вам так делать не нужно); как мы его развивали и чему научили; как мы им пользуемся и как планируем развивать дальше.
Foliant на гитхабе: https://github.com/foliant-docs/foliant.
Митап будет в Москве, 14 октября, с 13:00. Зарегистрируйтесь здесь: митап Write the Docs #2.
#writethedocs #writethedocs_moscow
WTD Moscow #2: Никита Самохвалов, «Исчерпывающая документация на RESTful API».
Ещё один доклад на митапе Write the Docs в Москве 14 октября.
Никита Самохвалов из компании Нотамедиа расскажет о том, как документировать RESTful API с помощью Open API Specification.
Когда огрызки недодокументации на API вызывают негодование, а процесс написания оной доставляет немало хлопот, самое время подумать об автоматизации. В каком формате писать? Что писать? Как проверять? Приходите на митап, чтобы узнать, как изо дня в день инженеры «Нотамедии» решают подобные задачи.
Москва, 14 октября, начало в 13:00. Вы знаете, что делать.
#writethedocs #writethedocs_moscow
Ещё один доклад на митапе Write the Docs в Москве 14 октября.
Никита Самохвалов из компании Нотамедиа расскажет о том, как документировать RESTful API с помощью Open API Specification.
Когда огрызки недодокументации на API вызывают негодование, а процесс написания оной доставляет немало хлопот, самое время подумать об автоматизации. В каком формате писать? Что писать? Как проверять? Приходите на митап, чтобы узнать, как изо дня в день инженеры «Нотамедии» решают подобные задачи.
Москва, 14 октября, начало в 13:00. Вы знаете, что делать.
#writethedocs #writethedocs_moscow
WTD Moscow #2: Данила Медведев, НейроКод.
Ещё один доклад на митапе Write the Docs в Москве 14 октября. Наконец мы добрались до управления знаниями.
Данила Медведев расскажет про инструмент для моделирования и хранения знаний под названием «НейроКод». Я видел этот инструмент и немного пользовался — очень крутая штука, принципиально отличается от всех баз знаний, вики и заметок, которые я когда-либо видел. Деталей не расскажу, потому что NDA. Зато их расскажет Данила.
Вот небольшое введение в тему от автора:
Новое комплексное архитектурное решение для решения основной задачи ИТ. DKR, OHS, усиление интеллекта, фрактальность, spatial hypertext, ZUI, моделирование, бизнес- и ИТ-архитектура, управление знаниями, PIM/GIM.
Концепция документации была сформулирована в книге "Traité de documentation: le livre sur le livre, théorie et pratique" Пола Отлета, создателя прото-Интернета и сооснователя Лиги Наций. Затем область документации разошлась на два направления — электронного документооборота ("Toward Paperless Information Systems" Фредерика Ланкастера) и человеко-машинного симбиоза ("Man-Computer Symbiosis" Джозефа Ликлайдера и "Augmenting Human Intellect: A Conceptual Framework" Дугласа Энгельбарта).
Я расскажу про второе направление. Для организации информации Энгельбарт предложил архитектуру Open Hyperdocument System/Dynamic Knowledge Repository. Из существующих концепций именно она лучше всего описывает, что мы делаем, разрабатывая технологию НейроКод. Эта технология также базируется на принципе фрактальной организации сетей информации и концепции масштабируемого интерфейса.
С помощью этой технологии пользователи и организации могут решать задачи моделирования своих процессов и систем, проектирования бизнес- и ИТ-архитектуры, управления знаниями. Цель её применения — сокращение непроизводительных затрат на обеспечивающие процессы и усиление коллективного интеллекта организации.
Если вы мало что поняли и не знаете все эти аббревиатуры — дайте я вас обниму, я тоже не знаю. Приходите на митап, поймём и узнаем вместе.
Зарегистрируйтесь и напишите своё настоящее имя и фамилию — вход строго по записи, охрана строгая.
#writethedocs #writethedocs_moscow
Ещё один доклад на митапе Write the Docs в Москве 14 октября. Наконец мы добрались до управления знаниями.
Данила Медведев расскажет про инструмент для моделирования и хранения знаний под названием «НейроКод». Я видел этот инструмент и немного пользовался — очень крутая штука, принципиально отличается от всех баз знаний, вики и заметок, которые я когда-либо видел. Деталей не расскажу, потому что NDA. Зато их расскажет Данила.
Вот небольшое введение в тему от автора:
Новое комплексное архитектурное решение для решения основной задачи ИТ. DKR, OHS, усиление интеллекта, фрактальность, spatial hypertext, ZUI, моделирование, бизнес- и ИТ-архитектура, управление знаниями, PIM/GIM.
Концепция документации была сформулирована в книге "Traité de documentation: le livre sur le livre, théorie et pratique" Пола Отлета, создателя прото-Интернета и сооснователя Лиги Наций. Затем область документации разошлась на два направления — электронного документооборота ("Toward Paperless Information Systems" Фредерика Ланкастера) и человеко-машинного симбиоза ("Man-Computer Symbiosis" Джозефа Ликлайдера и "Augmenting Human Intellect: A Conceptual Framework" Дугласа Энгельбарта).
Я расскажу про второе направление. Для организации информации Энгельбарт предложил архитектуру Open Hyperdocument System/Dynamic Knowledge Repository. Из существующих концепций именно она лучше всего описывает, что мы делаем, разрабатывая технологию НейроКод. Эта технология также базируется на принципе фрактальной организации сетей информации и концепции масштабируемого интерфейса.
С помощью этой технологии пользователи и организации могут решать задачи моделирования своих процессов и систем, проектирования бизнес- и ИТ-архитектуры, управления знаниями. Цель её применения — сокращение непроизводительных затрат на обеспечивающие процессы и усиление коллективного интеллекта организации.
Если вы мало что поняли и не знаете все эти аббревиатуры — дайте я вас обниму, я тоже не знаю. Приходите на митап, поймём и узнаем вместе.
Зарегистрируйтесь и напишите своё настоящее имя и фамилию — вход строго по записи, охрана строгая.
#writethedocs #writethedocs_moscow
Пирамида рецензирования
В разработке документации есть этапы (слои) рецензирования. Это порядок проверки документа, он примерно такой:
— сам перечитал и проверил на грубые ошибки;
— отдал коллеге на проверку грамотности, структуры и стиля;
— отдал эксперту на проверку смысла и содержания.
Если на конкретном этапе есть замечания, документ возвращают доработку, а не передают дальше.
А в тестировании есть понятие «пирамида тестирования». Тесты выполняются в таком порядке:
— модульные тесты проверяют логику отдельных деталей;
— функциональные тесты проверяют то, как работают фичи продукта;
— интеграционные тесты проверяют то, как части большого продукта работают вместе.
Если на конкретном уровне продукт не проходит тесты, то тесты на более высоком уровне не имеют смысла; продукт возвращают на доработку.
Кажется, между рецензированием документа и тестированием продукта есть что-то общее.
В разработке документации есть этапы (слои) рецензирования. Это порядок проверки документа, он примерно такой:
— сам перечитал и проверил на грубые ошибки;
— отдал коллеге на проверку грамотности, структуры и стиля;
— отдал эксперту на проверку смысла и содержания.
Если на конкретном этапе есть замечания, документ возвращают доработку, а не передают дальше.
А в тестировании есть понятие «пирамида тестирования». Тесты выполняются в таком порядке:
— модульные тесты проверяют логику отдельных деталей;
— функциональные тесты проверяют то, как работают фичи продукта;
— интеграционные тесты проверяют то, как части большого продукта работают вместе.
Если на конкретном уровне продукт не проходит тесты, то тесты на более высоком уровне не имеют смысла; продукт возвращают на доработку.
Кажется, между рецензированием документа и тестированием продукта есть что-то общее.
Нашёл хороший канал про UX, а в нём рекомендации, как писать тексты в интерфейсе:
https://news.1rj.ru/str/uxnotes/186
https://news.1rj.ru/str/uxnotes/186
Telegram
UX Notes
Рекомендации авторам микротекста (теперь их называют UX-писателями 🙊):
— Сотрудничайте с дизайнерами, вместе прорабатывая структуры страниц и адаптируя дизайн под контент;
— Сотрудничайте с исследователями, чтобы говорить с пользователем на одном языке;
—…
— Сотрудничайте с дизайнерами, вместе прорабатывая структуры страниц и адаптируя дизайн под контент;
— Сотрудничайте с исследователями, чтобы говорить с пользователем на одном языке;
—…
WTD Moscow #2: Светлана Новикова, «Управление знаниями с помощью матрицы компетенций».
Продолжаем тему управления знаниями на митапе Write the Docs в Москве 14 октября.
Светлана Новикова работает в компании IPONWEB, в офисе которой мы с вами встретимся. Светлана расскажет про матрицу компетенций и как с ее помощью организовать управление знаниями в команде разработки:
Расскажу про саму технику матрицы компетенций, откуда она взялась, почему существует еще с 80х годов, и про то, как мы сделали матрицу 2.0. Мы использовали ее для «ориентации на местности», описав, какие явные и неявные знания есть в проекте, какие навыки нужны разработчику, а затем привязали к ней работу с артефактами знаний, включая, но не ограничиваясь документацией, например, knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое.
Митап уже послезавтра. Регистрация закроется сегодня в 17 по Москве. Успейте зарегистрироваться.
Если не успеваете — посмотрите трансляцию, она будет доступна для всех.
Продолжаем тему управления знаниями на митапе Write the Docs в Москве 14 октября.
Светлана Новикова работает в компании IPONWEB, в офисе которой мы с вами встретимся. Светлана расскажет про матрицу компетенций и как с ее помощью организовать управление знаниями в команде разработки:
Расскажу про саму технику матрицы компетенций, откуда она взялась, почему существует еще с 80х годов, и про то, как мы сделали матрицу 2.0. Мы использовали ее для «ориентации на местности», описав, какие явные и неявные знания есть в проекте, какие навыки нужны разработчику, а затем привязали к ней работу с артефактами знаний, включая, но не ограничиваясь документацией, например, knowledge sharing sessions, тренинги, обучения, тесты на понимание, чек-листы и другое.
Митап уже послезавтра. Регистрация закроется сегодня в 17 по Москве. Успейте зарегистрироваться.
Если не успеваете — посмотрите трансляцию, она будет доступна для всех.
Что проверить в документации для заказчика? Что вы не упоминаете других заказчиков!
Опытом делится Николай Поташников на secrus.org.
Слайды: https://quizzical-jang-f3e5a7.netlify.com/
Опытом делится Николай Поташников на secrus.org.
Слайды: https://quizzical-jang-f3e5a7.netlify.com/
WTD Moscow #2: Николай Волынкин, «Технический писатель 2.0.1».
Ещё один доклад на Write the Docs #2 в Москве 14 октября.
Николай — это я, автор канала @docops.
Поделюсь своими наблюдениями и мнением о том, какие задачи может выполнять технический писатель, чтобы принести больше пользы бизнесу; как эти задачи сформулировать и измерить успех. А ещё о том, куда движется профессия, что теряет ценность, а что наоборот, становится ценным.
Трансляция прямо сейчас: https://www.youtube.com/watch?v=p7G9VRkhjkA
Слайды: nick.volynkin.gitlab.io/techwriter20.
Версия 2.0.1 в названии — не случайность. Про «Техписателя 2.0» я рассказывал в субботу на конференции SECR. За день получил порцию обратной связи и немного обновил содержание. Надеюсь, что за следующий год обратной связи хватит на 3.0.
Обещаю, «Техписателя Х» не будет.
#writethedocs #writethedocs_moscow
Ещё один доклад на Write the Docs #2 в Москве 14 октября.
Николай — это я, автор канала @docops.
Поделюсь своими наблюдениями и мнением о том, какие задачи может выполнять технический писатель, чтобы принести больше пользы бизнесу; как эти задачи сформулировать и измерить успех. А ещё о том, куда движется профессия, что теряет ценность, а что наоборот, становится ценным.
Трансляция прямо сейчас: https://www.youtube.com/watch?v=p7G9VRkhjkA
Слайды: nick.volynkin.gitlab.io/techwriter20.
Версия 2.0.1 в названии — не случайность. Про «Техписателя 2.0» я рассказывал в субботу на конференции SECR. За день получил порцию обратной связи и немного обновил содержание. Надеюсь, что за следующий год обратной связи хватит на 3.0.
Обещаю, «Техписателя Х» не будет.
#writethedocs #writethedocs_moscow
Ретроспектива конференции
Сам хотел написать об этом, но меня опередили. Подробный пост о том, как мы в Plesk проводим ретроспективу конференции и в чём польза от этой практики:
https://news.1rj.ru/str/program_man/47
Сам хотел написать об этом, но меня опередили. Подробный пост о том, как мы в Plesk проводим ретроспективу конференции и в чём польза от этой практики:
https://news.1rj.ru/str/program_man/47
Telegram
Products | People | Process
Хотел бы поделиться одной довольно хорошо работающей у нас практикой.
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой…
Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой…
Обратная связь по митапу WTD Moscow #2.
Если вы были на митапе WTD Moscow #2 или смотрели трансляцию, пожалуйста, оставьте отзыв. Мы стараемся делать митапы чаще и лучше, так что ваша обратная связь нам сильно поможет.
Заполните форму, это займёт минут пять-десять: https://goo.gl/forms/d5ZInFDnwuNdhmtO2.
Если что, трансляция пока что доступна: https://www.youtube.com/watch?v=p7G9VRkhjkA. Через некоторое время вместо неё мы опубликуем отдельные видеозаписи докладов.
Если вы были на митапе WTD Moscow #2 или смотрели трансляцию, пожалуйста, оставьте отзыв. Мы стараемся делать митапы чаще и лучше, так что ваша обратная связь нам сильно поможет.
Заполните форму, это займёт минут пять-десять: https://goo.gl/forms/d5ZInFDnwuNdhmtO2.
Если что, трансляция пока что доступна: https://www.youtube.com/watch?v=p7G9VRkhjkA. Через некоторое время вместо неё мы опубликуем отдельные видеозаписи докладов.
Google Docs
Отзыв о митапе WTD Moscow #2, 14 октября 2018
Спасибо вам, что пришли на митап!
Пожалуйста, ответьте на несколько вопросов. Этим вы поможете нам сделать следующие митапы интереснее и полезнее.
Пожалуйста, ответьте на несколько вопросов. Этим вы поможете нам сделать следующие митапы интереснее и полезнее.
Привет, давайте знакомиться!
Я работаю техническим писателем в Plesk, внедряю практику «документация как код», пишу в этом канале про документацию и управление знаниями, организую митапы на те же темы. Посты в канале обсуждают в чате @docsascode.
Сегодня я смотрю Highload++, на ходу пишу и оформляю конспекты, и сразу их публикую на GitHub. Это эксперимент, он уже точно удачный, так что я и дальше буду так делать.
Если ваша документация болит и требует улучшения — давайте обсудим, пишите @nick_volynkin. Я сейчас не беру заказы на разработку документации, но посоветую вам хорошего аутсорсера.
Если вы хотите рассказать о том, как вы пишете и автоматизируете доки, внедряете управление знаниями, решаете другие задачи бизнеса с помощью технического текста — это очень круто, жду вас на митапе в Москве, Питере, Новосибирске или других городах. Пожалуйста, заполните форму заявки, я вам отвечу.
До связи,
Николай Волынкин.
Я работаю техническим писателем в Plesk, внедряю практику «документация как код», пишу в этом канале про документацию и управление знаниями, организую митапы на те же темы. Посты в канале обсуждают в чате @docsascode.
Сегодня я смотрю Highload++, на ходу пишу и оформляю конспекты, и сразу их публикую на GitHub. Это эксперимент, он уже точно удачный, так что я и дальше буду так делать.
Если ваша документация болит и требует улучшения — давайте обсудим, пишите @nick_volynkin. Я сейчас не беру заказы на разработку документации, но посоветую вам хорошего аутсорсера.
Если вы хотите рассказать о том, как вы пишете и автоматизируете доки, внедряете управление знаниями, решаете другие задачи бизнеса с помощью технического текста — это очень круто, жду вас на митапе в Москве, Питере, Новосибирске или других городах. Пожалуйста, заполните форму заявки, я вам отвечу.
До связи,
Николай Волынкин.
Вадим Мадисон из Авито, «Что мы знаем о микросервисах».
Вадим рассказывает в том числе про требования к документации для микросервиса. Они прям всерьёз требуют документацию и без неё не принимают микросервис от разработчиков. Вот что в неё входит:
— Описание сервиса. В двух предложениях, что сервис делает.
— Диаграмма архитектуры.
— Runbook. (Про них я скоро опубликую конспект из книги Seeking SRE)
— FAQ
— Описание API endpoints
— Labels — к какому продукту, функциональности и структурному подразделению относится сервис.
— Владельцы кода.
Конспект здесь: https://github.com/NickVolynkin/highload-2018/blob/master/1.1-microservices.md
Вадим рассказывает в том числе про требования к документации для микросервиса. Они прям всерьёз требуют документацию и без неё не принимают микросервис от разработчиков. Вот что в неё входит:
— Описание сервиса. В двух предложениях, что сервис делает.
— Диаграмма архитектуры.
— Runbook. (Про них я скоро опубликую конспект из книги Seeking SRE)
— FAQ
— Описание API endpoints
— Labels — к какому продукту, функциональности и структурному подразделению относится сервис.
— Владельцы кода.
Конспект здесь: https://github.com/NickVolynkin/highload-2018/blob/master/1.1-microservices.md
Тернии контейнеризированных приложений и микросервисов
Иван Круглов, Booking.com
Очень толковый доклад о проблеме, двух неудачных и одной удачной попытке решения. Полный конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.2-per-aspera-ad-paas.md
Ключевые мысли:
Мысль 1: не стоит недооценивать способность кода выживать. Если вы что-то написали, этим внезапно будут пользоваться. Если там баги, люди с ними столкнутся и будут требовать исправлений.
Мысль 2: лучше скучный инструмент, который вы можете освоить, чем крутецкий, но слишком сложный.
Мысль 3: стоит заранее сформулировать ожидания пользователей от системы и системы от пользователей.
Мысль 4 (продолжение второй): kubernetes хорош, но важнее подумать о том, как вы будете его интегрировать в сществующую экосистему. Только если вы не стартап, все такие cloud-native.
Иван Круглов, Booking.com
Очень толковый доклад о проблеме, двух неудачных и одной удачной попытке решения. Полный конспект: https://github.com/NickVolynkin/highload-2018/blob/master/1.2-per-aspera-ad-paas.md
Ключевые мысли:
Мысль 1: не стоит недооценивать способность кода выживать. Если вы что-то написали, этим внезапно будут пользоваться. Если там баги, люди с ними столкнутся и будут требовать исправлений.
Мысль 2: лучше скучный инструмент, который вы можете освоить, чем крутецкий, но слишком сложный.
Мысль 3: стоит заранее сформулировать ожидания пользователей от системы и системы от пользователей.
Мысль 4 (продолжение второй): kubernetes хорош, но важнее подумать о том, как вы будете его интегрировать в сществующую экосистему. Только если вы не стартап, все такие cloud-native.