Это лишь в фантазиях сумасшедших мир плоский, стоит на спинах трёх слонов, которые танцуют степ на панцире большой черепахи. Настоящий мир конечно же не такой. Это скучный шар из кремния в разной форме и состояния. Залитый унылыми серо-синими морями. Но всё это не относится к 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