Про контейнеры

Как все-таки изменилось понятие "контейнер" по сравнению с самым началом его зарождения :)

Вообще, идея изоляции ресурсов без супервизора не нова. Еще в начале далеких нулевых FreeBSD успешно запустила свои jail-ы и это было очень круто. Со фряхи я начинал свой путь админа и в джейлах было очень удобно запускать всякую дрянь без риска повредить основную ОС. Потом был Solaris со своими Zones, а в 2009 году подтянулся и Linux со своими нативными LXC-контейнерами.
(В линуксе до этого был уродец-chroot, не идеально, но тоже вполне себе изолировал часть ресурсов)

Ну а потом в 2013 начал свое победное шествие Docker и это был реально life-changing moment, мир разделился на до и после. Docker не сделал ничего нового, он просто собрал уже имеющиеся технологии и запаковал их в красивую обертку, сделав очень важный шаг: он положил начало развитию экосистемы, запустив DockerHub

Тренд на Cloud-native уже было не повернуть вспять и вся эта история становилась все красивее и удобнее. В принципе, и сейчас есть люди, которые закидают меня помидорами, но нельзя не признать, что всё, облака плотно закрепились в нашей жизни. А контейнеры стали удобным специализированным средством доставки приложений. Любых. Все стало контейнером. ОС, внешние зависимости, инструменты, базы данных, конечные продукты, все стало можно обернуть в контейнеры. Как классические репозитории пакетов изначально сильно облегчили жизнь и популяризовали UNIX-like OS (некоторые дистрибутивы линукса уже гораздо проще той же винды и в консоль лазить не надо, если не хочется), так и контейнеры перевернули мир deployment&delivery для продуктов, придав облачным окружениям мощный буст.

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

Появились, например, Kata Containers, которые реализуют CRI для k8s и запускают контейнеры под гипервизором KVM, немного проигрывая в скорости, но дающие бОльший уровень безопасности, делающий почти невозможным побег из контейнера. Появились даже, господи прости, Windows-контейнеры, существующие в двух ипостасях: первая, также, как и kata, работающая под Hyper-V и вторая, умеющая строить изоляцию на уровне виндовых процессов. Как, не спрашивайте, я в это глубоко не погружался :) Реализация от Microsoft даже совместима с докером (но, конечно, надо понимать, что винду на голой линуксовой машины вы в докере не запустите)

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

​​Про когнитивные искажения

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

Обо всех когнитивных искажений поговорить не хватит и десятка постов, да и незачем. Все уже написано до нас, если хотите глубже погрузиться в тему, то очень рекомендую книгу Артура Фримена "Ошибки мышления, или Как жить без сожалений" (ее еще можно встретить под названием "Если бы да кабы"). А мы поговорим о моих самых любимых.

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

Наш хит-парад открывает когнитивное искажение, которым страдают фактически все.
"Да он накосячил, потому что он мудак криворукий, а я ошибся. потому что случай реально сложный, сходу не вывезешь". Знакомо? Только честно :) Да точно знакомо. Встречайте, фундаментальная ошибка атрибуции. Фактически тот самый переход на личности, дада) Мы всегда стараемся объяснить свои действия внешними факторами, тогда как действия окружающих (а уж "соперников" в любом их виде и подавно) исключительно их личностными качествами.

Это большая проблема для руководителя (и не только😁). Приходится реально заставлять себя быть объективным и любое решение просеивать и продумывать. У меня проблем с самооценкой никогда не было, в принципе и я был очень подвержен этой херне. Как-то почти полтора года я вел дневник эмоций и поступков. Кроме огромного материала для самоанализа это помогло мне научиться ловить это искажение на подлете. В принципе, вот этот пост — это как раз про это. Ну и учитывайте, я, конечно, привел очень утрированный пример, на деле эта ошибка очень коварна и хорошо маскируется

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

