Что читает и где обитает автор. Список собран в случайном порядке.

Ниже - все публичные группы и каналы в которых я нахожусь (по личным и профессиональным соображениям):
@anykeynotes - канал Миши Жучкова. Контент там редок, но прекрасен.
@pythonstudent - канал моего друга, который внезапно открыл в себе любовь к программированию и бросил все, чтобы стать тридцатилетним джуном (херов дауншифтер). В канал пишет редко, но следить за его прогрессом интересно.
@sbiohack - единственный канал в моей подборке, который вообще не связан с ИТ. Саша очень интересно пишет про здоровье и человеческое тело.
@DevOpsOnCall и @DevOpsOnCall_chat - кто знает меня давно, знает когда и как все началось.
@AWS_Ru - крупнейшее сообщество русско-говорящих амазонщиков и его побратимы: @aws_minsk, @awsNSK (Новосибирск) и AWSKz (Казахстан).
@linkmeup_podcast - не нуждается в представлении. One love СДСМ.
@SysadminNotes - прекрасный канал @servers. Помимо интересных постов, Артем еще делится полезными книгами.
@aws_notes - лучший русскоязычный канал про работу с AWS от самого сильного русскоязычного амазонщика из тех, кого знаю лично.
@count0_digest - лучший агрегатор полезного контента про ИТ, мой личный заменитель Saved Messages. Говорят, если принести в жертву 12 девственниц, на канале появляется авторский контент.
@theaftertimes и @libmustdie - в представлении не нуждаются.
@devopsmoscow - уютная московская тусовочка человеков-культур.

Простите, что пропал, пришлось побороться с вирусом (обычным вирусом). Себе на заметку: в Нидерландах скорая не приедет, если температура ниже 42 градусов.

С температурой 42 и выше можно и не дождаться, но это уже другая история.

Сегодня поговорим о "я же говорил"-ах - биче любого проекта.

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

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

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

В результате имеем человека, который видит, что еб*нет, но без контекста и этих ваших social skills не может донести до ЛПР свою точку зрения. Происходит неизбежное, менеджеры чешут затылки, выходит наш персонаж, выдает свое любимое, в него летят проклятия и помидоры. Занавес.

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

Яжеговорилам же стоит научиться доносить свою точку зрения. Или же замолкнуть навсегда.

В Нидерландах карантин объявили 15-ого марта, объявили о закрытии всех магазинов, баров, рестораном и т.д., за исключением продуктовых и аптек.

Люди тогда подорвались за травой. Очереди вы наверняка наблюдали в Телеграмм и других соцсетях. Люди привыкли проводить свободное время, находясь в наркотическом опьянении, и сама мысль о трезвости вызвала у них панику.

Это говорит достаточно об уровне интеллектуального развития нидерландской молодежи.

Мой личный карантин продлился несколько дольше. 2.5 недели в феврале я догуливал отпуск на предыдущей работе, потом неделю "дорабатывал", затем слег на неделю с ОРВИ (по официальной версии это был ОРВИ), потом вышел на новую работу, поездил в офис неделю... и снова работа из дома.

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

Из минусов:
- Решение вопросов путем коммуникаций (на нынешнем месте это 80% моей работы) занимает значительно больше времени (ногами до человека не дойдешь, нужно писать/звонить и ждать, пока ответят).
- Наше жилище никак не оборудовано под домашний офис, я всегда разделял работу (давай, паши, давай) и дом (семья, отдых, уют).
- Из-за изоляции дни недели смешались. Выходные проходят незаметно, режим сна нарушен. Само собой, нарушено ощущение рабочего дня, и ловишь себя на том, что делаешь что-то по работе в 9 вечера.

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

Когда я приехал в неотложку с температурой 40.5 и рассказал про контакт с человеком из Италии (это не было для них новостью - я уже рассказывал об этом и скорой, и своему домашнему врачу), дежурные врачи не знали, что со мной делать, и меня водили из кабинета в кабинет. Если я тогда был болен COVID-19 (вряд ли - я слишком быстро оклемался), то я мог заразить почти всех в комнате ожидания, ассистентов, которые брали у меня анализы, и осматривающего меня терапевта.

Менее чем за месяц количество больных в Нидерландах выросло с 2 до 6412.

Будьте здоровы и не страдайте херней.

Во всей этой истории с COVID-19 есть потенциальный выигрыш: поскольку бизнес адаптируется под дистанционное обслуживание, возможно в Сбербанке больше не будет "где карту открывали, туда и идите" для элементарного обслуживания физ. лиц.

Обещаю, это последний пост, связанный с COVID-19.

