Теперь по поводу картинки. Для начала уберем пункты, которые действительно правильные:
1. Не просите их починить принтер - хочется верить, что в 2018-ом году бизнес-пользователи видят разницу между разработчиком и helpdesk специалистом. Ежели нет - бегите.
2. Не ставьте себя выше них - спорный момент, но есть кадры, которые придерживаются правила “Заказчик == Бог”. Если у вас похожий кейс, то смотрите п. 1.

Вот в принципе и все, что в картинке “правильно”. Перейдем к “неправильно”.

Сразу переходите к сути.

Есть такой термин User Story в Agile/Scrum. История отличается от конкретной задачи определенным уровнем абстракции и отсутствием технического контекста. Условная история выглядит так: “Как пользователь портала я хочу иметь кнопочку, которая будет показывать мне корзину в всплывающем окошке”. Как видите - никакой конкретики. Ни где должна быть расположена эта кнопочка, ни какого она должна быть цвета, ни надо ли показывать фото товара во всплывающем окне.
Такие задачи должны проходить через менеджера проекта или банду аналитиков, которые на выходе нарисуют конкретное ТЗ. Stakeholder (условно заказчик) не должен давать ничего больше, чем видение конечного результата. Мало того, заказчик не всегда знает, чего он хочет (что НОРМАЛЬНО), и это работа исполнителей превратить входную информацию в конкретную задачу через общение с ним.

Постарайтесь на самом деле понять, что они говорят.

Один вопрос - почему? Почему конечный пользователь продукта должна понимать технический сленг? Почему владелец продукта должен видеть разницу между jQuery и GraphQL? Если заказчик обладает такими же техническими компетенциями, что и разработчик, то зачем вообще нужен разработчик? На моей памяти разработчики, козырявшие техническими терминами на встрече с бизнесом, хотели потешить своей ЧСВ. Таких надо гнать, не задумываясь (Skilled assholes хуже рака).

Признайте, что они умнее вас (а они умнее).

На моей прошлой работе напрямую с разработкой работали менеджеры по продажам. Они ставили им прямые задачи по функционалу и следили за конечным результатом (этакое acceptance тестирование). Разработчики у нас были высшего разряда, профессионалы, окончившие бауманку и мехмат МГУ. Означало ли это, что они разбирались в торговле и управлению рисками на рынке commodity лучше “продажников”? Никак нет. Делало ли это продажников умнее разработчиков? Тоже нет. Коммуникация, построенная на модели “я умный, ты дурак” обречена на провал, вне зависимости от того, с какой стороны она исходит.

Дальнейший разбор будет позже. Надо и работать иногда. 😉

Продолжаю читать «Скандинавских богов».

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

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

Продолжаем разбор.

Четко объясните, что вы от них хотите.

Заказчик хочет кнопочку. Хочет экран, отчет, dashboard, симпатичный график, поменять размер шрифта или цвет кнопок. Этого объяснения должно быть достаточно, а все уточняющие моменты должны выясняться аналитиками, руководителями проекта и самими разработчиками.
Я не могу представить себе ситуацию, когда заказчик приходит и говорит: “Сделайте прикольно.”

Дайте им больше времени, чем они просят. Многие вещи в программировании нельзя предвидеть.

Если команда сама написала продукт (а не получила его от другой команды), если текучка в команде небольшая, то программист по умолчанию знает свой продукт достаточно хорошо, чтобы оценить все риски разработки нового функционала. Риск нарваться на неизведанное высок, когда продукт плохо задокументирован. Если это ваш кейс, то стоит дать разработчикам время, чтобы хорошенько пройтись по продукту, написать документацию и комментарии к коду и API. Ежели продукт задокументирован от и до, а разработчик все равно не уверен, сколько времени ему нужно, то компетенцию разработчика можно ставить под сомнение.
Для команд, работающих над продуктом, будущее которого не определено, придумали Scrum и спринты, в которых команда гарантирует доставку определенного количества “фич” и не больше. Этот пункт - камень в огород исполнителя, а не заказчика.

Не отвлекайте их, даже если вам кажется, что они ничем не заняты.

Тут я частично согласен. Где-то в интернете есть пост, в котором человек посчитал, сколько времени ему понадобится, чтобы вернуться к мысли после того, как его отвлекли. В среднем это занимало 20 минут, и если человека отвлекать каждый час, то как минимум треть его рабочего дня будет уходить в молоко.
Однако возникают вопросы, которые можно решить быстро и для этого надо дернуть кого-то из backend/frontend/devops. Чтобы не мучать себя и других, команды на ежедневной основе назначают так называемого “дежурного” - того самого парня/девушку/подставьте_сюда_свой_гендер_по_вкусу, который/ая/ое большую часть дня проводит в чате, отвечая на разного рода вопросы.

