Разработчики часто думают о том, как несправедлив к ним найм. Что вокруг одно легаси (хотя кто в этом виноват?),
неадекватные менеджеры и все стараются выманить их с удаленки в офис. Но ситуация, в которой оказывались люди
отзывающиеся на вакансию СТО Платформизации в Broiler 228, была куда анекдотичнее.

Итак, компания потратила 250 миллионов Großmar'ок годового бюджета на консультации за месяц. После чего встал вопрос, что делать и как быть. Обращаться к совладельцам, никто особенно не желал, а планы по переезду на микросервисы нужно было исполнять.

В итоге была размещена вакансия с совершенно сумасшедшими цифрами - за 450 тысяч Großmar'ок в месяц (в 3 раза меньше предшественника, кстати), будущий директор должен был перевести монолит на микросервисы, не нанимая людей (т.к. бюджет 0). Ему оставляли и оплачивали тех людей которые уже были и времени в целом было в обрез, т.к. пока суд да дело шёл уже 5й месяц. Ну а если будет достигнут успех к началу года, то счастливчику позволяли забрать премию, от которой отказался предыдущий платформизтор - целых 6 миллионов Großmar'ок.

Люди приходившие в светлый офис крупной национальной компании "Broiler 228" слушали всё это и впервые в истории найма в Großland'e именно они говорили HR'ам и "нанимающим менеджерам", "мы подумаем и свяжемся с вами". Вереница задумчивых связистов была поистине бесконечной. Месяц за месяцем и лето шло к концу. Идиотов не находилось.

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

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

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

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

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

1. Сервис каталога SKU должен выдерживать 5 тысяч RPS.
2. Сервис обработки заказов 2 тысячи.
3. ....
4. Profit!

На эти жалкие 4 месяца до конца года вся вселенная затаила дыхание. СТО II изнервничался. А "бизнес" в лице
собственников воодушевился. Близился высокий сезон нового года, тот самый в который компания продающая спиртосодержащие жидкости зарабатывала большую часть своей выручки за год. Никогда ещё судьба нескольких миллиардов не зависила от человека с зарплатой несчастного джуна с 3+ годами опыта.

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

#tales #fridaytales #broiler228

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

А т.к. существует некоторый запрос, на контент и некоторые советы от старика (а 5 новых книг одновременно читаются как-то медленно), то запустим завтра новую рубрику "Метод деда", где буду показывать некоторые свои исследования и подходы к формированию дизайна и программированию.

Присаживайся сынок. Зря ты разбудил дедушку от его летаргического сна после работы. Придётся послушать теперь одну очень старую историю.

У одного незначительного видео сервиса, что торчал на севере Москвы, работал один мидл. И оставалось то ему работать
три дня и три ночи, до его первого года. Так уж вышло, что очень он любил кушать и обучился ремеслу на стороне.
Приписал себе опыт работы пару лишних лет. Очень уж хотел понравиться девушке Олесе из соседнего подъезда.

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

А в сервисе служил ещё один эффективный прапор. Гад редкий. Не понравилось ему как мидл общается с джунами в интернете.
И как-то ночью, когда мидл уснул, подкрался к нему директор направления с красным пожарным топором и уволил его.
Послал всем HRам личное дело с "волчьим билетом" в котором написано было, что погибла карьера парня -
упала ночью на топор и погибло его личное дело.

Прошло два года. Обгрызли HRки все ногти в поисках мидлов. А эффективный менеджер собрался на повышение. Собрали в общем корпоратив. Собрались все: и СТО пришёл и HR директор и дружки менеджеры направления.

И тут! Стук в дверь!

Выходит какой-то мужик в капюшоне и блюдо с крышкой несёт. Поставил на стол перед менеджерьём залётным. Те крышку открыли и видят - это чёрный волчий хвост с анальной пробкой.

- Ты кто?! - крикнул прапор незнакомцу.

А парень то наш капюшон откинул и глаза выпучил и как закричит - "Я ЧЁРНЫЙ МЕНТОР, ТВОЮ МАТЬ! Ха-ха-а!"

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

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

Так уж получилось, что я крайне везучий человек. Всё началось с кранча на работе. А потом мне повезло сломать в предплечье обе кости левой руки.