Ну и завершает тройку лидеров не столько искажение, сколько очень популярная логическая ошибка.
"После" — не значит "вследствие"
Это про умение находить реальные причинно-следственные связи. (Вы заметили, насколько все, о чем я пишу сегодня, связано друг с другом?😁) Сбой БД совершенно не обязательно связан вот с этим пиком на графике, они могут просто совпасть по времени. Сервис падает не обязательно из-за перегрузки, может нарушиться сетевая связанность. И сбои в трафике необязательно связаны с введением нового ingress-контроллера. Если уж мы говорим про сложные программно-аппаратные комплексы, то избежать этой логической ошибки как раз помогает проектирование и имплементация observability и решительный отказ от гадания трех графиках, которые вы умеете читать

Для желающих окунуться в прекрасный мир когнитивной психологии рекомендую начать вот с этой прекрасной статьи в Википедии

Про знание и понимание

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

"Знание также отличается от понимания, как рецепт на пенициллин от самого пенициллина"
Олдос Хаксли

На этом, в принципе, можно ставить точку🙂 Но нет.

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

Знание вполне может быть зафиксировано в системе знаков и этого добра сейчас пруд пруди. По всем направлениям знания больше чем достаточно в свободном доступе, бери и впитывай. Однако понимание передается через века только лично, от учителя к ученику. И это всегда не массовая история. И это всегда требует усилий с обоих сторон. Хороший ментор не может быть отмасштабирован в бизнес. (А Тони Роббинс может😄)

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

Мы можем сказать, что понимание = знание + опыт. Но я бы, наверное, добавил бы в это уравнение то количество души, которые вложили в занятия преподаватель и ученик.
Впитывать знания проблемы не составляет вообще, но их всегда необходимо провалидировать об кого-то, всегда надо понять, правильно ты делаешь или нет. С опытом ты учишься понимать это сам и необходимость во внешней валидации пропадает или, по крайне мере, сильно уменьшается. Почему сразу это не получается? Чего не хватает? Что такое запрятано между строк? Это вопросы, на которые однозначного ответа нет

Исследуйте ограничения. Знание дает прямой идеальный путь, а дьявол, как всегда, в деталях. Разумное исследование ограничений — это хороший вклад в копилку понимания, в процесс когда знание растворяется в опыте, образуя устойчивый фундамент

Обучение состоит в добавлении к своим запасам день за днем. Практика дао состоит в вычитании
Лао Цзы

Чеклист идеального релиза

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

Сегодня я поделюсь с вами чеклистом идеального релиза, разбирайте. Обратите внимание, необязательно сразу же примерять на свои процессы все, что там написано. Это, скорее, вектор, который можно применить и построить процесс в каждом конкретном случае. И да, мы будем говорить о кумулятивных релизах, а не о процессе Continuous deployment/delivery, об этом поговорим в другой раз.

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

Текст оказался слишком длинным для поста, отправил в телетайп: https://teletype.in/@happydevops/release-checklist

Эти пункты покрывают большинство ситуаций, которые важны при больших кумулятивных релизах. Вообще, конечно, большие редкие релизы — это хреновая практика, которая тормозит основные продуктовые метрики и зачастую это пережиток прошлого, от этого надо уходить в сторону мелких гранулярных релизов, которые автоматизированы по максимуму. Очень хорошо, когда ваш мониторинг и observability позволяют принимать решение об откате или распределении трафика самостоятельно, оставляя инженерам лишь роль наблюдателя и возможность перехватить управление в случае чего.

Ну уж если автопилоты начали ездить в реальной жизни по городам и error rate у них уже приемлем для выпуска их на дороги общего пользования, то неужели так сложно сделать релизы полностью автоматизированными?

Я сам знаю как делать

Это очень страшная болезнь — болезнь просроченного знания.

Я сейчас птыаюсь погрузить в современные реалии одного довольно взрослого дядьку. Я ни разу не эйджист и мне вообще пофиг на то, сколько человеку лет, к какому гендеру он себя причисляет и как относится к другим расам. Пока человек выполняет задачи — я его уважаю и горячо приветствую.

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

