Архив за месяц: Март 2017

Книга: визуальные заметки, Майк Роуди

 

clip_image002После того, как я прошёл курс IQDoodles, нужно было двигаться дальше: научиться использовать новое умение не только для иллюстрации блога, но найти ему и другие применения. Про скрайбинг я уже писал, но пока мне некуда его применить. Следующая возможность улучшить свою жизнь с помощью визуализации – визуальные заметки.

Книжка из заголовка прекрасно готовит и мотивирует к этому занятию. По крайней мере, саму книжку я стал документировать не в виде мыслесхемы, как привык, а в виде заметок с рисунками. Да и на встрече с автором комиксов komikaki тоже удалось сделать несколько зарисовок.

Чуть ниже пара примеров, в которых можно хоть немного разобрать почерк.

А пока немного полезностей из книги для затравки:

·         Майк рекомендует делать заметки ручкой. Карандашом, по его мнению, получается хуже: вместо отображения сути начинаешь наводить красивость;

·         Нужно обобщать, чтобы успеть записать/зарисовать самое важное. Но при этом теряются детали;

·         Самое важное всё-таки творится не на твоём блокноте, а на мероприятии. Фокусируйся на том, что фиксируешь, не на процессе фиксации. Иначе ничего не получится;

·         Структура и контент важнее красивых рисунков;

Какие-то сухие заметки получились. Книга сильно лучше. Рекомендую книжку прочитать, если кажется, что такой способ исполнения заметок может пригодиться и понравиться.

Ну и некоторые из зарисовок (кликабельно).

майк роуди_виз. заметки page6

майк роуди_виз. заметки page9

майк роуди_виз. заметки page10

Легко ли читать: Да, конечно. Книжка на 80% состоит из рисунков, а как ещё? =)

clip_image001[4]

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

clip_image002[4]

 

Реклама

@innubis и секреты iPad’

в поисках лета Final

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

Кирилл просил не особо афишировать содержимое курса пока, так что фиг вам, а не подробности. Но как минимум пару приёмов и новых сценариев использования планшета я для себя вытащил. К примеру, использование некоторых приложений нестандартное: Кирилл использует Trello для планирования курсов. А paper by 53 можно использовать в брейнштормах, или вообще как замену флипчарту. Когда вдруг приобрету или получу в дар iPad Pro, буду использовать. Или найду замену для себя.

Ну и посмотрел, как создаются комикаки:

А вот результат:

WP_20170302_19_52_57_Pro

Чтобы не быть на этом фоне совсем уж бездарью, сам придумал и нарисовал комикс, с которого начинается статья. Назвал “В поисках лета” Winking smile

Книга: The Phoenix Project

clip_image002[7]Итак, я добрался до Святая Святых девопса – бЫзнес-романа The Phoenix Project. Снова прозреваю, что кроме меня его уже все читали. Так что я снова коротенько по задевшим лично меня моментам, равно как и по непонятным или смешным.

Интересный подход: выкатывать, но не включать функционал. Тогда код уже на проде и всё работает, в общем-то. Или включаем, но не для всех пользователей или сценариев. Или только для тестирования. Увы, не для всех типов ПО подходит. Но нужно использовать, где это возможно.

Есть три путя:

1)      Никакой локальной оптимизации, никакого «с моей стороны пуля вылетела». Делаем мелкими партиями, никогда не передаём дефектный код дальше. Инструментарий:

a.       Continuous build, integration and deployment.

b.       Создание окружений по запросу.

c.       Ограничение WIP.

d.       Построение safe systems and organizations that are safe to change. Вот этот кусок несколько абстрактен. Прозреваю, что пойму, когда настанет пора (или когда прочитаю DevOps Handbook J).

2)      Построение обратной связи. Не очень понятно, как мне это делать в своей ситуации. Тоже нужно разбираться.

a.       Остановка production line когда тесты и билды фейлятся. Здесь всё просто относительно, если мы качественно разберёмся с пп.1 и 2d.

b.       Постоянно улучшать работу даже в ущерб повседневной работе. Всё понятно, но нужно где-то взять политической воли. Есть взаймы у кого-нибудь? =)

c.       Создание быстрых автотестов, подтверждающих, что код всегда готов к деплою.

d.       Создание общих целей между Dev & Ops.

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

3)      Создание культуры, которая пестует постоянные эксперименты и учёбу на ошибках и успехах.

a.       Создание культуры инноваций и принятия риска. Вот тут ещё учиться и учиться. Мне.

b.       Выделение хотя бы 20% времени на постоянное улучшение. Как показал эксперимент, тупо выделение этого времени не работает. Нужно предыдущий подпункт корректировать, да и ещё чего-то может не хватать.

Хотя везде идёт рефреном «break the silos», всё равно эта история – про повышение ответственности той части команды, которая пишет код продуктов. Автоматизация релизов просто не оставляет других шансов. Если ручное развёртывание Ops’ами релизов ещё как-то нивелирует последствия плохого кода или тестирования (админ может руками что-то откатить или допилить на лету вместе с разработчиком), то полная автоматизация должна это сделать сама. Нет, понятно, что разбудить админа, чтобы он починил, всё равно можно, но это дополнительное время простоя. Немного нивелируется это тем, что теперь ответственность Ops за инфраструктуру именно доставки кода и окружений также становится очень высокой. На самом деле, надёжность этого куска должна быть, кажется, запредельной. Чуть ли не выше доступности самих продуктов.

Автоматизировать всё нужно даже не для сокращения издержек, а для того, чтобы разрабы могли сами получать окружение, похожее на продуктив. Чтобы прохождение тестов на stage-среде действительно было маркой качества: развёртывание в бой не сорвётся. И чтобы переиспользовать эту экспертизу для разных команд разработки.

Вопросы:

По книге основные потоки работы это: бизнес-проекты, технические проекты, изменения, починка/тушение пожаров. Но как-то до меня из книжки не дошло:

1)      Почему разделяются бизнес и технические проекты? Обновление почтовой системы – технический проект? Но там есть функционал для бизнеса, допустим. В общем, мне это деление кажется несколько условным.

2)      Проекты состоят из изменений, почему мы их, опять же, разделили?

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

Легко ли читать: Да, легко и интересно. Всё-таки, это больше художка, и не так, чтобы плохо написанная.

clip_image004

Полезность: выше средней. Прорыва у меня пока нет, всех ответов нет. Нужно следующее читать. Но и зря потраченным временем это не назвать – польза однозначно есть.

clip_image006