Ну и финальное - умственная работа ничуть не проще физической, просто она менее заметна.

Как раз умственная работа заметна гораздо больше, чем физическая. Благодаря умственной работе мы знаем, что Земля круглая и вертится вокруг Солнца (хотя есть люди, которые в это не верят). Благодаря ей у нас есть персональные компьютеры, смартфоны, тиндер, фейсбук, стволовые клетки, бионические протезы, тезлы, космотуризм и биткоины.
Ни один человек в здравом уме не ставит под сомнение полезность какой-либо работы в принципе. Есть люди, которые говорят: “Фу, сидит за своим компом целый день и жалуется, что устал. Ахаха, устал сидеть”. Но есть и люди, которые говорят: “Ой таскал мешки за 5 рублей в час и жалуется, лучше б в тыжпрограммисты пошел, раз не нравится.”
Любая работа важна. Прогеры-илитки, смеющиеся над уборщицей, ничуть не лучше амбалов-качков, смеющихся на прогерами-илиткой.

Касательно охеревших разработчиков: @CarrolCox поделился очень классным чтивом на эту тему - https://medium.com/software-developer/how-to-be-really-awesome-at-your-job-and-not-be-a-complete-dick-53ff071f5b19

Ребята, количество людей, попавших в DevOps менее чем 3 года назад (согласно последнему опросу), наталкивает меня на мысль: «А не сделать ли мне свой вклад в развитие отечественной индустрии.»

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

Естественно речь идет на о махровых профессионалах, которые пишут Jenkinsfile закрытыми глазами и вместо кубика Рубика собирают кластеры Kubernetes. Интересные мне в данном контексте ребята - линуксовые/виндовые инженеры с опытом в ИТ индустрии максимум один-два года.

Чтобы показать свои компетенции, проведу небольшой мастер-класс, этакий DevOps 101 (тоже платно, но подъемно).
Нравится такое? Жмите на «козу». Если наберется 20 коз, значит интерес есть, и можно пускать идею в работу.

P.S. Только не жмите по фану, мне нужна максимально честная реакция.
P.P.S. Контенту это не повредит, не волнуйтесь (скорее даже поможет).

Офигеть вы шустрые!

(ушел готовить материал)

Я вам так скажу, готовить простенький мастер-класс занятие очень увлекательное. Приходится вспоминать многое из того, что не трогал довольно давно. %)

Сложнее всего начать. Поскольку в Нидерах сейчас аномальная жара, просто заставить себя сесть за работу невозможно, на ноуте так вообще можно яичницу жарить.
Для тех, у кого проблемы с мотивацией или не знаете с чего начать проект, пусть даже небольшой, есть полезный совет из прекрасной книжки “A subtle art of not giving a fuck”.

Совет очень простой: Сделайте что-нибудь.

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

Ведь мне для мастер-класса что нужно? Найти платформу для вебинара, надо подготовить окружение-песочницу, нарисовать презентацию, написать пару местных приложений. Глядишь на все вместе - кажется задачей на пару спринтов.
А как садишься описывать конфигурацию вагрантовых коробок, там уже и ансиблевые плейбуки прут, и на вебинар.ру зарегистрировался, и приложения решил не писать, а брать готовые (благо на Github всяких hello-world навалом).

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

Если у вас есть животрепещущие вопросы, вы знаете куда писать. ;)

Я начинаю понимать любовь творческой интеллигенции к столице Франции. Город впитал в себя многолетнюю культуру государства, и гуляя по улицам, особенно в темное время суток, чувствуешь себя героем фильма Вуди Аллена “Ночь в Париже”.
Одним из главных пунктов “посмотреть, иначе считай не был” был Лувр. Музей настолько огромный, что меня хватило только на четверть, хоть я и увидел предметы искусства, которые меня интересовали больше всего: Нику, Венеру Милосскую и всем известную Джоконду.

Когда я добрался до экспозиции одного из самых известных трудов да Винчи, я в очередной раз (как это обычно со мной бывает в музеях) познал дзен. Не потому что я увидел саму картину - Джоконда это самый яркий пример оверхайпа во всем мире, который вы когда-либо увидите, посетив Париж. Пространство вокруг картины, надежно спрятанной за бронированным стеклом, кишело туристами, которые стояли напротив картины минутами, снимая ее на телефон (причем некоторые даже снимали на видео).
Надо встать рядом. Надо смотреть на нее в упор. Надо сделать селфи. Надо позвонить дальнему родственнику: “Посмотри на меня, я стою напротив Моны Лизы, она прекрасна и у нее нет бровей!”.