Дядька, к сожалению, просроченный. Outdated. Причем фундаментальные знания у него хорошие и он, наверняка, полезен и результативен как сферический разработчик в вакууме на задачах типа "кодить от забора и до обеда", но блин, сейчас это уже не самый полезный скилл. А фигово то, что он не открывается навстречу новому, он залип в своем знании и верит в его исключительность

Говорят, что айти — это профессия молодых и "No Country for Old Men", фигня все это. Позволю себе возразить. Айти — это профессия для уиных и готовых развиваться людкй. И при этом не важно, сколько тебе лет. Сделай усилие над собой и отрефлексируй тот момент, когда ты начинаешь думать, что в твое время было лучше и что твое знание — единственно верное. В этот момент пора "забывать все, чему учили в институте" и переабатывать реальность заново.

А еще лучше, просто никогда не выпадать из этого процесса.

Про самомониторинг

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

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

Трекеры рабочего времени
Их два. RescueTime я использую для контроля всего времени в течении дня, чтобы понимать на какие приложения и активности делится все рабочее время. Там довольно гибко настраиваются активности, бесплатной версии хватает для всего. Я ее купил из-за фичи Focus.
Be Focused — это помидорный таймер. Их тысячи, можно выбрать по вкусу. Помидорки я использую как некий аналог сторипоинтов: при планировании времени на задачи я прикидываю, сколько помидорок займет таск. Стараюсь декомпозировать таски до 1-2 помидорок. Я использую помидорки по 25 минут с 5-минутным перерывом и длинные перерывы по 15 минут

Трекер привычек
Банальная табличка в Notion, в которой я просто отслеживаю привычки помесячно. Просто отмечаю каждый день, когда я делал желаемое, зелененьким, а когда не делал — красненьким. Статистика показывает, что в моем случае привычка формируется примерно за 90 дней

Личный таск-трекер
Я использую Microsoft To-do и люблю его за максимальную простоту. У меня нет разницы между личным и рабочем трекером, все активности я веду в одном. Рабочие задачи я ставлю (или мне ставят) в рабочей Jira, а в личный я их переношу в декомпозированном виде

Трекер физического состояния
Для моих потребностей мне с верхом хватает Xiaomi Mi Band. Там я отслеживаю тренировки и пульс в течении дня. Также очень важная вещь — это трекер сна. С того момента как я всерьез озаботился сном и начал его настраивать, жизнь поменялась в лучшую сторону прямо очень существенно. Для настройки сна я использую Слипи-бота, а для контроля — трекер сна, встроенный в браслет.

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

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

"Пустой инбокс"
Ну и всегда есть некий поток задач, которые надо просто сделать. Типа что-то купить, куда-то позвонить, поменять лоток кошке и все такое. Для этого я использую технику Пустого Инбокса из ГТД и пуляю все подобные задачи в Saved Messages в телеграме. И каждую субботу я трачу час времени на разгребание этого и превращаю все это в запланированные активности

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

​​Хочу в FAANG

Для новогодних обещаний, конечно, рановато, но я хочу подготовиться 🙂

Итак, поймал себя на мысли о том, что мне скучновато. Душа просит челленджа, причем не повседневного такого челленджа, их у меня на работе хватает, а прям Челленджа.

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

Я решил пройти интервью и получить джоб оффер у трех из пяти компаний FAANG-а: это гугл, амазон и фейсбук

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

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

Мне надо сильно подтянуть "олимпиадное" программирование (алгоритмы и все такое), прочитать много всего по system design и подтянуть английский (сейчас у меня Upper Intermediate, в принципе я свободно прохожу интервью на английском, но я хочу быть абсолютно уверенным)

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

С января до июня 22 недели, это 396 запланированных часов. Для ровного счета возьмем 400. Вот за эти 400 часов я хочу стать настолько уверенным в себе, чтобы получить приглашения на работу от ведущих мировых игроков в IT-отрасли

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

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