Бизнес в Нидерландах пострадал коллосально. У нас тут хоть и Booking с Philips и ASML, но будет наивно полагать, что они держат всю экономику на своих плечах. Сильнее всего ударило по организаторам всякого рода рейвов, биеннале и прочих мероприятий, тур. потоку, музеям, цветам и, конечно же, KLM. Последний, в частности, сократил опер. деятельность аж до 10-20%.

В связи с этим правительство учредило ряд мер, среди которых была схема компенсации зарплат сотрудникам, которым "порезали" часы работы в связи с кризисом. Компенсировать будут аж 90% потерянного дохода, а государство таким образом пытается избежать массовых увольнений.

И покуда люди радуются тому, что их высоким налогам наконец-то нашлось достойное применение, а бизнес встает в очередь на получение этой и иной помощи, мне стало интересно: "Откуда деньги, Зина?" Явно не его Высочество Виллем-Александр продал свои 500 квартир в Амстердаме (байка среди местных) и решил помочь населению.

Оказывается, деньги на NOW (аббревиатура этой схемы) взяты из фонда UWV (пособие по безработице). Пособие безработным при этом временно перестали выплачивать, а податься на NOW, им нельзя. Проще говоря, взяли деньги безработных и отдали им тем, кто скоро станет безработными.

Источник: The new temporary measure (NOW, Noodfonds Overbrugging Werkgelegenheid) will provide financial help for employers to help pay their employees' wages. The unemployment benefit during short-time working scheme has been cancelled. You cannot apply for the NOW scheme yet, but everything is being done to make the scheme available as soon as possible.

И не сказать, что это прям очень плохо - можно догадаться, кто основной бенефициар "обычного" пособия по безработице.

Но получилось довольно интересно.

Менее года назад, когда я закончил цикл статей про AWS IAM, @patrick239 намекнул, что неплохо бы сделать такой же про CloudFormation.

Получилось несколько лучше. 29 мая выходит моя книга по CFN.

В книге будет все, что внутри шаблона, Stack Sets, Custom Resources, Template Macros, Continuous Delivery, SAM, CDK и многое, многое другое. Вместе с книгой читатели получат ссылку на репозиторий, где будет лежать весь код, используемый в книге, и доступ к видеозаписям, где этот код демонстрируется.

Но должен предупредить - книга не совсем для новичков, и я ожидаю, что мой читатель уже трогал CloudFormation, а также умеет писать (или хотя бы читать) код на Python, работал с Boto3 и, разумеется, умеет в AWS.

Я выражаю огромную благодарность @patrick239 и @t1bur1an за помощь в доведении этой книги до финала и конструктивную критику, а также всех, кто помогал мне в подготовке материала, кодовой базы и схем.

Хотите, расскажу про опыт написания книги по заказу Packt?
👍 - да
👎 - нет

Книгу писать я решил не сам, лукавить не стану. Прошлой осенью со мной вышла на связь сотрудница Packt с предложением написать для них книгу по CloudFormation, дескать ей очень понравился мой блог на Medium.

"Вот она, слава!" - подумал я, но моя муза предложила все хорошенько обдумать. Писать книгу - тяжелый труд, особенно когда ты не Стивен Кинг, а у издателя жесткий дедлайн. Я потратил пару дней, шерстя треды на Hackernews, посвященные авторству для издателей типа Packt и O'Reilly, и узнал следующее.

Заработать на книге вряд ли удастся. Нет, за нее платят аванс и положены комиссионные, но вы потратите очень много времени на нее, невероятно много. Если сконвертировать время, потраченное на проработку концепции, R&D, написание и тестирование кода, запись демонстрационных видео (чтобы доказать, что код рабочий) и написание, собственно, самого материала в почасовую оплату труда, то вы поймете, что "работали" в убыток.

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

И это прекрасно понимаю не только я, но и все авторы, когда берутся за заказ. Мотивация у таковых следующая:
- Престиж и возможность добавить слово "writer" в профиль LinkedIn (т.е. личный бренд)
- Новый опыт
- Верхние 4 ступени пирамиды Маслоу

С моей стороны к этому еще добавляется удовлетворение потребностей "вбить в голову элементарные, по моему мнению, вещи" и "если ты делаешь что-то хорошо, не делай это бесплатно".

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

Логика здесь очень простая. Единственное, на что я могу повлиять для стимулирования продаж - качество материала. Материал должен быть такой, какой захочется прочитать и посоветовать друзьям, какой покупают в "рабочую" библиотеку и так далее. Для этого необходимо не только досконально знать тему, но и подать ее так, чтобы читатель усвоил материал и при этом не помер со скуки.

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

