Надеюсь, что многие заждались регулярного контента. Но так уж сложились обстоятельства, что он пропущен был на этой неделе. Впрочем, уже в эту пятницу начнётся описание история о падении компании "Broiler-228", на протяжении многих серий, так что уверен, как и я насладитесь историями, что напевают мне птицы в весенних садах.
А в рамках компенсации хотелось бы оставить очередной вброс про AI, Wipe Coding (и да, я, как всегда, не ошибся) и мое безбедное и беззаботное будущее. Последний год, я с удовольствием читаю новости, статьи и всевозможные видео интервью в которых люди обсуждают как искусственный интеллект бодро меня заменит. Или заменит джунов, или заменит мидлов. Или
я должен буду превратиться в архитектора и прочая прочая прочая.
Реальность примерно такова. Что когда в руках у нас оказывается код, написанный молодым поколением с любовью к вайб кодингу, этот код постигает именно вайп. Почему? Потому что задача программиста в целом не писать или создавать что-то. Его задача поддерживать результат своего или чужого труда. А для этого нужны навыки, которые вырабатываются разрешением проблем в продуктивных средах, в ситуациях, когда у тебя нет контекста и автора написанного. И ты идёшь, читаешь это произведение и пытаешься диагностировать место, в котором проблема.
Проблема же может быть в код, в базе данных, в сети или обнаруживаться на графиках или при анализе журналов. И если ты умеешь писать код, то читать код вайб-кодеров не составляет трудности. Ты находишь в них баги, находишь просто читая его как книгу —
сверху-вниз. Но вот они сами этих проблем не находят.
Последние 10 лет я наблюдаю одни и те же истории. Заглушенные линтеры, отсутствие юнит-тестов, анти-паттерны в коде, просто плохой и не работающий код, наивные реализации. Теперь добавился код, который человек наивно предполагает работающим,
но таковым не является. Что удивительно, аргументы в защиту глупости, подвергнутой остракизму десятилетия назад, плодятся. Люди, защищающие плохие подходы, лишь увеличиваются численностью год от года. Но только не в публичном поле.
Каждая вакансия содержит мантру умение или обязанность "писать unit-тесты", но ни на одном из собеседований не проверяется это умение. Говорящие же головы утверждают, что вот конкретно тесты то AI-пишет отличные (спойлер: нет). Нужно уметь писать качественный и высокопроизводительный код (но конфиг линтера вам никто не приложит к вакансии, а число
quality gate'ов не перечислит).
Но при чём тут wibe coding, спросит меня читатель. Мне пока не попадались творцы заклинаний, которые генерировали бы код высоких стандартов. Вот сгенерировать микросервис на пару тысяч строк кода, к которому будут замечания базового строгого линтера как на скрине - это пожалуйста. Чудес снова не случилось, банкет отменяем. Результат генерации требует пост-обработки и без определенных навыков (умения читать код) обойтись всё равно не получится. И те кто на вайбе смогут создать работающие стартапы в итоге всё равно будут вынуждены приходить к старичью, чтобы оно их оживляло с помощью шоковой терапии.
А в рамках компенсации хотелось бы оставить очередной вброс про AI, Wipe Coding (и да, я, как всегда, не ошибся) и мое безбедное и беззаботное будущее. Последний год, я с удовольствием читаю новости, статьи и всевозможные видео интервью в которых люди обсуждают как искусственный интеллект бодро меня заменит. Или заменит джунов, или заменит мидлов. Или
я должен буду превратиться в архитектора и прочая прочая прочая.
Реальность примерно такова. Что когда в руках у нас оказывается код, написанный молодым поколением с любовью к вайб кодингу, этот код постигает именно вайп. Почему? Потому что задача программиста в целом не писать или создавать что-то. Его задача поддерживать результат своего или чужого труда. А для этого нужны навыки, которые вырабатываются разрешением проблем в продуктивных средах, в ситуациях, когда у тебя нет контекста и автора написанного. И ты идёшь, читаешь это произведение и пытаешься диагностировать место, в котором проблема.
Проблема же может быть в код, в базе данных, в сети или обнаруживаться на графиках или при анализе журналов. И если ты умеешь писать код, то читать код вайб-кодеров не составляет трудности. Ты находишь в них баги, находишь просто читая его как книгу —
сверху-вниз. Но вот они сами этих проблем не находят.
Последние 10 лет я наблюдаю одни и те же истории. Заглушенные линтеры, отсутствие юнит-тестов, анти-паттерны в коде, просто плохой и не работающий код, наивные реализации. Теперь добавился код, который человек наивно предполагает работающим,
но таковым не является. Что удивительно, аргументы в защиту глупости, подвергнутой остракизму десятилетия назад, плодятся. Люди, защищающие плохие подходы, лишь увеличиваются численностью год от года. Но только не в публичном поле.
Каждая вакансия содержит мантру умение или обязанность "писать unit-тесты", но ни на одном из собеседований не проверяется это умение. Говорящие же головы утверждают, что вот конкретно тесты то AI-пишет отличные (спойлер: нет). Нужно уметь писать качественный и высокопроизводительный код (но конфиг линтера вам никто не приложит к вакансии, а число
quality gate'ов не перечислит).
Но при чём тут wibe coding, спросит меня читатель. Мне пока не попадались творцы заклинаний, которые генерировали бы код высоких стандартов. Вот сгенерировать микросервис на пару тысяч строк кода, к которому будут замечания базового строгого линтера как на скрине - это пожалуйста. Чудес снова не случилось, банкет отменяем. Результат генерации требует пост-обработки и без определенных навыков (умения читать код) обойтись всё равно не получится. И те кто на вайбе смогут создать работающие стартапы в итоге всё равно будут вынуждены приходить к старичью, чтобы оно их оживляло с помощью шоковой терапии.
❤10🤩3🤝3❤🔥1
Это лишь в фантазиях сумасшедших мир плоский, стоит на спинах трёх слонов, которые танцуют степ на панцире большой черепахи. Настоящий мир конечно же не такой. Это скучный шар из кремния в разной форме и состояния. Залитый унылыми серо-синими морями. Но всё это не относится к Großland ни в коей мере. Это колоссальная по размерам страна настолько велика, что ее две столицы расположились на спинах у дохлых слонов, которые, зловонно воняя, разлагаются на панцире у напившейся в стельку черепахи, плывущей в океане в абсолютно шокированного от данного факта мир.
Только в настолько безумном месте и могла произойти эта история.
В темные, для страны времена, один предприимчивый человек и его товарищи (те самые, которые легко могли порезать людей на части и скормить свиньям) решили создать предприятие. Которое перевозит спиртосодержащие флаконы из других стран в Großland, дабы ликвидировать дефицит. И пользуясь всяческими ухищрениями, они создали устойчивый бизнес. Компанию
иронично назвали "Broiler-228" и её вывески год за годом расползались по каждому более или менее крупному городу в стране.
Спустя целых 15 лет компания стала крупным ритейлером. Важным участником рынка и практически синонимом целой отрасли. Внутри же компании установилась любопытная культура. Люди там работали буквально только на одной работе - на этой. Ты покидал университет и оказывался джуном в айти-отделе и спустя 5-10-15-20 лет всё ещё работал здесь же. Таким человеком и был CTO компании и его зам. В их трудовой книжке было как раз единственное место работы. Все воспринимали компанию как семью, свою семью и своё творение. Что не было проблемой, пока у руля стоял Отец-основатель.
Однако быть бизнесменом это сложный и опасный труд. И Основатель в прямом смысле сгорел на работе. На втором десятке, тяжело заболев и отправившись в мир иной. Оставив наследников — жену, дочь и сына. Часто в таких историях начинается крутое пике. Т.к. наследники слабы и хилы и постепенно разбазаривают бизнес. Или его крадут партнеры. Но Мать, была не такой и как смогла взяла власть в компании.
Именно тут и начинается наша прекрасная история. В компании был архитектурный ландшафт DelphiusDB - как лучшая энтерпрайзная база данных на свете использовалась практически во всех айти решениях. И тут СТО компании неожиданно пришёл к мысли, что большая зарплата и просторный кабинет недостаточен для счастья. Хотелось этого же, но до конца жизни. Да и вообще оказалось, что мы все семья, но вот Мать и её дети - больше семья. И теперь компания вообще не наша.
И у нашего бодрого директора, возникла идейка. Обкашляв с замом, он создал компанию "Broiler 229 Technoligies" в соседнем и союзном государстве — Weißland'e и постепенно нанял туда большую часть сотрудников IT отдела. По итогу, все компетенции оказались там, а компания "Broiler-228" теперь платила за собственных сотрудников дань своему бывшему СТО.
После чего, передав дела, своему заместителю, наш доблестный СТО был таков. Следующие 2 десятка лет, он получал приличную маржу на том, что изначально принадлежало той самой компании, в которой он был членом семьи. И которая сделала его приличным человеком.
Но не один наш хитрый инженер считал, что деньги компании "Broiler-228" это его деньги, а не деньги собственников. Но
о следующей великой афёре уже в следующий раз. Сериал будет долгим и весёлым.
Пока же мораль проста. Бойтесь не профессионалов, за деньги работающих, а тех, кто вам как собственные дети. Именно они и обманут вас и будут рассказывать про "интересы бизнеса". На протяжении всех последующих серий.
#tales #broiler228
Только в настолько безумном месте и могла произойти эта история.
В темные, для страны времена, один предприимчивый человек и его товарищи (те самые, которые легко могли порезать людей на части и скормить свиньям) решили создать предприятие. Которое перевозит спиртосодержащие флаконы из других стран в Großland, дабы ликвидировать дефицит. И пользуясь всяческими ухищрениями, они создали устойчивый бизнес. Компанию
иронично назвали "Broiler-228" и её вывески год за годом расползались по каждому более или менее крупному городу в стране.
Спустя целых 15 лет компания стала крупным ритейлером. Важным участником рынка и практически синонимом целой отрасли. Внутри же компании установилась любопытная культура. Люди там работали буквально только на одной работе - на этой. Ты покидал университет и оказывался джуном в айти-отделе и спустя 5-10-15-20 лет всё ещё работал здесь же. Таким человеком и был CTO компании и его зам. В их трудовой книжке было как раз единственное место работы. Все воспринимали компанию как семью, свою семью и своё творение. Что не было проблемой, пока у руля стоял Отец-основатель.
Однако быть бизнесменом это сложный и опасный труд. И Основатель в прямом смысле сгорел на работе. На втором десятке, тяжело заболев и отправившись в мир иной. Оставив наследников — жену, дочь и сына. Часто в таких историях начинается крутое пике. Т.к. наследники слабы и хилы и постепенно разбазаривают бизнес. Или его крадут партнеры. Но Мать, была не такой и как смогла взяла власть в компании.
Именно тут и начинается наша прекрасная история. В компании был архитектурный ландшафт DelphiusDB - как лучшая энтерпрайзная база данных на свете использовалась практически во всех айти решениях. И тут СТО компании неожиданно пришёл к мысли, что большая зарплата и просторный кабинет недостаточен для счастья. Хотелось этого же, но до конца жизни. Да и вообще оказалось, что мы все семья, но вот Мать и её дети - больше семья. И теперь компания вообще не наша.
И у нашего бодрого директора, возникла идейка. Обкашляв с замом, он создал компанию "Broiler 229 Technoligies" в соседнем и союзном государстве — Weißland'e и постепенно нанял туда большую часть сотрудников IT отдела. По итогу, все компетенции оказались там, а компания "Broiler-228" теперь платила за собственных сотрудников дань своему бывшему СТО.
После чего, передав дела, своему заместителю, наш доблестный СТО был таков. Следующие 2 десятка лет, он получал приличную маржу на том, что изначально принадлежало той самой компании, в которой он был членом семьи. И которая сделала его приличным человеком.
Но не один наш хитрый инженер считал, что деньги компании "Broiler-228" это его деньги, а не деньги собственников. Но
о следующей великой афёре уже в следующий раз. Сериал будет долгим и весёлым.
Пока же мораль проста. Бойтесь не профессионалов, за деньги работающих, а тех, кто вам как собственные дети. Именно они и обманут вас и будут рассказывать про "интересы бизнеса". На протяжении всех последующих серий.
#tales #broiler228
❤6🥰2🤷♂1🤔1💯1
Если послушать дискурс HRюш, то нет более надежного и верного сотрудника, нежели человек, проведший в компании десятилетия. Человек, пожертвовавший собственным доходом и карьерой ради того, чтобы некогда небольшой бизнес рос и крепчал, становясь большой корпорацией. Особенно в Großland'е, где изменчиво всё и повсеместно.
На беду "Broiler 228", таких людей в компании оказалось много. И прямо уж скажем, каждый второй (а то и первый)
руководитель. Будучи большим ретейлом размазанным продажей спиртосодержащих жидкостей в каждом крупном городе страны, "Broiler 228" сильно зависели от логистики. Для ритейла очень важно, чтобы в каждом локальном магазине были именно те товары, который покупает каждый второй заходящий. Пусть и не самые дорогие, но зато очень популярные.
В бытность своей истории компания связалась с Альфой и Омегой всего бизнеса страны — с "Großbank", а точнее с одним из подразделений формирующейся монополии — "Graphologist". Год от года бизнес рос и росли логистические доходы первого и крупнейшего банка Großland'a. Пока руководителю банка Ингланду Бубну не пришла в голову мысль о том, что все эти ритейл компании и онлайн магазинчики дескать развиваются и конкурируют с ещё одним детищем — "Großultramarkt" — приобретённой компании маркетплейса. Светлая голова банкира выдала идею: расторгнуть договора с клиентами "Graphologist" и обеспечивать только потребности в логистике своего собственного маркетплейса. Однажды мы эту историю раскроем и с этой стороны.
Для "Broiler 228" это был довольно серьезный удар. Так как теперь нужно было выстраивать систему доставки с нуля. И тут
внутренние логисты компании предложили "сэкономить" и выстраивать свою систему, чтобы больше не оказываться в западне контракта с большой компанией (которую потом могут тоже поглотить). Будем возить частниками, и развивать свою систему.
В итоге каждый логист компании просто начал наживаться на откатах с каждой машины, что везла товары в магазины ретейла. Доставки становились дороже и медленнее. Ведь никто не хочет возить товары машинками, с которых мзда не идёт. Ну или если машинки не принадлежат компании жены, сестры, деда или ещё какого соседа по школьной парте. Но зато и компания и её процессы были в безопасности. Они теперь не зависели от росчерка пера большого банкира.
Беда снова пришла оттуда, откуда не ждали. Каждый обогащающийся лояльный логист и не думал о том, что последствия будут столь драматические. Чем медленнее и дороже становилась логистика, тем реже наполнялись полки магазинов. В том числе теми товарами, которые люди чаще всего и хотели купить. В итоге доходы компании стали падать. Люди понимая, что просто так по дороге домой нельзя зайти и найти нужную спиртосодержащую жидкость, нашли простой выход. На не столь уж важном и значимом для компании сайте они начали делать заказы с доставкой в ближайший им магазин. Дабы найти товар и забрать от туда.
Результат оказался ещё жестче. Так как нагрузка на логистику возросла, наличие номенклатуры на складе магазинов ещё
медленнее наполнялось. Но что хуже — бедный и несчастный сайт, в основе которого лежали хранимые процедуры по 5000 строк кода в DelphiusDB, просто стал падать и терять покупателей. Если раньше магазины в оффлайне приносили основные в продажи, то теперь всё по-сути строилось через продажи с сайта. И в высокий сезон компания понесла потери, поставившие под вопрос её прибыльность.
А отвечать вызовам современности, лояльная команда, выросшая на энтерпрайз технологиях с тёмных времен, просто
оказалась, неспособной. Нужно было приступить к IT-трансформации. Как кадровой, так и технологической. И как понимает внимательный читатель, эта трансформация будет и предметом нашего внимания и неудержимого веселья.
#tales #fridaytales
На беду "Broiler 228", таких людей в компании оказалось много. И прямо уж скажем, каждый второй (а то и первый)
руководитель. Будучи большим ретейлом размазанным продажей спиртосодержащих жидкостей в каждом крупном городе страны, "Broiler 228" сильно зависели от логистики. Для ритейла очень важно, чтобы в каждом локальном магазине были именно те товары, который покупает каждый второй заходящий. Пусть и не самые дорогие, но зато очень популярные.
В бытность своей истории компания связалась с Альфой и Омегой всего бизнеса страны — с "Großbank", а точнее с одним из подразделений формирующейся монополии — "Graphologist". Год от года бизнес рос и росли логистические доходы первого и крупнейшего банка Großland'a. Пока руководителю банка Ингланду Бубну не пришла в голову мысль о том, что все эти ритейл компании и онлайн магазинчики дескать развиваются и конкурируют с ещё одним детищем — "Großultramarkt" — приобретённой компании маркетплейса. Светлая голова банкира выдала идею: расторгнуть договора с клиентами "Graphologist" и обеспечивать только потребности в логистике своего собственного маркетплейса. Однажды мы эту историю раскроем и с этой стороны.
Для "Broiler 228" это был довольно серьезный удар. Так как теперь нужно было выстраивать систему доставки с нуля. И тут
внутренние логисты компании предложили "сэкономить" и выстраивать свою систему, чтобы больше не оказываться в западне контракта с большой компанией (которую потом могут тоже поглотить). Будем возить частниками, и развивать свою систему.
В итоге каждый логист компании просто начал наживаться на откатах с каждой машины, что везла товары в магазины ретейла. Доставки становились дороже и медленнее. Ведь никто не хочет возить товары машинками, с которых мзда не идёт. Ну или если машинки не принадлежат компании жены, сестры, деда или ещё какого соседа по школьной парте. Но зато и компания и её процессы были в безопасности. Они теперь не зависели от росчерка пера большого банкира.
Беда снова пришла оттуда, откуда не ждали. Каждый обогащающийся лояльный логист и не думал о том, что последствия будут столь драматические. Чем медленнее и дороже становилась логистика, тем реже наполнялись полки магазинов. В том числе теми товарами, которые люди чаще всего и хотели купить. В итоге доходы компании стали падать. Люди понимая, что просто так по дороге домой нельзя зайти и найти нужную спиртосодержащую жидкость, нашли простой выход. На не столь уж важном и значимом для компании сайте они начали делать заказы с доставкой в ближайший им магазин. Дабы найти товар и забрать от туда.
Результат оказался ещё жестче. Так как нагрузка на логистику возросла, наличие номенклатуры на складе магазинов ещё
медленнее наполнялось. Но что хуже — бедный и несчастный сайт, в основе которого лежали хранимые процедуры по 5000 строк кода в DelphiusDB, просто стал падать и терять покупателей. Если раньше магазины в оффлайне приносили основные в продажи, то теперь всё по-сути строилось через продажи с сайта. И в высокий сезон компания понесла потери, поставившие под вопрос её прибыльность.
А отвечать вызовам современности, лояльная команда, выросшая на энтерпрайз технологиях с тёмных времен, просто
оказалась, неспособной. Нужно было приступить к IT-трансформации. Как кадровой, так и технологической. И как понимает внимательный читатель, эта трансформация будет и предметом нашего внимания и неудержимого веселья.
#tales #fridaytales
🔥9🌭3👍2
Последние два дня оказались непростыми. Тем любопытнее мысль посетила сегодня, о книге, которую я прочитал за 3-4 дня полгода (где-то) назад.
В момент чтения я ловил себя на мысли, о том, что непонятно зачем я вообще купил и читаю книгу "Грокаем конкурентность". Большая часть текста, примеров и кода оказались обычными и самоочевидными. Большинство освещенных тем бесперспективных и бессмысленными. Несмотря на прекрасную статью на хабре (которая и продала мне книгу), остальной материал оказался совершено неувлекательным. Главный вывод, который я тогда для себя сделал, что эта книга безусловна не бесполезна, но почти не заслуживает ни освещения, ни внимания. Есть и есть.
Тем фантасмогоричны события, происходящие сейчас. Оказываясь на собеседовании, я вижу в целом неплохих (наверное) молодых инженеров, которые понимают конкурентность исключительно в одном единственном аспекте. В том, как устроен рантайм го (помните книгу про 100 ошибок? 2 главы от туда) и весьма посредственно понимают всё остальное. И думаю, что эта книга абсолютно точно помогла бы систематизировать понимание о параллелизме, конкурентности и том, в чём конкретно хорошо то или иное решение.
И на этом фоне мне стала понятна аудитория книги. Это люди, которые получают опыт на практике. Те у кого решение проблем связанных с конкурентным доступом, редкость. Которая может иногда проявляться в работе, но не каждый даже месяц. Тем кто в целом пропустили курс по устройству операционных систем в ВУЗе. Или кто вообще не сталкивался с конкурентностью в форме отличной от попытки корректно записать что-то в базу данных.
Если вы ловите себя на мысли, что вам непонятны слова вроде "семафор", "барьер" или "атомарность". Или не понимаете отличие "конкурентности" от "параллелизма" - вам сюда. А когда разыграется аппетит, можете отправляться в любимую книгу Подольского.
Единственное я бы не рекомендовал покупать бумажную версию книги. Ни ее форма, ни содержание не заслуживает всё таки места на полке. Всё же это книжка для джуниора и лишь самое начало в прекрасный мир абсолютного безумия:
https://www.piter.com/collection/seriya-grokaem/product/grokaem-konkurentnost
#bookshelf
В момент чтения я ловил себя на мысли, о том, что непонятно зачем я вообще купил и читаю книгу "Грокаем конкурентность". Большая часть текста, примеров и кода оказались обычными и самоочевидными. Большинство освещенных тем бесперспективных и бессмысленными. Несмотря на прекрасную статью на хабре (которая и продала мне книгу), остальной материал оказался совершено неувлекательным. Главный вывод, который я тогда для себя сделал, что эта книга безусловна не бесполезна, но почти не заслуживает ни освещения, ни внимания. Есть и есть.
Тем фантасмогоричны события, происходящие сейчас. Оказываясь на собеседовании, я вижу в целом неплохих (наверное) молодых инженеров, которые понимают конкурентность исключительно в одном единственном аспекте. В том, как устроен рантайм го (помните книгу про 100 ошибок? 2 главы от туда) и весьма посредственно понимают всё остальное. И думаю, что эта книга абсолютно точно помогла бы систематизировать понимание о параллелизме, конкурентности и том, в чём конкретно хорошо то или иное решение.
И на этом фоне мне стала понятна аудитория книги. Это люди, которые получают опыт на практике. Те у кого решение проблем связанных с конкурентным доступом, редкость. Которая может иногда проявляться в работе, но не каждый даже месяц. Тем кто в целом пропустили курс по устройству операционных систем в ВУЗе. Или кто вообще не сталкивался с конкурентностью в форме отличной от попытки корректно записать что-то в базу данных.
Если вы ловите себя на мысли, что вам непонятны слова вроде "семафор", "барьер" или "атомарность". Или не понимаете отличие "конкурентности" от "параллелизма" - вам сюда. А когда разыграется аппетит, можете отправляться в любимую книгу Подольского.
Единственное я бы не рекомендовал покупать бумажную версию книги. Ни ее форма, ни содержание не заслуживает всё таки места на полке. Всё же это книжка для джуниора и лишь самое начало в прекрасный мир абсолютного безумия:
https://www.piter.com/collection/seriya-grokaem/product/grokaem-konkurentnost
#bookshelf
🔥8❤2🌭1
Ландшафт мира дрожал от новой идеи, той самой, которая помогла Großtech'ам бурно расти и завладеть умами кодерков. Микросервисы! Вот это сила! Вот где истина, вот где серебреная пуля. И раз уж сайт "Broiler 228" оказался неспособен выдерживать нагрузку и все попытки CTO II исправить ситуацию не удавались, настал момент трансформации. Истинной платформизации!
Под это дело большие полномочия получил IT-директор. Став CTO платформизации. Под это гиблое дело, он выбил себе бюджет и решил сделать всё по науке. Обратился к известным компаниям за консалтингом и на протяжении целого года, занимался выработкой стратегического плана развития IT в компании, которая до этого в целом занималась спокойной продажей спиртосодержащих жидкостей, на бескрайних и безумных ландшафтах крупнейшей страны мира. На консультации было потрачено 150 миллионов Großmar'ок. Сумма, мягко говоря, не маленькая.
По прошествию календарного года, декларировалось, что стратегия выработана и на её исполнение теперь нужны люди, время и конечно же деньги. Дела же и продажи у компании шли ни шатко, ни валко. Все меры, принимаемые CTO, не проходили. Несмотря, на свои вошедшие в легенду способности справляться с неприятностями и техническими сложностями.
За прошедшие годы, CTO II нанимал разного рода экспертов в компанию, цель которых была не делать что-то, а составлять
экспертизу по техническому ландшафту. Быть консультантами и советниками технического директора! В результате любой
катаклизм удавалось преодолеть, ведь эксперты по DelphiusDB находили решение и путь в лабиринте хранимых процедур и раз за разом CTO получал реноме компетентного и талантливого инженера. Но, все же помнят первую главу, в его интересы всё так же не входило менять текущее решение и заниматься платформизацией. Он доблестно занимался латанием тонущего (по-мнению владельцев) судна и конечно же талантливо вставлял палки в колёса в платформизацию. В будущем, пока он просто оставался в тени.
На платформизацию и ее реализацию выделено было 250 миллионов Großmar'ок. Цена 5 комнатной квартиры в историческом особняке в центре столице страны - Großdorf'e. Прошло 3 месяца и финансовое состояние компании стало тревожить владельцев и "люди" захотели узнать что там с платформизацией. Бюджеты еле удавалось свести к минимальным прибылям, ожидаемые дивиденды были не впечатляющими и IT директора вызвали на ковер с вопросом "ну что, как там".
Мало кто ожидал, что директор даже не придёт на совещание, а напишет заявление об увольнении по собственному желанию с просьбой "не выплачивать ему годовую премию в размере 6 миллионов Großmar'ок (6 окладов своих к слову)", после чего - будет таков. Инвентаризация наследия талантливого управленца выявит, что за прошедшие месяца было нанято 0 человек. Написано 0 строк кода. Сделано 0 каких либо задач. И осталось ровно 0 - Großmar'ок из выделенного годового бюджета.
Недоумевающий читатель задастся вопросом, а куда же и как пропал бюджет. А ответ будет замечательным в своей простоте - он ушёл на "консультации".
Главный вопрос, который мучает нас. Как же так вышло, что "люди" (те самые совладельцы с
самого создания компании) - которые успешно в темные времена пересаживали кожу с людей на барабаны, отпустили ловкого и лояльного специалиста в туман?
Ответа мы не знаем (пока), но держимся концепции того, что Großland выдуманная страна и happyend'ы тут, в отличие от настоящей жизни, видимо случаются.
В то время как компания осталась с проблемой (как делать платформизацию), без денег на её решение и лидера для управления процессом. Мы минуем мораль и отправимся на отдых. Невозможно раз за разом напоминать, что нанимать надо компетентных профессионалов, а не софтскилльных жуликов. Тех что утащат у вас в итоге 400 миллионов и не оставят даже документа на пару страничек как артефакта.
#tales #broiler #broiler228
Под это дело большие полномочия получил IT-директор. Став CTO платформизации. Под это гиблое дело, он выбил себе бюджет и решил сделать всё по науке. Обратился к известным компаниям за консалтингом и на протяжении целого года, занимался выработкой стратегического плана развития IT в компании, которая до этого в целом занималась спокойной продажей спиртосодержащих жидкостей, на бескрайних и безумных ландшафтах крупнейшей страны мира. На консультации было потрачено 150 миллионов Großmar'ок. Сумма, мягко говоря, не маленькая.
По прошествию календарного года, декларировалось, что стратегия выработана и на её исполнение теперь нужны люди, время и конечно же деньги. Дела же и продажи у компании шли ни шатко, ни валко. Все меры, принимаемые CTO, не проходили. Несмотря, на свои вошедшие в легенду способности справляться с неприятностями и техническими сложностями.
За прошедшие годы, CTO II нанимал разного рода экспертов в компанию, цель которых была не делать что-то, а составлять
экспертизу по техническому ландшафту. Быть консультантами и советниками технического директора! В результате любой
катаклизм удавалось преодолеть, ведь эксперты по DelphiusDB находили решение и путь в лабиринте хранимых процедур и раз за разом CTO получал реноме компетентного и талантливого инженера. Но, все же помнят первую главу, в его интересы всё так же не входило менять текущее решение и заниматься платформизацией. Он доблестно занимался латанием тонущего (по-мнению владельцев) судна и конечно же талантливо вставлял палки в колёса в платформизацию. В будущем, пока он просто оставался в тени.
На платформизацию и ее реализацию выделено было 250 миллионов Großmar'ок. Цена 5 комнатной квартиры в историческом особняке в центре столице страны - Großdorf'e. Прошло 3 месяца и финансовое состояние компании стало тревожить владельцев и "люди" захотели узнать что там с платформизацией. Бюджеты еле удавалось свести к минимальным прибылям, ожидаемые дивиденды были не впечатляющими и IT директора вызвали на ковер с вопросом "ну что, как там".
Мало кто ожидал, что директор даже не придёт на совещание, а напишет заявление об увольнении по собственному желанию с просьбой "не выплачивать ему годовую премию в размере 6 миллионов Großmar'ок (6 окладов своих к слову)", после чего - будет таков. Инвентаризация наследия талантливого управленца выявит, что за прошедшие месяца было нанято 0 человек. Написано 0 строк кода. Сделано 0 каких либо задач. И осталось ровно 0 - Großmar'ок из выделенного годового бюджета.
Недоумевающий читатель задастся вопросом, а куда же и как пропал бюджет. А ответ будет замечательным в своей простоте - он ушёл на "консультации".
Главный вопрос, который мучает нас. Как же так вышло, что "люди" (те самые совладельцы с
самого создания компании) - которые успешно в темные времена пересаживали кожу с людей на барабаны, отпустили ловкого и лояльного специалиста в туман?
Ответа мы не знаем (пока), но держимся концепции того, что Großland выдуманная страна и happyend'ы тут, в отличие от настоящей жизни, видимо случаются.
В то время как компания осталась с проблемой (как делать платформизацию), без денег на её решение и лидера для управления процессом. Мы минуем мораль и отправимся на отдых. Невозможно раз за разом напоминать, что нанимать надо компетентных профессионалов, а не софтскилльных жуликов. Тех что утащат у вас в итоге 400 миллионов и не оставят даже документа на пару страничек как артефакта.
#tales #broiler #broiler228
👍11👏2🌭1
Меня впечатлило мнение комментаторов к моему интервью, о том, что уж софтскиллы то мне помогли бы. Поэтому я последнюю неделю давясь дочитывал прекрасную книгу - чтобы спасти вас от её чтения.
Тут важна маленькая предыстория. В сообществе, которое воспитало мою профессиональную этику, не было принято заниматься накручиванием соплей на локти. Поэтому начало эпохи выгорания и появления термина "soft skills" было нами в целом встречено с большой долей сарказма и иронией. Десятилетие мы презрительно относились и к этому термину, довольно резонно и справедливо полагая то, что навыки могут быть только "твердыми".
Поэтому надо понимать, что за книгу с названием "Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты" я приобрел с особым настроением. "Наконец-то мне не только объяснят, что же это за зверь такой, да ещё и получу работу мечты!!!".
В действительности книга наполнена большим количеством очевидных вещей и значимой частью того, что в российских реалиях можно считать глупостью. Скажем попытка "посчитать" стоимость сотрудника в компании и таким образом оценить, что компания не должна повышать вам зарплату, иначе как вредительством определить нельзя. Тем более что ранее в книге автор пытался научить читателя торговаться за зарплату и приводил совершенно бессмысленный в реалиях РФ пример — когда он согласился на снижение зарплаты в пользу получения опциона с 50% скидкой к цене акции компании взамен.
Из полезного, начинающему специалисту, было бы полезно прочитать информацию о математики бизнеса, но с другой стороны не лучше ли прочитать специализированную литературу на эту тему. Сама глава об этой теме слишком мала.
Многие темы, вроде лидерства — раскрыты плохо, хотя и многословно. Лидерство у мягконавычных это способ управлять, увольнять и нанимать. Но не вдохновлять и не организовывать. О способах как организовывать коллективы инженеров не сказано вообще ничего. Зато примерно 5 листов посвящены тому, какие мы все разные и как важно, чтобы черные девушки
учились программированию.
И вот сразу после разговора об инклюзивности, разнообразии, толерантности и терпимости автор упомянул своего мужа. Мне сложно сказать, что я не был готов к каминг-ауту в книге про софтскиллы, но в этот момент всё-таки проверил,
что автор — мужчина. Семейная драма была описана ещё и в следующей главе. Но дальше сошла на нет.
Ещё один интересный момент касался истории о том, как автор участвовал в процессе расширения оборудования и предложил компании купить его за полмиллиона долларов и о ужас — менеджер, принимающий решение, связался с компанией поставщиком и выяснил, что можно потратить 120 тысяч для достижения цели. Из этого делается любопытный вывод, что нужно понять, цели бизнеса и дескать менеджер понимал это лучше молодого автора книги.
Опять же современные реалии корпоративного устройства в нашей стране говорят о том, что заплачено было бы 2 миллиона долларов за 3 комплекта и полмиллиона легло бы в карман принимающему решение менеджеру.
Книга может быть полезна, как и любая другая. Упражнения и некоторые методы могут помочь в нелегком и бурном море хаоса, которым является современный "гибкий" мир. Но если честно, это просто бездарно потраченная целлюлоза. Так что наше милое сообщество токсичных стариков в очередной раз оказалось право. Займитесь просто делом и развивайте настоящие навыки. Ну или как советует в целом автор — сливайтесь в управление или консалтинг. Инфоцыгане (вроде автора) зарабатывают больше чем инженеры.
PS: книга на сайте издательства https://eksmo.ru/book/prokachay-kareru-soft-skills-dlya-it-spetsialistov-ITD1280304/
#bookshelf
Тут важна маленькая предыстория. В сообществе, которое воспитало мою профессиональную этику, не было принято заниматься накручиванием соплей на локти. Поэтому начало эпохи выгорания и появления термина "soft skills" было нами в целом встречено с большой долей сарказма и иронией. Десятилетие мы презрительно относились и к этому термину, довольно резонно и справедливо полагая то, что навыки могут быть только "твердыми".
Поэтому надо понимать, что за книгу с названием "Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты" я приобрел с особым настроением. "Наконец-то мне не только объяснят, что же это за зверь такой, да ещё и получу работу мечты!!!".
В действительности книга наполнена большим количеством очевидных вещей и значимой частью того, что в российских реалиях можно считать глупостью. Скажем попытка "посчитать" стоимость сотрудника в компании и таким образом оценить, что компания не должна повышать вам зарплату, иначе как вредительством определить нельзя. Тем более что ранее в книге автор пытался научить читателя торговаться за зарплату и приводил совершенно бессмысленный в реалиях РФ пример — когда он согласился на снижение зарплаты в пользу получения опциона с 50% скидкой к цене акции компании взамен.
Из полезного, начинающему специалисту, было бы полезно прочитать информацию о математики бизнеса, но с другой стороны не лучше ли прочитать специализированную литературу на эту тему. Сама глава об этой теме слишком мала.
Многие темы, вроде лидерства — раскрыты плохо, хотя и многословно. Лидерство у мягконавычных это способ управлять, увольнять и нанимать. Но не вдохновлять и не организовывать. О способах как организовывать коллективы инженеров не сказано вообще ничего. Зато примерно 5 листов посвящены тому, какие мы все разные и как важно, чтобы черные девушки
учились программированию.
И вот сразу после разговора об инклюзивности, разнообразии, толерантности и терпимости автор упомянул своего мужа. Мне сложно сказать, что я не был готов к каминг-ауту в книге про софтскиллы, но в этот момент всё-таки проверил,
что автор — мужчина. Семейная драма была описана ещё и в следующей главе. Но дальше сошла на нет.
Ещё один интересный момент касался истории о том, как автор участвовал в процессе расширения оборудования и предложил компании купить его за полмиллиона долларов и о ужас — менеджер, принимающий решение, связался с компанией поставщиком и выяснил, что можно потратить 120 тысяч для достижения цели. Из этого делается любопытный вывод, что нужно понять, цели бизнеса и дескать менеджер понимал это лучше молодого автора книги.
Опять же современные реалии корпоративного устройства в нашей стране говорят о том, что заплачено было бы 2 миллиона долларов за 3 комплекта и полмиллиона легло бы в карман принимающему решение менеджеру.
Книга может быть полезна, как и любая другая. Упражнения и некоторые методы могут помочь в нелегком и бурном море хаоса, которым является современный "гибкий" мир. Но если честно, это просто бездарно потраченная целлюлоза. Так что наше милое сообщество токсичных стариков в очередной раз оказалось право. Займитесь просто делом и развивайте настоящие навыки. Ну или как советует в целом автор — сливайтесь в управление или консалтинг. Инфоцыгане (вроде автора) зарабатывают больше чем инженеры.
PS: книга на сайте издательства https://eksmo.ru/book/prokachay-kareru-soft-skills-dlya-it-spetsialistov-ITD1280304/
#bookshelf
eksmo.ru
Soft skills для IT-специалистов. Прокачай карьеру и получи работу мечты
Возьмите свою карьеру под контроль! Чего вы ждете от карьеры в IT — высокой зарплаты, руководящей должности, гибкого графика, удаленной работы? Дон Джонс, мировой эксперт в области построения карьеры и личного бренда в технологической сфере, поможет вам добиться…
😁15👍11🌭3❤2
На работе смотрим онлайн трансляцию 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