И да пребудет со мной Сила!

P.S. Ну и, наверное, время открыть комменты. Пусть все будет максимально прозрачным :)

​​Итак, потихоньку систематизирую. Пока про кодинг

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

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

На собесах, по большей части, будут задачи уровня Medium. Поэтому при подготовке рекомендуют разделять так:
- 20% Easy
- 60% Medium
- 20% Hard

Но так как я ненастоящий программист, то, пожалуй, добавлю 10% к Easy и, соответственно, уберу 10% у Hard. Весь январь буду решать в основном задачки уровня Easy, надо набить руку

Из дидактических материалов в бумажном виде у меня есть класснейшая "Грокаем алгоритмы" и просто "Алгоритмы" за авторством Рода Стивенса. В электронном виде буду читать две из серии Cracking: "Cracking the Coding interview" и "Cracking the PM interview". Хотя вторая про продактов, но знающие люди говорят, что она не менее полезна при подготовке

Есть вопрос

В процессе поиска информации я нахожу прекраснейшие заметки, типа вот этой:
How to use LeetCode to help yourself efficiently and effectively (for beginners)
Возникает желание перевести ее и опубликовать перевод, но не будет ли это напрасной работой? Потому как для подготовки и прохождения собеседования английский не то что важен, а прямо-таки необходим и люди, которых может заинтересовать этот текст, смогут прочитать его самостоятельно и им будет достаточно ссылки.
Что думаете?

​​Язык шаблонов

Опять про книжки. "Язык шаблонов" Кристофера Александера, больше тысячи страниц чистейшего кайфа. Ее я читал, надо сказать, очень долго, почти год. Но эта книга плохо предназначена для чтения подряд, это, скорее, справочное издание, но и просто ее читать — сплошное удовольствие.
Это, однозначно, маст хэв для любого, кто имеет отношение к любому проектированию. Книга изначально про архитектуру, но сам подход и принцип выработки языка паттернов и построения из них удобных пространств — просто охуенно. Очень легко перекладывается на проектирование архитектур как ПО, так и инфраструктурных решений для него. Я реально научился визуализировать в голове те системы, с которыми я работаю не схемой, а... шаблонами🤷‍♂️ Сложно объяснить, надо читать, в общем
Собственно, идея шаблонов в С++ возникла именно благодаря этой книге.
Книга впервые была переведена и издана на русском студией Артемия Лебедева и вот к Лебедеву как к личности можно относиться как угодно, но в профессиональном плане он охуенен безусловно. Книга очень хорошо переведена, очень хорошо сверстана и вообще читать ее очень приятно, видно, что в нее вложили много любви и много души
Такой очень хвалебный получился пост, но просто литература такого уровня, к сожалению, встречается очень редко. Чистый кайф.

Про книжки (но на самом деле про ощущения)

Что-то я немного выбился из ритма постов, на прошлой недел вышел всего один. Я честно приболел и, внезапно, почувствовал некие новые ощущения в связи вот с этой историей с офферами в ФААНГ и пытался их как-то отрефлексировать

Я понял, что я боюсь. Боюсь довольно сильно, потому что очень не люблю проигрывать и всегда старался проигрыши как-то замаскировать. А еще лучше, заранее подстелить соломки. Ну типа "лучше никому не говорить, сделаю — значит молодец, а не сделаю — заметем под ковер и никто и не узнает".

Это хреновая история.

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

Сегодня на нашей повестке книжки из серии "Cracking the interview" и их две: про интервью продакт-менеджера и про интервью разработчика. Написала их Гейл МакДоуэлл, хорошая тетя с большим опытом работы разработчиком в больших компаниях типа Микрософт сотоварищи.

"Cracking the coding interview" дает некий ландшафт по техническому собеседованию, показывает топики на которые стоит обратить внимание и все такое. Я ее читал несколько лет назад, но задачки не решал, просто пролистывал. Это больше про хард-скиллы

