33. В поисках траектории.
- "Вам сколько сессий?" - спросила девушка за стойкой. Я немного помялся, а потом выпалил - "Три!". Я не был уверен, что я выдержу три сессии, все же год не катался. Я не был уверен, что машина выдержит три сессии, ибо сток, и на треке я ее еще не проверял. Но чувство, что половина сезона уже бездарно потеряна, жгло и подгоняло.
"До начала следующего заезда 5 минут" - раздался голос из громкоговорителей. Машины послушно выстроились на пит-лейне. Я огляделся - заряженные порше, прокатные эмки, невнятные хот-хэтчи, и даже прототип. Черт, вот это пелетон. Оно и понятно - трек-дней в этом году мало, поэтому воскресным вечером сюда стянулись петролхэды всех мастей, от овощей типа меня до серьезных гонщиков. Будет потно. Главное - успевать замечать в зеркалах прототип и не лезть под него, иначе - ой!
До включения светофора остается с минуту. Включаю телеметрию, начинаю самонакачку, прокручиваю в голове первые повороты. "Это же не гонка, а простые покатушки" - звучит голос разума. Но предстартовый мандраж не унять. Надо поберечь машину, за три сессии все равно укатаюсь в салат. Так что не будем рваться сразу в бой - первый круг прогревочный, далее каждый третий остывочный.
Зеленый! Воздух наполняется утробным ревом полутора десятков моторов всех возможных конфигураций. Уже непонятно, от чего он дрожит над горизонтом - от жары ли, или пульсирует в унисон с нашими шатунно-поршневыми группами. Пелетон вытекает из пит-лейна на гоночную дорожку и сразу вваливается в первый левый.
Я, позабыв о прогреве шин и тормозов, сразу бросаюсь в атаку на зазевавшегося гольфа gti. Но сразу одергиваю себя - я уже в апексе второго поворота, а он коварней первого. Вываливаться наружу не стоит - там грозят ребята посерьезней, которые вот-вот начнут резать траекторию под правую улитку. Здесь не борщим, здесь я в гравии уже бывал, не понравилось.
Следующая связка левых не пугает - в них я привожу мало скорости, потому что после улитки не успеваю нормально разогнаться. А вот дальше два пологих изгиба, которые нужно идти во всю дыру - главное не струсить и, не отпуская газ, прописать правильную траекторию насквозь. Короткий прямик, 7600 оборотов - и вот уже набор высоты помогает сбросить скорость. Пытаюсь не сорвать машину в снос, не получается, но тут поребрик не опасный. Следующие 5 поворотов помню хуже, поэтому сейвлюсь, и все равно траекторно ошибаюсь. Ладно, на следующих кругах буду расторопней.
Длиннющая прямая, хоть и разорванная ретардером посередине, показыает, кто тут папочка (не я). Однако, под конец скорость уже за 150, и сейчас тормозам придется несладко. Скидываю на третью передачу, колеса почти блокируются. Последний поворот на старт-финишную прямую, и я снова выкручиваю мотор до звона, потому что мимо светофора надо ехать эффектно. Не знаю, почему, просто так принято.
Ко второму кругу уже более-менее вкатываюсь, и вспоминаю завет "ехать медленнее, чтобы ехать быстрее". Не надо пытаться пройти все повороты "на рогах", отбрасываю эмоции, начинаю писать траектории, облизывая апексы более грамотно. Позже тормозить, меньше скользить, раньше открываться. Впереди еще несколько кругов, не перегреть бы тормоза! Потом остыть, и снова в бой.
К концу третьей сессии сил не остается ни у меня, ни у машины. Но Миата показала себя превосходно, я перегрелся раньше. Такой рулежки и контроля я на кузовных машинах еще не испытывал (самое близкое - shortcut 527, он великолепен). Истинное единение кожаного мешка и тонны железа в поисках границы дозволенного, и чуть за пределами законов физики. Аригато годзаимас, Мазда-сан! До встречи на разгоне!
- "Вам сколько сессий?" - спросила девушка за стойкой. Я немного помялся, а потом выпалил - "Три!". Я не был уверен, что я выдержу три сессии, все же год не катался. Я не был уверен, что машина выдержит три сессии, ибо сток, и на треке я ее еще не проверял. Но чувство, что половина сезона уже бездарно потеряна, жгло и подгоняло.
"До начала следующего заезда 5 минут" - раздался голос из громкоговорителей. Машины послушно выстроились на пит-лейне. Я огляделся - заряженные порше, прокатные эмки, невнятные хот-хэтчи, и даже прототип. Черт, вот это пелетон. Оно и понятно - трек-дней в этом году мало, поэтому воскресным вечером сюда стянулись петролхэды всех мастей, от овощей типа меня до серьезных гонщиков. Будет потно. Главное - успевать замечать в зеркалах прототип и не лезть под него, иначе - ой!
До включения светофора остается с минуту. Включаю телеметрию, начинаю самонакачку, прокручиваю в голове первые повороты. "Это же не гонка, а простые покатушки" - звучит голос разума. Но предстартовый мандраж не унять. Надо поберечь машину, за три сессии все равно укатаюсь в салат. Так что не будем рваться сразу в бой - первый круг прогревочный, далее каждый третий остывочный.
Зеленый! Воздух наполняется утробным ревом полутора десятков моторов всех возможных конфигураций. Уже непонятно, от чего он дрожит над горизонтом - от жары ли, или пульсирует в унисон с нашими шатунно-поршневыми группами. Пелетон вытекает из пит-лейна на гоночную дорожку и сразу вваливается в первый левый.
Я, позабыв о прогреве шин и тормозов, сразу бросаюсь в атаку на зазевавшегося гольфа gti. Но сразу одергиваю себя - я уже в апексе второго поворота, а он коварней первого. Вываливаться наружу не стоит - там грозят ребята посерьезней, которые вот-вот начнут резать траекторию под правую улитку. Здесь не борщим, здесь я в гравии уже бывал, не понравилось.
Следующая связка левых не пугает - в них я привожу мало скорости, потому что после улитки не успеваю нормально разогнаться. А вот дальше два пологих изгиба, которые нужно идти во всю дыру - главное не струсить и, не отпуская газ, прописать правильную траекторию насквозь. Короткий прямик, 7600 оборотов - и вот уже набор высоты помогает сбросить скорость. Пытаюсь не сорвать машину в снос, не получается, но тут поребрик не опасный. Следующие 5 поворотов помню хуже, поэтому сейвлюсь, и все равно траекторно ошибаюсь. Ладно, на следующих кругах буду расторопней.
Длиннющая прямая, хоть и разорванная ретардером посередине, показыает, кто тут папочка (не я). Однако, под конец скорость уже за 150, и сейчас тормозам придется несладко. Скидываю на третью передачу, колеса почти блокируются. Последний поворот на старт-финишную прямую, и я снова выкручиваю мотор до звона, потому что мимо светофора надо ехать эффектно. Не знаю, почему, просто так принято.
Ко второму кругу уже более-менее вкатываюсь, и вспоминаю завет "ехать медленнее, чтобы ехать быстрее". Не надо пытаться пройти все повороты "на рогах", отбрасываю эмоции, начинаю писать траектории, облизывая апексы более грамотно. Позже тормозить, меньше скользить, раньше открываться. Впереди еще несколько кругов, не перегреть бы тормоза! Потом остыть, и снова в бой.
К концу третьей сессии сил не остается ни у меня, ни у машины. Но Миата показала себя превосходно, я перегрелся раньше. Такой рулежки и контроля я на кузовных машинах еще не испытывал (самое близкое - shortcut 527, он великолепен). Истинное единение кожаного мешка и тонны железа в поисках границы дозволенного, и чуть за пределами законов физики. Аригато годзаимас, Мазда-сан! До встречи на разгоне!
🔥21🆒7❤4😱1🏆1😐1
34. Монополия
Если вы думаете, что, став монополистом, можно расслабиться - как бы не так. Даже если вы доминируете в своем сегменте рынка, вы должны расти. Остановившись, вы проиграете (ну если полный коммунизм еще не наступил). А как расти, если вы уже №1? У кого отбирать долю? Очевидно, у непрямых конкурентов. То есть у тех, с кем вас даже особо не сравнивают, когда выбирают продукт.
Гугл (в мире) конкурирует не с другими поисковиками, а с привычками людей, чтобы быть top of mind не только в задачах поиска. Газпром конкурирует не с другими газовыми компаниями, а с фондовыми рынками. Яндекс Такси конкурирует с общественным транспортом. Яндекс еда - с привычкой готовить дома (впрочем, Еда и так не монополист, так как своя доставка ресторанов и магазинов занимает большую долю рынка).
Чтобы конкурировать вне своего сегмента, недостаточно быть "как конкурент, но чуть лучше". Тут нужно выходить за рамки привычного продукта - завоевывать новые ниши, менять ландшафт рынка, влиять на привычки пользователей, создавать новые уникальные товарные предложения. А это - уже игра в другой лиге.
К чему я все это? Эти строки для утреннего поста я пишу из вагона ночного поезда Москва - Санкт-Петербург, который в моей голове в этот раз (и примерно впервые) выиграл в конкуренции с самолетами. В том числе, благодаря УТП в виде гранд-империал-люкс-купе с собственным туалетом и душем (ну не могу я с поезда приехать на работу без душа и с немытой головой). Оказывается, бывает и такое. Отдельный прикол в том, что это как раз не РЖД, а частный поезд, но и у РЖД такие люксы, вроде бы, теперь появились. Но пойнт к том, что тут не РЖД конкурирует с Гранд Экспрессом, и не Аэрофлот с S7, а ж/д с авиа.
И казалось бы, что тут могло поменяться за последние пару десятков лет? А оно меняется, хотя в своих сегментах есть очевидные лидеры. Ж/д делают новые вагоны, не сильно уступающие в комфорте отелям. Аэрофлот запустил шаттл (рейсы строго раз в полчаса с упрощенным изменением рейса в пределах дня). Спрос рождает конкуренцию. А конкуренция - двигатель прогресса. Не останавливайте развитие, даже если кажется, что свой кусок пирога вы уже отъели. А чтобы расти с высокой базы, нужны экстра-усилия и драматическое расширение сферы влияния.
Если вы думаете, что, став монополистом, можно расслабиться - как бы не так. Даже если вы доминируете в своем сегменте рынка, вы должны расти. Остановившись, вы проиграете (ну если полный коммунизм еще не наступил). А как расти, если вы уже №1? У кого отбирать долю? Очевидно, у непрямых конкурентов. То есть у тех, с кем вас даже особо не сравнивают, когда выбирают продукт.
Гугл (в мире) конкурирует не с другими поисковиками, а с привычками людей, чтобы быть top of mind не только в задачах поиска. Газпром конкурирует не с другими газовыми компаниями, а с фондовыми рынками. Яндекс Такси конкурирует с общественным транспортом. Яндекс еда - с привычкой готовить дома (впрочем, Еда и так не монополист, так как своя доставка ресторанов и магазинов занимает большую долю рынка).
Чтобы конкурировать вне своего сегмента, недостаточно быть "как конкурент, но чуть лучше". Тут нужно выходить за рамки привычного продукта - завоевывать новые ниши, менять ландшафт рынка, влиять на привычки пользователей, создавать новые уникальные товарные предложения. А это - уже игра в другой лиге.
К чему я все это? Эти строки для утреннего поста я пишу из вагона ночного поезда Москва - Санкт-Петербург, который в моей голове в этот раз (и примерно впервые) выиграл в конкуренции с самолетами. В том числе, благодаря УТП в виде гранд-империал-люкс-купе с собственным туалетом и душем (ну не могу я с поезда приехать на работу без душа и с немытой головой). Оказывается, бывает и такое. Отдельный прикол в том, что это как раз не РЖД, а частный поезд, но и у РЖД такие люксы, вроде бы, теперь появились. Но пойнт к том, что тут не РЖД конкурирует с Гранд Экспрессом, и не Аэрофлот с S7, а ж/д с авиа.
И казалось бы, что тут могло поменяться за последние пару десятков лет? А оно меняется, хотя в своих сегментах есть очевидные лидеры. Ж/д делают новые вагоны, не сильно уступающие в комфорте отелям. Аэрофлот запустил шаттл (рейсы строго раз в полчаса с упрощенным изменением рейса в пределах дня). Спрос рождает конкуренцию. А конкуренция - двигатель прогресса. Не останавливайте развитие, даже если кажется, что свой кусок пирога вы уже отъели. А чтобы расти с высокой базы, нужны экстра-усилия и драматическое расширение сферы влияния.
35. Вредные советы для стажеров.
Если ты пришел стажером (или, пожалуй, джуном) в крупную IT-компанию, следуй этим советам, и тогда обязательно очень скоро вернешься к поискам нового места работы.
1. Не докучай своему ментору. Он и так весь в мыле, еще и ты со своими глупыми вопросами. Особенно, если он и так уже уделил тебе сегодня минут 15. Все, что осталось непонятно, это твои проблемы.
(А на самом деле, не стесняйся задавать любые вопросы и в любом количестве, ментор у тебя есть не просто так, и он сам не меньше тебя заинтересован в том, чтобы ты побыстрее во всем разобрался)
2. Ни в коем случае не спрашивай про ожидания от тебя в целом, и уж тем более - про образ результата по задаче, которую тебе дали. Иначе руководство подумает, что ты вообще ничего не понимаешь, и зря тебя взяли на стажировку.
(А на самом деле, как говорится, "без четкого ТЗ результат - ХЗ". Проговорить скоуп обязанностей и ожидаемую степень самостоятельности - это гигиенический минимум. Иначе можно закопаться в том месте, где подразумевалась помощь ментора)
3. Если задача кажется тебе слишком сложной - молчи, иначе подумают, что ты безнадежен. Если задача кажется тебе слишком простой - тем более! Иначе нагрузят еще пачкой, лучше потяни ее недельку, как будто так и надо.
(А на самом деле, не стесняйся делиться фидбеком по задачам - что заходит лучше, где застреваешь. Это поможет ментору адаптировать задачи под твой ритм. Так ты быстрее вкатишься и раскроешь свой потенциал)
4. Если тебе не хватает обратной связи от ментора, скорее всего, ты бездарь, и тебе тут не рады. Не напрашивайся на похвалу, а поругать всегда успеют. А пока не ругают - сиди тихо.
(А на самом деле, запрос на регулярную и конструктивную обратную связь - это база. Но, к сожалению, иногда ментор или руководитель может чуть забыться или нечетко ее сформулировать. Если не будешь переспрашивать - будет непонятно, куда на самом деле копать)
5. Игнорируй несистематизированную информацию вне базового онбординга. Всех этих статей, видосиков, вики-страничек, курсов - пруд пруди, поглотить это абсолютно нереально, нечего и пытаться.
(А на самом деле, четкой и структурной документации зачастую, правда, не хватает. И чем больше ты проявишь самостоятельности в поиске нужной тебе информации, тем лучше - автономность в поиске нужных для решения задачи данных дорого стоит. А если ты по ходу дела где-то доку обновишь/дополнишь, тебе еще и за это спасибо скажут)
6. Не подавай виду, что хочешь попасть в штат. Стоит руководителю заметить в тебе эту надежду, он тебя раскусит, и начнет всячески тобой помыкать.
(А на самом деле, синк в этом вопросе очень важен. Руководителю нужно держать в голове необходимость в штатной ставке, а тебе нужно понимать реальные шансы попадания в штат, в том числе с учетом наличия ставок. Нет ничего зазорного в открытом разговоре про это. А еще можно вместе с ментором поразглядывать матрицу компетенций, чтобы понять основные точки роста)
7. Не обсуждай личное. На работе есть место только работе. Веди себя как робот. Тем более, что руководитель ведет себя так же.
(А на самом деле, в любой команде главное - это люди. Мы не роботы, нам не чуждо ничто человеческое. Стоит сразу вливаться в коллектив, знакомиться с ребятами, обрастать полезными связями).
И помни, что стажировка очень коротка. В случае успеха, уже через 3 месяца ты станешь штатным сотрудником, от которого мы ожидаем проактивности, самостоятельности, нацеленности на результат. Нужно уметь работать в условиях умеренной неопределенности. Умение коммуницировать с коллегами для достижения результата - тоже навык, который надо качать. Четкий план "делай раз, делай два" бывает не всегда, нужно уметь добыть необходимую информацию, а при необходимости - переобуться в воздухе. И всему этому лучше начинать учиться с первых дней стажировки. Тогда, при должном усердии и мотивированности, все получится.
Если ты пришел стажером (или, пожалуй, джуном) в крупную IT-компанию, следуй этим советам, и тогда обязательно очень скоро вернешься к поискам нового места работы.
1. Не докучай своему ментору. Он и так весь в мыле, еще и ты со своими глупыми вопросами. Особенно, если он и так уже уделил тебе сегодня минут 15. Все, что осталось непонятно, это твои проблемы.
(А на самом деле, не стесняйся задавать любые вопросы и в любом количестве, ментор у тебя есть не просто так, и он сам не меньше тебя заинтересован в том, чтобы ты побыстрее во всем разобрался)
2. Ни в коем случае не спрашивай про ожидания от тебя в целом, и уж тем более - про образ результата по задаче, которую тебе дали. Иначе руководство подумает, что ты вообще ничего не понимаешь, и зря тебя взяли на стажировку.
(А на самом деле, как говорится, "без четкого ТЗ результат - ХЗ". Проговорить скоуп обязанностей и ожидаемую степень самостоятельности - это гигиенический минимум. Иначе можно закопаться в том месте, где подразумевалась помощь ментора)
3. Если задача кажется тебе слишком сложной - молчи, иначе подумают, что ты безнадежен. Если задача кажется тебе слишком простой - тем более! Иначе нагрузят еще пачкой, лучше потяни ее недельку, как будто так и надо.
(А на самом деле, не стесняйся делиться фидбеком по задачам - что заходит лучше, где застреваешь. Это поможет ментору адаптировать задачи под твой ритм. Так ты быстрее вкатишься и раскроешь свой потенциал)
4. Если тебе не хватает обратной связи от ментора, скорее всего, ты бездарь, и тебе тут не рады. Не напрашивайся на похвалу, а поругать всегда успеют. А пока не ругают - сиди тихо.
(А на самом деле, запрос на регулярную и конструктивную обратную связь - это база. Но, к сожалению, иногда ментор или руководитель может чуть забыться или нечетко ее сформулировать. Если не будешь переспрашивать - будет непонятно, куда на самом деле копать)
5. Игнорируй несистематизированную информацию вне базового онбординга. Всех этих статей, видосиков, вики-страничек, курсов - пруд пруди, поглотить это абсолютно нереально, нечего и пытаться.
(А на самом деле, четкой и структурной документации зачастую, правда, не хватает. И чем больше ты проявишь самостоятельности в поиске нужной тебе информации, тем лучше - автономность в поиске нужных для решения задачи данных дорого стоит. А если ты по ходу дела где-то доку обновишь/дополнишь, тебе еще и за это спасибо скажут)
6. Не подавай виду, что хочешь попасть в штат. Стоит руководителю заметить в тебе эту надежду, он тебя раскусит, и начнет всячески тобой помыкать.
(А на самом деле, синк в этом вопросе очень важен. Руководителю нужно держать в голове необходимость в штатной ставке, а тебе нужно понимать реальные шансы попадания в штат, в том числе с учетом наличия ставок. Нет ничего зазорного в открытом разговоре про это. А еще можно вместе с ментором поразглядывать матрицу компетенций, чтобы понять основные точки роста)
7. Не обсуждай личное. На работе есть место только работе. Веди себя как робот. Тем более, что руководитель ведет себя так же.
(А на самом деле, в любой команде главное - это люди. Мы не роботы, нам не чуждо ничто человеческое. Стоит сразу вливаться в коллектив, знакомиться с ребятами, обрастать полезными связями).
И помни, что стажировка очень коротка. В случае успеха, уже через 3 месяца ты станешь штатным сотрудником, от которого мы ожидаем проактивности, самостоятельности, нацеленности на результат. Нужно уметь работать в условиях умеренной неопределенности. Умение коммуницировать с коллегами для достижения результата - тоже навык, который надо качать. Четкий план "делай раз, делай два" бывает не всегда, нужно уметь добыть необходимую информацию, а при необходимости - переобуться в воздухе. И всему этому лучше начинать учиться с первых дней стажировки. Тогда, при должном усердии и мотивированности, все получится.
❤11👍8🤓2
NaN. В предыдущих сериях.
Я с вами уже почти два месяца. Или это вы со мной - тут уж как посмотреть.
В любом случае, можно немного осмыслить, что за это время произошло.
Вот легкий рекап моего контента, если вдруг вы чего-то тут еще не видели)
Кстати, если вам заходит то, что я пишу, будьте добры - поделитесь каналом с друзьями/знакомыми/коллегами.
Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков).
Заранее спасибо, люблю вас!
Важный дисклеймер (есть в закрепе)
Рабочее:
5. Олды тут?
12. Надежность
15. C++
19.1. Коммуникации (1/2)
19.2. Коммуникации (2/2)
22. Чеклист здорового тимлида
24. Один день из жизни разработчика
28. Об алгоритмах на собеседованиях.
32. iOS и его друзья
35. Вредные советы для стажеров.
Про ИИ:
2. Минус-вайб
3. Нас всех заменят?
4. Промт-инженеры.
7. Будущее ИИ
Про тачки:
6. Вне работы
14. Про китайский автопром
17. Электрички
25.1. Японцы делают вещи (1/2)
25.2. Японцы делают вещи (2/2)
33. В поисках траектории.
Ворчанье:
0. Вместо вступления
8. Офис
9. Не-офис
23. Этот мир чертовски ускорился
26. О времена, о нравы!
29. Курьеры бывшими не бывают.
31. О разнообразии видов.
Мотивационное:
10. Стресс
21. Как влиять на будущее*?
34. Монополия
Философское:
1. Колонка
11. Есть ли у программы душа?
20. Нас обманывали?
27. Верите ли вы в зеленых человечков?
30. Старый друг лучше новых двух?
Про путешествия:
13. Смена декораций
16. О пользе отпуска
18. Кыргызстан
Ну а подкаст лежит ТУТ
Я с вами уже почти два месяца. Или это вы со мной - тут уж как посмотреть.
В любом случае, можно немного осмыслить, что за это время произошло.
Вот легкий рекап моего контента, если вдруг вы чего-то тут еще не видели)
Кстати, если вам заходит то, что я пишу, будьте добры - поделитесь каналом с друзьями/знакомыми/коллегами.
Только так канал будет расти и развиваться, а я ценю релевантную и читающую аудиторию (потому не прибегаю ко всяким мутным схемам накрутки подписчиков).
Заранее спасибо, люблю вас!
Важный дисклеймер (есть в закрепе)
Рабочее:
5. Олды тут?
12. Надежность
15. C++
19.1. Коммуникации (1/2)
19.2. Коммуникации (2/2)
22. Чеклист здорового тимлида
24. Один день из жизни разработчика
28. Об алгоритмах на собеседованиях.
32. iOS и его друзья
35. Вредные советы для стажеров.
Про ИИ:
2. Минус-вайб
3. Нас всех заменят?
4. Промт-инженеры.
7. Будущее ИИ
Про тачки:
6. Вне работы
14. Про китайский автопром
17. Электрички
25.1. Японцы делают вещи (1/2)
25.2. Японцы делают вещи (2/2)
33. В поисках траектории.
Ворчанье:
0. Вместо вступления
8. Офис
9. Не-офис
23. Этот мир чертовски ускорился
26. О времена, о нравы!
29. Курьеры бывшими не бывают.
31. О разнообразии видов.
Мотивационное:
10. Стресс
21. Как влиять на будущее*?
34. Монополия
Философское:
1. Колонка
11. Есть ли у программы душа?
20. Нас обманывали?
27. Верите ли вы в зеленых человечков?
30. Старый друг лучше новых двух?
Про путешествия:
13. Смена декораций
16. О пользе отпуска
18. Кыргызстан
Ну а подкаст лежит ТУТ
Telegram
Ворчливый IT-дед
И на всякий случай давайте договоримся - не воспринимайте написанное в этой колонке буквально и близко к сердцу. Автор не претендует на истину в последней инстанции и не преследует цели кого-то задеть или оскорбить. Некоторые идеи могут быть в иллюстративных…
🔥14🎉5❤2👍1
О пользе караоке
Что общего между работой технического лидера и караоке? Правильно, навыки публичный выступлений. И второе сильно помогает первому. Один мой коллега даже подметил, что я начал больше выступать на конференциях и митапах как раз после того, как начал петь в караоке (совпадение?).
Случилось это (караоке, не конференции), как всегда, почти случайно. В командировке в Воронеж (мы туда поехали поработать "в полях" в нашем контакт-центре - отвечать на звонки злых и голодных юзеров) году так в 2021. До этого я никогда не был в караоке и не собирался - это ж кринж. Но теплым летним вечером меня, тоже тепленького, туда незаметно увели добрые коллеги, и понеслась.
Что нужно для выступлений на конференциях, митапах, да и в целом для коммуникации на большие команды от руководителя? Верно - умение четко, громко, складно говорить, а также отсутствие страха и стеснения перед аудиторией. Разминка лицевых мышц, работа над дикцией, умение складывать мысли в речь, правильное дыхание - это база номер один. Вторая - уметь выйти перед аудиторией и не спасовать, даже если не вполне уверен в контенте.
И во всем этом поможет караоке. И чем хуже вы поете - тем лучше (не стесняться петь хорошо каждый может). Отдельная задача со звездочкой - петь что-то лютое, недоступное и непонятное большинству, например - Amatory. После этого уже ничего не страшно!
Отдельно отмечу, что многие могут себе позволить петь, только изрядно набравшись. Не будем рассуждать о вреде алкоголя, это и так всем понятно. Так вот хорошая тренировка - это с каждым разом начинать петь под все меньшей мухой, чтобы в итоге начать без стыда и зазрения петь трезвым. Попробуйте! (Авторский метод Сергея Г., ему тут респект и лавры.) Кстати, ровно этим мы занимались на бизнес-тренинге на прошлой неделе всей большой командой. Дарю вам бесплатную идею для старта корпоратива. Главное - делать это с очень серьезным лицом.
Что общего между работой технического лидера и караоке? Правильно, навыки публичный выступлений. И второе сильно помогает первому. Один мой коллега даже подметил, что я начал больше выступать на конференциях и митапах как раз после того, как начал петь в караоке (совпадение?).
Случилось это (караоке, не конференции), как всегда, почти случайно. В командировке в Воронеж (мы туда поехали поработать "в полях" в нашем контакт-центре - отвечать на звонки злых и голодных юзеров) году так в 2021. До этого я никогда не был в караоке и не собирался - это ж кринж. Но теплым летним вечером меня, тоже тепленького, туда незаметно увели добрые коллеги, и понеслась.
Что нужно для выступлений на конференциях, митапах, да и в целом для коммуникации на большие команды от руководителя? Верно - умение четко, громко, складно говорить, а также отсутствие страха и стеснения перед аудиторией. Разминка лицевых мышц, работа над дикцией, умение складывать мысли в речь, правильное дыхание - это база номер один. Вторая - уметь выйти перед аудиторией и не спасовать, даже если не вполне уверен в контенте.
И во всем этом поможет караоке. И чем хуже вы поете - тем лучше (не стесняться петь хорошо каждый может). Отдельная задача со звездочкой - петь что-то лютое, недоступное и непонятное большинству, например - Amatory. После этого уже ничего не страшно!
Отдельно отмечу, что многие могут себе позволить петь, только изрядно набравшись. Не будем рассуждать о вреде алкоголя, это и так всем понятно. Так вот хорошая тренировка - это с каждым разом начинать петь под все меньшей мухой, чтобы в итоге начать без стыда и зазрения петь трезвым. Попробуйте! (Авторский метод Сергея Г., ему тут респект и лавры.) Кстати, ровно этим мы занимались на бизнес-тренинге на прошлой неделе всей большой командой. Дарю вам бесплатную идею для старта корпоратива. Главное - делать это с очень серьезным лицом.
👏9😁7🔥4
И снова про алгоритмы
Бытует мнение, что на бекенде алгоритмы - огого! А на фронте только кнопки красят. Но мы-то с вами знаем, что это не так. Хорошему фронтендеру (веб, мобилка - не важно) тоже частенько приходится применять алгоритмическое мышление и знание структур данных.
Начиная с более повседневных вещей типа оптимального обхода дерева или трансформации данных (очень желательно не за квадрат, не сожрать всю память, не крашнуться, и не словить ANR). Тут, кстати, цена неоптимального решения порой даже выше, чем на бекенде - сервера то все стерпят, а вот клиентские девайсы будут тормозить, греться и разряжаться.
Продолжим задачами типа мержа диффов при оптимистичном применении изменений локально. Особенно, когда данные могут разъехаться не только между клиентом и сервером, но и между несколькими клиентами. Примеры тому - собранная корзина в каком-нибудь еком-приложении, или пусть будет приложение заметок.
И закончим трудностями адаптации визуала к сложным данным. Например, вы пробовали в календаре отрисовать 5 частично пересекающихся встреч так, чтобы это оставалось читаемым? Или, скажем, задача визуализации графов с топологической сортировкой («А вызывает Б, значит А должно быть левее Б») и динамическим добавлением новых вершин так, чтобы пересечений линий было поменьше.
А вы спрашиваете, зачем алгосы на собеседованиях на фронтов. Не важно, какой путь выбрали вы - перекладывать жсоны или красить кнопки, алгосы ftw! Пишите в комментарии, как вы на фронтах применяете алгоритмы и структуры данных!
Бытует мнение, что на бекенде алгоритмы - огого! А на фронте только кнопки красят. Но мы-то с вами знаем, что это не так. Хорошему фронтендеру (веб, мобилка - не важно) тоже частенько приходится применять алгоритмическое мышление и знание структур данных.
Начиная с более повседневных вещей типа оптимального обхода дерева или трансформации данных (очень желательно не за квадрат, не сожрать всю память, не крашнуться, и не словить ANR). Тут, кстати, цена неоптимального решения порой даже выше, чем на бекенде - сервера то все стерпят, а вот клиентские девайсы будут тормозить, греться и разряжаться.
Продолжим задачами типа мержа диффов при оптимистичном применении изменений локально. Особенно, когда данные могут разъехаться не только между клиентом и сервером, но и между несколькими клиентами. Примеры тому - собранная корзина в каком-нибудь еком-приложении, или пусть будет приложение заметок.
И закончим трудностями адаптации визуала к сложным данным. Например, вы пробовали в календаре отрисовать 5 частично пересекающихся встреч так, чтобы это оставалось читаемым? Или, скажем, задача визуализации графов с топологической сортировкой («А вызывает Б, значит А должно быть левее Б») и динамическим добавлением новых вершин так, чтобы пересечений линий было поменьше.
А вы спрашиваете, зачем алгосы на собеседованиях на фронтов. Не важно, какой путь выбрали вы - перекладывать жсоны или красить кнопки, алгосы ftw! Пишите в комментарии, как вы на фронтах применяете алгоритмы и структуры данных!
🔥8😁1👀1
О дипломированных специалистах
Недавно в одном чате наблюдал мельком за дискуссией о необходимости высшего технического образования в IT. Вот да, правда ли нужно закончить универ, чтобы сделать успешную карьеру в IT? Как будто - нет. Но есть нюанс. Что может вам дать высшее техническое образование в профильном вузе/факультете?
Во-первых, дисциплину и умение учиться. Пройдя суровую школу серьезного ВУЗа вы научитесь преодолевать и достигать, находить решения и срезать углы. Познаете, что такое дедлайны, обратная связь и перформанс-ревью (в ВУЗах это по-старинке называют сессией). Научитесь быстро разбираться в неизвестном, постигать новое и совершать невозможное за ночь. В общем, будете лучше подготовлены к реальной жизни в энтерпрайзе.
Во-вторых, кругозор и базу. Как ни крути, большая часть того, чем мы занимаемся на работе, зиждется на знаниях, полученных в универе. Начиная с того, что кое-как прогать в универе все же учат, заканчивая пользой от понимания базовых штук типа матстата. А если вам в разработке приходится касаться ML, то ВУЗовские знания точно пригодятся. Да и разнообразие учебных курсов поможет расширить круг знаний и интересов. У меня было три семестра эзотерики - рефал, лисп и пролог. Писал ли я на них потом - конечно, нет. Полезно ли было для мозга потрогать функциональщину - точно да.
В-третьих, опыт. Если у вас в универе есть какие-то проекты, или, тем более, вы помимо пар делаете что-то полезное на кафедре, этот опыт полезен. Умение запускать и доводить до ума какие-то проекты, даже учебные, в плюс. Опыт работы в команде (иногда в учебных проектах бывает и такое) - тоже в плюс. Просто факт, что вы немного потрогали разные темы и технологии, поможет вам в дальнейшем. Например, я в универе в рамках одного из курсов писал простенькую игрушку на Qt. Спустя несколько лет мне нужно было принимать решение о выборе технологии, и я уже знал некоторые плюсы и минусы Qt, что изрядно помогло.
Можно ли получить все это без академического образования? Конечно, можно. Самообучение и реальный опыт могут заменить ВУЗ в каком-то объеме. Я даже знаю некоторых CTO без корочки (и очень даже крутых!). Но мое мнение - чтобы все это заменить, нужно быть либо очень талантливым, либо очень упорным и дисциплинированным. В массе - все же профильное образование является сильным подспорьем на старте карьеры.
А те, кто вкатывается в IT без универа, зато после курсов "С++ за 21 день" и всерьез думают, что они моментально стали супер-айтишниками - ну удачи, чё. С наскоку тут успеха не добиться. Хотя с этими вашими вайб-кодингами и курсорами теперь накодить что-то, с пяти метров выглядящее работоспособным, может любой гуманитарий. Правда, такая фигня получится... Но об этом я уже размышлял на заре этого канала.
Недавно в одном чате наблюдал мельком за дискуссией о необходимости высшего технического образования в IT. Вот да, правда ли нужно закончить универ, чтобы сделать успешную карьеру в IT? Как будто - нет. Но есть нюанс. Что может вам дать высшее техническое образование в профильном вузе/факультете?
Во-первых, дисциплину и умение учиться. Пройдя суровую школу серьезного ВУЗа вы научитесь преодолевать и достигать, находить решения и срезать углы. Познаете, что такое дедлайны, обратная связь и перформанс-ревью (в ВУЗах это по-старинке называют сессией). Научитесь быстро разбираться в неизвестном, постигать новое и совершать невозможное за ночь. В общем, будете лучше подготовлены к реальной жизни в энтерпрайзе.
Во-вторых, кругозор и базу. Как ни крути, большая часть того, чем мы занимаемся на работе, зиждется на знаниях, полученных в универе. Начиная с того, что кое-как прогать в универе все же учат, заканчивая пользой от понимания базовых штук типа матстата. А если вам в разработке приходится касаться ML, то ВУЗовские знания точно пригодятся. Да и разнообразие учебных курсов поможет расширить круг знаний и интересов. У меня было три семестра эзотерики - рефал, лисп и пролог. Писал ли я на них потом - конечно, нет. Полезно ли было для мозга потрогать функциональщину - точно да.
В-третьих, опыт. Если у вас в универе есть какие-то проекты, или, тем более, вы помимо пар делаете что-то полезное на кафедре, этот опыт полезен. Умение запускать и доводить до ума какие-то проекты, даже учебные, в плюс. Опыт работы в команде (иногда в учебных проектах бывает и такое) - тоже в плюс. Просто факт, что вы немного потрогали разные темы и технологии, поможет вам в дальнейшем. Например, я в универе в рамках одного из курсов писал простенькую игрушку на Qt. Спустя несколько лет мне нужно было принимать решение о выборе технологии, и я уже знал некоторые плюсы и минусы Qt, что изрядно помогло.
Можно ли получить все это без академического образования? Конечно, можно. Самообучение и реальный опыт могут заменить ВУЗ в каком-то объеме. Я даже знаю некоторых CTO без корочки (и очень даже крутых!). Но мое мнение - чтобы все это заменить, нужно быть либо очень талантливым, либо очень упорным и дисциплинированным. В массе - все же профильное образование является сильным подспорьем на старте карьеры.
А те, кто вкатывается в IT без универа, зато после курсов "С++ за 21 день" и всерьез думают, что они моментально стали супер-айтишниками - ну удачи, чё. С наскоку тут успеха не добиться. Хотя с этими вашими вайб-кодингами и курсорами теперь накодить что-то, с пяти метров выглядящее работоспособным, может любой гуманитарий. Правда, такая фигня получится... Но об этом я уже размышлял на заре этого канала.
💯23
Зирвак как платформа надежности
Готовил в субботу плов на мангале, и вот что подумал. Знаете, что общего у плова и хорошего продукта? Платформа.
Зирвак нужно варить долго, часа 2 хотя бы. Это основа вкуса. Так и платформа - залог качества, надежности и масштабируемости. Не надо тут спешить.
Мангал должен быть устойчивым и просторным, чтобы было удобно регулировать огонь. Так и инфраструктура должна помогать вам делать продукт, вы не должны с ней бороться и превозмогать.
Не жалейте лука - он все равно растворится в ноль, но вкус отдаст. Так и тесты - их много не бывает. Главное - помельче нарезать.
Без моркови плов - не плов. Без метрик/мониторингов/алертов/графиков продукт - не продукт. Просто не надо таким заниматься.
Специи - это дизайн-система. У вас точно есть свое чувство прекрасного, а иногда можно немного поимпровизировать, чтобы у всех был вау-эффект. Но острое не всем заходит, будьте осторожны.
Мясо - дело вкуса, а иногда - и религии. Постгрес, монга, мускуль - решать вам. Но оно должно быть очень хорошим и нежным. Готовить долго, и надо уметь. Но ради этого все и затевалось.
С рисом все в целом понятно. Тут можно звать продактов и пилить фичи.
Охапка дров - продукт готов!
Готовил в субботу плов на мангале, и вот что подумал. Знаете, что общего у плова и хорошего продукта? Платформа.
Зирвак нужно варить долго, часа 2 хотя бы. Это основа вкуса. Так и платформа - залог качества, надежности и масштабируемости. Не надо тут спешить.
Мангал должен быть устойчивым и просторным, чтобы было удобно регулировать огонь. Так и инфраструктура должна помогать вам делать продукт, вы не должны с ней бороться и превозмогать.
Не жалейте лука - он все равно растворится в ноль, но вкус отдаст. Так и тесты - их много не бывает. Главное - помельче нарезать.
Без моркови плов - не плов. Без метрик/мониторингов/алертов/графиков продукт - не продукт. Просто не надо таким заниматься.
Специи - это дизайн-система. У вас точно есть свое чувство прекрасного, а иногда можно немного поимпровизировать, чтобы у всех был вау-эффект. Но острое не всем заходит, будьте осторожны.
Мясо - дело вкуса, а иногда - и религии. Постгрес, монга, мускуль - решать вам. Но оно должно быть очень хорошим и нежным. Готовить долго, и надо уметь. Но ради этого все и затевалось.
С рисом все в целом понятно. Тут можно звать продактов и пилить фичи.
Охапка дров - продукт готов!
🔥18❤6😁6🤯2🤔1😱1💯1
Бизнес-план
Периодически на внутренней доске объявлений встречаю предложения по съему квартир. Коллеги часто сдают друг другу квартиры ниже рынка, получая проверенного и адекватного арендатора взамен на скидку. И иногда там встречается фича - "свежий ремонт, сдается впервые, никто раньше не жил!". Ага. Как будто это хорошо. Как будто от этого цена должна быть выше. Нет же!
У свежего ремонта, в котором никто не жил, очевидно будут "детские болячки". Только пожив несколько месяцев, их можно выявить и устранить.
Найти весь брак и косяки.
Заметить огрехи эргономичности.
Проверить все системы и инженерку.
Перенастроить технику.
Поменять шторы, потому что слишком светло.
Передвинуть тумбочку, стоящую аккурат на траектории мизинца ноги.
В общем, провести пусконаладку и обкатку.
И я должен за это еще и больше платить? Ну уж дудки. Предлагаю иначе - это вы (арендодатель) мне платите, чтобы я пожил у вас в свежем ремонте и обкатал его. А когда квартира будет готова к заселению живого человека - с него и берите деньги. Ладно, у меня, на самом деле, своя квартира есть. Но идею готов подарить читателю. А то ишь, повадились драть деньги за сырой продукт.
Периодически на внутренней доске объявлений встречаю предложения по съему квартир. Коллеги часто сдают друг другу квартиры ниже рынка, получая проверенного и адекватного арендатора взамен на скидку. И иногда там встречается фича - "свежий ремонт, сдается впервые, никто раньше не жил!". Ага. Как будто это хорошо. Как будто от этого цена должна быть выше. Нет же!
У свежего ремонта, в котором никто не жил, очевидно будут "детские болячки". Только пожив несколько месяцев, их можно выявить и устранить.
Найти весь брак и косяки.
Заметить огрехи эргономичности.
Проверить все системы и инженерку.
Перенастроить технику.
Поменять шторы, потому что слишком светло.
Передвинуть тумбочку, стоящую аккурат на траектории мизинца ноги.
В общем, провести пусконаладку и обкатку.
И я должен за это еще и больше платить? Ну уж дудки. Предлагаю иначе - это вы (арендодатель) мне платите, чтобы я пожил у вас в свежем ремонте и обкатал его. А когда квартира будет готова к заселению живого человека - с него и берите деньги. Ладно, у меня, на самом деле, своя квартира есть. Но идею готов подарить читателю. А то ишь, повадились драть деньги за сырой продукт.
❤5💊4👍2🤝1
Автопуть
Меня все же попросили рассказать, каков был мой путь в автомобилях. Что ж, погнали!
- Первой у меня была Nissan Almera 2004. Полторашка, механика - для первой самое то. Очень приятная машинка в своем сегменте.
- Потом захотелось чего-то нового, прям из салона. Так появилась Skoda Octavia 2012 1.8. Хороший агрегат, по сей день служит моему другу.
- А я пересел на новую Audi Q5 2014 дизель, потому что потянуло на премиум. Это идеальный автомобиль, на ней моя жена ездила аж до 2023.
- Жена училась водить, купил ей Mazda 2 2009 1.3 MT. Пока доучивалась, я катался сам. Веселая малышка, даже на MRW погоняла.
- Мне ауди наскучила, отдал ее жене, сам пересел на BMW 325 2006 на N52B25. Поселился в автосервисе, подружился с эвакуаторщиком.
- Надоело жить на сервисе, поменял на Toyota Camry 2006 3.5. Очень надежно и очень комфортно. Но очень скучно. Слишком скучно.
- Чтобы было весело, взял Subaru Impreza WRX 2001. Как положено, синюю, на золотистых дисках. Высокая лавка, подсветка днища. Разбил(
- После субарика снова захотелось в комфорт. И теперь - по-серьезному. Mercedes S-klasse 2001 - вышка. Ломался, но сначала довозил.
- Допом к мерсу взял турбовый Mitsubishi Eclipse 1999, как в форсаже и NFS. Угарнул по автозвуку. Но автомат все портил.
- Во время пандемии продал мерс и эклипс, а потом познал америку - Cadillac Escalade 2010. Но он меня трижды подвел, за что был продан.
- Познаем мир дальше - Infiniti FX37s 2010 в красивом бронзовом цвете. Стильно, быстро, но управляемость и колейность - мама дорогая!
- Увлекся дрифтом, взял Lexus IS 1999 (aka toyota altezza) и оторвался по полной - свап на 4л UZ и мкпп, полный обвес как у Дамира - лють!
- Комфорта не хватало, докупил Lexus LS460L 2008. Оказывается, мерс S-класса не такой уж крутой) LS просто восхитителен. И надежен.
- Потянуло на янгтаймеры, докупил Mercedes W124 1995 купе в отличном сохране. Чистый кайф и уважение на районе гарантированы.
- В 2022 делал ремонт, денег не хватило, пришлось продать Теззу, LS и 124(( Пересел на ВАЗ 2109. Лучше, чем на метро. Больше плюсов нет.
- Доделал ремонт, купил Toyota Cresta 1989. У самурая нет цели, есть только дырявый выхлоп и просевшие пружины. Но JDM в сердечке.
- JDM intencifies - взял кей-кар Honda N-box 2017. Угарная вещица, всем рекомендую. Но по трассе больше 110 ехать не хочет - мотор-то 0.6л.
- Чтобы ездить на дачу, докупил Toyota Celica 2000. Типично дачная тачка, да? Зато веселая, 200 сил на механике, едет бодро! А потом...
- Жене разбили ауди, пришлось продать селику, чтобы купить Mercedes A-klasse 2018. Сам тоже немало на ней катался. Но жене не зашла.
- И тут вылетает объява - Chrysler New-Yorker 1989. Бордовый, на бордовом велюре, слепые фары. Как не взять? Но нюансов у ровесницы - ой.
- Возвращаемся к премиуму - Porsche Panamera 4S 2012. Меньше, чем за 3 мульта, ты получаешь и скорость, и роскошь - очень нравится.
- Но подростковые гештальты сами себя не закроют. Mercedes G500 2003. Разумеется, переодетый под 63рест. Тачка ужасна, но это феномен.
- О, кабрика же еще не было. Mazda MX-5 2019. Про нее уже писал выше, в посте про покатушки на трек-дне MRW. Она прекрасна.
Продолжение следует...
Здесь я супер-коротко что-то обозначил про каждую машину, но если вы хотите про какую-то из них подробнее - пишите в комменты)
А чуть подробней про некоторые, про свое отношение к авто, и почему у мужчины в моменте должно быть 3 тачки, я рассказывал в подкасте.
Меня все же попросили рассказать, каков был мой путь в автомобилях. Что ж, погнали!
- Первой у меня была Nissan Almera 2004. Полторашка, механика - для первой самое то. Очень приятная машинка в своем сегменте.
- Потом захотелось чего-то нового, прям из салона. Так появилась Skoda Octavia 2012 1.8. Хороший агрегат, по сей день служит моему другу.
- А я пересел на новую Audi Q5 2014 дизель, потому что потянуло на премиум. Это идеальный автомобиль, на ней моя жена ездила аж до 2023.
- Жена училась водить, купил ей Mazda 2 2009 1.3 MT. Пока доучивалась, я катался сам. Веселая малышка, даже на MRW погоняла.
- Мне ауди наскучила, отдал ее жене, сам пересел на BMW 325 2006 на N52B25. Поселился в автосервисе, подружился с эвакуаторщиком.
- Надоело жить на сервисе, поменял на Toyota Camry 2006 3.5. Очень надежно и очень комфортно. Но очень скучно. Слишком скучно.
- Чтобы было весело, взял Subaru Impreza WRX 2001. Как положено, синюю, на золотистых дисках. Высокая лавка, подсветка днища. Разбил(
- После субарика снова захотелось в комфорт. И теперь - по-серьезному. Mercedes S-klasse 2001 - вышка. Ломался, но сначала довозил.
- Допом к мерсу взял турбовый Mitsubishi Eclipse 1999, как в форсаже и NFS. Угарнул по автозвуку. Но автомат все портил.
- Во время пандемии продал мерс и эклипс, а потом познал америку - Cadillac Escalade 2010. Но он меня трижды подвел, за что был продан.
- Познаем мир дальше - Infiniti FX37s 2010 в красивом бронзовом цвете. Стильно, быстро, но управляемость и колейность - мама дорогая!
- Увлекся дрифтом, взял Lexus IS 1999 (aka toyota altezza) и оторвался по полной - свап на 4л UZ и мкпп, полный обвес как у Дамира - лють!
- Комфорта не хватало, докупил Lexus LS460L 2008. Оказывается, мерс S-класса не такой уж крутой) LS просто восхитителен. И надежен.
- Потянуло на янгтаймеры, докупил Mercedes W124 1995 купе в отличном сохране. Чистый кайф и уважение на районе гарантированы.
- В 2022 делал ремонт, денег не хватило, пришлось продать Теззу, LS и 124(( Пересел на ВАЗ 2109. Лучше, чем на метро. Больше плюсов нет.
- Доделал ремонт, купил Toyota Cresta 1989. У самурая нет цели, есть только дырявый выхлоп и просевшие пружины. Но JDM в сердечке.
- JDM intencifies - взял кей-кар Honda N-box 2017. Угарная вещица, всем рекомендую. Но по трассе больше 110 ехать не хочет - мотор-то 0.6л.
- Чтобы ездить на дачу, докупил Toyota Celica 2000. Типично дачная тачка, да? Зато веселая, 200 сил на механике, едет бодро! А потом...
- Жене разбили ауди, пришлось продать селику, чтобы купить Mercedes A-klasse 2018. Сам тоже немало на ней катался. Но жене не зашла.
- И тут вылетает объява - Chrysler New-Yorker 1989. Бордовый, на бордовом велюре, слепые фары. Как не взять? Но нюансов у ровесницы - ой.
- Возвращаемся к премиуму - Porsche Panamera 4S 2012. Меньше, чем за 3 мульта, ты получаешь и скорость, и роскошь - очень нравится.
- Но подростковые гештальты сами себя не закроют. Mercedes G500 2003. Разумеется, переодетый под 63рест. Тачка ужасна, но это феномен.
- О, кабрика же еще не было. Mazda MX-5 2019. Про нее уже писал выше, в посте про покатушки на трек-дне MRW. Она прекрасна.
Продолжение следует...
Здесь я супер-коротко что-то обозначил про каждую машину, но если вы хотите про какую-то из них подробнее - пишите в комменты)
А чуть подробней про некоторые, про свое отношение к авто, и почему у мужчины в моменте должно быть 3 тачки, я рассказывал в подкасте.
🔥23😁5❤3👏1🤯1🆒1
Распределенный бог
Часто считается, что бог - это какая-то концентрированная сущность со своим мнением, планами и намерениями. Есть и другая точка зрения - что бог - это распределенная система, выраженная в каждом объекте вселенной и его состоянии в каждый момент времени. Эдакий комплекс всего, что есть в мире и происходит прямо сейчас. Децентрализованное провидение, целиком влияющее на каждый составляющий его объект.
Через это объясняется и отсутствие монокаузальности в наших действиях. Вот стоишь ты на кухне, занеся газету над мухой, в желании ее прихлопнуть. Кто виновен в неизбежной смерти насекомого? Ты, который не любит мух? Почтальон, принесший газету? Издание, выпустившее номер? А может, сама муха, залетевшая не в то окно? Ты с газетой в руке - это режущая кромка истории, а меч судьбы целиком так огромен, что никому его не увидеть. Это весь космос. Нет единопричинности, есть конъюнктура момента.
Та же философия применима к понятию счастья. Мы все хотим быть счастливы. Если разобрать эту интенцию до конца, мы желаем вот чего: чтобы нам немедленно стало хорошо. Другого счастья не бывает, потому что не бывает другого момента времени. Но как ни старайся, невозможно гарантированно приехать в точку под называнием "счастье" в результате лишь собственных усилий. Хотя бы потому, что в каждом нашем миге участвует весь остальной мир. А мы над ним не властны.
Это не отменяет необходимость прилагать свои усилия, сидеть на попе ровно и ждать у моря погоды не предлагаю. Но терзаться несовершенством мира и отчаиваться - тоже не вариант. Поэтому дорога к счастью только одна. Смирись в своем сердце с тем, что происходит в эту секунду. Прими все так, как если бы ты мечтал об этом всю жизнь. Просто растворись в моменте. И как только ты перестанешь с ним бороться, ты поймешь, что тебе никогда не нужно было ничего искать.
Свобода - тоже в принятии. Прими все, что происходит в эту секунду с тобой - ибо это и есть воля божья (того самого, распределенного). Как только ты сделаешь так и расслабишься, ты поймешь, что здесь и скрыта единственная доступная человеку свобода. Почему свободу называют "волей"? Да потому, что свобода и есть полное принятие воли бога/вселенной/космоса как своей. Любое несогласие в этой волей карается немедленно и жестоко, и кара заключается в ощущении, что ты несвободен и несчастен. Не-счастье всегда сделано из борьбы за то, чтобы текущая секунда была какой-то другой. Не такой, как есть. Просто позволь происходящему происходить. Оно будет происходить и без твоего позволения.
И, на всякий случай, отмечу, что это все не про достижение какого-либо результата (в работе, карьере, личной жизни). Там мотивация и механика совершенно иная. Это лишь о своем мироощущении на пути к цели. Если ты все делаешь правильно, и провидение вселенной тебе благоволит - у тебя все получится. А страдать по пути - ну такое.
(Инспирировано (и частично процитировано) произведениями В. Пелевина)
Часто считается, что бог - это какая-то концентрированная сущность со своим мнением, планами и намерениями. Есть и другая точка зрения - что бог - это распределенная система, выраженная в каждом объекте вселенной и его состоянии в каждый момент времени. Эдакий комплекс всего, что есть в мире и происходит прямо сейчас. Децентрализованное провидение, целиком влияющее на каждый составляющий его объект.
Через это объясняется и отсутствие монокаузальности в наших действиях. Вот стоишь ты на кухне, занеся газету над мухой, в желании ее прихлопнуть. Кто виновен в неизбежной смерти насекомого? Ты, который не любит мух? Почтальон, принесший газету? Издание, выпустившее номер? А может, сама муха, залетевшая не в то окно? Ты с газетой в руке - это режущая кромка истории, а меч судьбы целиком так огромен, что никому его не увидеть. Это весь космос. Нет единопричинности, есть конъюнктура момента.
Та же философия применима к понятию счастья. Мы все хотим быть счастливы. Если разобрать эту интенцию до конца, мы желаем вот чего: чтобы нам немедленно стало хорошо. Другого счастья не бывает, потому что не бывает другого момента времени. Но как ни старайся, невозможно гарантированно приехать в точку под называнием "счастье" в результате лишь собственных усилий. Хотя бы потому, что в каждом нашем миге участвует весь остальной мир. А мы над ним не властны.
Это не отменяет необходимость прилагать свои усилия, сидеть на попе ровно и ждать у моря погоды не предлагаю. Но терзаться несовершенством мира и отчаиваться - тоже не вариант. Поэтому дорога к счастью только одна. Смирись в своем сердце с тем, что происходит в эту секунду. Прими все так, как если бы ты мечтал об этом всю жизнь. Просто растворись в моменте. И как только ты перестанешь с ним бороться, ты поймешь, что тебе никогда не нужно было ничего искать.
Свобода - тоже в принятии. Прими все, что происходит в эту секунду с тобой - ибо это и есть воля божья (того самого, распределенного). Как только ты сделаешь так и расслабишься, ты поймешь, что здесь и скрыта единственная доступная человеку свобода. Почему свободу называют "волей"? Да потому, что свобода и есть полное принятие воли бога/вселенной/космоса как своей. Любое несогласие в этой волей карается немедленно и жестоко, и кара заключается в ощущении, что ты несвободен и несчастен. Не-счастье всегда сделано из борьбы за то, чтобы текущая секунда была какой-то другой. Не такой, как есть. Просто позволь происходящему происходить. Оно будет происходить и без твоего позволения.
И, на всякий случай, отмечу, что это все не про достижение какого-либо результата (в работе, карьере, личной жизни). Там мотивация и механика совершенно иная. Это лишь о своем мироощущении на пути к цели. Если ты все делаешь правильно, и провидение вселенной тебе благоволит - у тебя все получится. А страдать по пути - ну такое.
(Инспирировано (и частично процитировано) произведениями В. Пелевина)
👍12❤3🔥2
Доверьте работу профессионалам
Посмотрел на днях фильм F1 (про формулу 1). И я получил огромное удовольствие от того, насколько этот фильм близок к реальности. Как автофанат, я в целом шарю достаточно, чтобы замечать автоляпы во многих фильмов (да, Форсаж лучше считать просто фантастикой и относиться к нему соответствующе).
В закулисье Формулы-1 я разбираюсь чуть хуже, чем в медицине (Drive to survive я посмотрел только 5 сезонов против 8 в House M.D.), но все же докопаться было особо не до чего. А участие реальных действующих лиц из Ф1 в фильме и вовсе считаю прекрасным режиссерским ходом.
А знаете, почему им это удалось? Потому что со-продюсером фильма выступил Льюис Хэмилтон, 7-кратный чемпион Ф1. Доверьте работу профессионалам!
И та же история с ремонтом. Даже если у вас руки растут из правильного места, вы можете что-то средне-сложное сделать сами. Но выйдет дольше и хуже, чем если обратиться к тем, кто основной хлеб зарабатывает этим - электрики, плиточники, сантехники справятся лучше бекендеров и тимлидов.
На конференции про архитектуру лучше расскажет тот, кто годами hands-on этим занимается, нежели руководитель-говорящая-голова, который, может, еще не все забыл, но уже не так репрезентативен.
Главное - не давайте бекендерам делать UI/UX, даже для админки ;)
Это я к чему? T-shape - это хорошо. Fullstack - уже, обычно, не так хорошо. Некомпетентность - совсем плохо. Используйте свои сильные стороны, чтобы нанести пользу, даже за пределами своего основного проекта. А там, где вам не хватает хардов - не всегда получится залить все софтами, призовите на помощь более компетентного спеца.
Посмотрел на днях фильм F1 (про формулу 1). И я получил огромное удовольствие от того, насколько этот фильм близок к реальности. Как автофанат, я в целом шарю достаточно, чтобы замечать автоляпы во многих фильмов (да, Форсаж лучше считать просто фантастикой и относиться к нему соответствующе).
В закулисье Формулы-1 я разбираюсь чуть хуже, чем в медицине (Drive to survive я посмотрел только 5 сезонов против 8 в House M.D.), но все же докопаться было особо не до чего. А участие реальных действующих лиц из Ф1 в фильме и вовсе считаю прекрасным режиссерским ходом.
А знаете, почему им это удалось? Потому что со-продюсером фильма выступил Льюис Хэмилтон, 7-кратный чемпион Ф1. Доверьте работу профессионалам!
И та же история с ремонтом. Даже если у вас руки растут из правильного места, вы можете что-то средне-сложное сделать сами. Но выйдет дольше и хуже, чем если обратиться к тем, кто основной хлеб зарабатывает этим - электрики, плиточники, сантехники справятся лучше бекендеров и тимлидов.
На конференции про архитектуру лучше расскажет тот, кто годами hands-on этим занимается, нежели руководитель-говорящая-голова, который, может, еще не все забыл, но уже не так репрезентативен.
Главное - не давайте бекендерам делать UI/UX, даже для админки ;)
Это я к чему? T-shape - это хорошо. Fullstack - уже, обычно, не так хорошо. Некомпетентность - совсем плохо. Используйте свои сильные стороны, чтобы нанести пользу, даже за пределами своего основного проекта. А там, где вам не хватает хардов - не всегда получится залить все софтами, призовите на помощь более компетентного спеца.
🔥12😁3
Стратегия надежности (1/3)
В одном из постов выше я ворчал на тему того, что надежностью заниматься не надо. На самом деле - надо. И финансовые выкладки это подтверждают. Особенно если учесть, что при инцидентах вы не только упускаете часть заказов и недозарабатываете на них, но и фэйлите ту часть заказов, которые вы приняли, но не смогли выполнить.
На днях составил некий документ, преследующий цель зафиксировать стратегию надежности, чтобы все было наглядно и под рукой. Возьму на себя смелость им поделиться - самые секретные части я оттуда вырежу. Остальное - здравый смысл, упакованный в actionable план. Вряд ли там много нового или неочевидного, но чаще всего мы упускаем как раз самые очевидные вещи.
Приложу отдельными постами (иначе не влезет) манифест и план. В манифесте - цель и майндсет, позволяющий ее достичь. В плане - шаги, направленные на достижение цели. Часть шагов я по понятным причинам не могу публиковать наружу. Каких-то очевидных шагов в плане нет - по ним уже и так все неплохо. Часть вещей из плана у нас уже есть, но в них есть точки роста. А про часть я чуть подробней поворчу в следующих постах.
Кстати, если вы классно умеете делать такие штуки, го к нам! https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)
В одном из постов выше я ворчал на тему того, что надежностью заниматься не надо. На самом деле - надо. И финансовые выкладки это подтверждают. Особенно если учесть, что при инцидентах вы не только упускаете часть заказов и недозарабатываете на них, но и фэйлите ту часть заказов, которые вы приняли, но не смогли выполнить.
На днях составил некий документ, преследующий цель зафиксировать стратегию надежности, чтобы все было наглядно и под рукой. Возьму на себя смелость им поделиться - самые секретные части я оттуда вырежу. Остальное - здравый смысл, упакованный в actionable план. Вряд ли там много нового или неочевидного, но чаще всего мы упускаем как раз самые очевидные вещи.
Приложу отдельными постами (иначе не влезет) манифест и план. В манифесте - цель и майндсет, позволяющий ее достичь. В плане - шаги, направленные на достижение цели. Часть шагов я по понятным причинам не могу публиковать наружу. Каких-то очевидных шагов в плане нет - по ним уже и так все неплохо. Часть вещей из плана у нас уже есть, но в них есть точки роста. А про часть я чуть подробней поворчу в следующих постах.
Кстати, если вы классно умеете делать такие штуки, го к нам! https://yandex.ru/jobs/services/eda или пишите в предложку (или личку @jkennedy)
Стратегия надежности (2/3)
Манифест:
Как гласит девиз МЧС, "Предупреждение, спасение, помощь".
Так и с надежностью - инциденты нужно предотвращать, купировать и выносить из них уроки.
Цель.
- 99.95% в заказах по атласу (внутренняя система детекта аномалий). 99.99% rps-uptime по сервисам tier A (сервисы, влияющие на цикл заказа).
- Соответствие тира критичности и тира надежности сервисов по модели 9999 (внутренняя классификация тиров надежности и требования к ним).
- Фокус на спасение заказов на более поздних стадиях, когда в случае потери будут большие инсентивы (сопутствующие потери на компенсации).
Предупреждение.
Лучший инцидент - тот, который не случился благодаря нашим стараниям.
Для этого повышаем качество релизов, не допускаем рецидивов, снижаем количество критичных зависимостей.
Спасение.
Как ни предотвращай, инциденты всегда будут случаться. Важно уметь их быстро купировать.
Для этого улучшаем реагирование, рычаги снижения влияния, инструментарий поиска руткоза, обзервабилити.
Помощь.
Достичь успеха можно только направленными совместными усилиями команды.
Важно, чтобы команды друг другу в этом помогали. Платформа - продукту. Продукт - платформе. Взаимозависимые команды - друг другу.
Манифест:
Как гласит девиз МЧС, "Предупреждение, спасение, помощь".
Так и с надежностью - инциденты нужно предотвращать, купировать и выносить из них уроки.
Цель.
- 99.95% в заказах по атласу (внутренняя система детекта аномалий). 99.99% rps-uptime по сервисам tier A (сервисы, влияющие на цикл заказа).
- Соответствие тира критичности и тира надежности сервисов по модели 9999 (внутренняя классификация тиров надежности и требования к ним).
- Фокус на спасение заказов на более поздних стадиях, когда в случае потери будут большие инсентивы (сопутствующие потери на компенсации).
Предупреждение.
Лучший инцидент - тот, который не случился благодаря нашим стараниям.
Для этого повышаем качество релизов, не допускаем рецидивов, снижаем количество критичных зависимостей.
Спасение.
Как ни предотвращай, инциденты всегда будут случаться. Важно уметь их быстро купировать.
Для этого улучшаем реагирование, рычаги снижения влияния, инструментарий поиска руткоза, обзервабилити.
Помощь.
Достичь успеха можно только направленными совместными усилиями команды.
Важно, чтобы команды друг другу в этом помогали. Платформа - продукту. Продукт - платформе. Взаимозависимые команды - друг другу.
👍1
Стратегия надежности (3/3)
Проекты, задачи, процессы:
Качество релизов:
- автоматические стрельбы по сервисам тира А в ci-пайплайне при каждой сборке (поможет отловить снижение производительности из-за неаккуратных изменений в коде, корки и утечки, снижение капасити, повышение таймингов)
- регулярное нагрузочное тестирование в продакшне танком (читающие сценарии) и виртуальными заказами (цикл заказа) (поможет контролировать капасити системы в целом в реальных условиях)
- автоматизация тестирования, близкая к 80% (снижает человеческий фактор, повышает полноту регресса)
- модуляризация, флексизация (bdui-механика), микрофронты (позволят кататься меньшими кусочками и не ломать смежную функциональность)
Предотвращение инцидентов из-за потенциально известных проблем:
- снижаем SLA на блокирующие action-item-ы к инцидентам (позволит снизить вероятность рецидива)
- держим SLA по дьюти (обращения пользователей и коллег) first-touch&full-resolve и ZBP blockers (ибо любой дьютик или багрепорт - потенциальный предвестник инцидента)
- регулярные учения -дц (помогает находить валенки на пульте в тепличных условиях)
- автоскейлер (помогает автомагически держать нужное капасити для cpu-bound сервисов с быстрым стартом)
- помогаем партнерам быть стабильнее (детали - <censored>)
Снижение зависимостей:
- <тут было несколько пунктов про вынос из некоторых сервисов той функциональности, которая нужна на разных этапах пользовательского пути, чтобы меньше компонент упирались в один сервис, предоставляющий нужные всем данные>
- регулярно проводим учения хаосом в проде для сервисов тира Б (поможет найти неочевидные зависимости)
Улучшаем реагирование:
- повышаем alerts uptime (чтобы не было слепоты к алертам)
- держим тримап (инструмент визуализации алертов) зеленым (также для снижения слепоты)
- автопротоколы там, где их еще нет (+эскалация)
- растим обзервабилити клиентских ошибок (детали - <censored>)
Ускоряем купирование:
- автооткат в случае проблем, как минимум для престейбла (ускоряет откат проблемного релиза, снижает человеческий фактор)
- проводим учения по восстановлению сервиса (поможет отработать навыки координации и траблшутинга для дежурных)
- ускоряем старт сервисов, которые поднимаются слишком долго (позволит быстрее откатываться и докидываться)
- инструкции на случай типовых поломок - фолбеки, способы митигации (поможет быстрее найти нужный рубильник)
- возможно, попробуем AI для определения руткоза и/или способов купирования
Снижаем импакт:
- тыквы (продуктовые фолбеки и деградации вида "хорошая мина при плохой игре")
- наведем порядок в дизастерах и авто-деградациях (сейчас там есть точки роста)
- мета-конфиги для быстрого включения дизастер-режимов в различных системах (автоматизация синхронного включения режимов деградации в разных частях системы)
- точность биллинга (детали - <censored>)
Проекты, задачи, процессы:
Качество релизов:
- автоматические стрельбы по сервисам тира А в ci-пайплайне при каждой сборке (поможет отловить снижение производительности из-за неаккуратных изменений в коде, корки и утечки, снижение капасити, повышение таймингов)
- регулярное нагрузочное тестирование в продакшне танком (читающие сценарии) и виртуальными заказами (цикл заказа) (поможет контролировать капасити системы в целом в реальных условиях)
- автоматизация тестирования, близкая к 80% (снижает человеческий фактор, повышает полноту регресса)
- модуляризация, флексизация (bdui-механика), микрофронты (позволят кататься меньшими кусочками и не ломать смежную функциональность)
Предотвращение инцидентов из-за потенциально известных проблем:
- снижаем SLA на блокирующие action-item-ы к инцидентам (позволит снизить вероятность рецидива)
- держим SLA по дьюти (обращения пользователей и коллег) first-touch&full-resolve и ZBP blockers (ибо любой дьютик или багрепорт - потенциальный предвестник инцидента)
- регулярные учения -дц (помогает находить валенки на пульте в тепличных условиях)
- автоскейлер (помогает автомагически держать нужное капасити для cpu-bound сервисов с быстрым стартом)
- помогаем партнерам быть стабильнее (детали - <censored>)
Снижение зависимостей:
- <тут было несколько пунктов про вынос из некоторых сервисов той функциональности, которая нужна на разных этапах пользовательского пути, чтобы меньше компонент упирались в один сервис, предоставляющий нужные всем данные>
- регулярно проводим учения хаосом в проде для сервисов тира Б (поможет найти неочевидные зависимости)
Улучшаем реагирование:
- повышаем alerts uptime (чтобы не было слепоты к алертам)
- держим тримап (инструмент визуализации алертов) зеленым (также для снижения слепоты)
- автопротоколы там, где их еще нет (+эскалация)
- растим обзервабилити клиентских ошибок (детали - <censored>)
Ускоряем купирование:
- автооткат в случае проблем, как минимум для престейбла (ускоряет откат проблемного релиза, снижает человеческий фактор)
- проводим учения по восстановлению сервиса (поможет отработать навыки координации и траблшутинга для дежурных)
- ускоряем старт сервисов, которые поднимаются слишком долго (позволит быстрее откатываться и докидываться)
- инструкции на случай типовых поломок - фолбеки, способы митигации (поможет быстрее найти нужный рубильник)
- возможно, попробуем AI для определения руткоза и/или способов купирования
Снижаем импакт:
- тыквы (продуктовые фолбеки и деградации вида "хорошая мина при плохой игре")
- наведем порядок в дизастерах и авто-деградациях (сейчас там есть точки роста)
- мета-конфиги для быстрого включения дизастер-режимов в различных системах (автоматизация синхронного включения режимов деградации в разных частях системы)
- точность биллинга (детали - <censored>)
🔥5
Трудности перевода
Про свое отношение к ИИ в разработке я уже писал - раз , два , три , четыре поста. Но за эти пару месяцев я стал замечать еще один факт, который лишний раз демонстрирует, что ИИ не так хорош, как принято думать.
Я все чаще встречаю в разных местах фразы типа "запустили каталог готовых промтов", "self-service аналитика с конкретными промтами", "поделились промтами", "отладили промты и стало хорошо" и так далее.
Это что же получается, та самая штука, которая должна понимать нас с нашей естественной речью, для которой не нужно обладать специфичными знаниями, и которая чуть ли не мысли читает - она на самом деле нормально (корректно) работает только с выверенным до запятой запросом? А если сформулировать мысль хоть чуточку иначе - выдает фигню и галлюцинирует? Как так то?)
В таком случае, оно мне больше напоминает еще-более-высокоуровневый язык программирования, для которого нужно как-то специально учиться и запоминать/записывать инструкции/примитивы. Да еще и отлаживать потом методом перебора и последовательного приближения. Просто инструкции этого языка укрупнились и вышли на более высокий уровень абстракций.
Ну как переход от ассемблера к сям ("ого, можно самому не мувать регистры!") или от сей к го/джаве ("ого, можно не выделять и не освобождать память!"), так и тут - "ого, можно не писать руками for, офигеть".
Я уж молчу о том, что, как за последнее время подмечают все сеньорные коллеги, думать за тебя ллм-ка не может. Если ты сам знаешь, как решить задачу - она тебе поможет. Если не знаешь - не поможет.
В общем, магии снова не случилось. Никакого вайба.
Про свое отношение к ИИ в разработке я уже писал - раз , два , три , четыре поста. Но за эти пару месяцев я стал замечать еще один факт, который лишний раз демонстрирует, что ИИ не так хорош, как принято думать.
Я все чаще встречаю в разных местах фразы типа "запустили каталог готовых промтов", "self-service аналитика с конкретными промтами", "поделились промтами", "отладили промты и стало хорошо" и так далее.
Это что же получается, та самая штука, которая должна понимать нас с нашей естественной речью, для которой не нужно обладать специфичными знаниями, и которая чуть ли не мысли читает - она на самом деле нормально (корректно) работает только с выверенным до запятой запросом? А если сформулировать мысль хоть чуточку иначе - выдает фигню и галлюцинирует? Как так то?)
В таком случае, оно мне больше напоминает еще-более-высокоуровневый язык программирования, для которого нужно как-то специально учиться и запоминать/записывать инструкции/примитивы. Да еще и отлаживать потом методом перебора и последовательного приближения. Просто инструкции этого языка укрупнились и вышли на более высокий уровень абстракций.
Ну как переход от ассемблера к сям ("ого, можно самому не мувать регистры!") или от сей к го/джаве ("ого, можно не выделять и не освобождать память!"), так и тут - "ого, можно не писать руками for, офигеть".
Я уж молчу о том, что, как за последнее время подмечают все сеньорные коллеги, думать за тебя ллм-ка не может. Если ты сам знаешь, как решить задачу - она тебе поможет. Если не знаешь - не поможет.
В общем, магии снова не случилось. Никакого вайба.
💯21👍2
Mercedes-Benz Panamera WRX
Что общего у Mercedes-Benz W124, Porsche Panamera и Subaru Impreza WRX? Во-первых, они все классные. А во-вторых, про них меня попросили рассказать подробнее в комментах к посту про мой автопуть
Mercedes-Benz W124. Легенда и живая классика. Эстетика 90-х, притягивающая взгляды ценителей и не только. Автомобиль с душой и характером, комфортный и благородный. В нем чувствуется какая-то внутренняя интеллигентность, а на ходу она больше напоминает небольшой дорогой катер. В конце концов, получаешь удовольствие от самого факта обладания ей. В ней качественные материалы, монументальная тяжесть и фишечки, которых не ожидаешь от 90-х (например, ИК-ключ или автоподача ремня).
Мой экземпляр был 1995 года, купе-хардтоп, в состоянии "булочка" (не "музей", но вид имеет). Притом я за ней ездил в Питер - именно там нашелся интересный вариант. Были сомнения, доеду ли я на ней до Москвы, поэтому в дорогу были запасены: все жидкости, набор инструментов, вэдэшка, скотч, стяжки, насос и многое другое. Однако, ничего не пригодилось. И в последствии машина показала себя надежным агрегатом, хотя внимания и требовала. Впрочем, как и другие мерседесы - сначала довозила до пункта назначения (в отличие, например, от Эскалейда, который меня трижды подвел в самые неподходящие моменты - если хотите эти кул-стори, пишите в комменты). Главное - избегайте моторов на каеджетронике.
Porsche Panamera. Тоже катер, даже более премиальный, но еще и быстроходный. Редкий компромисс между комфортом и драйвом. С одной стороны, это пятиметровая баржа на пневме с потрясным качеством салона и материалов. Реальный премиум, на голову выше большой немецкой тройки. С другой - это все-таки Порше, и 400-сильный V8 отлично сочетается с отточенным шасси. Машина управляется превосходно (по меркам двухтонного бегемотика) и дает много удовольствия за рулем.
Мой экземпляр 2012 года был куплен полтора года назад меньше, чем за 3 миллиона рублей - на мой взгяд, очень неплохое вложение. Даже на пробеге чуть за 100 тысяч, состояние прекрасное, машина имеет лютый запас прочности. Хотя обслуживание недешево - за год тысяч 200 она вполне может просить. Главное - не берите из-под горячих ребят, которые на них ураганят и плохо обслуживают. Лучше воспользоваться подбором и обязательно проверять движок с эндоскопом - они склонны к задирам.
Subaru Impreza WRX. Продолжая морские метафоры - это бешеная тайская лодка на джейзете, избыточно быстрая, шумная, неуправляемая, некомфортная. Но очень нравится. Харизма так и прет - начиная с фирменного бу-бу-бу от неравнодлинного коллектора оппозитника, и заканчивая фирменным же полным приводом, позволяющим грести на всех парах по любому покрытию. Старая японская школа - аскетизм в сочетании с диким кайфом от вождения. Зимой прямо едет редко, но ты удивительно быстро добираешься до пункта назначения.
Мой экземпляр был 2001 года - так называемый, "лупатый". Естественно, синий. Разумеется, на золотых дисках (правда, только летних). Первым делом поменял лавку на высокую от sti (да еще и с распорками в духе wrc). Вторым - сделал подсветку под днищем в духе форсажа и need for speed. Непременно поставил blow-off. Выря вполне хватает, сти - даже перебор. Увы, машина пала в неравной борбе с бетонной стеной развязки ТТК в условиях гололедицы, поворота, уклона, обратного бенкинга и хреновой липучки.
Что общего у Mercedes-Benz W124, Porsche Panamera и Subaru Impreza WRX? Во-первых, они все классные. А во-вторых, про них меня попросили рассказать подробнее в комментах к посту про мой автопуть
Mercedes-Benz W124. Легенда и живая классика. Эстетика 90-х, притягивающая взгляды ценителей и не только. Автомобиль с душой и характером, комфортный и благородный. В нем чувствуется какая-то внутренняя интеллигентность, а на ходу она больше напоминает небольшой дорогой катер. В конце концов, получаешь удовольствие от самого факта обладания ей. В ней качественные материалы, монументальная тяжесть и фишечки, которых не ожидаешь от 90-х (например, ИК-ключ или автоподача ремня).
Мой экземпляр был 1995 года, купе-хардтоп, в состоянии "булочка" (не "музей", но вид имеет). Притом я за ней ездил в Питер - именно там нашелся интересный вариант. Были сомнения, доеду ли я на ней до Москвы, поэтому в дорогу были запасены: все жидкости, набор инструментов, вэдэшка, скотч, стяжки, насос и многое другое. Однако, ничего не пригодилось. И в последствии машина показала себя надежным агрегатом, хотя внимания и требовала. Впрочем, как и другие мерседесы - сначала довозила до пункта назначения (в отличие, например, от Эскалейда, который меня трижды подвел в самые неподходящие моменты - если хотите эти кул-стори, пишите в комменты). Главное - избегайте моторов на каеджетронике.
Porsche Panamera. Тоже катер, даже более премиальный, но еще и быстроходный. Редкий компромисс между комфортом и драйвом. С одной стороны, это пятиметровая баржа на пневме с потрясным качеством салона и материалов. Реальный премиум, на голову выше большой немецкой тройки. С другой - это все-таки Порше, и 400-сильный V8 отлично сочетается с отточенным шасси. Машина управляется превосходно (по меркам двухтонного бегемотика) и дает много удовольствия за рулем.
Мой экземпляр 2012 года был куплен полтора года назад меньше, чем за 3 миллиона рублей - на мой взгяд, очень неплохое вложение. Даже на пробеге чуть за 100 тысяч, состояние прекрасное, машина имеет лютый запас прочности. Хотя обслуживание недешево - за год тысяч 200 она вполне может просить. Главное - не берите из-под горячих ребят, которые на них ураганят и плохо обслуживают. Лучше воспользоваться подбором и обязательно проверять движок с эндоскопом - они склонны к задирам.
Subaru Impreza WRX. Продолжая морские метафоры - это бешеная тайская лодка на джейзете, избыточно быстрая, шумная, неуправляемая, некомфортная. Но очень нравится. Харизма так и прет - начиная с фирменного бу-бу-бу от неравнодлинного коллектора оппозитника, и заканчивая фирменным же полным приводом, позволяющим грести на всех парах по любому покрытию. Старая японская школа - аскетизм в сочетании с диким кайфом от вождения. Зимой прямо едет редко, но ты удивительно быстро добираешься до пункта назначения.
Мой экземпляр был 2001 года - так называемый, "лупатый". Естественно, синий. Разумеется, на золотых дисках (правда, только летних). Первым делом поменял лавку на высокую от sti (да еще и с распорками в духе wrc). Вторым - сделал подсветку под днищем в духе форсажа и need for speed. Непременно поставил blow-off. Выря вполне хватает, сти - даже перебор. Увы, машина пала в неравной борбе с бетонной стеной развязки ТТК в условиях гололедицы, поворота, уклона, обратного бенкинга и хреновой липучки.
🔥7👍1
Надежность: качество релизов
Недавно писал сюда нашу стратегию надежности. Думаю, стоит раскрыть чуть подробней некоторые пункты - почему они важны и полезны. В этот раз - про качество релизов.
Пусть у вас в эксплуатации находится сложная и развестстая система сервисов, обеспечивающих функционирование вашего продукта. Даже если ее не трогать (вообще убрать руки с клавиатуры) она долго не протянет. Но мы же постоянно норовим нанести пользы и причинить добро. А потому катаем разного рода релизы по 50+ раз в неделю (это не преувеличение, это количество релизов только бекендов Еды за прошлую неделю).
Каждый релиз сопряжен с рисками возникновения инцидента. Можно ошибиться в коде, можно подтянуть бажную зависимость, можно неправильно рассчитать нагрузку, можно забыть проковырять сетевую дырку - возможных причин упасть больше, чем глаз, следящих за выкладками. Поэтому системно повышать стабильность релизов и автоматизировать это - благо.
Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.
Также можно проверять капасити системы end-to-end нагрузочным тестированием в продакшне. Это поможет своевременно заметить нахватку запаса прочности по системе в целом, а иногда - заметить проблемный релиз, произошедший между регулярными стрельбами. Тестировать можно скриптом, можно танком - важно, что если у вас транзакционный сервис, должен проверяться цикл заказа (главное - не забудьте отметить в системе тестовые заказы тестовыми).
Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.
Ну и понятная, но не очень простая в реализации вещь - кататься лучше маленькими кусочками. Чтобы не было принципа "одно лечим - другое калечим". Разбиение приложения на модули, уход от монолитов (не только на беке - с фронтами та же история), сокращение импакта изменений, изоляция блоков - залог более крепкого сна после выкладки. Различные bdui-подходы этому тоже помогают. Впрочем, тема bdui намного шире, про нее стоит как-нибудь поразгонять отдельно.
Недавно писал сюда нашу стратегию надежности. Думаю, стоит раскрыть чуть подробней некоторые пункты - почему они важны и полезны. В этот раз - про качество релизов.
Пусть у вас в эксплуатации находится сложная и развестстая система сервисов, обеспечивающих функционирование вашего продукта. Даже если ее не трогать (вообще убрать руки с клавиатуры) она долго не протянет. Но мы же постоянно норовим нанести пользы и причинить добро. А потому катаем разного рода релизы по 50+ раз в неделю (это не преувеличение, это количество релизов только бекендов Еды за прошлую неделю).
Каждый релиз сопряжен с рисками возникновения инцидента. Можно ошибиться в коде, можно подтянуть бажную зависимость, можно неправильно рассчитать нагрузку, можно забыть проковырять сетевую дырку - возможных причин упасть больше, чем глаз, следящих за выкладками. Поэтому системно повышать стабильность релизов и автоматизировать это - благо.
Например, сделать в ci-пайплайне автоматическое нагрузочное тестирование микросервиса в изолированном load-окружении перед каждой выкладкой. Если ваш сервис поработает хотя бы 10-15 минут под полной нагрузкой, у вас будут шансы увидеть намного больше, чем при функциональном тестировании - обычные тесты не смогут спровоцировать корки (сегфолты), утечки или проезды по памяти. Вы сможете убедиться, что утилизация ресурсов и тайминги ответов не ухудшаются vs прошлый релиз. Что вы нигде не наворотили с алгоритмической сложностью, сделав вложенный цикл или выбрав неудачную структуру данных. Да, внедрение требует усилий. Да, нужно поддерживать патроны (запросы) в актуальном и релевантном состоянии. Да, отсутствие проблем в релизе это не гарантирует. Но это хорошая солома, которую лучше подстелить.
Также можно проверять капасити системы end-to-end нагрузочным тестированием в продакшне. Это поможет своевременно заметить нахватку запаса прочности по системе в целом, а иногда - заметить проблемный релиз, произошедший между регулярными стрельбами. Тестировать можно скриптом, можно танком - важно, что если у вас транзакционный сервис, должен проверяться цикл заказа (главное - не забудьте отметить в системе тестовые заказы тестовыми).
Разумеется, у вас есть тестирование. Но если оно по большей части ручное, вам не избежать ошибок из-за человеческого фактора. А если у вас в добавок очень много тесткейсов, вряд ли вы сможете при каждом релизе проверять их все. Скорее всего, вы придумаете какой-то подход с чередованием паков тестов от релиза к релизу. Но автоматизировав 75-80-90% тестов, вы получите и снижение пропусков, и возможность всегда гонять весь пак регресс-тестов. Без этого - никак.
Ну и понятная, но не очень простая в реализации вещь - кататься лучше маленькими кусочками. Чтобы не было принципа "одно лечим - другое калечим". Разбиение приложения на модули, уход от монолитов (не только на беке - с фронтами та же история), сокращение импакта изменений, изоляция блоков - залог более крепкого сна после выкладки. Различные bdui-подходы этому тоже помогают. Впрочем, тема bdui намного шире, про нее стоит как-нибудь поразгонять отдельно.
Про BDUI
Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.
Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.
Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.
Но вскоре подоспела третья генерация на основе решения "FLEX", зародившегося в Маркете. Тут уже совсем другие пироги - с бекенда можно задавать не только сетку виджетов, но и сами виджеты, включая верстку, экшны, навигацию. Клиент становится тоньше - по сути для отрисовки экрана достаточно SDK, а логика и верстка пишутся на бекенде на Котлине (впрочем, как я понимаю, от котлина там по сути только синтаксис, потому что все равно все примитивы там от фреймворка).
Чем это хорошо?
Во-первых, вы пишете фичу 1 раз на обе платформы (а будет вебная реализация - так вообще под все 3). Значит, команда сможет выдавать в полтора-два раза больше фичей в единицу времени тем же составом. Еще и поведение продукта будет консистентным между платформами.
Во-вторых, для доставки фичи до юзеров достаточно релиза бекенда. Никакого релизного цикла, никакого хвоста старых версий. Это ли не то, почему фронты всегда завидовали бекендерам? Фиксы, кстати, тоже доезжают сразу и до всех.
А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.
Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!
Не будем уходить далеко от темы backend-driven-UI и попробуем разобраться, хорошо это или плохо. Но сначала - краткий исторический экскурс в бдуй Яндекс Еды.
Когда я пришел в Еду в начале 2021 года, BDUI уже был. Но простенький такой, на минималках. Можно было через так называемый Layout Constructor задавать с бекенда вид некоторых экранов (в первую очередь - главной страницы с каталогом). Было понятие блоков/виджетов. Это было нужно для того, чтобы продакт мог сам немного поменять вид главной в поисках оптимального сетапа. Мог запустить эксперимент с альтернативной главной на сегмент аудитории без кода. Мог развести фичи по сегментам или географиям. Но вот незадача - админка была написана чужими для хищников, и пользоваться ей умело 2-3 человека.
Поэтому появилась вторая генерация - с Layout Configurator-ом и виджетами-без-кода. Тут уже все было по-людски, плюс реализация логики виджетов стала выезжать из LC, в котором можно было через админку задать правила обхода источников и формирования выдачи из их ответов. Хорошее проявление лоу-код/ноу-код подхода. Без всякого там богомерзкого ИИ.
Но вскоре подоспела третья генерация на основе решения "FLEX", зародившегося в Маркете. Тут уже совсем другие пироги - с бекенда можно задавать не только сетку виджетов, но и сами виджеты, включая верстку, экшны, навигацию. Клиент становится тоньше - по сути для отрисовки экрана достаточно SDK, а логика и верстка пишутся на бекенде на Котлине (впрочем, как я понимаю, от котлина там по сути только синтаксис, потому что все равно все примитивы там от фреймворка).
Чем это хорошо?
Во-первых, вы пишете фичу 1 раз на обе платформы (а будет вебная реализация - так вообще под все 3). Значит, команда сможет выдавать в полтора-два раза больше фичей в единицу времени тем же составом. Еще и поведение продукта будет консистентным между платформами.
Во-вторых, для доставки фичи до юзеров достаточно релиза бекенда. Никакого релизного цикла, никакого хвоста старых версий. Это ли не то, почему фронты всегда завидовали бекендерам? Фиксы, кстати, тоже доезжают сразу и до всех.
А минусы будут? Куда без них.
Во-первых, сокращается гибкость, особенно в вопросах сложных визуалов. Не может такой фреймворк уметь во все те фишечки, что заложены в натив вендором платформы. Всякие красивости-анимации, всякие глубоко-платформенные look&feel особенности (в большей степени характерные для ios) в таких SDK по большей части недоступны. Но не беда - всегда же можно оставить какие-то части, где это важно, нативными. Или допилить SDK.
Во-вторых, некоторые разработчики слишком сильно любят те самые нативные фишечки и не хотят уходить в бекендно-фреймворковую разработку. Типа это не то. Ну камон, если ты - в первую очередь, инженер, то ты должен понимать, что это более эффективный способ достигать целей. Это инструмент, который про make things done, про результат. Кому важнее процесс - такая работа тоже никуда не денется. Или пилить сам SDK.
Есть и другие плюсы-минусы, можете дополнять меня в комментариях. Но конъюнктура момента такова, что бизнесу нужен bdui, а мы тут как бы зарплату за это все получаем. Так что не ворчим и пилим фичи!
❤10🤡7🖕4