Сейчас моя книга в стадии производства, она с 99.99% вероятностью в срок, но я все еще веду работу с редакторами (и я уже сбился со счету, в который уже раз мы "мучаем" главу по шаблонам).

Итак, с изначальными требованиями и рисками разобрались, приняли решение писать.

Дальше (новоиспеченного) автора ожидают следующие стадии принятия неизбежного:
1. Подготовка наброска книги, рассмотрение издателем, подготовка и подписание контракта
2. Написание и редактура первичных черновиков
3. Технический обзор, редактура финальных черновиков
4. Производство

Набросок (book outline) - по факту текстовый документ-форма, в котором вы указываете: о чем и почему будете писать; какие части будут у вашей книги, какие главы; какие навыки приобретут читатели и так далее. Заполнение наброска занимает 1-2 дня, после чего его рассматривает издатель и принимает решение - начинать такой проект или нет. Как только положительное решение принимается, вам присылают шаблон контракта на проверку и запрашивают персональные данные для заполнения полей в контракте.

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

Отдельно стоит упомянуть название книги, а именно слово "Mastering". Нет, это не понты автора - у Packt есть 3 "уровня" книг: Learn, Hands-On и Mastering, каждая из которых имеет свою аудиторию.

Если книги Learn направлены на аудиторию уровня Beginner, а конечный результат будет Intermediate, то Mastering - на уровень Intermediate, с ориентацией на то, что после книги вы должны знать все-все-все. Неоспоримым плюсом этой серии является отсутствие необходимости разжевывать прописные истины, а минусом - писать надо понятно о сложном.

Так что если вы собираетесь купить книгу о Packt, обращайте внимание на название. В одной группе коллега жаловался, что читает книгу про Elastic, а там все написано как для детей, и ничего нового из нее не усвоить.

Называлась она "Learning Elastic Stack" :)

Когда набросок книги подтвержден, контракт (с оговоренными в нем сроками) подписан, а все участники проекта друг с другом познакомились, начинается самая трудозатратная часть - работа над первичным черновиком материала.

Предполагается, что одновременно ведется работа только над одной главой, в соответствии с этим и проставляются сроки сдачи материала. Что интересно - издатель изначально давал мне по 2 рабочей недели на главу, вне зависимости от ее размера и темы. Проще говоря, у вас что на вступительную главу на 10 страниц, что на огромную главу на 50 будут выдавать одинаковое количество времени.

Разумеется, это можно и нужно оспаривать. Более того, если однажды возьметесь за заказ - я настоятельно рекомендую докидывать как минимум 5 рабочих дней на сроки по тем главам, тема которых вами не изучена на 100%! Объясню почему.

CloudFormation я знаю хорошо. Очень хорошо. Я давно с ним работаю, застал времена, когда его можно было писать только в формате JSON, и ликовал, когда завезли cfn-init. Однако, в моей книге есть главы про SAM и CDK, и если SAM это кастрированный CFN, то CDK - это нечто модное, стильное и молодежное, нечто нетронутое моим чопорным "оно работает" взглядом, но прекрасно ложащееся на мое повествование (почему - тема отдельного поста).

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

Очевидно, большую часть времени занимают 2 и 3 пункты. Задача не просто пройтись по документации и нарисовать "Hello, World". Задача - от и до изучить тему и донести её до читателя в рамках интересного и понятного повествования.

Нередко во время написания прототипа может еще появиться новая идея ("А что если я сделаю тут по-другому и посмотрю, что будет?"). Тогда ее обязательно надо проработать и включить в книгу.

Так, например, у меня появилась мысль вручную проставлять True и False в значения Conditions (Спойлер - так делать нельзя).

Но это еще не самое сложное в подготовке и сдаче материала.

Итак, вы написали главу, перечитали ее несколько раз, и готовы отправлять редактору. Вы не настолько наивны, чтобы полагать, что к главе не будет никаких вопросов.

Чтобы сократить количество комментариев, вы, как автор, можете сделать следующее:
1. Убедиться, что повествование строится в соответствии с методическими рекомендациями издателя (вам их предоставят).
2. Целая страница не состоит только из кода или скриншотов (т.е. не больше 75%).
3. Грамматические конструкции понятны читателю.

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

Редактор будет задавать вопросы в стиле "Код выше будет понятен читателям?", а вы будете смотреть на код, видеть там print("Hello, World") и невольно думать, что с редактором что-то не так.

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