На площадке оказался врач, запретивший мне шевелить руку. Еще и мой ровесник оперативно вызвал скорую. Старший товарищ 20 минут следил чтобы я не потерял сознание до прибытия врачей. А молодой друг отвёз мои вещи домой и привез жену в больницу. Оказалось что меня ждет полостная операция.

В итоге я оказался в больничной палате. В которую привезли потрясающе мощного старика. В свои 92 года он был чудовищно похож на моего деда. Остроумный и непоколебимо живой. С переломом шейки бедра он стоически переносил всё и страшную новость о траве и равнодушие и косность персонала.

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

Мой организм невозможно сломать двумя порезами в половину руки. Поэтому когда спустя 2 часа после моей операции деда ввезли в палату и он при этом бодрым басом шутил над санитарками я сразу позвонил с его телефона и услышал новую эмоцию -
счастья и любви. Слова адресованные совсем не мне. Мне удалось доложить о состоянии супруга и когда его уложили в
постель передать ему трубку.

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

Мне повезло, что меня посетил руководитель (когда ещё дождешься от СТО ананас в подарок), а молодые товарищи устроят паломничество в больницу с ягодами и фруктами скрашивающими наш больничный быт. Узнать что они там расписали визиты по дням, чтобы поддержать меня и скрасить в итоге наш быт.

Вот только боевой дед под мою выписку (на вторые сутки после операции) начал кашлять и я обнаружил что в корпусе
московской больницы сданном (опять везение) только 2 недели назад разваливаются стеклопакеты. Я засавил сестер вызвать ремонтника и просил трижды врача обратить внимание на кашель и состояние человека который оставался с ними.

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

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

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

А вечером мне позвонила его неподражаемая супруга и рассказала о том что он умер из-за двухстороннего воспаления легких.Человек в кровать которого попала зажигательная бомба в осажденном Ленинграде был убит простым человеческим равнодушием. Ровно так же как и 25 лет назад мой дед. Участь и адмирала и рабочего из одной эпохи оказалась одинаковой.

Мне действительно повезло. Я остался жив. Вокруг оказалось неожиданно много молодых, энергичных людей с большими сердцами. Которым почему-то было не всё равно. Они и могучий старик вдохновили меня на небольшой трудовой подвиг - 30 сложных технически проблем за 1.5 недели. И именно понимание того, что эти люди всё же есть помогают пережить утрату И удивительная книга "Море моё" последний экземпляр которой остался у меня как память о том что случилось. Не знаю как вы сможете её найти, но если получится - прочитайте она стоит того.

#bookshelf

Карго культ - часть нашего общества. Так и System Design Interview - часть процесса современного найма. В пятницу я вернусь, еще к тому как вершатся судьбы дизайнов систем и архитектур с традиционной сказкой. А сегодня будем готовиться к лютому контенту по сурьёзу.

В конце прошлого года издательство "Питер" перевело книгу с легендарным названием "System Design пережить интервью".

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

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

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

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

Может для прохождения интервью в FAANG это и подходящее руководство. Но для российских реалий чрезмерное.

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

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

Как всегда в конце ссылочка на книгу: https://www.piter.com/collection/all/product/system-design-perezhit-intervyu
#bookshelf

Особенность найма в Großland'е суровы и непредсказуемые. С одной стороны всех заменит GroßIntellekt, с другой стороны
найм свежего мяса не прекращается. Стоит лишь диску этого чудесного мира повернуться и прямо на севере Großdorf'a
наблюдателю посчастливилось бы увидеть офис компании "InDeKont". Блеск дипломов сотрудников которой, когда-то, освещал
внутренние помещения по-чище, чем лампы прожектора.

Но так уж получилось, что со сменой СЕО изменилась и стратегия найма. Оказалось, что невомзожно поддерживать свою
внутреннюю разработку на технологиях 20 летней давности уже невозможно. И в связи с этим компания запустила карусель
найма. Однако владеет теперь компанией некий ХОЛДИНГ и посему совершенно невозможно предоставлять людям конкурентные
зарплаты. А кого тогда мы будем нанимать? Правильно - кого попало.

Цель нашего пациента заключалась в том, чтобы понять, как же компания собирается нанять больше 1000 го разработчиков
за неделю. Поэтому когда в чате к нему обратилась HR, отказаться решительным образом было не возможно. Тем более такая
честь поучаствовать в разработке того, чем будут пользоваться миллионы человек и триллионы блох.

Конечно же на первой фазе интервью было всё что нужно:

Замечательные задачи на то, что произойдет если мы будем пытаться мутировать иммутабельный слайс:

a := make([]int, 0, 5)
b := append(a, 1, 2, 3)
c := append(b, 4, 5)
a = append(a, 3, 2, 1)

fmt.Println(a)
fmt.Println(b)
fmt.Println(c)

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

Ну и венец - написать конечно же in memory cache. Задача безусловно достойная будущего тех лида, на позицию коего и
собеседовали нашу птаху. В какой-то момент времени, я аж включил ее в состав "примера"
(https://github.com/godepo/groat/blob/main/example/example.go#L32)к своей библиотеки для тестирования на го, чтобы
просто воспроизводить по памяти с надутыми щеками.

Самое кошмарное заключается не в том, что пройдя такое собеседование разработчик с улицы может стать техлидом или
сеньором. Самое дикое, что именно такие кеши они потом в продакшене и пишут. С мьютексом и маппой. ХОТЯ. Буквально за
15 минут до написания кеша их спрашивали про то как решается коллизия ключей в этой структуре данных.

Итогом первого собеседования стало понятно - цель это не сеньоры и техлиды. Цель найма это джуниоры с пятилетним
опытом. Но тем интереснее становился приз. Ведь за этот "WEEKEND OFFER", предлагался прекрасный приз - зарплата по
результатам собеседования и даже получение грейда и лычки в соответствии с ним. Казалось бы еще чуть-чуть - пара тройка
собеседований (а как без этого) и мы окажемся - в "InDeKont". Главной социальной сети всего Großland'a.

Ещё никогда наша птаха - так не ошибалась!

#grosstech #interviews

Некоторое время назад я перестал воспринимать собеседования и технические интервью в КРУПНЫХ компаниях как что-то существенное. Давайте разберем замечательную задачу про "кэш" которая встречается на каждом втором техническом скрининге.

Суть задачи бывает разной, но обычно, нам нужно написать кэш компонент. И если решать эту задачу правильно, те 10–20 минут, что на нее будет выделено. Не позволит её решить. Вот пример (https://habr.com/ru/companies/avito/articles/943336/) попытки — как команда независимых разработчиков, чтобы это не значило, пыталась решить её 9 месяцев.

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

type Cache[T] struct {
    data map[string]T
}

func (c *Cache) Get(key string) (T, bool)  {
   v, ok := c.data[key]
   return v, ok
}

func (c *Cache) Set(key string, v T) {
    c.data[key] = v 
}

Тут с многозначительным выражением лица надо вперёд коварного интервьюера сказать — "но такой кэш будет приводить" к суровой проблеме — гонке данных при попытке записи!

type Cache[T] struct {
    data map[string]T
    lock *sync.RWMutex
}

И всё! Вы - победитель соревнования умственно отсталых — способность добавить сюда RWMutex демонстрирует то, что вы прекрасно разбираетесь... В чём? В том, что надо рассказать, что при взятии мьютекса обязательно надо сделать — defer!

unc (c *Cache) Get(key string) (T, bool)  {
    c.lock.RLock()
    defer c.lock.RUnlock()
...

func (c *Cache) Set(key string, v T) {
    c.lock.Lock()
    defer c.lock.Unlock()
...

На этом вся задача в целом обычно заканчивается и появляются "ЗВЕЗДОЧКИ". Например, сбрасывать кэш по расписанию (запустить гороутину и по таймеру в цикле создавать новый мап и заменять им тот, что внутри не забыв про select с остановкой, как во вчерашнем примере).

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

Потом у нас на тысячах РПС вся система упирается в единственный мьютекс такого кэша и получается бутылочное очко для трафика. Причем о том, как преодолеть эту проблему спрашивают в 2-5% интервью в большие компании. Даже при собеседовании на вакансии стафф/техлида. Ну потому что… Зачем?

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

func (c *Cache) loop(ctx context.Context, updater func() map[string]T, error) {
     for {
    select {
    case <-srv.ctx.Done():
      return
    case <-srv.ticker.C:
      result, err := updater()

      srv.ticker.Reset(srv.cfg.TTL)

      if err != nil {
          continue
      }
      
      c.data = result
    }
  }
}

Но что особенно иронично. В подавляющем количество реализаций такого кэша с обновлением по расписанию — будет висеть мьютекс. Он будет просто тратить процессорное время там, где гонки НИКОГДА НЕ СЛУЧАТСЯ. А нужен он там, потому что карго культ с интервью или выветривается (и люди просто пишут код с гонками данных, т.к. никогда и не умели писать конкурентный код) или просто не способны думать своей головой.

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

#interviews #stupidcache

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

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

Однако жизнь такова, что некоторые вещи и запросы требуют быстрого и близкого к моментальному времени ответа. Что делать
в таком случае? Ну представьте себе, такую задачу, вы хотите определить пользователя, который произвел платежей в системе
на 10000$ и перевести его на новый тарифный план и сообщить об этом письмо. Причем платежи мультивалютные и поставщик
валюты шлёт вам поток данных по изменениям курсов валют.

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

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

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

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

https://www.piter.com/collection/all/product/potokovye-bazy-dannyh

#bookshelf

Каждый день и в каждом утюге идёт рассуждение о AI. О том как он всех заменит, о будущем и о том как в это будущее попадёт только некоторая элита. Однако для того, чтобы понять всё это нужно сделать очень большой шаг в прошлое и затаить дыхание стоя на той самой скале возле реки Großflüss, где первый Großmensch рисовал первую программу, иллюстрирующую прыжок стада антилоп в обрыв.

Gemini в поисковой выдаче гугла утверждает, что "около 80-85 процентов населения мира относят себя к верующим или
религиозным людям. Если вдуматься, то подавляющее большинство людей верят в то, что горящий куст определил
какой народ будет избранным. И так уже ориентировочно на протяжении около 4 тысяч лет. Когда горящий куст заговорил
второй раз, образовался арабский халифат.

Ну и простая экстраполяция говорит нам очень важную вещь — теперь эти 85 процентов людей на планете подвержены общению с действительно говорящим горящим кустом.

Мышление человека, в целом крайне ритуализованно. Давайте посмотрим примеры из нашей профессии.

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

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

Всё это важно, т.к. наш комфорт определяет в целом порядок и структурированность мира вокруг. Поэтому мы создаем ритуал.Религиозные практики, медитации. Вместо создания реальных ценностей, в критической ситуации. Человечество
более 5 тысяч лет молилось высшим силам, которые должны решить свои проблемы. А AI создает ощущение, что бог теперь
еще и отвечает и решает эти самые проблемы.

Иронично то, что количество параметров у GPT5 от 3 до 5 триллионов. В сравнении у человека число синапсов в мозгу от
100 до 600 триллионов. Вы бы доверили свои жизни и будущее цивилизации своему 95 летнему деду, Альцгеймер которого не позволяет ему вас узнавать и отличить унитаз, от вашей чашки для кофе?

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

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

Однако он не заменяет и не заменит никогда квалифицированного и обученного инженера. Просто таких примерно 15%,
а все остальные красят кнопки, ходят на стендапы и переименовывают сервисы.

Для тех, кто сомневается. Разница между квалифицированным инженером и всеми остальными составляет ровно порядок. Даже когда те используют AI. Для того чтобы AI приносил пользу вместо хотя бы джунов. Нужно, чтобы инженер писал LLD
документы и верифицировал результат. Совершенно не важно, будешь ли ты писать инструкции для компилятора или
для транслятора (в виде claude). Кроме одного факта — разница просто увеличится. Между квалифицированным и "разработчиком" из бигтеха.

#ai #future

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

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

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

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

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

#teambuilding

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

Так я и попал на видео Олега Козырева. Я несколько раз пролистывал ленту дальше, предпочитая поезд с физиком и астрономом. Но в конечном итоге любопытство взяло вверх. Ведь снимает его не просто кто-то там. А стафф инженер из Т-Банка (ex Ozon, ex Avito). Человек, проработавший много где и занимающийся менторством разработчиков и автор своего собственного курса по микросервисам на го.

Примерно 6 последних лет я выслушиваю всевозможные смешные мнения о том, как ужасен uber/fx. От людей которые не имеют публичного веса и не занимаются опен сорсом. А тут такая возможность. Видео я слушал, паралельно занимаясь исследованием Rust. И тут мое ухо зацепилось за фразу: "Uber/FX не может работать с зависимостями, если интерфейс расположен так, как принято в Go, по месту использования". Я посмотрел в код в ролике и увидел вот это:

// В Fx нельзя просто написать fx.As(new(A), new(B), new(C)).
    // Если один провайдер возвращает конкретный тип, а его нужно
    // подать как РАЗНЫЕ интерфейсы в разные потребители — нужно
    // писать специальные структуры-адаптеры с fx.Out.
    //
    // Либо — провайдить конкретный тип + отдельные provide-обёртки
    // для каждого интерфейса. Оба варианта — бойлерплейт.
    //
    // Мы используем fx.Out структуры — каноничный подход Fx.

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

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

Ну что же у нас с несчастным и всем поруганном fx на самом деле - узнаем в следующем тексте.

#staffengineering #leak-base #ликбез

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

Даже комментарий не правильны т.к написать fx.As(new(A), new(B)) можно. Это будет аннтоировать позиции возвращаемых
провайдер функцией результаты (об этом написать в code docs к функции). И тогда каждый возвращаемый позиционный элемент будет считаться имплементирующим каждый соответствующий ему в позиции аргумент.

Однако если бы у стафф инженера был минимальный опыт работы с DI контейнерами не написанными им самим и он вообще интересовался этим, он знал бы слово "аннотация", ну или как минимум проследовал бы по quick start к библиотеке.

Дело в том, что в целом при разрешении зависимостей не достаточно имплементировать интерфейc. В компонентной среде могут быть десятки РАЗНЫХ имплементаций и в каком порядке и где их разрешать, в языках где есть компилятор
(не его подобие как в го), как раз и используется аннотации. И у fx они есть, т.к это DSL, в замен отсутствующего
инструментария в языке.

Вместо того чтобы использовать fx.Out (который нужен совсем не для этого), нужно использовать fx.Annotate:

fx.Provide(
    fx.Annotate(
        func(ctx context.Context) (*pgxpool.Pool, error) {
            return pgxpool.New(ctx, "postgres://postgres:postgres@localhost:5432/catofoleg?sslmode=disable")
        },
        fx.As(new(users.DB)),
        fx.As(new(payments.DB)),
    ),
),

Т.к. функция принимает variadic аргументы типа аннотаций - каждая As (которая тоже аннотация кстати) детализирует
результат конструктора и по итогу, все что требовалось сделать staff engineer - уметь пользовться паттерном functional
options, который вроде "базовый" для го.

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

И он на прекрасном русском языке мне посоветовал реализовать два антипаттерна по работе с fx, в которые мсье и пошел. Но в конце - предложил верное решение тоже.

В резюме к видео, стафф инженер сказал, что дескать польза от fx только в том, что он умеет дескать делать
graceful shutdown. Но в следующем коде к своему мешку бойлерплейта он его реализует и fx точно будет не нужен!

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

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

Мораль такова. Титул senior инженер мы уже испортили. Теперь туда же отправляется и Staff. От ментора и автора курса можно ждать было чего-то большего, нежели исполнения в стиле: "не разобрался и сделал так как мне удобно". Слышал, что это уровень джунов.

#staffengineering #leak-base #ликбез

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

Каждый раз, когда я касаюсь произведений, я надеюсь ошибится в своих - крайне низких ожиданиях от го разработчиков и
идей и концепций которые они могут презентовать и воплотить. И в этот раз, Юлии Поповой в книге
"Go: разработка приложений в микросервисной архитектуре с нуля" удалось снова оправдать мои ожидания.

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

Здесь все любимые идеи - бесконечные полотна текста в main функциях. Сервисы которые способны запуститься целиком
исключительно в виде собранного бинарного файла. Анти патерны с управлениям транзакциями и нарушением смыслового назначения паттерна "Repository" (вот у человечества это один смысл умеет и у Фаулера и у Эванса, а у гоферов - другой).

Качеству кода посвящено. Два абзаца и это называется Code Style. Впервые в истории любой экосистемы не упомянут линтер пак. Действительно. Статический анализ кода и управление стилем кода благодаря этому, не достойная тема для разработки микросервисов с нуля. Разговаривая о кафке, берем самую уродливую и загаженную проблемами библиотеку.

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

Книга пропускает все лучшее, что есть в го - fx, контекстное логгирование, темпорал, ватермилл, sqlc, golangci. Зато воспевает создание лапши.

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


Зачем она читателю - решительным образом нет: https://bhv.ru/product/go-razrabotka-prilozhenij-v-mikroservisnoj-arhitekture-s-nulya

#bookshelf