А вот "Cracking the PM interview" — она про софт-скиллы. И тут первая большая тайна: на собесе в ФААНГ софт-скиллы и бихевиорал матчинг (то есть совпадение по культуре и поведение) является гораздо более важным, чем ваше умение кодить. Как уже раньше замечали в комментах, то кандидаты из СНГ часто валятся именно на этом, просто что русскому — здравствуй, американцу — харрасмент. Я за эту часть не сильно беспокоюсь, я много работал с американцами и понимаю их майндсет довольно неплохо

Первая книэка переведена на русский под названием "Карьера программиста", но перевод, как всегда, говно и сильно рекомендую именно эти книги читать в оригинале

Про силу воли

Сила воли не работает так, как ее пытаются заставить работать в большинстве случаев :)

- Ты как бросил курить?
- На силе воли

Это неправда. Сила воли — это такой ресурс, спускается очень быстро, а восстанавливается очень долго. Поэтому сформировать привычку на силе воли невозможно. Сила воли — это спринт, формирование привычки — это марафон. Надо быть готовым использовать оба ресурса.

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

А потом проанализировать и осознать причины возникновения тяги, исключить этот вариант из жизни на ближайшее время и продолжать марафон, сила воли в этот момент на перезарядке. А аддикты всегда надеются, что достаточно перетерпеть один раз и дальше оно все само. Нет, нифига, по моему опыта первый раз самый легкий. В "Интернах" была хорошая серия, где Купитману не доверяют интернов потому что он бухает и они у него не работают. Он предлагает проверить, берет интернов и весь рабочий день абсолютно трезвый. Когда Быков и Кисегач приходят к нему извиняться, он лежит пьяный в хлам и мычит "Купитман может". Вот это неправильное использование силы воли.

И не надо себя проверять на прочность. Бросаем курить? Выбрасываем все зажигалки, сигареты, все свяазнное с курением. Чем больше триггеров исключим, тем проще будет бросить. Тоже самое, например, при приучении себя к спортзалу. Определить цель и как-то зафиксировать ее. Зачем и на каком промеужтке? Это одна фраза. Я такое просто распечатываю и пришпиливаю к доске. Она у меня постоянно на глазах и я так или иначе думаю об этом гораздо больше, поэтому проще формировать привычку

Ключ к любой хуйне — в регулярности. Правило 10000 часов и все такое. Работает абсолютно со всем, на редкость универсальный способ

Яндексовая "Балабоба" умнее многих ребят, которых я собеседовал

Забавный факт :) Шаблоны С++ являются Тьюринг-полными (относительно compile time☝🏻)
То есть на них можно реализовать еще один С++ например :)

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

Взялся ковырять то, что давно будоражит мою душеньку. А именно: процессоры и вообще булева алгебра и машинная арифметика. Когда-то давно я увидел реализацию x86 на JavaScript (это был, наверное, год 2012😁) и эта тема меня и не отпускает. С тех пор как только не извращаются люди: компьютер построили в Майнкрафте, вот товарищ собрал компьютер на простых логических микросхемах, примеров очень много и это очень интересно

Еще один забавный факт :) Аппаратная реализация машинной логики вырастает всего из одного элемента. И это NAND, "логическое отрицание И", в русскоязычных изданиях обозначается как "элемент И-НЕ". Моя любимая микросхема К155ЛА3 содержит 4 сдвоенных таких элемента и теоретически на них можно запузырить полноценную логику x86, но я даже боюсь представить, насколько сложным будет этот проект

Сам NAND можно построить на вполне себе механических элементах, на двух реле, если быть точным. Да-да, даже не на полупроводниках. А на его базе уже строятся все остальные логические блоки. Вот просто офигенная игра на эту тему, я уже тетрадку исписал, играя в нее. Кому нечем заняться на праздники, прям очень рекомендую

Про инфраструктуру-как-продукт

