⛽️Кодовый газлайтинг.
Нет ничего страшнее, как мне кажется, чем кодовый газлайтинг.
Это когда ты тратишь время на проверки, выкатываешь код на прод, а потом кто-то приходит к тебе и спрашивает: "Ну как там, раскатил изменения? А то что-то ничего не поменялось."
Ты приходишь на прод, а там реально ничего не поменялось. Идешь в репу, ищешь там код. Код есть. И работает под дебагом. Изменения видны. Кнопка отображается, нажимается. Даже тесты, сука, есть и проходят!
А на проде кнопки нет! Сидишь в замешательстве(да в каком замешательстве!? ты в чистом ахуе!) , думаешь на себя, что ты чертов растяпа, не проверил что-то. Вспоминаешь, как перед выкаткой позволил себе слабость – не проверил какую-то там запятую. И понимаешь, что вот ты безответственный мудак! А потом – БАЦ!
И оказывается, что просто кто-то накатил что-то поверх и просто затер случайно твою фичу... Я так пару раз чуть кукухой не поехал. 🐦
Нет ничего страшнее, как мне кажется, чем кодовый газлайтинг.
Это когда ты тратишь время на проверки, выкатываешь код на прод, а потом кто-то приходит к тебе и спрашивает: "Ну как там, раскатил изменения? А то что-то ничего не поменялось."
Ты приходишь на прод, а там реально ничего не поменялось. Идешь в репу, ищешь там код. Код есть. И работает под дебагом. Изменения видны. Кнопка отображается, нажимается. Даже тесты, сука, есть и проходят!
А на проде кнопки нет! Сидишь в замешательстве
И оказывается, что просто кто-то накатил что-то поверх и просто затер случайно твою фичу... Я так пару раз чуть кукухой не поехал. 🐦
🤯1
План – не стратегия!
Я уже говорил, что обожаю Harward Business Review. Так вот теперь я их обожаю еще и в своем любимом видеоформате! И не могу не поделиться видосом про отличие стратегии от плана, которые все часто путают. А разница просто жесть какая!
Ключевые мысли видоса:
1️⃣ Стратегия – это связанный набор решений, который позволяет вам разместиться на игровом поле в положении, из которого вы можете выиграть.
2️⃣ Стратегия – это теория! Как и всякая теория она должна быть непротиворечивой и согласованной. Отвечать на вопрос, почему мы делаем что-то на этом игровом поле (читай рынке), а не на другом? И как мы будем приносить здесь большую пользу, чем конкуренты?
3️⃣ Планирование – не имеет никакой согласованности. Это просто набор действий.
4️⃣ Лидеры чаще выбирают планирование, просто потому что это проще.
🅰️ Смотреть здесь:
https://www.youtube.com/watch?v=iuYlGRnC7J8&ab_channel=HarvardBusinessReview
P.S.: А еще там важная мысль, о том, что словосочетание Стратегическое Планирование – это вообще бессмысленная хуета.
Я уже говорил, что обожаю Harward Business Review. Так вот теперь я их обожаю еще и в своем любимом видеоформате! И не могу не поделиться видосом про отличие стратегии от плана, которые все часто путают. А разница просто жесть какая!
Ключевые мысли видоса:
1️⃣ Стратегия – это связанный набор решений, который позволяет вам разместиться на игровом поле в положении, из которого вы можете выиграть.
2️⃣ Стратегия – это теория! Как и всякая теория она должна быть непротиворечивой и согласованной. Отвечать на вопрос, почему мы делаем что-то на этом игровом поле (читай рынке), а не на другом? И как мы будем приносить здесь большую пользу, чем конкуренты?
3️⃣ Планирование – не имеет никакой согласованности. Это просто набор действий.
4️⃣ Лидеры чаще выбирают планирование, просто потому что это проще.
🅰️ Смотреть здесь:
https://www.youtube.com/watch?v=iuYlGRnC7J8&ab_channel=HarvardBusinessReview
P.S.: А еще там важная мысль, о том, что словосочетание Стратегическое Планирование – это вообще бессмысленная хуета.
YouTube
A Plan Is Not a Strategy
A comprehensive plan—with goals, initiatives, and budgets–is comforting. But starting with a plan is a terrible way to make strategy. Roger Martin, former dean of the Rotman School of Management at the University of Toronto and one of the world’s leading…
🔥1
C# Short Posts 🔞
План – не стратегия! Я уже говорил, что обожаю Harward Business Review. Так вот теперь я их обожаю еще и в своем любимом видеоформате! И не могу не поделиться видосом про отличие стратегии от плана, которые все часто путают. А разница просто жесть какая! …
Если прикладывать чисто к программистским потребностям. Допустим, у вас есть план обучения:
1) Сначала выучу алгоритмы,
2) Потом базы данных,
3) Потом еще какое-то говно.
То через год вы обнаружите себя чувком, который знает все, да нихуя по делу.
И, напротив, если ваша стратегия обучения в том, чтобы вы могли через год, к примеру, спроектировать высоконагруженную систему. То через год вы будете знать то же самое, но сможете все это применить по делу – при проектировании.
Выбирайте стратегию! Это сложно, но окупается.
1) Сначала выучу алгоритмы,
2) Потом базы данных,
3) Потом еще какое-то говно.
То через год вы обнаружите себя чувком, который знает все, да нихуя по делу.
И, напротив, если ваша стратегия обучения в том, чтобы вы могли через год, к примеру, спроектировать высоконагруженную систему. То через год вы будете знать то же самое, но сможете все это применить по делу – при проектировании.
Выбирайте стратегию! Это сложно, но окупается.
🍚 Как сделать так чтобы RICE заработал?
Я тут прохожу курс для product ownerов https://productmindset.net, и там у них есть таблица скиллов по грейдам, где один из инструментов приоритезации, которым должен уметь пользоваться крутой PO – RICE.
Это такая скоринговая модель, где вы оцениваете то насколько много пользователей заденет ваша фича, насколько вы уверены что сделаете ее, насколько она приблизит вас к желаемым метрикам, ну и то насколько вы вообще сами считаете эту штуку важной (ага магический коэффициент, который позволяет подгонять итоговое значение).
Мы как-то пользовались этой штукой, чтобы приоритезировать техдолг. И она работала, ну как сказать... Честно говоря не то чтобы плохо, но просто в какой-то момент уже заебало ее считать, а потом один хер задачи не делать.
И я долго рефлексировал, что же с этим всем не так?
🅰️ Так вот, как мне кажется все дело в том, что эта штука супер-херово работает в отсутствие стратегии. То есть если вы насквозь оцените свой бэклог, то получится, что задачи из разных контекстов, бьющие в разные метрики, начнут смешиваться друг с другом. То есть делали вы что-то в бэкофисе, потом по приоритету вам попалась задача из клиентского приложения, потом снова бэкофис и так далее. И вот это переключение контекстов будет сжирать по итогу продуктивность. Однако!
🅰️Если оценивать задачи по RICE внутри одного контекста, то получится гораздо лучше!
P.S. Мне вообще в последнее время кажется, что внятная стратегия для команды разработки это что-то вроде коллективного здравого смысла. Если она есть, то вам скорее всего не понадобится никакой RICE. Ну и наоборот, если вы не можете сформулировать стратегию, то никакой ветер не будет вам попутным.
Я тут прохожу курс для product ownerов https://productmindset.net, и там у них есть таблица скиллов по грейдам, где один из инструментов приоритезации, которым должен уметь пользоваться крутой PO – RICE.
Это такая скоринговая модель, где вы оцениваете то насколько много пользователей заденет ваша фича, насколько вы уверены что сделаете ее, насколько она приблизит вас к желаемым метрикам, ну и то насколько вы вообще сами считаете эту штуку важной (ага магический коэффициент, который позволяет подгонять итоговое значение).
Мы как-то пользовались этой штукой, чтобы приоритезировать техдолг. И она работала, ну как сказать... Честно говоря не то чтобы плохо, но просто в какой-то момент уже заебало ее считать, а потом один хер задачи не делать.
И я долго рефлексировал, что же с этим всем не так?
🅰️ Так вот, как мне кажется все дело в том, что эта штука супер-херово работает в отсутствие стратегии. То есть если вы насквозь оцените свой бэклог, то получится, что задачи из разных контекстов, бьющие в разные метрики, начнут смешиваться друг с другом. То есть делали вы что-то в бэкофисе, потом по приоритету вам попалась задача из клиентского приложения, потом снова бэкофис и так далее. И вот это переключение контекстов будет сжирать по итогу продуктивность. Однако!
🅰️Если оценивать задачи по RICE внутри одного контекста, то получится гораздо лучше!
P.S. Мне вообще в последнее время кажется, что внятная стратегия для команды разработки это что-то вроде коллективного здравого смысла. Если она есть, то вам скорее всего не понадобится никакой RICE. Ну и наоборот, если вы не можете сформулировать стратегию, то никакой ветер не будет вам попутным.
productmindset.net
Product Mindset - Помогаем людям и компаниям развиваться
🔥4
💣 Задача 5: Идемпотентность параметров при ретраях
Если вы считаете, что не стоит закладывать бомбы замедленного действия в основы вашей системы, то я сейчас вам покажу откуда такая бомба может на вас готовиться.
Вот этот ретрай не заработает. Вопрос: как думаете, почему?
[HttpGet]
public async Task<string> Get()
{
var policy = GetPolicy();
var url = new Uri(@"http://localhost:5000/someurl");
var msg = new HttpRequestMessage(HttpMethod.Get, url);
}
private IAsyncPolicy GetPolicy() {
}
private async Task<string> GetForecasts(HttpRequestMessage msg)
{
var resp = await _client.SendAsync(msg);
if (_rng.NextDouble() > 0.95) {
throw new Exception( "oops");
}
return await resp.Content.ReadAsStringAsync();
}
Вы пока подумайте, а я ответ отправлю завтра. Но думаю, что в любом случае дам подсказку, что смотреть нужно на особенности HttpRequestMessage.
#ресайленс
Если вы считаете, что не стоит закладывать бомбы замедленного действия в основы вашей системы, то я сейчас вам покажу откуда такая бомба может на вас готовиться.
Вот этот ретрай не заработает. Вопрос: как думаете, почему?
[HttpGet]
public async Task<string> Get()
{
var policy = GetPolicy();
var url = new Uri(@"http://localhost:5000/someurl");
var msg = new HttpRequestMessage(HttpMethod.Get, url);
return await policy.ExecuteAsync(() => GetForecasts(msg)); }
private IAsyncPolicy GetPolicy() {
return Policy.Handle<Exception>().RetryAsync(3);}
private async Task<string> GetForecasts(HttpRequestMessage msg)
{
var resp = await _client.SendAsync(msg);
if (_rng.NextDouble() > 0.95) {
throw new Exception( "oops");
}
return await resp.Content.ReadAsStringAsync();
}
Вы пока подумайте, а я ответ отправлю завтра. Но думаю, что в любом случае дам подсказку, что смотреть нужно на особенности HttpRequestMessage.
#ресайленс
💣 Задача 5: Неочевидности при ретраях. Ответ
При ретрае HttpRequestMessage выдаст ошибку:
Чтобы это исправить, вам нужно внести переменную msg внутрь GetForecasts.
🅰️В общем, передавая параметры в лямбду при ретраях, смотрите внимательно, а не нужно ли их создавать заново при каждом запросе. Так-то! Ну признавайтесь, ведь не думали об этом!
#ресайленс
При ретрае HttpRequestMessage выдаст ошибку:
InvalidOperationException(SR.net_http_client_request_already_sent)Чтобы это исправить, вам нужно внести переменную msg внутрь GetForecasts.
🅰️В общем, передавая параметры в лямбду при ретраях, смотрите внимательно, а не нужно ли их создавать заново при каждом запросе. Так-то! Ну признавайтесь, ведь не думали об этом!
#ресайленс
🈴 Разбор проекта с явной (Explicit) архитектурой
Поскольку я херовасто понимаю теоретические излияния, то всегда стараюсь совместить их с практикой.
Сделал небольшой визуальный разбор статьи
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
На примере репозитория
Если вы, как и я запутались в ПОРТАХ и АДАПТЕРАХ и не поняли, что это такое, то этот разбор поможет вам осознать все это.
Все для вас, дорогие радиослушатели! 📻
UPD: Fuck там на певром слайде опечатка – не АДАПТЕРЫ, а ПОРТЫ.
[Вот ссылочка на miro]
Поскольку я херовасто понимаю теоретические излияния, то всегда стараюсь совместить их с практикой.
Сделал небольшой визуальный разбор статьи
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
На примере репозитория
Если вы, как и я запутались в ПОРТАХ и АДАПТЕРАХ и не поняли, что это такое, то этот разбор поможет вам осознать все это.
Все для вас, дорогие радиослушатели! 📻
UPD: Fuck там на певром слайде опечатка – не АДАПТЕРЫ, а ПОРТЫ.
[Вот ссылочка на miro]
👍1
🥅 Service Mesh
Уже в 10-ый раз я пытался разобраться с тем, что такое Service Mesh и с чем его едят. Ндавно вот была очередная 11-ая попытка. Закреплю здесь все, что понял, чтобы облегчить себе следующую попытку.
🧑🏭 Service Mesh – это когда ваш сервис перестает сам делать запросы к другим сервисам. Вместо этого мы ставим рядом с нашим сервисом сайдкар (просто еще один сервис) и делаем запросы к нему. Этот сайдкар понимает, к какому сервису мы хотим обратиться и идет к этому сервису к сайдкару этого сервиса! Вот так вот. Пояснительный дикпик выше. Подробное описание ниже:
[Подробное описание]
❓А что это дает?
С точки зрения производственной практики в целом ничего. Но с точки зрения отладки – это мастхэв. Сайдкары инкапсулируют в себе всю логику по взаимодействию между сервисами – ретраи, трейсинг, логирование времени запроса и прочее.
Есть определенные инструменты, которые могут анализировать взаимодействие сайдкаров между собой и предлагать вам оптимизации, если ваши коммуникации перегружены.
🅰️Когда надо брать?
Когда вы чувствуете, что погрязли в рутине настройки межсервисных коммуникаций и почти перестали писать бизнес-логику.
#servicemesh
Уже в 10-ый раз я пытался разобраться с тем, что такое Service Mesh и с чем его едят. Ндавно вот была очередная 11-ая попытка. Закреплю здесь все, что понял, чтобы облегчить себе следующую попытку.
🧑🏭 Service Mesh – это когда ваш сервис перестает сам делать запросы к другим сервисам. Вместо этого мы ставим рядом с нашим сервисом сайдкар (просто еще один сервис) и делаем запросы к нему. Этот сайдкар понимает, к какому сервису мы хотим обратиться и идет к этому сервису к сайдкару этого сервиса! Вот так вот. Пояснительный дикпик выше. Подробное описание ниже:
[Подробное описание]
❓А что это дает?
С точки зрения производственной практики в целом ничего. Но с точки зрения отладки – это мастхэв. Сайдкары инкапсулируют в себе всю логику по взаимодействию между сервисами – ретраи, трейсинг, логирование времени запроса и прочее.
Есть определенные инструменты, которые могут анализировать взаимодействие сайдкаров между собой и предлагать вам оптимизации, если ваши коммуникации перегружены.
🅰️Когда надо брать?
Когда вы чувствуете, что погрязли в рутине настройки межсервисных коммуникаций и почти перестали писать бизнес-логику.
#servicemesh
Redhat
What is a service mesh?
Read this article to find out more about what a service mesh is, how it works, and the benefits and challenges of implementing a service mesh.
👍2
❓Как запустить продуктовую команду, если у вас нет продукта?
Продолжаю проходить курс на ProductMindset и сегодня смотрел тему по скарму. Я уже давно вроде как знаю этот фреймворк, но только сейчас заметил некоторый его фундаментальный недостаток – скрам позволяет работать только если у вас уже есть продукт и его метрики. Но что делать если продукта еще нет?
🦤 У нас в Додо, как мне кажется, как раз такая ситуация с продуктами для управления процессами на кухне.
Есть какой-то разрозненный набор сервисов, но на какую единую задачу они работают, толком сказать никто не может. Какие метрики у этого набора продуктов? Или хотя бы у каждого из продуктов?
Ⓜ️Мысль, как исправить это: Перед запуском скрам команды в таком случае необходимо провести разработку/разведку продукта. То есть взять несколько спринтов, за которые продуктовая команда для начала выяснить:
1️⃣ Какие основные метрики они собираются улучшать
2️⃣ Как улучшение этих метрик связано с целями компании
3️⃣ Какие изменения за один квартал можно успеть сделать чтобы улучшить эти метрики.
❗️Тут мне кажется важно, что первый бэклог, который будет сформирован не должен быть годовым. Потому что, руководствуясь одним из принципов скрама – работа короткими итерациями, – в течение первого пробного спринта могут вылезти какие-то другие метрики, а какие-то стать ненужными и это нормально.
#процессы
Продолжаю проходить курс на ProductMindset и сегодня смотрел тему по скарму. Я уже давно вроде как знаю этот фреймворк, но только сейчас заметил некоторый его фундаментальный недостаток – скрам позволяет работать только если у вас уже есть продукт и его метрики. Но что делать если продукта еще нет?
🦤 У нас в Додо, как мне кажется, как раз такая ситуация с продуктами для управления процессами на кухне.
Есть какой-то разрозненный набор сервисов, но на какую единую задачу они работают, толком сказать никто не может. Какие метрики у этого набора продуктов? Или хотя бы у каждого из продуктов?
Ⓜ️Мысль, как исправить это: Перед запуском скрам команды в таком случае необходимо провести разработку/разведку продукта. То есть взять несколько спринтов, за которые продуктовая команда для начала выяснить:
1️⃣ Какие основные метрики они собираются улучшать
2️⃣ Как улучшение этих метрик связано с целями компании
3️⃣ Какие изменения за один квартал можно успеть сделать чтобы улучшить эти метрики.
❗️Тут мне кажется важно, что первый бэклог, который будет сформирован не должен быть годовым. Потому что, руководствуясь одним из принципов скрама – работа короткими итерациями, – в течение первого пробного спринта могут вылезти какие-то другие метрики, а какие-то стать ненужными и это нормально.
#процессы
👍1🤔1
Как IDE влияет на архитектуру вашего решения.
Я тут наткнулся на статью в соседнем C# канале: Ваш Язык Влияет на то, Как Вы Думаете. https://news.1rj.ru/str/NetDeveloperDiary/1630
Там рассказывается о том, что DI контейнеры в Java считаются плохой практикой, а в .NET наоборот считаются хорошей. И все не из-за того, что сама концепция DI плохая, а из-за особенностей языка.
Как-то давно я думал о чем-то подобном, что вообще не только сам язык определяет то как вы думаете, но еще и менее очевидная мысль – IDE которой вы пользуетесь тоже определяет ваш образ мыслей.
Как-то мне пришлось писать на Go. (Абсолютно богомерзкий язык на тот момент !) Под рукой не было GoLand от JetBrains, и я воспользовался Visual Studio Code. В расширении для Go был баг, из-за которого автокомплит не работал.
И тут я понял, что классическая структура с папочками и разными файлами, тут настолько неудобна, что пришлось от нее отказаться. Потому что вспоминать название какого-то метода и класса гораздо проще, когда все файлы свалены в одну папку.
То есть один только автокомплит позволяет вам в принципе думать о том, чтобы раскидать файлы по папочкам!
🅰️ Какой практический вывод можно сделать? Да самый прямой! Если у вас в разных командах в почЁте разные IDE, то и архитектура проектов этих команд может различаться чуть сильнее чем вам хотелось бы. Чтобы избежать таких изменений продумывйте ограничения (главное не запрещайте IDE – это тупизм) которые помогу избежать слишком больших различий. StyleCop и все вот это вам в помощь.
Я тут наткнулся на статью в соседнем C# канале: Ваш Язык Влияет на то, Как Вы Думаете. https://news.1rj.ru/str/NetDeveloperDiary/1630
Там рассказывается о том, что DI контейнеры в Java считаются плохой практикой, а в .NET наоборот считаются хорошей. И все не из-за того, что сама концепция DI плохая, а из-за особенностей языка.
Как-то давно я думал о чем-то подобном, что вообще не только сам язык определяет то как вы думаете, но еще и менее очевидная мысль – IDE которой вы пользуетесь тоже определяет ваш образ мыслей.
Как-то мне пришлось писать на Go. (
И тут я понял, что классическая структура с папочками и разными файлами, тут настолько неудобна, что пришлось от нее отказаться. Потому что вспоминать название какого-то метода и класса гораздо проще, когда все файлы свалены в одну папку.
То есть один только автокомплит позволяет вам в принципе думать о том, чтобы раскидать файлы по папочкам!
🅰️ Какой практический вывод можно сделать? Да самый прямой! Если у вас в разных командах в почЁте разные IDE, то и архитектура проектов этих команд может различаться чуть сильнее чем вам хотелось бы. Чтобы избежать таких изменений продумывйте ограничения (главное не запрещайте IDE – это тупизм) которые помогу избежать слишком больших различий. StyleCop и все вот это вам в помощь.
Telegram
.NET Разработчик
День 1313. #TypesAndLanguages
Ваш Язык Влияет на то, Как Вы Думаете. Начало
Кажется очевидным, не так ли? Ваш язык диктует правила, и вам нужно играть по правилам. Однако последствия гораздо серьёзнее, чем вы думаете. Дело не только в том, что мы выбираем…
Ваш Язык Влияет на то, Как Вы Думаете. Начало
Кажется очевидным, не так ли? Ваш язык диктует правила, и вам нужно играть по правилам. Однако последствия гораздо серьёзнее, чем вы думаете. Дело не только в том, что мы выбираем…
🔥1
🦾Внедрение IoT решений
Третьего дня ребята из одной из крутейших наших команд показывали результат своих экспериментов с умными весами. Ну как умными. Весы умеют отдавать свои показатели через http.И что, они теперь умные? Я вот свои показатели по http отдать не могу. Получается тупой – не преодолел технологическую сингулярность.
🤖Так вот, для меня в их рассказе стало самым интересным, что для производственного IoT решения как ни крути нужен локальный хаб, который может быстро обмениваться данными с устройствами на местах. Иначе раундтрип по сети до сервера убьёт напрочь всю отзывчивость интерфейса.
🪵И для меня сразу открылась веточка развития под названием "Архитектура IoT". А именно ответ на вопрос, а как вообще люди приходят к внедрению этого дела у себя в бизнесе.
В голове сложились такие этапы:
1️⃣ Любительский эксперимент, который упрощает локальную рутину.
2️⃣ Несколько разрозненных любительских экспериментов, без упорядочивания и стандартизации
3️⃣ Упорядочивание и стандартизация платформы - подключение новых решений по стандарту.
⚠️Вот мне кажется, что между 2️⃣ и 3️⃣ этапами очень легко упустить момент, и подойти к третьему этапу с таким зоопарком технологий и физических устройств, что стандартизировать это будет уже очень больно.
❓Как не упустить этот этап? Вопрос хороший, и, кажется, скоро мы увидим на него ответ. Я пока пойду искать опыт внедрения в интернете.
🅰️Кстати, если видели какие-то материалы по этой теме, накидайте в комментарии. Интересно будет почитать.
#IoT #architecture
Третьего дня ребята из одной из крутейших наших команд показывали результат своих экспериментов с умными весами. Ну как умными. Весы умеют отдавать свои показатели через http.
🤖Так вот, для меня в их рассказе стало самым интересным, что для производственного IoT решения как ни крути нужен локальный хаб, который может быстро обмениваться данными с устройствами на местах. Иначе раундтрип по сети до сервера убьёт напрочь всю отзывчивость интерфейса.
🪵И для меня сразу открылась веточка развития под названием "Архитектура IoT". А именно ответ на вопрос, а как вообще люди приходят к внедрению этого дела у себя в бизнесе.
В голове сложились такие этапы:
1️⃣ Любительский эксперимент, который упрощает локальную рутину.
2️⃣ Несколько разрозненных любительских экспериментов, без упорядочивания и стандартизации
3️⃣ Упорядочивание и стандартизация платформы - подключение новых решений по стандарту.
⚠️Вот мне кажется, что между 2️⃣ и 3️⃣ этапами очень легко упустить момент, и подойти к третьему этапу с таким зоопарком технологий и физических устройств, что стандартизировать это будет уже очень больно.
❓Как не упустить этот этап? Вопрос хороший, и, кажется, скоро мы увидим на него ответ. Я пока пойду искать опыт внедрения в интернете.
🅰️Кстати, если видели какие-то материалы по этой теме, накидайте в комментарии. Интересно будет почитать.
#IoT #architecture
🔥3
Разговаривают как-то два программиста – опытный и новичок. Опытный говорит:
— Знаешь, какая разница между продакт оунером и скрам мастером?
Молодой мотает головой, мол не знает. Опытный продолжает:
— Когда продакт оунер видит программиста, он кричит: "Ой, бля!". А когда скрам-мастер видит программиста, он говорит: "Оп-па!", а программист говорит: "Ой, бля!".
#компильдот
Please open Telegram to view this post
VIEW IN TELEGRAM
😁3
Компильдот от...
⚙️ Короче, у нас в компании один замечательный(да что уж там говорить – охуенный!) инженер @pastushenkoy ввёл лучшую в мире инженерную практику – анекдоты категории Б по вторникам.
👆 Чуть выше, вы видели продолжение этой практики от меня – компилированный анекдот, или компильдот. Компильдоты будут появляться здесь по вторникам (а может по пятницам, я пока не знаю, кажется, что в пятницу будет пизже ).
🔞Также я официально начинаю прием заявок на публикацию компильдотов! Важное условие – они должны быть про айтишную жизнь. Других ограничений нет. Они могут быть абстрактными, пошлыми и кринжовыми, главное чтоб про что-то айтишное.
#компильдот
⚙️ Короче, у нас в компании один замечательный
🔞Также я официально начинаю прием заявок на публикацию компильдотов! Важное условие – они должны быть про айтишную жизнь. Других ограничений нет. Они могут быть абстрактными, пошлыми и кринжовыми, главное чтоб про что-то айтишное.
#компильдот
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾3🐳1
This media is not supported in your browser
VIEW IN TELEGRAM
♨️ Новый, жаркий, кодогенерированный!
Вчера, пока все ждали обращения Волан-де-Морта, я нахуячил себе новенький логотип для канала. Да не простой, а анимированный!😵💫
Когда-то, не так давно, я преподавал детям курсы по разработке игр (да-да, вот что я делал эти 8 лет ). И в эти игры входили всякого рода анимации. Анимации в Adobe Flash (да преупокоится он с миром), ключевые анимации в 3D Max и еще много-много где. И вот что я вам скажу – ненавижу анимировать что-то руками. Это я очень МЯГКО постарался сформулировать.
🅰️ В этот раз я нашел Python 🐍 библиотеку, которой пользуется один крутой математический блоГГер 3Blue1Brown. Называется она manim. Пара часов с матами и кряхтеним, но все заработало!
🐻❄️Теперь у меня крутой анимированный по-программистски логотип. И даже исходнички имеются!
P.S.: Да, я знаю, что нам всем в эти тревожные времена не до логотипов. Но так вам скажу. Не хочу позволять этим людям контролировать мои нервы. В общем, берите manim, и берите власть над собой в свои руки!
Вчера, пока все ждали обращения Волан-де-Морта, я нахуячил себе новенький логотип для канала. Да не простой, а анимированный!
Когда-то, не так давно, я преподавал детям курсы по разработке игр (
🅰️ В этот раз я нашел Python 🐍 библиотеку, которой пользуется один крутой математический блоГГер 3Blue1Brown. Называется она manim. Пара часов с матами и кряхтеним, но все заработало!
🐻❄️Теперь у меня крутой анимированный по-программистски логотип. И даже исходнички имеются!
P.S.: Да, я знаю, что нам всем в эти тревожные времена не до логотипов. Но так вам скажу. Не хочу позволять этим людям контролировать мои нервы. В общем, берите manim, и берите власть над собой в свои руки!
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
Про зоны ответственности.
Напишу тут этот пост, и чтобы запомнить эти злоебучие времена, и чтобы запомнить, какие выводы я из них сделал.
Я смотался в Грузию месяцем раньше чем начался Пиздец.
Как и все из моего окружения, кто успел уехать, я стал помогать тем, кто выбирается с нашей Родины, чтобы не сгинуть в этой ебучей войне. Найти билеты, просто помочь добрым словом.
Тут важная, не отоносящаяся к основной линии ремарка про отношение к русским в Грузии:
Люди порой боятся, что к русским теперь плохо относятся в Грузии, а это вот ни разу не так. Вчера говорил с хозяйкой съемной квартиры, вот ее слова: "Слава Богу, что вы успели уехать. Это такой кошмар!" Не бойтесь – в Грузии живут прекрасные люди!
Но это ладно. Самое главное, что я вынес для себя из этого опыта – человек сам выбирает, как и куда ему ехать. Моя задача только помочь ему купить билеты на этот путь. Какой бы дебильный путь ни был выбран.
Есть один друг, который купил билет в Тегеран (да, в это время все еще есть люди, которые не читают новости). Вот 100 раз хотелось его отговорить, с учетом всего. Но человек выбрал путь – я могу лишь сделать его чуть более гладким – что-то оплатить с иностранной карты, где-то подбодрить и сказать, что все получится. А иногда достаточно просто быть на связи, чтобы человек мог тебе проговорить свои мысли и немного осмотреться. (Блять, ну и разумеется, я просто для галочки проинформировал, что там так-то тоже пиздос! )
В общем, сегодня мы многое поняли: если человек сделал выбор, за который несет ответственность только он, это его дело. Значит психологически он готов именно к такому пути, а в таких ситуациях психология важнее всего.
Ну и, да, если кому-то нужна помощь в Батуми, то я здесь и готов встречать в аэропорту, давать насколько могу ночлег, показывать, что тут и как с деньгами и вообще осваиваться. Такие дела. Если нужно кого-то встретить, пишите!
UPD: С другом, который летел через Тегеран все в порядке - долетел до Дубая. Вот уж воистину. А еще друг из Минска прилетел в Тбилиси вчера. Так что зря даже Максим Кац нагнетал по этому поводу.
Напишу тут этот пост, и чтобы запомнить эти злоебучие времена, и чтобы запомнить, какие выводы я из них сделал.
Я смотался в Грузию месяцем раньше чем начался Пиздец.
Как и все из моего окружения, кто успел уехать, я стал помогать тем, кто выбирается с нашей Родины, чтобы не сгинуть в этой ебучей войне. Найти билеты, просто помочь добрым словом.
Тут важная, не отоносящаяся к основной линии ремарка про отношение к русским в Грузии:
Люди порой боятся, что к русским теперь плохо относятся в Грузии, а это вот ни разу не так. Вчера говорил с хозяйкой съемной квартиры, вот ее слова: "Слава Богу, что вы успели уехать. Это такой кошмар!" Не бойтесь – в Грузии живут прекрасные люди!
Но это ладно. Самое главное, что я вынес для себя из этого опыта – человек сам выбирает, как и куда ему ехать. Моя задача только помочь ему купить билеты на этот путь. Какой бы дебильный путь ни был выбран.
Есть один друг, который купил билет в Тегеран (да, в это время все еще есть люди, которые не читают новости). Вот 100 раз хотелось его отговорить, с учетом всего. Но человек выбрал путь – я могу лишь сделать его чуть более гладким – что-то оплатить с иностранной карты, где-то подбодрить и сказать, что все получится. А иногда достаточно просто быть на связи, чтобы человек мог тебе проговорить свои мысли и немного осмотреться. (
В общем, сегодня мы многое поняли: если человек сделал выбор, за который несет ответственность только он, это его дело. Значит психологически он готов именно к такому пути, а в таких ситуациях психология важнее всего.
Ну и, да, если кому-то нужна помощь в Батуми, то я здесь и готов встречать в аэропорту, давать насколько могу ночлег, показывать, что тут и как с деньгами и вообще осваиваться. Такие дела. Если нужно кого-то встретить, пишите!
UPD: С другом, который летел через Тегеран все в порядке - долетел до Дубая. Вот уж воистину. А еще друг из Минска прилетел в Тбилиси вчера. Так что зря даже Максим Кац нагнетал по этому поводу.
❤2
📆Недавно с нами случился абсолютный краш. Один из подконтрольных нашей команде сервисов вдруг начал сыпать ошибками. Сообщения в них говорили, что сервис не может достучаться по сети до базы, до редиса, до соседних сервисов. И вообще ему плохо и у него лапки 🐾.
🌚Вот вчерась оно снова повторилось. Но, к счастью, на этот раз мы уже предварительно смотрели в код и примерно понимали, где там могут быть проблемы. А проблемы, они в CancellationToken.
То есть кто-то приходит и кидает нам большой запрос к базе. Затем по таймауту в две минуты соединение отстреливается. В базе запрос не отменяется. Минус один коннект у коннекшн пула. Затем ситуация повторяется до победного – пока весь пул на поде не забьется. Вот так вот просто.
В итоге все это добро пожирало сначала коннекшн пул, а потом еще и потоки и CPU. Из-за чего и ответы от других сервисов не успевали обработаться, что и приводило к картине, будто вся сеть отключилась.
🅰️Мой вывод из этой ситуации. Если в асинхронный метод не проброшен CancellationToken, то нужно чтобы приложение просто не собиралось нахер.
А я пошел пробрасывать оные. Там дохера где надо. :
UPD: А может и не только в токенах дело. Возможно старая бага Entity вылезла ¯\_(ツ)_/¯
UPD2: Тут на самом деле недавно у нас был пиздец какой краш. Сначала в стране, а потом и вдобавок система наебнулась на 4 часа. Но по этому крашу мне пока рассказать нечего.
А еще хочу добавить: Спасибо Грузии за то что помогает нам всем бежать от кровавого мудака и его войны! Сердечное спасибо 🧡
Сакартвелос гаумарджос! 🇬🇪 (Да здравствует Грузия!)
#трудовыебудни #опыт
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1