Но дзен не в этом. Напротив Моны Лизы, окруженной сотней человек, если не больше, выставлена картина Паоло Веронезе “Брак в Кане Галилейской”, поистине огромная и прекрасная во всем, начиная с кошки, дерущей вазу, заканчивая изображением Христа посередине стола, словно его скопировали с “Тайной Вечери”.
И пока Мона Лиза держалась под натиском толп китайцев и британцев, результат работы Паоло Веронезе стоял одиноко, и всего лишь пара человек остановилась, чтобы разглядеть изображенных на ней псов.

И в этом весь наш мир. “Мона Лиза” в Лувре - это семейка Кардашьян, концерт Джастина Бибера и очередь людей за новым айфоном. “Брак” - Илья Кочергин, взявший золото олимпиады по физике в Цурихе, русские студенты, выигравшие кубок ICPC, Дмитрий Маковкин, закрывший собой смертницу, в Волгограде в 2013-ом году.
Что объединяет этих людей с картиной Веронезе? То что всем на них плевать. Как и на Les Noces de Cana.

Миграционные проекты - одни из моих самых любимых. За всю свою карьеру я занимался “переездами” во всех возможных проявлениях: от тяжелых legacy кластеров до в буквальном смысле переездов из одного офиса в другой.

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

Миграцию при этом надо делать по-умному. Повезло, если у приложения есть окно обслуживания, когда его можно просто выключить на часок-другой. Хуже - когда приложение обслуживает клиентов 24/7, и не дай Бог гламурная нимфетка не сможет с первого раза выложить свое личико на всеобщее обозрение.
В таком случае конторы обычно нанимают под это дело консультантов или контрактников, чья работа заключается в переманивании клиентов на свою платформу и помощи пережить migration pain. Если нет денег на “наемника”, контора делает шаг в пропасть и пытается переехать своими силами. Чаще всего - с огромными репутационными и финансовыми потерями. Поэтому если вам предстоит переезд, выбейте у бизнеса денег хотя бы на обучение.

Миграция делится на два типа: переделывание приложений с нуля под архитектуру новой платформы (читай - переписываешь все под тот же Амазон) и lift-and-shift (перетаскиваем как есть).
Оба способа имеют свои недостатки, и не смотря на “некрутость” lift-and-shift считается самым оптимальным по стоимости и скорости.
Переписывая все с нуля под новую платформу, вы рискуете попасть в неприятную ситуацию, потому что:
1. Неправильно спроектированная архитектура, в виду отсутствия компетенций.
2. Старые проблемы могут быть так же переписаны в новом коде.
На выходе вы получите такой же велосипед на костылях, но зато с IAM ролями вместо API ключей.

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

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

Вот вам пример - нам нужно перетащить старый MySQL от хостинга в Амазон с минимальным downtime (речь идет о mission critical системе).
Что сделал один из разработчиков-stakeholder’ов? Нагуглил прикольную доку: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

Правильный ли это подход? Может быть, не могу подтвердить или опровергнуть сразу. Но поскольку Амазон не меньше вашего заинтересован посадить клиента на свою инфраструктурную иглу, тот он наверняка предусмотрел этот сценарий и предложил решение в виде Database Migration Service, где весь этот процесс сделан автоматически, да и к тому же поддерживается репликационная миграция (читай продолжительная).
Чем поднимать руками ЕС2 и настраивать там MySQL мне гораздо проще развернуть репликационный таск и выключить его, когда приложение будет готово работать с промышленной базой в Амазоне. Весь downtime - один рестарт приложения.

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

Поднабив руку в Terraform и Cloudformation, внезапно понял, что мне больше не удобно пользоваться консолью AWS. O_O

Мое состояние, пока в Амстердаме бушует прайд.

Друзья, хорошие новости! Я закончил работу над вебинаром!

Важная информация: Вебинар пройдет 15 августа в 20.00 по Московскому времени.
Вебинар займет около 2 часов, но на всякий случай я бронирую 3 часа.
Стоимость участия - 750 рублей.

Чтобы оплатить и попасть на вебинар, нужно сделать следующее:
1. Отправить на карту 5100690020146821 сумму равную стоимости участия.
2. Сделать скриншот (с компа или телефона) подтверждения перевода.
3. Отправить этот скриншот мне на электронную почту: thomas.storm@protonmail.com. На адрес, с которого вы отправили скриншот, 11 августа придет ссылка на регистрацию на вебинар.
4. Дальнейшие инструкции будут отправлены по эл. почте в индивидуальном порядке.