Очень полезное упражнение — рассматривать инфраструктуру как продукт, предоставляемый для внутреннего заказчика. В этом случае становится возможным использовать продуктовый подход при развитии инфраструктуры и, что самое главное, использовать продуктовые метрики.

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

Например, есть такая хрень, как ICE Scoring. Это методика, которая позволяет количественно выразить важность фичи, опираясь на продуктовые метрики. ICE — это аббревиатура: Impact, Confidence, Ease. Каждый показатель может принимать значения от 1 до 10, и итоговая оценка рассчитывается по формуле Impact x Confidence x Ease = Ice Score
Impact: это влияние, оказываемое на ключевой показатель, подлежащий улучшению. Обратите внимание, в данном случае в качестве показателя выступает продуктовая метрика. Вы строите продукт, который имеет специфичный сценарий использования и который предназначен для внутренних пользователей. Так даже интереснее, на самом деле
Confidence: грубо говоря, это сводный показатель остальных двух показателей. То есть насколько вы уверены в том, что поставили именно такие значения для Impact и Ease. Такая поправка на ветер
Ease: здесь надо посчитать ресурсы. Все. Бабло, людей, железо, в общем все, что потребуется для реализации. А также не забудьте о том, что все эти ресурсы еще надо собрать воедино, это тоже влияет на легкость реализации (или сложность реализации, что по сути одно и тоже😁)

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

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

Важное про понимание OKR

OKR — это Objective -> Key Result. Очень важно, чтобы Key Result был измеримым.

Если вы ставите целью, например, "реализация мониторинга для приложения", то Key Result должен быть не "мониторинг реализован", а "90% сервисов поставлены под мониторинг"

Не надо бояться финальных метрик. Не надо занижать их "на всякий случай". Лучше поставить больше.

Не выполнять Key Result на 100% — нормально.

#ХочуВFAANG

Ну штош, заправлены в планшеты космические карты (оцените, насколько сильно это выражение поменяло смысл за последние несколько десятков лет 😁), пора готовиться к старту

“Предстартовый чек”-пост

Планирование: мне несколько лет назад кто-то подарил Agile-ежедневник Катерины Лейнгольд. Долго он мозолил мне глаза и вот теперь я подумал, что настало его время. Ничего сказать про него не могу, будет проба пера. В нем предлагаются 9-недельные спринты и, в принципе, вай нот? В итоге у меня количество недель увеличивается до 27 (3 спринта), 3 спринт будет по большей части отдан под собесы, я полагаю. Так что если закончу раньше, то и ладно :)

Цель: три оффера. От гугла, амазон и фейсбука. А также максимально детализированный learning path, который я хочу оставить для тех, кто захочет пойти моим путем.

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

Фокус:
- Кодинг
- Системный дизайн
- Софт-скиллы
- Английский
- Резюме

Все факторы очень важны для этих собесов и я буду работать над каждым из них.

Мое расписание: я работаю каждый день без выходных. В будние дни планирую две (утром и вечером) часовые кодинг-сессии с результатами на гитхабе, в выходные — работа с теорией (от 2 до 4 часов) с результатами в виде конспектов в ТГ и на гитхабе. Также каждую сессию (конечно же) будет сопровождать пост

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

Основные темы для задачек: Array, String, Tree, Binary search, Hash table, Depth-first search, Breadth-first search, Two pointers, Stack, Backtracking, Dynamic Programming. Также разбираю задачи на собеседованиях, которые есть на самом LeetCode (в общем, мой старт будет здесь)

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

Системный дизайн: невероятно прекрасный пост, его и возьмем за основу

Английский: я думаю, что пока остановлюсь на двух занятиях с репетитором в неделю, если есть хорошие репетиторы, кидайте контакты в комменты :) Скайенг, конечно же, предлагать не надо.

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

Вот пока как-то так. Последний вечер расслабления перед полугодовым забегом, и да пребудет со мной Сила!