Оспаривать комментарии можно и нужно. Вы как профессионал знаете точно, что является термином, что ключевым словом, что стоит обвести курсивом, а какой блок программного кода не нуждается в пояснении. Цикл "первичный черновик - правки - первичный черновик" в среднем у меня занимал 1-2 итерации. Но наивно полагать, что после принятия первичного черновика ваша работа завершена - затем черновик помучают технические обозреватели, затем снова ваш редактор, затем copy редактор, затем корректор... И лишь потом вы получите назад свою работу, чтобы дать свой финальный вердикт. После этого она уйдет в печать, а изменить уже ничего не получится.

Вот вам непрошеный совет - сохраните самый оригинал вашей главы, а потом сравните с тем, что получилось в самом конце.

Приятно или нет, но вы будете очень удивлены.

А дальше - дела механические: тираж, маркетинг, раздача слонов и прочие мелочи.

Писать книгу было... средне. Иногда текст шел сам, иногда было невероятно тяжело. С Template Macros прошло легко, над Custom Resources страдал. Тяжелее всего, как ни странно, далась последняя глава - надевать шапку "визионера" оказалось сложнее донесения простых истин.

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

Завтра ожидайте от меня хорошую новость. ;)

Любой кризис создает проблемы и возможности, таланты берутся за эти проблемы и стараются решить их, пока открыто окно Овертона.

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

Россия не остается в стороне, и уже сейчас можно подать заявку на https://hackthecrisisrussia.ru/.

Среди моих читателей и в целом в России огромное количество талантливых людей, полных интересных идей. Если вы ждали своего шанса - окно открылось и останется открытым до 27-ого апреля. Организаторы возьмут на себя всю скучную сторону вопроса, такую как организацию связи и предоставление необходимых ресурсов участникам. Ваша задача - подать заявку и предложить решение гребаной проблемы. Если у вас нет идей - вы можете предложить свои навыки.

Когда все это закончится, COVID-19 (да, я помню про свое обещание) еще ударит по нам и нашей экономике, и именно поэтому сейчас не стоит тратить время впустую.

Самое (не-)приятное занятие в работе с людьми - объяснять и доказывать элементарные, на мой взгляд, вещи.

Список огромный, но самый излюбленный дискурс - High Availability (HA) против Disaster Recovery (DR). Люди, даже технически подкованные, часто путают или, что еще хуже, смешивают эти два понятия.

Есть простой пример "из жизни", который прекрасно дает понять контекст.
HA - это несколько двигателей у самолета.
DR - это что должно произойти, когда самолет падает или ударяется об землю.

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

Теперь, когда у меня появилось в разы больше свободного времени, я смог его закончить.

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

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

На предыдущем месте работы я считался individual contributor, такую "метку" присваивают специалистам, которые не занимаются менеджментом, а просто делают свою работу. В нидерландских компаниях работу менеджера в принципе пытаются нивелировать до минимума - толи из-за миллениалов, которые не научились в субординацию, толи из-за нелюбви к конформистской/конкуретной организации.

Как результат, мне приходилось идти на компромиссы со всеми подряд, но делать это приходилось крайне редко - никто не обладал такой же, как у меня, экспертизой в вопросах инфраструктуры и системной инженерии, а это в разы упрощало проталкивание своих идей. Чего нельзя было сказать о моих коллегах из разработки.

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

Дела стали еще хуже, когда свежая кровь из только что нанятых коучей стала создавать так называемые "гильдии" (по аналогии со Spotify). Теперь, если ты фронтендер, тебе нужно было договариваться не только с бородатыми бекендерами, но и с особенными снежинками из своей гильдии, где каждый тащит свой подход ко всему - фреймворкам, платформам, coding conventions и прочим радостям промышленной разработки.

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

Итоговая картина получалась идиотская, но оно работало (да и до сих пор работает).

Быть единственным прошаренным амазонщиком в конторе было очень легко, а когда мои коллеги стали подтягиваться по знаниям, сложнее не стало - Well-Architected Framework един, и следуют ему все. Но вернуться в старое доброе лоно enterprise разработки после нескольких лет в ИТ-детсадике было радостно, хоть и очень непривычно в первое время.

Если спросить меня, с кем я больше всего хочу поработать, я однозначно назову имя Брендана Грегга.

Мало того, что Брендан автор Systems Performance, у него также имеются оригинальные исследования.

Например такое: https://youtu.be/tDacjrSCeq4

COUNTRY ROAD; TAKE ME HOME; TO THE PLACE; I BELONG

По иронии судьбы моих самых "сложных" stakeholder'ов зовут либо Себастьян, либо Кристоф.

От меня мало контента, но есть две новости:
1. Underpromise and overdeliver: моя книга вышла на 21 день раньше!
2. 4-ого июня можно будет увидеть мое карантинное лицо, рассказывающее основы основ одного маленького облачного провайдера. Всех буду рад видеть!