Важно! Регистрироваться на вебинар нужно будет с того же адреса, с которого вы отправили скриншот.
На вебинаре будет подтверждение участников, так что нет смысла делиться ссылкой с другими людьми.

Ниже - небольшая адженда по вебинару.
P.S. Если по каким-то причинам метод платежа выше вам не подходит, пишите в личку, что-нибудь придумаем.

Пока готовил материалы для демонстрации CI/CD в AWS, вдоволь наигрался с CodePipeline и Fargate.

На что обратил внимание:
1. CodeBuild использует похожую с TravisCI и Gitlab модель настроек. Если в Teamcity и Jenkins вы можете задать цепочку тестирования через пользовательский интерфейс, то в CB нужно прописать инструкции в buildspec.yml. Файл интуитивно понятный, но понадобится некоторое время покорпеть над документацией, чтобы не ошибиться с параметрами.
2. Сам CB не имеет в себе возможности сборки нескольких проектов. Если вам нужно прогнать тесты с несколькими приложениями (например интеграционные тесты), то нужно делать два отдельных проекта в СВ и связывать их с CodePipeline.
3. Fargate же построен типично по модели Kubernetes. Когда вы создаете task definition, вы задаете лимиты по ресурсам, а внутри него можно запустить несколько контейнеров (читай тот же Pod). Создавая сервисы, вы можете выбрать варианты развертывания REPLICA и DAEMON, что тонко намекает на концепцию Кубера (replicaset и daemonset).
4. CodePipeline позволяет связать все сервисы сборки и развертывания в одну цепочку, связываясь с GitHub по hook’ам, которые служат триггером для начала цепочки (что в принципе и есть основное ядро CONTINUOUS integration).
5. А вот с чем не понравилось работать, так это с CodeDeploy. Мало того, что appspec.yml (инструкции по развертыванию) гораздо сложнее “вкурить” чем buildspec, так еще очень много приходится возиться с ролями и настройками инстансов, на которые нужно разворачивать приложение. Изначально я хотел провести демо связки CodePipeline (CodeBuild + CodeDeploy G/B) + ASG, но после плюнул и решил уйти поглубже в контейнеры.

И все же, Fargate - one love. Буду топить за переезд на него в следующем году.

Я уже говорил, что у меня на работе есть коллега-архитектор?

Дядечка с 30+ лет опыта работы, помнит UNIX, съел собаку на AWS и нежно любит Bash. Я зову его ласково «Дед» (не в лицо разумеется, иначе поймают на эйджизме).
У меня порой бывали комплексы по поводу своего возраста, особенно потому что некоторые товарищи считали и до сих пор считают, что я не «дорос» до своей должности, но с Дедом никогда проблем не было.
Прикольнее всего смотреть, как Дед работает. Человек отпахал немало лет в Philips и прекрасно знает, как надо делать архитектуру уровня Enterprise.
Но поскольку я гораздо моложе его, то мое преимущество в скорости мышления. Поэтому с Дедом у нас этакий тандем. Дед рисует «скелет» любого проекта, а я, этакий Медведев на минималках, подкидываю туда всяких новомодных плюшек в лице всяких инфраструктур-как-код с этими вашими пайплайнами.
Ну и вишенка на торте - исправлять за дедом опечатки и прочие косяки. Ощущение, как учишь бабушку пользоваться Телеграмом.

Когда я работал в Coolblue в моей команде появилось вакантное место тимлида.

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

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

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

Что написал мой коллега, который тоже претендовал на эту должность? Он сравнил тимлида с Царем Леонидом, а команду с 300 спартанцев.

Мораль: военщина - плохо, 300 спартанцев и другие псевдоисторические аналогии - хорошо.

Опять же многоуважаемый @CarrolCox балует меня крутым контентом.

Очень классная лекция о том, почему у ИТшников едет крыша (Спойлер: вы в числе этих безумных.) - https://youtu.be/K6oZuB8_dU8

Для себя вынес полезный совет:
Делайте сами все правильно и исправляйте коллектив. Давайте другим звездюлей, будьте проактивными.

Всем, оплатившим вебинар, было выслано приглашение. Если вы оплатили, а письмо никакое не прилетело, пишите в личку.

Тем, кто еще не оплатил, но все равно хочет поучаствовать - не волнуйтесь, время еще есть.