На работе смотрим онлайн трансляцию Golang Conf. Ключевой вопрос, который мучает меня уже половину потраченного времени это ЦА этого мероприятия. Залы полупустые, контент докладов с форматом в 30/40 минут это примитивные обзоры достойные места где-нибудь на habor'e, а не на профессиональной конференции.
Большая часть кода, что я видел, состоит из примеров на Си. Для меня сие не является проблемой, т.к. я писал и читал код на этом языке и понимаю проблематику которую озвучивает автор доклада, но непонтяно как всё это связано с языком "Go". Да и зачем нужно программистам на го, которые нынче просто замена Java code monkey.
Из непосмотренного и ожидаемого доклада остался только материал от "Островка" про то как матчить отели с самописной in-memory базой данных. Исключительно из любви к компании где работал дам шанс и поболею за то, чтобы не было как то, что уже видел.
Особый шарм, это рассказывать о том, что Николай Тузов куда лучше расскажет на своём канале, когда решится. Ну или то, о чём можно прочитать просто в документации или любом другом публичном месте
Хотите примеров? Ну вот доклад про Swiss Map, которому противостоит ролик от Олега Козырева на ютубе. Или чревовещание от Даниила Подольского на тему дженериков - получилось и не о дженеирках и с низкой дидактической ценностью. О да, я знаю, что движующим обоснованием этой секции является термин "как устроено под капотом". Но при этом крайне вторично и учитывая прятанье это за пейволом - ещё и бесполезно.
Напомню, что стоимость билет доползла (по слухам) до 40 тысяч рублей, а образовательная и профессиональная ценность выступлений околонулевая.
Учитывая, что организаторы как говорящие головы утверждают, что уровень программиста вырастет от посещения этой клоун-фиесты хочется задать вопрос "а за счёт чего?". Ведь чтение любой книги или хорошей статьи на каждую из этих тем - куда полезнее (и что важно - дешевле), нежели этот нетворкинг для умственно отсталых.
#golangConf2025
Большая часть кода, что я видел, состоит из примеров на Си. Для меня сие не является проблемой, т.к. я писал и читал код на этом языке и понимаю проблематику которую озвучивает автор доклада, но непонтяно как всё это связано с языком "Go". Да и зачем нужно программистам на го, которые нынче просто замена Java code monkey.
Из непосмотренного и ожидаемого доклада остался только материал от "Островка" про то как матчить отели с самописной in-memory базой данных. Исключительно из любви к компании где работал дам шанс и поболею за то, чтобы не было как то, что уже видел.
Особый шарм, это рассказывать о том, что Николай Тузов куда лучше расскажет на своём канале, когда решится. Ну или то, о чём можно прочитать просто в документации или любом другом публичном месте
Хотите примеров? Ну вот доклад про Swiss Map, которому противостоит ролик от Олега Козырева на ютубе. Или чревовещание от Даниила Подольского на тему дженериков - получилось и не о дженеирках и с низкой дидактической ценностью. О да, я знаю, что движующим обоснованием этой секции является термин "как устроено под капотом". Но при этом крайне вторично и учитывая прятанье это за пейволом - ещё и бесполезно.
Напомню, что стоимость билет доползла (по слухам) до 40 тысяч рублей, а образовательная и профессиональная ценность выступлений околонулевая.
Учитывая, что организаторы как говорящие головы утверждают, что уровень программиста вырастет от посещения этой клоун-фиесты хочется задать вопрос "а за счёт чего?". Ведь чтение любой книги или хорошей статьи на каждую из этих тем - куда полезнее (и что важно - дешевле), нежели этот нетворкинг для умственно отсталых.
#golangConf2025
😁8👍5🌭1💯1
Доклад Ивана Комберта, кстати, был неплох. Он даже полезен для тех, кто не занимался разработкой баз данных или не читал любой материал про внутреннее их устройство.
Это первый доклад у которого мы просмотрели Q/A секцию до конца и даже глянули награждение тем, кто задавал вопросы. И тут я был опять вознагражден за свое терпение. Как и в книге про софтскиллы я оказался вознаграждён неожиданным роялем в кустах.
Конферансье (слонового телосложения) сказал, что обожает профессиональные конференции, после чего попросил Ивана и награжденных подарками вопросозадавателей поднять правую руку вверх... и поклонится. Внезапно.
P.S: подскажу, что это можно назвать, например, китайским салютом.
#golangConf2025 #newsalute
Это первый доклад у которого мы просмотрели Q/A секцию до конца и даже глянули награждение тем, кто задавал вопросы. И тут я был опять вознагражден за свое терпение. Как и в книге про софтскиллы я оказался вознаграждён неожиданным роялем в кустах.
Конферансье (слонового телосложения) сказал, что обожает профессиональные конференции, после чего попросил Ивана и награжденных подарками вопросозадавателей поднять правую руку вверх... и поклонится. Внезапно.
P.S: подскажу, что это можно назвать, например, китайским салютом.
#golangConf2025 #newsalute
😁4❤1
Разработчики часто думают о том, как несправедлив к ним найм. Что вокруг одно легаси (хотя кто в этом виноват?),
неадекватные менеджеры и все стараются выманить их с удаленки в офис. Но ситуация, в которой оказывались люди
отзывающиеся на вакансию СТО Платформизации в 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
неадекватные менеджеры и все стараются выманить их с удаленки в офис. Но ситуация, в которой оказывались люди
отзывающиеся на вакансию СТО Платформизации в 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
🔥9👏5❤2😁1🌚1🌭1😭1😨1
Пташки рассказывают страшное, что искусственный интеллект действительно вышел на путь замещения кожанного мусора, настоящим профессионализмом.
А т.к. существует некоторый запрос, на контент и некоторые советы от старика (а 5 новых книг одновременно читаются как-то медленно), то запустим завтра новую рубрику "Метод деда", где буду показывать некоторые свои исследования и подходы к формированию дизайна и программированию.
А т.к. существует некоторый запрос, на контент и некоторые советы от старика (а 5 новых книг одновременно читаются как-то медленно), то запустим завтра новую рубрику "Метод деда", где буду показывать некоторые свои исследования и подходы к формированию дизайна и программированию.
❤13😁8👍6🌭1
Присаживайся сынок. Зря ты разбудил дедушку от его летаргического сна после работы. Придётся послушать теперь одну очень старую историю.
У одного незначительного видео сервиса, что торчал на севере Москвы, работал один мидл. И оставалось то ему работать
три дня и три ночи, до его первого года. Так уж вышло, что очень он любил кушать и обучился ремеслу на стороне.
Приписал себе опыт работы пару лишних лет. Очень уж хотел понравиться девушке Олесе из соседнего подъезда.
Дело у них шло на лад. Да и после года можно было бы уже ходить к HRам из других компаний и искать себе работу приятнее.Больно уж нищебродские зарплаты всегда были у видео сервиса.
А в сервисе служил ещё один эффективный прапор. Гад редкий. Не понравилось ему как мидл общается с джунами в интернете.
И как-то ночью, когда мидл уснул, подкрался к нему директор направления с красным пожарным топором и уволил его.
Послал всем HRам личное дело с "волчьим билетом" в котором написано было, что погибла карьера парня -
упала ночью на топор и погибло его личное дело.
Прошло два года. Обгрызли HRки все ногти в поисках мидлов. А эффективный менеджер собрался на повышение. Собрали в общем корпоратив. Собрались все: и СТО пришёл и HR директор и дружки менеджеры направления.
И тут! Стук в дверь!
Выходит какой-то мужик в капюшоне и блюдо с крышкой несёт. Поставил на стол перед менеджерьём залётным. Те крышку открыли и видят - это чёрный волчий хвост с анальной пробкой.
- Ты кто?! - крикнул прапор незнакомцу.
А парень то наш капюшон откинул и глаза выпучил и как закричит - "Я ЧЁРНЫЙ МЕНТОР, ТВОЮ МАТЬ! Ха-ха-а!"
Тут свет погас, а когда его включили вокруг менеджерья стояли их сеньор и мидл разработчики - всё в волчьих плащах
как из игры престолов, а прапор на столе лежал в юбке и пробкой вставленной в анус.
И с тех пор Чёрный ментор ходит по свету, ищёт новые контракты и менти и нет его черной волчьей душе покоя.
У одного незначительного видео сервиса, что торчал на севере Москвы, работал один мидл. И оставалось то ему работать
три дня и три ночи, до его первого года. Так уж вышло, что очень он любил кушать и обучился ремеслу на стороне.
Приписал себе опыт работы пару лишних лет. Очень уж хотел понравиться девушке Олесе из соседнего подъезда.
Дело у них шло на лад. Да и после года можно было бы уже ходить к HRам из других компаний и искать себе работу приятнее.Больно уж нищебродские зарплаты всегда были у видео сервиса.
А в сервисе служил ещё один эффективный прапор. Гад редкий. Не понравилось ему как мидл общается с джунами в интернете.
И как-то ночью, когда мидл уснул, подкрался к нему директор направления с красным пожарным топором и уволил его.
Послал всем HRам личное дело с "волчьим билетом" в котором написано было, что погибла карьера парня -
упала ночью на топор и погибло его личное дело.
Прошло два года. Обгрызли HRки все ногти в поисках мидлов. А эффективный менеджер собрался на повышение. Собрали в общем корпоратив. Собрались все: и СТО пришёл и HR директор и дружки менеджеры направления.
И тут! Стук в дверь!
Выходит какой-то мужик в капюшоне и блюдо с крышкой несёт. Поставил на стол перед менеджерьём залётным. Те крышку открыли и видят - это чёрный волчий хвост с анальной пробкой.
- Ты кто?! - крикнул прапор незнакомцу.
А парень то наш капюшон откинул и глаза выпучил и как закричит - "Я ЧЁРНЫЙ МЕНТОР, ТВОЮ МАТЬ! Ха-ха-а!"
Тут свет погас, а когда его включили вокруг менеджерья стояли их сеньор и мидл разработчики - всё в волчьих плащах
как из игры престолов, а прапор на столе лежал в юбке и пробкой вставленной в анус.
И с тех пор Чёрный ментор ходит по свету, ищёт новые контракты и менти и нет его черной волчьей душе покоя.
😁33❤4👌3💅3👍2🤡1🌭1
Так уж получилось, что я крайне везучий человек. Всё началось с кранча на работе. А потом мне повезло сломать в предплечье обе кости левой руки.
На площадке оказался врач, запретивший мне шевелить руку. Еще и мой ровесник оперативно вызвал скорую. Старший товарищ 20 минут следил чтобы я не потерял сознание до прибытия врачей. А молодой друг отвёз мои вещи домой и привез жену в больницу. Оказалось что меня ждет полостная операция.
В итоге я оказался в больничной палате. В которую привезли потрясающе мощного старика. В свои 92 года он был чудовищно похож на моего деда. Остроумный и непоколебимо живой. С переломом шейки бедра он стоически переносил всё и страшную новость о траве и равнодушие и косность персонала.
А когда его увезли на операцию, спустя сутки ожил его телефон и в нем мне повезло услышать неподдельные чувства боли, сопереживания и любви. Супруга прожившая с ним 68 лет билась в тревоге и тоске без вестей.
Мой организм невозможно сломать двумя порезами в половину руки. Поэтому когда спустя 2 часа после моей операции деда ввезли в палату и он при этом бодрым басом шутил над санитарками я сразу позвонил с его телефона и услышал новую эмоцию -
счастья и любви. Слова адресованные совсем не мне. Мне удалось доложить о состоянии супруга и когда его уложили в
постель передать ему трубку.
А чуть позже я узнал, что мне и правда повезло оказаться в одной палате с действительно удивительным человеком -
вице-адмиралом Кузьминым Анатолием Алексеевичем. А еще мне повезло, что я спросил о том, не приходило ли ему в голову написать книгу. А потом ещё и мне повезло вступить в гонку за последнюю книгу в продаже и получить ее в итоге в подарок от коллеги купившего её раньше меня.
Мне повезло, что меня посетил руководитель (когда ещё дождешься от СТО ананас в подарок), а молодые товарищи устроят паломничество в больницу с ягодами и фруктами скрашивающими наш больничный быт. Узнать что они там расписали визиты по дням, чтобы поддержать меня и скрасить в итоге наш быт.
Вот только боевой дед под мою выписку (на вторые сутки после операции) начал кашлять и я обнаружил что в корпусе
московской больницы сданном (опять везение) только 2 недели назад разваливаются стеклопакеты. Я засавил сестер вызвать ремонтника и просил трижды врача обратить внимание на кашель и состояние человека который оставался с ними.
Дед боялся остаться без связи с супругой и о я отлично слышал почему. Перед выпиской я попросил друзей помочь. А спустя пару дней начав крестовый поход против нулевой эмпатии городской медицины (которая собиралась
видимо подарить мне пост операционный сепсис) я вернулся и привез ему бамбуковый столик, чтобы он мог есть и не пачкать белье.
Я несколько раз звонил просил его обращаться с любой просьбой. Ясно было что персоналу не до него. Дела погребли меня.
Читая его книгу по дорогу на работу я в каждой строке слышал его голос. Словно он говорит со мной о свой мечте и призвании - своём море, а на словах о знакомстве с его супругой я умудрился прослезиться прямо в вагоне метро. Вспоминая о визите его сына и его рассказах о своем отце я погрузился в ворох обычных проблем.
А вечером мне позвонила его неподражаемая супруга и рассказала о том что он умер из-за двухстороннего воспаления легких.Человек в кровать которого попала зажигательная бомба в осажденном Ленинграде был убит простым человеческим равнодушием. Ровно так же как и 25 лет назад мой дед. Участь и адмирала и рабочего из одной эпохи оказалась одинаковой.
Мне действительно повезло. Я остался жив. Вокруг оказалось неожиданно много молодых, энергичных людей с большими сердцами. Которым почему-то было не всё равно. Они и могучий старик вдохновили меня на небольшой трудовой подвиг - 30 сложных технически проблем за 1.5 недели. И именно понимание того, что эти люди всё же есть помогают пережить утрату И удивительная книга "Море моё" последний экземпляр которой остался у меня как память о том что случилось. Не знаю как вы сможете её найти, но если получится - прочитайте она стоит того.
#bookshelf
На площадке оказался врач, запретивший мне шевелить руку. Еще и мой ровесник оперативно вызвал скорую. Старший товарищ 20 минут следил чтобы я не потерял сознание до прибытия врачей. А молодой друг отвёз мои вещи домой и привез жену в больницу. Оказалось что меня ждет полостная операция.
В итоге я оказался в больничной палате. В которую привезли потрясающе мощного старика. В свои 92 года он был чудовищно похож на моего деда. Остроумный и непоколебимо живой. С переломом шейки бедра он стоически переносил всё и страшную новость о траве и равнодушие и косность персонала.
А когда его увезли на операцию, спустя сутки ожил его телефон и в нем мне повезло услышать неподдельные чувства боли, сопереживания и любви. Супруга прожившая с ним 68 лет билась в тревоге и тоске без вестей.
Мой организм невозможно сломать двумя порезами в половину руки. Поэтому когда спустя 2 часа после моей операции деда ввезли в палату и он при этом бодрым басом шутил над санитарками я сразу позвонил с его телефона и услышал новую эмоцию -
счастья и любви. Слова адресованные совсем не мне. Мне удалось доложить о состоянии супруга и когда его уложили в
постель передать ему трубку.
А чуть позже я узнал, что мне и правда повезло оказаться в одной палате с действительно удивительным человеком -
вице-адмиралом Кузьминым Анатолием Алексеевичем. А еще мне повезло, что я спросил о том, не приходило ли ему в голову написать книгу. А потом ещё и мне повезло вступить в гонку за последнюю книгу в продаже и получить ее в итоге в подарок от коллеги купившего её раньше меня.
Мне повезло, что меня посетил руководитель (когда ещё дождешься от СТО ананас в подарок), а молодые товарищи устроят паломничество в больницу с ягодами и фруктами скрашивающими наш больничный быт. Узнать что они там расписали визиты по дням, чтобы поддержать меня и скрасить в итоге наш быт.
Вот только боевой дед под мою выписку (на вторые сутки после операции) начал кашлять и я обнаружил что в корпусе
московской больницы сданном (опять везение) только 2 недели назад разваливаются стеклопакеты. Я засавил сестер вызвать ремонтника и просил трижды врача обратить внимание на кашель и состояние человека который оставался с ними.
Дед боялся остаться без связи с супругой и о я отлично слышал почему. Перед выпиской я попросил друзей помочь. А спустя пару дней начав крестовый поход против нулевой эмпатии городской медицины (которая собиралась
видимо подарить мне пост операционный сепсис) я вернулся и привез ему бамбуковый столик, чтобы он мог есть и не пачкать белье.
Я несколько раз звонил просил его обращаться с любой просьбой. Ясно было что персоналу не до него. Дела погребли меня.
Читая его книгу по дорогу на работу я в каждой строке слышал его голос. Словно он говорит со мной о свой мечте и призвании - своём море, а на словах о знакомстве с его супругой я умудрился прослезиться прямо в вагоне метро. Вспоминая о визите его сына и его рассказах о своем отце я погрузился в ворох обычных проблем.
А вечером мне позвонила его неподражаемая супруга и рассказала о том что он умер из-за двухстороннего воспаления легких.Человек в кровать которого попала зажигательная бомба в осажденном Ленинграде был убит простым человеческим равнодушием. Ровно так же как и 25 лет назад мой дед. Участь и адмирала и рабочего из одной эпохи оказалась одинаковой.
Мне действительно повезло. Я остался жив. Вокруг оказалось неожиданно много молодых, энергичных людей с большими сердцами. Которым почему-то было не всё равно. Они и могучий старик вдохновили меня на небольшой трудовой подвиг - 30 сложных технически проблем за 1.5 недели. И именно понимание того, что эти люди всё же есть помогают пережить утрату И удивительная книга "Море моё" последний экземпляр которой остался у меня как память о том что случилось. Не знаю как вы сможете её найти, но если получится - прочитайте она стоит того.
#bookshelf
😢38❤🔥20😭7❤4🤔3😨2🤬1💔1
Карго культ - часть нашего общества. Так и System Design Interview - часть процесса современного найма. В пятницу я вернусь, еще к тому как вершатся судьбы дизайнов систем и архитектур с традиционной сказкой. А сегодня будем готовиться к лютому контенту по сурьёзу.
В конце прошлого года издательство "Питер" перевело книгу с легендарным названием "System Design пережить интервью".
В этот момент я готовился пройти очередной этап в 4 месячном раунде собеседований в одну из компаний (о чем тоже стоит написать отдельно, жаль сломанная рука мешала) и посчитал смешным взять эту книгу прочитать её за неделю до собеседований.
Однако оказалось это не так просто. Пережить саму книгу оказалось тяжело. В действительности, я бы не сравнивал её с
предшественниками. Несмотря на скупой, трудно читаемый и обзорный текст, она содержит большое количество референсных ссылок на другие книги, статьи, выступления и даже научные работы. Поэтому при желании изучить какую-то из разбираемых проблем подробнее, она может стать хорошим справочником и каталогом для поиска материала.
Это особенно полезно для людей, которые сталкиваются с проектированием в первые в жизни. Если поставить себе цель не
пережить раунд тухлого интервью в российском бигтехе, а научится действительно мыслить системно и размышлять не о
"проектировании микросервисов", а о дизайне систем - то это прекрасная отправная точка.
Да в книге всё в целом по вершкам и обзорно. Без деталей. Однако зато можно будет разобраться во всех проблемах
современных веб-сервисов. От устройства сетей, до устройства дата платформ. В некотором смысле, эта книга как
научный журнал, статьи которого цитируют другие книги и материалы. Для человека понимающего глоссарий книги, нет смысла отвлекаться на эти темы, но даже для себя удалось найти интересные мысли и сноски.
Может для прохождения интервью в FAANG это и подходящее руководство. Но для российских реалий чрезмерное.
Однако же быть умнее чем требуется не так плохо - хотя бы смешно наблюдать за происходящим безумием на архитектурных комитетах. Главное не умрите от духоты языка автора. Пережить книгу само по себе будет достижением.
Ну и хоть в кулуарах и обвиняют меня, что я рекламирую издательство "Питер", жаль шо мне не платят.
Как всегда в конце ссылочка на книгу: https://www.piter.com/collection/all/product/system-design-perezhit-intervyu
#bookshelf
В конце прошлого года издательство "Питер" перевело книгу с легендарным названием "System Design пережить интервью".
В этот момент я готовился пройти очередной этап в 4 месячном раунде собеседований в одну из компаний (о чем тоже стоит написать отдельно, жаль сломанная рука мешала) и посчитал смешным взять эту книгу прочитать её за неделю до собеседований.
Однако оказалось это не так просто. Пережить саму книгу оказалось тяжело. В действительности, я бы не сравнивал её с
предшественниками. Несмотря на скупой, трудно читаемый и обзорный текст, она содержит большое количество референсных ссылок на другие книги, статьи, выступления и даже научные работы. Поэтому при желании изучить какую-то из разбираемых проблем подробнее, она может стать хорошим справочником и каталогом для поиска материала.
Это особенно полезно для людей, которые сталкиваются с проектированием в первые в жизни. Если поставить себе цель не
пережить раунд тухлого интервью в российском бигтехе, а научится действительно мыслить системно и размышлять не о
"проектировании микросервисов", а о дизайне систем - то это прекрасная отправная точка.
Да в книге всё в целом по вершкам и обзорно. Без деталей. Однако зато можно будет разобраться во всех проблемах
современных веб-сервисов. От устройства сетей, до устройства дата платформ. В некотором смысле, эта книга как
научный журнал, статьи которого цитируют другие книги и материалы. Для человека понимающего глоссарий книги, нет смысла отвлекаться на эти темы, но даже для себя удалось найти интересные мысли и сноски.
Может для прохождения интервью в FAANG это и подходящее руководство. Но для российских реалий чрезмерное.
Однако же быть умнее чем требуется не так плохо - хотя бы смешно наблюдать за происходящим безумием на архитектурных комитетах. Главное не умрите от духоты языка автора. Пережить книгу само по себе будет достижением.
Ну и хоть в кулуарах и обвиняют меня, что я рекламирую издательство "Питер", жаль шо мне не платят.
Как всегда в конце ссылочка на книгу: https://www.piter.com/collection/all/product/system-design-perezhit-intervyu
#bookshelf
🔥11❤6👍6
Особенность найма в Großland'е суровы и непредсказуемые. С одной стороны всех заменит GroßIntellekt, с другой стороны
найм свежего мяса не прекращается. Стоит лишь диску этого чудесного мира повернуться и прямо на севере Großdorf'a
наблюдателю посчастливилось бы увидеть офис компании "InDeKont". Блеск дипломов сотрудников которой, когда-то, освещал
внутренние помещения по-чище, чем лампы прожектора.
Но так уж получилось, что со сменой СЕО изменилась и стратегия найма. Оказалось, что невомзожно поддерживать свою
внутреннюю разработку на технологиях 20 летней давности уже невозможно. И в связи с этим компания запустила карусель
найма. Однако владеет теперь компанией некий ХОЛДИНГ и посему совершенно невозможно предоставлять людям конкурентные
зарплаты. А кого тогда мы будем нанимать? Правильно - кого попало.
Цель нашего пациента заключалась в том, чтобы понять, как же компания собирается нанять больше 1000 го разработчиков
за неделю. Поэтому когда в чате к нему обратилась HR, отказаться решительным образом было не возможно. Тем более такая
честь поучаствовать в разработке того, чем будут пользоваться миллионы человек и триллионы блох.
Конечно же на первой фазе интервью было всё что нужно:
Замечательные задачи на то, что произойдет если мы будем пытаться мутировать иммутабельный слайс:
Несмотря на поиск десять лет подряд ответ на смысл этой задачи, он не обнаружился и в этот раз. Не обойтись никак, без
сердечно привлекательных попыток выяснить, о том что такое сложность алгоритма (птаха честно признается, что до сих
пор четко не может сформулировать определение, но судя по всему интервьюеры и сами уже не знают).
Ну и венец - написать конечно же in memory cache. Задача безусловно достойная будущего тех лида, на позицию коего и
собеседовали нашу птаху. В какой-то момент времени, я аж включил ее в состав "примера"
(https://github.com/godepo/groat/blob/main/example/example.go#L32)к своей библиотеки для тестирования на го, чтобы
просто воспроизводить по памяти с надутыми щеками.
Самое кошмарное заключается не в том, что пройдя такое собеседование разработчик с улицы может стать техлидом или
сеньором. Самое дикое, что именно такие кеши они потом в продакшене и пишут. С мьютексом и маппой. ХОТЯ. Буквально за
15 минут до написания кеша их спрашивали про то как решается коллизия ключей в этой структуре данных.
Итогом первого собеседования стало понятно - цель это не сеньоры и техлиды. Цель найма это джуниоры с пятилетним
опытом. Но тем интереснее становился приз. Ведь за этот "WEEKEND OFFER", предлагался прекрасный приз - зарплата по
результатам собеседования и даже получение грейда и лычки в соответствии с ним. Казалось бы еще чуть-чуть - пара тройка
собеседований (а как без этого) и мы окажемся - в "InDeKont". Главной социальной сети всего Großland'a.
Ещё никогда наша птаха - так не ошибалась!
#grosstech #interviews
найм свежего мяса не прекращается. Стоит лишь диску этого чудесного мира повернуться и прямо на севере 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
GitHub
groat/example/example.go at main · godepo/groat
Groat is lightweight tookit for creation articulated declarative tests - godepo/groat
😁7👍4❤3👏1🌭1
Некоторое время назад я перестал воспринимать собеседования и технические интервью в КРУПНЫХ компаниях как что-то существенное. Давайте разберем замечательную задачу про "кэш" которая встречается на каждом втором техническом скрининге.
Суть задачи бывает разной, но обычно, нам нужно написать кэш компонент. И если решать эту задачу правильно, те 10–20 минут, что на нее будет выделено. Не позволит её решить. Вот пример (https://habr.com/ru/companies/avito/articles/943336/) попытки — как команда независимых разработчиков, чтобы это не значило, пыталась решить её 9 месяцев.
Причём, скорее всего, на интервью от вас ожидают способность решать возникающие проблемы. Ну вот и пойдем по дорожке из коричневого кирпича:
Тут с многозначительным выражением лица надо вперёд коварного интервьюера сказать — "но такой кэш будет приводить" к суровой проблеме — гонке данных при попытке записи!
И всё! Вы - победитель соревнования умственно отсталых — способность добавить сюда RWMutex демонстрирует то, что вы прекрасно разбираетесь... В чём? В том, что надо рассказать, что при взятии мьютекса обязательно надо сделать — defer!
На этом вся задача в целом обычно заканчивается и появляются "ЗВЕЗДОЧКИ". Например, сбрасывать кэш по расписанию (запустить гороутину и по таймеру в цикле создавать новый мап и заменять им тот, что внутри не забыв про select с остановкой, как во вчерашнем примере).
А теперь в чем беда. В том, что потом в продкашене на сотни тысяч или даже десятки миллионов ключей эта реализация "кэша"с умным видом лежит в продуктовом коде. Или. Что ещё кошмарнее — в платформенном. Причём при наличии в платформе — запрещено бывает использовать, что-то кроме этого убожества. А в статье, что я привёл в начале, рассмотрено существенно больше проблем.
Потом у нас на тысячах РПС вся система упирается в единственный мьютекс такого кэша и получается бутылочное очко для трафика. Причем о том, как преодолеть эту проблему спрашивают в 2-5% интервью в большие компании. Даже при собеседовании на вакансии стафф/техлида. Ну потому что… Зачем?
Но и это не всё! Есть инварианты кэшей, когда например у нас нет записи. Только чтение. И в такой реализации - не нужен мьютекс никакой. Т.к. крутящаяся в расписании функция обновления кэша заменяет его целиком:
Но что особенно иронично. В подавляющем количество реализаций такого кэша с обновлением по расписанию — будет висеть мьютекс. Он будет просто тратить процессорное время там, где гонки НИКОГДА НЕ СЛУЧАТСЯ. А нужен он там, потому что карго культ с интервью или выветривается (и люди просто пишут код с гонками данных, т.к. никогда и не умели писать конкурентный код) или просто не способны думать своей головой.
И вот это, мои горячо любимые птахи, проблема мапки с мьютексом. Рожки торчат ото всюду, а нужна она бывает на самом деле - почти никогда.
#interviews #stupidcache
Суть задачи бывает разной, но обычно, нам нужно написать кэш компонент. И если решать эту задачу правильно, те 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
👍8👏5🌭2❤1💊1
Никогда не поздно узнавать что-то новое. Один мой руководитель, любил говаривать: "всё в мире
есть поток". Почти всё что происходит в окружении нас существует во времени. Все данные существуют
в движении. По-сути все данные одновременно и частица и волна.
Для большинства разработчиков данные - это частица. Исключительно вне времени и только в пространстве. Если просто
понаблюдать как разрабатываются в BigTech микросервисы, это становится очевидно. Волновая же их природа доступна
отдельной области инженерии - инженерам данных. Но даже они успокаивают потоки и превращают их в пакеты.
Однако жизнь такова, что некоторые вещи и запросы требуют быстрого и близкого к моментальному времени ответа. Что делать
в таком случае? Ну представьте себе, такую задачу, вы хотите определить пользователя, который произвел платежей в системе
на 10000$ и перевести его на новый тарифный план и сообщить об этом письмо. Причем платежи мультивалютные и поставщик
валюты шлёт вам поток данных по изменениям курсов валют.
Классически будет написан воркер который будет запускаться раз в день или в квант времени и находить таких пользователей.
А что если лояльность зависит от скорости? Как решить проблему нескольких потоков - платежи, курсы валют,
настройки тарифных планов? Как всё это быстро и эффективно согласовать.
И ответ на это даёт книга "Потоковые базы данных". Она в целом обрисует проблему целиком и покажет примеры решения
подобных задач. Книга написана доступным языком и содержит хорошие примеры. И является некоторым проспектом в будущее
в котором мы можем снижать задержки и обрабатывать данные в живую на потоке, а не на пакетах с крупными задержками. И
даже предложит решения. Вполне себе работоспособные и готовые к продуктивной среде сейчас.
В целом хоть она и нацелена на дата инженеров и архитекторов. Однако любознательному читателю всё равно будет полезно
расширить кругозор. Т.к. это позволит принимать правильные решения в ситуациях, когда это потребуется.
Ну кто издавал книгу, вы знаете и сами. Впрочем, уже следующая по-просьбам читателей, будет от другого издательства.
И сами виноваты.
https://www.piter.com/collection/all/product/potokovye-bazy-dannyh
#bookshelf
есть поток". Почти всё что происходит в окружении нас существует во времени. Все данные существуют
в движении. По-сути все данные одновременно и частица и волна.
Для большинства разработчиков данные - это частица. Исключительно вне времени и только в пространстве. Если просто
понаблюдать как разрабатываются в BigTech микросервисы, это становится очевидно. Волновая же их природа доступна
отдельной области инженерии - инженерам данных. Но даже они успокаивают потоки и превращают их в пакеты.
Однако жизнь такова, что некоторые вещи и запросы требуют быстрого и близкого к моментальному времени ответа. Что делать
в таком случае? Ну представьте себе, такую задачу, вы хотите определить пользователя, который произвел платежей в системе
на 10000$ и перевести его на новый тарифный план и сообщить об этом письмо. Причем платежи мультивалютные и поставщик
валюты шлёт вам поток данных по изменениям курсов валют.
Классически будет написан воркер который будет запускаться раз в день или в квант времени и находить таких пользователей.
А что если лояльность зависит от скорости? Как решить проблему нескольких потоков - платежи, курсы валют,
настройки тарифных планов? Как всё это быстро и эффективно согласовать.
И ответ на это даёт книга "Потоковые базы данных". Она в целом обрисует проблему целиком и покажет примеры решения
подобных задач. Книга написана доступным языком и содержит хорошие примеры. И является некоторым проспектом в будущее
в котором мы можем снижать задержки и обрабатывать данные в живую на потоке, а не на пакетах с крупными задержками. И
даже предложит решения. Вполне себе работоспособные и готовые к продуктивной среде сейчас.
В целом хоть она и нацелена на дата инженеров и архитекторов. Однако любознательному читателю всё равно будет полезно
расширить кругозор. Т.к. это позволит принимать правильные решения в ситуациях, когда это потребуется.
Ну кто издавал книгу, вы знаете и сами. Впрочем, уже следующая по-просьбам читателей, будет от другого издательства.
И сами виноваты.
https://www.piter.com/collection/all/product/potokovye-bazy-dannyh
#bookshelf
👍10✍4🌭2
Каждый день и в каждом утюге идёт рассуждение о 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
Gemini в поисковой выдаче гугла утверждает, что "около 80-85 процентов населения мира относят себя к верующим или
религиозным людям. Если вдуматься, то подавляющее большинство людей верят в то, что горящий куст определил
какой народ будет избранным. И так уже ориентировочно на протяжении около 4 тысяч лет. Когда горящий куст заговорил
второй раз, образовался арабский халифат.
Ну и простая экстраполяция говорит нам очень важную вещь — теперь эти 85 процентов людей на планете подвержены общению с действительно говорящим горящим кустом.
Мышление человека, в целом крайне ритуализованно. Давайте посмотрим примеры из нашей профессии.
Представьте, что у вас дедлайн. Вас назначают тимлидом в команду, в стартапе который терпит бедствие. Дедлайн
определяющий, он отделяет провал от успеха. Новый раунд финансирование, от сливания отличной технологии и работы десятков людей на кладбище мертвых проектов. Чем вы займетесь, имея небольшой беклог, содержащий некоторое количество белых пятен?
Настоящий тимлид - начнет налаживать процессы, несмотря на срок в месяц. Важно, как задачки будут двигаться
по доске. Важно будет ли в команде из 1 человека код-ревью от тимлида. Определяющим станет переименование всех сервисов (ровно для того, чтобы поменялось DNS в кубернетесе и все остальные микросервисы остальных команд пришлось передеплоить с новыми настройками роутинга к тем же сервисам).
Всё это важно, т.к. наш комфорт определяет в целом порядок и структурированность мира вокруг. Поэтому мы создаем ритуал.Религиозные практики, медитации. Вместо создания реальных ценностей, в критической ситуации. Человечество
более 5 тысяч лет молилось высшим силам, которые должны решить свои проблемы. А AI создает ощущение, что бог теперь
еще и отвечает и решает эти самые проблемы.
Иронично то, что количество параметров у GPT5 от 3 до 5 триллионов. В сравнении у человека число синапсов в мозгу от
100 до 600 триллионов. Вы бы доверили свои жизни и будущее цивилизации своему 95 летнему деду, Альцгеймер которого не позволяет ему вас узнавать и отличить унитаз, от вашей чашки для кофе?
Визионеры, словно апостолы горящих кустов, из каждого блога и статьи вещают о том, насколько важна технология, на
обучение которой было потрачено энергии больше, чем на обучение и воспитание более 50 тысячи человек. А вся ценность
этой технологии в несколько более удобном и чувствительном поиске, по некоторому объему данных.
И да я не критик и не агностик. У AI есть то, что позволяет решать с ним многие вещи. Это приличный линтер,
хороший баг хантер. Его можно использовать как джуниор консультанта там, где не хватает собственной экспертизы.
Однако он не заменяет и не заменит никогда квалифицированного и обученного инженера. Просто таких примерно 15%,
а все остальные красят кнопки, ходят на стендапы и переименовывают сервисы.
Для тех, кто сомневается. Разница между квалифицированным инженером и всеми остальными составляет ровно порядок. Даже когда те используют AI. Для того чтобы AI приносил пользу вместо хотя бы джунов. Нужно, чтобы инженер писал LLD
документы и верифицировал результат. Совершенно не важно, будешь ли ты писать инструкции для компилятора или
для транслятора (в виде claude). Кроме одного факта — разница просто увеличится. Между квалифицированным и "разработчиком" из бигтеха.
#ai #future
👍13🔥2🤡2
В современном сообществе "разработки" не приветствуется токсичность. Нельзя выражать свое мнение, оскорблять чьи-то
чувства и высказываться о проблемах прямо, а не на серии душных и не искренних one-to-one. Нужно быть толерантным, не поднимать острых тем и нельзя заботиться о успехе предприятия больше, чем о спокойствии твоего менеджера. Если ты доставил неприятности любому из менеджеров - тебя уволят. Правда, если менеджер будет о тебя вытирать ноги, это
допустимо.
Вчера отмечал с коллегами на работе первый год отработанный вместе с ними. И пожалуй самым ценным стал их неожиданно ненужный и бесполезный подарок. Целый монумент иронии и сарказма. На протяжении год, "детишки" собирались вокруг и слушали токсичные речи о "умственно отсталых кодерках" и прочие пространные велиричиво-графоманские телеги, в моем
исполнении.
Поэтому подарок от коллектива единомышленников оказался под стать. Кресло качалка, в котором можно укутаться в плед и травить байки стайке детсадовцев. Мне крайне понравилось, буду его таскать теперь на душные миты, на которых часами ничего толкового не решается.
Хороший коллектив это тот, в котором люди компенсируют недостатки друг-друга. Не бояться говорить друг с другом и
умеют искренне посмеяться над самими собой и окружающими. Коллектив с хорошей иронией и чувством юмора, способен решить любые проблемы, т.к. не боится говорить друг с другом и умеет рефлексировать. И учиться всем вместе.
Теперь я официально признан дедом и могу травить байки без зазрения совести. Несмотря на множество негативных событий прошлого года, все эти ребята стали для меня довольно большой семьей - настоящей стаей. Осталось, чтобы седой Акелла не обосрался. Хотя в его возрасте - это нормально.
#teambuilding
чувства и высказываться о проблемах прямо, а не на серии душных и не искренних one-to-one. Нужно быть толерантным, не поднимать острых тем и нельзя заботиться о успехе предприятия больше, чем о спокойствии твоего менеджера. Если ты доставил неприятности любому из менеджеров - тебя уволят. Правда, если менеджер будет о тебя вытирать ноги, это
допустимо.
Вчера отмечал с коллегами на работе первый год отработанный вместе с ними. И пожалуй самым ценным стал их неожиданно ненужный и бесполезный подарок. Целый монумент иронии и сарказма. На протяжении год, "детишки" собирались вокруг и слушали токсичные речи о "умственно отсталых кодерках" и прочие пространные велиричиво-графоманские телеги, в моем
исполнении.
Поэтому подарок от коллектива единомышленников оказался под стать. Кресло качалка, в котором можно укутаться в плед и травить байки стайке детсадовцев. Мне крайне понравилось, буду его таскать теперь на душные миты, на которых часами ничего толкового не решается.
Хороший коллектив это тот, в котором люди компенсируют недостатки друг-друга. Не бояться говорить друг с другом и
умеют искренне посмеяться над самими собой и окружающими. Коллектив с хорошей иронией и чувством юмора, способен решить любые проблемы, т.к. не боится говорить друг с другом и умеет рефлексировать. И учиться всем вместе.
Теперь я официально признан дедом и могу травить байки без зазрения совести. Несмотря на множество негативных событий прошлого года, все эти ребята стали для меня довольно большой семьей - настоящей стаей. Осталось, чтобы седой Акелла не обосрался. Хотя в его возрасте - это нормально.
#teambuilding
🔥20👏5👍2🌭2
Многие, кому я рассказываю про Go и уровень исполнителей на этом языке или в целом истории из мира bigtech разработки
(и не только), - не верят мне считая, что я склонен драматизировать ситуацию. С несколькими друзьями у нас образовалась
традиция наблюдать мок интервью го разработчиков в живую. И теперь ютуб снова начал мне предлагать посмотреть
го-инфлюенсеров.
Так я и попал на видео Олега Козырева. Я несколько раз пролистывал ленту дальше, предпочитая поезд с физиком и астрономом. Но в конечном итоге любопытство взяло вверх. Ведь снимает его не просто кто-то там. А стафф инженер из Т-Банка (ex Ozon, ex Avito). Человек, проработавший много где и занимающийся менторством разработчиков и автор своего собственного курса по микросервисам на го.
Примерно 6 последних лет я выслушиваю всевозможные смешные мнения о том, как ужасен uber/fx. От людей которые не имеют публичного веса и не занимаются опен сорсом. А тут такая возможность. Видео я слушал, паралельно занимаясь исследованием Rust. И тут мое ухо зацепилось за фразу: "Uber/FX не может работать с зависимостями, если интерфейс расположен так, как принято в Go, по месту использования". Я посмотрел в код в ролике и увидел вот это:
Тут мне стало интересно и я стал наблюдать за видео и стало совсем хорошо. По итогу, коллега, умудрился написать
конструктор для конструкторов и усложнить код навалив бойлерплейта. Сделав это, он нисколько не сомневаясь обвинил в этом библиотеку, сказав что она не способна - работать ни с нетипичными для нее сценариями (мол положите интерфейсы как в Java и будет вам счастье), ни с (прости господи) с отложенной инициализацией зависимостей.
И поэтому (!) мы сейчас сделаем правильно. Дальше он сделал ровно тоже самое и заявил что бойлерплейта 40 строк кода (что конечно не так - тк его 250 судя по репозиторию в гитхабе), но руками.
Ну что же у нас с несчастным и всем поруганном fx на самом деле - узнаем в следующем тексте.
#staffengineering #leak-base #ликбез
(и не только), - не верят мне считая, что я склонен драматизировать ситуацию. С несколькими друзьями у нас образовалась
традиция наблюдать мок интервью го разработчиков в живую. И теперь ютуб снова начал мне предлагать посмотреть
го-инфлюенсеров.
Так я и попал на видео Олега Козырева. Я несколько раз пролистывал ленту дальше, предпочитая поезд с физиком и астрономом. Но в конечном итоге любопытство взяло вверх. Ведь снимает его не просто кто-то там. А стафф инженер из Т-Банка (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 #ликбез
YouTube
Ручной DI vs Uber Fx: какой подход не сломается в проде
main.go на 300 строк, который работает и трогать страшно. Сегодня разбираем Dependency Injection в Go с нуля: откуда берётся хрупкость, почему Wire мёртв, зачем нужен Uber Fx и как написать нормальный DI-контейнер в 40 строк без магии.
⚡ Забирай код из видео:…
⚡ Забирай код из видео:…
😁7🌭1
Проблема Go "инженеров" заключается в том, что они не умеют читать код и понимать его. Не привыкли работать с чужой
документацией и не умеют ни кругозора, ни вкуса, ни стиля. Это единственная экосистема в которой люди не способные задать вопрос нейросети (или просто написать его на русском в гугле), сами выдумывают проблемы и сами борясь с ветрянной мельницей побеждают с ней в упорной борьбе.
Даже комментарий не правильны т.к написать fx.As(new(A), new(B)) можно. Это будет аннтоировать позиции возвращаемых
провайдер функцией результаты (об этом написать в code docs к функции). И тогда каждый возвращаемый позиционный элемент будет считаться имплементирующим каждый соответствующий ему в позиции аргумент.
Однако если бы у стафф инженера был минимальный опыт работы с DI контейнерами не написанными им самим и он вообще интересовался этим, он знал бы слово "аннотация", ну или как минимум проследовал бы по quick start к библиотеке.
Дело в том, что в целом при разрешении зависимостей не достаточно имплементировать интерфейc. В компонентной среде могут быть десятки РАЗНЫХ имплементаций и в каком порядке и где их разрешать, в языках где есть компилятор
(не его подобие как в го), как раз и используется аннотации. И у fx они есть, т.к это DSL, в замен отсутствующего
инструментария в языке.
Вместо того чтобы использовать fx.Out (который нужен совсем не для этого), нужно использовать fx.Annotate:
Т.к. функция принимает variadic аргументы типа аннотаций - каждая As (которая тоже аннотация кстати) детализирует
результат конструктора и по итогу, все что требовалось сделать staff engineer - уметь пользовться паттерном functional
options, который вроде "базовый" для го.
Соответственно - количество строк кода было бы такое же как и в предлагаемом им варианте (сам признал что круто и красиво выглядит к слову)где все интерфейсы лежали бы в единственном числе. Ладно. Открыть туториал по библиотеке и понять, это было бы сложно для "инженеров", которые не любят токсичного ревью от старых сеньоров и привыкли перепаивать платы когда код не работает. Но что сделать если спросить об этом у AI?
И он на прекрасном русском языке мне посоветовал реализовать два антипаттерна по работе с fx, в которые мсье и пошел. Но в конце - предложил верное решение тоже.
В резюме к видео, стафф инженер сказал, что дескать польза от fx только в том, что он умеет дескать делать
graceful shutdown. Но в следующем коде к своему мешку бойлерплейта он его реализует и fx точно будет не нужен!
В действительности же lifecycle операторы внутри fx как раз позволяют сделать настояющую lazyload инструментацию
зависимостей (при разрешении циклической зависимости, с которой наш герой не справился в итоге).
Ну и кроме того, функциональная природа fx, позволяет создать такую иснтрументацию запуска приложения, в которой можно будет константно доказать, что оно запускается и работает. Написав unit-тесты. Позволяет создавать множество контекстов и слоев для запуска. А не получить бесконечные рекурсивные вызовы при деплоее от стафф инженера.
Мораль такова. Титул senior инженер мы уже испортили. Теперь туда же отправляется и Staff. От ментора и автора курса можно ждать было чего-то большего, нежели исполнения в стиле: "не разобрался и сделал так как мне удобно". Слышал, что это уровень джунов.
#staffengineering #leak-base #ликбез
документацией и не умеют ни кругозора, ни вкуса, ни стиля. Это единственная экосистема в которой люди не способные задать вопрос нейросети (или просто написать его на русском в гугле), сами выдумывают проблемы и сами борясь с ветрянной мельницей побеждают с ней в упорной борьбе.
Даже комментарий не правильны т.к написать 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 #ликбез
👍10😁4❤3🔥3🤯1🌭1💯1
Сначала мне попался код человека рассказывающего про микросервисы на го на курсах. А потом эта книга.
Потрясающе, конечно, что издательство презентовало автора (и да - я это намерено), как эксперта и в nodejs и отлично
разбирающуюся в го.
Каждый раз, когда я касаюсь произведений, я надеюсь ошибится в своих - крайне низких ожиданиях от го разработчиков и
идей и концепций которые они могут презентовать и воплотить. И в этот раз, Юлии Поповой в книге
"Go: разработка приложений в микросервисной архитектуре с нуля" удалось снова оправдать мои ожидания.
Нельзя сказать, что эта книга уж совсем бесполезна и вредна (как и курс Олега Козырева). Беда в том, что она фиксирует
ситуацию в российском бигтехе. Когда абсолютно бездарные идеи репродуцируются бесконечно, в угоду лобби не стремящемуся напрягать голову. Репродуцируя этот опыт бесконечно и порождая код, заведомо с посредственным дизайном, зато доступный лентяям.
Здесь все любимые идеи - бесконечные полотна текста в main функциях. Сервисы которые способны запуститься целиком
исключительно в виде собранного бинарного файла. Анти патерны с управлениям транзакциями и нарушением смыслового назначения паттерна "Repository" (вот у человечества это один смысл умеет и у Фаулера и у Эванса, а у гоферов - другой).
Качеству кода посвящено. Два абзаца и это называется Code Style. Впервые в истории любой экосистемы не упомянут линтер пак. Действительно. Статический анализ кода и управление стилем кода благодаря этому, не достойная тема для разработки микросервисов с нуля. Разговаривая о кафке, берем самую уродливую и загаженную проблемами библиотеку.
Зато треть книги можно потратить на сборку контейнеров, нормальные формы (нормальные люди их в википедии прочитали бы).
Книга пропускает все лучшее, что есть в го - fx, контекстное логгирование, темпорал, ватермилл, sqlc, golangci. Зато воспевает создание лапши.
Плюс от этой книги только один. Предупрежден, значит вооружен. Но ничего кроме посредственности для человека
понимающего в том, как разрабатывать софт на любом другом языке, она не несёт. Зачем её издало издательство понятно.
Зачем она читателю - решительным образом нет: https://bhv.ru/product/go-razrabotka-prilozhenij-v-mikroservisnoj-arhitekture-s-nulya
#bookshelf
Потрясающе, конечно, что издательство презентовало автора (и да - я это намерено), как эксперта и в nodejs и отлично
разбирающуюся в го.
Каждый раз, когда я касаюсь произведений, я надеюсь ошибится в своих - крайне низких ожиданиях от го разработчиков и
идей и концепций которые они могут презентовать и воплотить. И в этот раз, Юлии Поповой в книге
"Go: разработка приложений в микросервисной архитектуре с нуля" удалось снова оправдать мои ожидания.
Нельзя сказать, что эта книга уж совсем бесполезна и вредна (как и курс Олега Козырева). Беда в том, что она фиксирует
ситуацию в российском бигтехе. Когда абсолютно бездарные идеи репродуцируются бесконечно, в угоду лобби не стремящемуся напрягать голову. Репродуцируя этот опыт бесконечно и порождая код, заведомо с посредственным дизайном, зато доступный лентяям.
Здесь все любимые идеи - бесконечные полотна текста в main функциях. Сервисы которые способны запуститься целиком
исключительно в виде собранного бинарного файла. Анти патерны с управлениям транзакциями и нарушением смыслового назначения паттерна "Repository" (вот у человечества это один смысл умеет и у Фаулера и у Эванса, а у гоферов - другой).
Качеству кода посвящено. Два абзаца и это называется Code Style. Впервые в истории любой экосистемы не упомянут линтер пак. Действительно. Статический анализ кода и управление стилем кода благодаря этому, не достойная тема для разработки микросервисов с нуля. Разговаривая о кафке, берем самую уродливую и загаженную проблемами библиотеку.
Зато треть книги можно потратить на сборку контейнеров, нормальные формы (нормальные люди их в википедии прочитали бы).
Книга пропускает все лучшее, что есть в го - fx, контекстное логгирование, темпорал, ватермилл, sqlc, golangci. Зато воспевает создание лапши.
Плюс от этой книги только один. Предупрежден, значит вооружен. Но ничего кроме посредственности для человека
понимающего в том, как разрабатывать софт на любом другом языке, она не несёт. Зачем её издало издательство понятно.
Зачем она читателю - решительным образом нет: https://bhv.ru/product/go-razrabotka-prilozhenij-v-mikroservisnoj-arhitekture-s-nulya
#bookshelf
👍12🔥5🌭2