Если вдруг вы до сих пор не активировали себе chatgpt, потому что лень разбираться с виртуальными номерами и обходить ограничения (турецкие симки тоже не работают!), то внезапно Skype (мобильный точно, десктопный не проверял) добавил Bing-бота, который внутри chatgpt. Как говорится, инджой. Update: поправляют, что турецкие симки работают; внутри бота GPT-3.5.
Сделал опрос в фейсбук-группе: какие темы в контексте AI в целом и ChatGPT/генеративных сетей в частности вам интересны, и знаете что?
Три топовых вопроса:
* Kто из программистов уже генерит продакшен AI код?
* Cдувается ли тема Metaverse, или просто ещё не пришло время?
* Text2Video: когда фильмы будут генерировать прямо из сценария?
Я позвал замечательного эксперта Дениса Пархоменко из МГУ помочь ответить на них, и Денис любезно согласился, но на первый вопрос, надеюсь, ответят сами программисты.
Кстати, вы можете тоже проголосовать за вопросы или добавить свой или даже ответить (но это чуть позже) - ссылка на пост в группе ниже.
На следующей неделе будем обсуждать в формате QA-сессии. Знаю, что среди вас много экспертов и просто талантливых людей - призываю всех участвовать. У меня по крайней мере есть ответ на один вопрос “Стали ли кандидаты массово использовать ChatGPT на интервью, и как этому противостоять”, впрочем, довольно очевидный.
https://www.facebook.com/groups/feedme.ru/posts/6495206017178396/
На картинке для привлечения внимания: так 5й миджорней представляет идеальную женщину глазами программиста.
Три топовых вопроса:
* Kто из программистов уже генерит продакшен AI код?
* Cдувается ли тема Metaverse, или просто ещё не пришло время?
* Text2Video: когда фильмы будут генерировать прямо из сценария?
Я позвал замечательного эксперта Дениса Пархоменко из МГУ помочь ответить на них, и Денис любезно согласился, но на первый вопрос, надеюсь, ответят сами программисты.
Кстати, вы можете тоже проголосовать за вопросы или добавить свой или даже ответить (но это чуть позже) - ссылка на пост в группе ниже.
На следующей неделе будем обсуждать в формате QA-сессии. Знаю, что среди вас много экспертов и просто талантливых людей - призываю всех участвовать. У меня по крайней мере есть ответ на один вопрос “Стали ли кандидаты массово использовать ChatGPT на интервью, и как этому противостоять”, впрочем, довольно очевидный.
https://www.facebook.com/groups/feedme.ru/posts/6495206017178396/
На картинке для привлечения внимания: так 5й миджорней представляет идеальную женщину глазами программиста.
Писать код и читить на job-интервью с помощью ChatGPT
Скину сюда пост в рамках недели online QA по теме ChatGPT (ссылка на группу была раньше).
Отвечает Денис Пархоменко (МГУ).
Chatgpt используют как stackoverflow. Возможность оперативно получить понятное объяснение и переспросить привлекает многих.Сopilot помогает простые вещи автоматизировать: обертки, что-то шаблонное. AI обработает хорошо запросы на генерацию “скелета”: шаблона-обработчика, чат-бота.
В общем, для чего было более чем достаточно обучающих данных - с высокой вероятностью будет сгенерировано качественно.
В моём окружении до %20 инженеров-программистов начали пользоваться AI как помощником (но у меня смещенная выборка, общий процент скорее всего поменьше).
При этом AI часто ошибается при написании кода, вот пример. В библиотеке gector, пример использования которой попросили сгенерить ChatGPT - нет метода load_model.
Интервью - да, ChatGPT уже прекрасно решает leetcode. Причем уже появились вот такие плагины для смены направления взгляда в камеру на конференции (https://www.youtube.com/watch?v=O50BkP16eZo) - никто и не заметит, что Вы читите. Но надо понимать, что генеративные способности AI хоть и велики, но ограничены. С большой вероятностью он ошибётся в нестандартной задаче.
Придумайте 3-4 задачи, которых, кроме Вас никто не знает (не было в обучающей выборке AI) и спрашивайте их.
Скину сюда пост в рамках недели online QA по теме ChatGPT (ссылка на группу была раньше).
Отвечает Денис Пархоменко (МГУ).
Chatgpt используют как stackoverflow. Возможность оперативно получить понятное объяснение и переспросить привлекает многих.Сopilot помогает простые вещи автоматизировать: обертки, что-то шаблонное. AI обработает хорошо запросы на генерацию “скелета”: шаблона-обработчика, чат-бота.
В общем, для чего было более чем достаточно обучающих данных - с высокой вероятностью будет сгенерировано качественно.
В моём окружении до %20 инженеров-программистов начали пользоваться AI как помощником (но у меня смещенная выборка, общий процент скорее всего поменьше).
При этом AI часто ошибается при написании кода, вот пример. В библиотеке gector, пример использования которой попросили сгенерить ChatGPT - нет метода load_model.
Интервью - да, ChatGPT уже прекрасно решает leetcode. Причем уже появились вот такие плагины для смены направления взгляда в камеру на конференции (https://www.youtube.com/watch?v=O50BkP16eZo) - никто и не заметит, что Вы читите. Но надо понимать, что генеративные способности AI хоть и велики, но ограничены. С большой вероятностью он ошибётся в нестандартной задаче.
Придумайте 3-4 задачи, которых, кроме Вас никто не знает (не было в обучающей выборке AI) и спрашивайте их.
Дополнение от меня про ChatGPT, читинг на интервью и что с этим делать
Давайте предположим, что AI получает real-time всю информацию, которую спрашивает интервьюер, и умеет скрыть элементы обмана, движения глаз и тд.
Какие классы задач и вопросов теперь в зоне риска: (1) известные, leetcode и тд. (2) задачи “что делает этот код”, (3) общие “”понятийные” вопросы “для отличников” (что такое …).
Какие классы задач пока работают: (1) все оффлайновые, на листочке, на доске - всё что вы обычно люто-бешено ненавидите, готовьтесь, FAANG/СОВЯТА теперь никогда от этого не откажутся (2) оригинальные (до поры до времени), возможно параметризованные (задаете в форме с небольшими изменениями) (3) привязанные к конкретному опыту кандидата (тут море вопросов, я обычно иду сразу сюда - но это всё-таки исключение, я чаще всего уже на последних этапах).
Кстати, про разбор кода. В одном программистском чате недавно запостили разбор ChatGPT известной злой шутки с perl-кодом (который не надо выполнять, пожалуйста).
Ответ ChatGPT хорошо иллюстрирует текущие способности AI.
Вы используете AI для написания кода? Расскажите о вашем опыте, очень интересно. Я пока в это не очень верю, но думаю, что это всё временно. Очень верю в шаблонизацию и генерацию кода, но возможно AI как раз разрешит проблему дисциплины, которая нужна для команд, практикующих разработку в ключе максимальной генерации кода по описанию на условном мета-языке.
Давайте предположим, что AI получает real-time всю информацию, которую спрашивает интервьюер, и умеет скрыть элементы обмана, движения глаз и тд.
Какие классы задач и вопросов теперь в зоне риска: (1) известные, leetcode и тд. (2) задачи “что делает этот код”, (3) общие “”понятийные” вопросы “для отличников” (что такое …).
Какие классы задач пока работают: (1) все оффлайновые, на листочке, на доске - всё что вы обычно люто-бешено ненавидите, готовьтесь, FAANG/СОВЯТА теперь никогда от этого не откажутся (2) оригинальные (до поры до времени), возможно параметризованные (задаете в форме с небольшими изменениями) (3) привязанные к конкретному опыту кандидата (тут море вопросов, я обычно иду сразу сюда - но это всё-таки исключение, я чаще всего уже на последних этапах).
Кстати, про разбор кода. В одном программистском чате недавно запостили разбор ChatGPT известной злой шутки с perl-кодом (который не надо выполнять, пожалуйста).
Ответ ChatGPT хорошо иллюстрирует текущие способности AI.
Вы используете AI для написания кода? Расскажите о вашем опыте, очень интересно. Я пока в это не очень верю, но думаю, что это всё временно. Очень верю в шаблонизацию и генерацию кода, но возможно AI как раз разрешит проблему дисциплины, которая нужна для команд, практикующих разработку в ключе максимальной генерации кода по описанию на условном мета-языке.
Буткемп по Хайлоаду
Приглашаю бекендеров с опытом работы 1-3+ года на обучение в новый “буткэмп” DevHands.io // Hardcore Backend. Актуально для тех, кто хотел бы прокачаться в понимании инфры, производительности и масштабирования.
В рамках буткемпа слушатели изучают основы хайлоада, самостоятельно строят и тестируют инфраструктуру, тюнят перфоманс и знакомятся с основами масштабирования. Linux + nginx + ваш стек (он не имеет значения, но группы сформируем по “близкому” стэку). Только практика, никаких “покупок закрытых видео на youtube”: в первый же день получаете свою инфру и сами с ней работате. Разберетесь в том, что принято называть System Design, и без знания чего не пройти ни одно интервью в компании типа FAANG.
Обучение полу-синхронное, без отрыва от работы/учебы. Даже если в будущем вы не будете непосредственно отвечать за инфру, а ваш клауд-провайдер предоставит вам магические бесконечно-масштабируемые компоненты – вы начнете значительно лучше понимать, что там под капотом.
Сейчас набираю пилотную группу на первую часть программы - управление виртуальными машинами и базовая настройка производительности. Рассчитана на 1-3 месяца. Стоимость пилотного модуля минимальна (20.000 рублей), фактически всё уйдет на инфру. Буду очень благодарен, если пошерите это по друзьям и знакомым, мне кажется эта возможность достаточно уникальной.
Больше информация об этом буткэмпе здесь: https://devhands.io/hardcore-backend-ru-pilot.html. Если есть интерес адаптировать обучение под корпоративные программы – тоже пишите, обсудим. Чтобы попасть в группы, нужно написать мне ЛС в телеграм (https://xn--r1a.website/alexeyrybak): группы формируются в соответствии с опытом и возможностями.
Приглашаю бекендеров с опытом работы 1-3+ года на обучение в новый “буткэмп” DevHands.io // Hardcore Backend. Актуально для тех, кто хотел бы прокачаться в понимании инфры, производительности и масштабирования.
В рамках буткемпа слушатели изучают основы хайлоада, самостоятельно строят и тестируют инфраструктуру, тюнят перфоманс и знакомятся с основами масштабирования. Linux + nginx + ваш стек (он не имеет значения, но группы сформируем по “близкому” стэку). Только практика, никаких “покупок закрытых видео на youtube”: в первый же день получаете свою инфру и сами с ней работате. Разберетесь в том, что принято называть System Design, и без знания чего не пройти ни одно интервью в компании типа FAANG.
Обучение полу-синхронное, без отрыва от работы/учебы. Даже если в будущем вы не будете непосредственно отвечать за инфру, а ваш клауд-провайдер предоставит вам магические бесконечно-масштабируемые компоненты – вы начнете значительно лучше понимать, что там под капотом.
Сейчас набираю пилотную группу на первую часть программы - управление виртуальными машинами и базовая настройка производительности. Рассчитана на 1-3 месяца. Стоимость пилотного модуля минимальна (20.000 рублей), фактически всё уйдет на инфру. Буду очень благодарен, если пошерите это по друзьям и знакомым, мне кажется эта возможность достаточно уникальной.
Больше информация об этом буткэмпе здесь: https://devhands.io/hardcore-backend-ru-pilot.html. Если есть интерес адаптировать обучение под корпоративные программы – тоже пишите, обсудим. Чтобы попасть в группы, нужно написать мне ЛС в телеграм (https://xn--r1a.website/alexeyrybak): группы формируются в соответствии с опытом и возможностями.
👍2
В одной из пилотных учебных групп буткемпа через месяц отвалился участник. Не поворачивается язык назвать его «учеником» – группа сплошь из довольно опытных ребят, многие с 10+ лет опытом. К нам вообще не приходят джуны, кстати говоря, изначально я позиционировал буткемп как буст карьеры, не как старт (ещё напишу про это).
Причина – основная, и скорее всего, так будет почти у всех отвалившихся: работа, на плотную практику нет времени. Настройка с нуля виртуалок, освоение инструментов, лабы со стрельбами, тюнинг – если раньше этого не делал, то нужно хотя бы несколько часов в неделю, чтобы двигаться в среднем темпе. Хотя есть ребята, которые наоборот говорят, что задания простые и делаются «за час».
Короче, отвалился, жаль, работа, всё ясно. Но это же в эдтехе всегда вопрос балланса усилий, занятости и ценности. Если ценность высокая – сделаешь усилие при почти любой занятости. В процессе «интервью» выясняется такой факт: на работе всё завернуто в докер, и привычнее докер/кубер, в то время, как я принципиально на начальном этапе отказался от этой «прослойки»: на мой взгляд, она лишь мешает понять, как всё устроено, и учить это надо позже.
Могло ли это повлиять на ценность и отвал? Конечно могло. У меня по-прежнему сильно опасение, что есть прям большое поколение людей, для которых докер – это вот уже просто дефолтный интерфейс взаимодействия со внешним миром. Думаю, в будущем придется или прям отдельно много-много проговаривать это на входе, или отдельно делать трек для тех, кто хочет всё в докере, или вообще разрешать и так, и так, и посмотреть, что у таких получается. Склоняюсь к комбинации первого и третьего.
А есть ли среди вас технари, кто согласен, что всё надо ставить через докер, и учиться линуксу, инфре, производительности, масштабированию только в контексте докер/кубер? Было бы очень интересно это обсудить - например, как вы учились сами.
Ну и до кучи: в пилотные группы Hardcore Backend Bootcamp (или обучение «хайлоаду») пока есть 3 места - присоединяйтесь, советуйте коллегам. Подробнее о программе можно почитать в прошлых постах и тут: https://devhands.io/hardcore-backend-ru-pilot.html
Причина – основная, и скорее всего, так будет почти у всех отвалившихся: работа, на плотную практику нет времени. Настройка с нуля виртуалок, освоение инструментов, лабы со стрельбами, тюнинг – если раньше этого не делал, то нужно хотя бы несколько часов в неделю, чтобы двигаться в среднем темпе. Хотя есть ребята, которые наоборот говорят, что задания простые и делаются «за час».
Короче, отвалился, жаль, работа, всё ясно. Но это же в эдтехе всегда вопрос балланса усилий, занятости и ценности. Если ценность высокая – сделаешь усилие при почти любой занятости. В процессе «интервью» выясняется такой факт: на работе всё завернуто в докер, и привычнее докер/кубер, в то время, как я принципиально на начальном этапе отказался от этой «прослойки»: на мой взгляд, она лишь мешает понять, как всё устроено, и учить это надо позже.
Могло ли это повлиять на ценность и отвал? Конечно могло. У меня по-прежнему сильно опасение, что есть прям большое поколение людей, для которых докер – это вот уже просто дефолтный интерфейс взаимодействия со внешним миром. Думаю, в будущем придется или прям отдельно много-много проговаривать это на входе, или отдельно делать трек для тех, кто хочет всё в докере, или вообще разрешать и так, и так, и посмотреть, что у таких получается. Склоняюсь к комбинации первого и третьего.
А есть ли среди вас технари, кто согласен, что всё надо ставить через докер, и учиться линуксу, инфре, производительности, масштабированию только в контексте докер/кубер? Было бы очень интересно это обсудить - например, как вы учились сами.
Ну и до кучи: в пилотные группы Hardcore Backend Bootcamp (или обучение «хайлоаду») пока есть 3 места - присоединяйтесь, советуйте коллегам. Подробнее о программе можно почитать в прошлых постах и тут: https://devhands.io/hardcore-backend-ru-pilot.html
👍2
Perplexity.AI и новые идеи применения LLM для программистов
Познакомился с интересными ребятами на митапе Хайлоада. Занимаются заказной разработкой в области AI/LLM (те самые large language models).
Ловите ещё несколько интересных применений LLM чат-ботов для программистов:
* сгенери метод DAO по текстовому описанию запроса (xo на стероидах). Кстати генерация схемы по текстовому представлению тоже должна отлично работать. Хочется, конечно, поёрничать насчет «ORM, до свидания», но посмотрим, вряд ли.
* сгенери код на таком-то языке, который делает то-то и добавь в него ошибку (для интервью - найди ошибку).
* покажи SQL-запрос с сортировкой по вычисляемому полю (или коррелированный подзапрос – добавьте сложности по вкусу), сгенери и покажи для него explain постреса (для интервью - объясни по плану, что тут плохого).
В процессе обсуждения активно использовался https://www.perplexity.ai: он делает поисковые запросы реалтайм, и вообще оказался крутейшей альтернативой другим чат-ботам. Enjoy.
Познакомился с интересными ребятами на митапе Хайлоада. Занимаются заказной разработкой в области AI/LLM (те самые large language models).
Ловите ещё несколько интересных применений LLM чат-ботов для программистов:
* сгенери метод DAO по текстовому описанию запроса (xo на стероидах). Кстати генерация схемы по текстовому представлению тоже должна отлично работать. Хочется, конечно, поёрничать насчет «ORM, до свидания», но посмотрим, вряд ли.
* сгенери код на таком-то языке, который делает то-то и добавь в него ошибку (для интервью - найди ошибку).
* покажи SQL-запрос с сортировкой по вычисляемому полю (или коррелированный подзапрос – добавьте сложности по вкусу), сгенери и покажи для него explain постреса (для интервью - объясни по плану, что тут плохого).
В процессе обсуждения активно использовался https://www.perplexity.ai: он делает поисковые запросы реалтайм, и вообще оказался крутейшей альтернативой другим чат-ботам. Enjoy.
Perplexity AI
Perplexity is a free AI-powered answer engine that provides accurate, trusted, and real-time answers to any question.
👍7
Культурные различия
Когда-то давно в Москве и в Лондоне мы запустили программу обучения для менеджеров, с фокусом на повышение эффективности. Я уже был тогда главой разработки Badoo, главным заказчиком этого обучения и участвовал в обоих программах. Про этот опыт, наверное, можно написать десятки постов, но я напишу о главном.
В Лондоне тренинг был слабее, был больше сфокусирован не на эффективном управлении, а на личностном росте, хотя мы стопицот раз обсуждали с ними программу, и вроде как на бумаге всё выглядело лучше.
Лондонский тренинг закончился конгениально. Все участники прошли тестирование на “силоскопе” (от слова “сила”) и получили карту сильных и слабых личностных сторон. Это была такая хреновина, похожая на radar chart: из центра во все стороны под равным углом торчат разной длины такие “палки”, ваши сильные и слабые стороны. И главный “мессадж” этого упражнения (да и вообще тренинга) был такой: не фокусируйтесь на слабых сторонах, фокусируйтесь на сильных.
Русские, кто проходил тренинг и в Москве, и в Лондоне были изрядно злы. Мы вытащили на тренинг чуваков из Лондона, чтобы кто-то со стороны им рассказал о том, что эффективное управление – это не массаж и обеды от шеф-повара, не игровые автоматы и не дежурное “congrats” после релизов. А тут мало того, что не про управление, так ещё и всем говорят: фиг с ними, со слабыми сторонами: давайте сфокусируемся на сильных! Какая у вас сильная сторона, Сreativity и Сommon Sense? Отлично! Congrats! Фокусируйтесь на них. Чтобы это ни значило.
В принципе, я понимаю культурные различия - в английской корпоративной культуре невероятно важна вежливость, границы, фокус на позитиве. В этом смысле фокус на сильных сторонах для личностного роста абсолютно понятен. И даже с организационной точки зрения фокус на сильных сторонах важен: одна из важнейших задач руководителя подобрать команду так, чтобы сильные стороны одних компенсировали слабые стороны других. Но это всего лишь одна из задач.
Короче, фокус исключительно и в первую очередь на сильных сторонах - ничего более сомнительного в жизни не слышал. Я за радикальную честность ещё со времен, когда её так не называли. И я всегда считал, что фокусироваться нужно не на сильных сторонах, а на слабых - в них сидят все потери. Но о потерях - в следующем программном посте.
——————
devhands.io - хайлоад-буткэмп для бекендеров (по-прежнему идёт набор в пилотные группы!)
@feedmetoo - обсуждаем новости вокруг разработки, релизы, тренды
Когда-то давно в Москве и в Лондоне мы запустили программу обучения для менеджеров, с фокусом на повышение эффективности. Я уже был тогда главой разработки Badoo, главным заказчиком этого обучения и участвовал в обоих программах. Про этот опыт, наверное, можно написать десятки постов, но я напишу о главном.
В Лондоне тренинг был слабее, был больше сфокусирован не на эффективном управлении, а на личностном росте, хотя мы стопицот раз обсуждали с ними программу, и вроде как на бумаге всё выглядело лучше.
Лондонский тренинг закончился конгениально. Все участники прошли тестирование на “силоскопе” (от слова “сила”) и получили карту сильных и слабых личностных сторон. Это была такая хреновина, похожая на radar chart: из центра во все стороны под равным углом торчат разной длины такие “палки”, ваши сильные и слабые стороны. И главный “мессадж” этого упражнения (да и вообще тренинга) был такой: не фокусируйтесь на слабых сторонах, фокусируйтесь на сильных.
Русские, кто проходил тренинг и в Москве, и в Лондоне были изрядно злы. Мы вытащили на тренинг чуваков из Лондона, чтобы кто-то со стороны им рассказал о том, что эффективное управление – это не массаж и обеды от шеф-повара, не игровые автоматы и не дежурное “congrats” после релизов. А тут мало того, что не про управление, так ещё и всем говорят: фиг с ними, со слабыми сторонами: давайте сфокусируемся на сильных! Какая у вас сильная сторона, Сreativity и Сommon Sense? Отлично! Congrats! Фокусируйтесь на них. Чтобы это ни значило.
В принципе, я понимаю культурные различия - в английской корпоративной культуре невероятно важна вежливость, границы, фокус на позитиве. В этом смысле фокус на сильных сторонах для личностного роста абсолютно понятен. И даже с организационной точки зрения фокус на сильных сторонах важен: одна из важнейших задач руководителя подобрать команду так, чтобы сильные стороны одних компенсировали слабые стороны других. Но это всего лишь одна из задач.
Короче, фокус исключительно и в первую очередь на сильных сторонах - ничего более сомнительного в жизни не слышал. Я за радикальную честность ещё со времен, когда её так не называли. И я всегда считал, что фокусироваться нужно не на сильных сторонах, а на слабых - в них сидят все потери. Но о потерях - в следующем программном посте.
——————
devhands.io - хайлоад-буткэмп для бекендеров (по-прежнему идёт набор в пилотные группы!)
@feedmetoo - обсуждаем новости вокруг разработки, релизы, тренды
👍13
9 потерь в разработке
В прошлом посте я написал, что нужен фокус на слабых сторонах: там сидят наши потери. Эффективность организации падает не потому, что мы хреново используем наши сильные стороны, а потому что мы допустили перекос в слабых, и потери убивают нашу эффективность. Грубо, у нас отличный дизайн. Зачем нам улучшать дизайн и делать его просто бомбическим, если внезапно у инженеров текучка 50% в год?
Фокус на потерях - идея старая, пришла из философии бережливого производства, но в книжках, которые я читал, все потери были уж чересчур ”производственные”: перепроизводство, ожидание, запасы, ну вот это всё. Короче, я возможно мало читал или плохо искал, но я не знаю и не нашел нормального списка потерь для разработки. Поэтому я хочу взять на себя смелость и поделиться своим. Я разбил его на две группы, позволю себе не расписывать каждый компонент, кажется там всё достаточно понятно.
Потери первого рода - проявляются на всех, даже самых малых масштабах
1. потери целей (неверных, избыточных, формулировок)
2. потери декомпозиции (как проекта так и ролей)
3. потери мотивации и фокуса (миллион всего, основное: быстро-весело, не тяп-ляп, ору о проблемах и решаю их сам, дружно и по-доброму. И меня не отвлекают и не заваливают кучей одновременных проектов)
4. потери качества (и баги, и косяки эксплуатации)
5. потери координации и контроля (потери поздней реакции на изменения, боязнь уволить и тд)
Потери второго рода - проявляются на большем масштабе
1. потери организационных зависимостей (зависимости между отделами, коммуникация, ожидания, сюда же наверное скорость найма, хотя тянет на отдельный пункт)
2. потери техдолга (любого, начиная с выбора инструментов)
3. потери безопасности
4. потери производительности и масштабирования
Что думаете, ничего не забыл? Будет интересно узнать ваше мнение. То, что некоторые потери второго рода могут проявляться на уровне команд - понимаю, но нельзя же делать один список из 9 пунктов - его ж не запомнит никто.
————
@feedmetoo - новости вокруг разработки
https://devhands.io - хайлоад-буткэмп для девелоперов (по-прежнему идёт набор в пилотные группы!)
В прошлом посте я написал, что нужен фокус на слабых сторонах: там сидят наши потери. Эффективность организации падает не потому, что мы хреново используем наши сильные стороны, а потому что мы допустили перекос в слабых, и потери убивают нашу эффективность. Грубо, у нас отличный дизайн. Зачем нам улучшать дизайн и делать его просто бомбическим, если внезапно у инженеров текучка 50% в год?
Фокус на потерях - идея старая, пришла из философии бережливого производства, но в книжках, которые я читал, все потери были уж чересчур ”производственные”: перепроизводство, ожидание, запасы, ну вот это всё. Короче, я возможно мало читал или плохо искал, но я не знаю и не нашел нормального списка потерь для разработки. Поэтому я хочу взять на себя смелость и поделиться своим. Я разбил его на две группы, позволю себе не расписывать каждый компонент, кажется там всё достаточно понятно.
Потери первого рода - проявляются на всех, даже самых малых масштабах
1. потери целей (неверных, избыточных, формулировок)
2. потери декомпозиции (как проекта так и ролей)
3. потери мотивации и фокуса (миллион всего, основное: быстро-весело, не тяп-ляп, ору о проблемах и решаю их сам, дружно и по-доброму. И меня не отвлекают и не заваливают кучей одновременных проектов)
4. потери качества (и баги, и косяки эксплуатации)
5. потери координации и контроля (потери поздней реакции на изменения, боязнь уволить и тд)
Потери второго рода - проявляются на большем масштабе
1. потери организационных зависимостей (зависимости между отделами, коммуникация, ожидания, сюда же наверное скорость найма, хотя тянет на отдельный пункт)
2. потери техдолга (любого, начиная с выбора инструментов)
3. потери безопасности
4. потери производительности и масштабирования
Что думаете, ничего не забыл? Будет интересно узнать ваше мнение. То, что некоторые потери второго рода могут проявляться на уровне команд - понимаю, но нельзя же делать один список из 9 пунктов - его ж не запомнит никто.
————
@feedmetoo - новости вокруг разработки
https://devhands.io - хайлоад-буткэмп для девелоперов (по-прежнему идёт набор в пилотные группы!)
👍14
Threads
На днях открылся Threads, конкурент Твиттера от Инстаграм (как его писать по-русски, Трэдз? Посмотрим). Короче, я сразу зарегился, вот мои впечатления.
Главный успех, на мой взгляд, это очень добротно сделанное приложение, и похоже, с крутейшей инфрой под капотом. Если мне не изменяет память, у меня были дни с миллионом регистраций в день, но сделать десятки миллонов в день и нигде не слажать - это вот мега-круто. Мне нравится интерфейс, и меня даже не раздражает индикатор загрузки в виде червячка, заполняемой цветом.
Технологии могут быть крутые, но это вообще не главное. С точки зрения продукта: я не понимаю, зачем ещё одна соц-сеть. Я понимаю, зачем ещё одна казуальная игра, даже если она кажется похожей на прежние: налил трафик с понятной конверсией - если откалибрована механика продаж/рекламы, то будет профит. Понимаю, зачем ещё один магазин: люди покупали, покупают, и будут покупать продукты/вещи/услуги. Но в соц-сети успешность в первую очередь зависит от её “мощности” - числа активных генераторов контента. Взлет и стремительное падение добротно сделанных соц-сетей Гугла (Plus), Яндекса (Аура, Мой Круг) показало, что технологии вообще не имеют определяющего значения.
В Threads нет ничего, что бы прям меня зацепило. Мне кажется, что люди регистрируются в Threads по трем причинам: продавцы и инфлюенсеры просто потому, что надо изучать и по возможности утилизировать новые каналы, активные инстаграм пользователи - потому что интересно посмотреть, и наиболее консервативные типа меня - просто чтобы быть в курсе и застолбить ник (я знаю одного Алексея Рыбака из Лондона и даже встречался с ним, он мне говорил, как его дико бесит, что куда он ни придет - там его логин уже занят. Мне очень жаль, что ему приходится сталкиваться с такой проблемой, но мне очень не хотелось бы оказаться на его месте).
Короче, пока мой прогноз по Threads - резкое снижение всех показателей через какое-то время и быстрое “затухание”, если не будет найдена “подпитка” контентом. Буду рад ошибиться, продукт сделан правда клёво. Просто мне пока непонятно, зачем.
——
https://devhands.io - last call в пилотные июльские группы! хайлоад-буткэмп для девелоперов
@feedmetoo - новости вокруг разработки
На днях открылся Threads, конкурент Твиттера от Инстаграм (как его писать по-русски, Трэдз? Посмотрим). Короче, я сразу зарегился, вот мои впечатления.
Главный успех, на мой взгляд, это очень добротно сделанное приложение, и похоже, с крутейшей инфрой под капотом. Если мне не изменяет память, у меня были дни с миллионом регистраций в день, но сделать десятки миллонов в день и нигде не слажать - это вот мега-круто. Мне нравится интерфейс, и меня даже не раздражает индикатор загрузки в виде червячка, заполняемой цветом.
Технологии могут быть крутые, но это вообще не главное. С точки зрения продукта: я не понимаю, зачем ещё одна соц-сеть. Я понимаю, зачем ещё одна казуальная игра, даже если она кажется похожей на прежние: налил трафик с понятной конверсией - если откалибрована механика продаж/рекламы, то будет профит. Понимаю, зачем ещё один магазин: люди покупали, покупают, и будут покупать продукты/вещи/услуги. Но в соц-сети успешность в первую очередь зависит от её “мощности” - числа активных генераторов контента. Взлет и стремительное падение добротно сделанных соц-сетей Гугла (Plus), Яндекса (Аура, Мой Круг) показало, что технологии вообще не имеют определяющего значения.
В Threads нет ничего, что бы прям меня зацепило. Мне кажется, что люди регистрируются в Threads по трем причинам: продавцы и инфлюенсеры просто потому, что надо изучать и по возможности утилизировать новые каналы, активные инстаграм пользователи - потому что интересно посмотреть, и наиболее консервативные типа меня - просто чтобы быть в курсе и застолбить ник (я знаю одного Алексея Рыбака из Лондона и даже встречался с ним, он мне говорил, как его дико бесит, что куда он ни придет - там его логин уже занят. Мне очень жаль, что ему приходится сталкиваться с такой проблемой, но мне очень не хотелось бы оказаться на его месте).
Короче, пока мой прогноз по Threads - резкое снижение всех показателей через какое-то время и быстрое “затухание”, если не будет найдена “подпитка” контентом. Буду рад ошибиться, продукт сделан правда клёво. Просто мне пока непонятно, зачем.
——
https://devhands.io - last call в пилотные июльские группы! хайлоад-буткэмп для девелоперов
@feedmetoo - новости вокруг разработки
👍3
Вчера посетил мероприятие Yandex.Cloud (спасибо Oleg Bondar ) - Yandex Data Open Source Day. Уже готово видео - но там целых пять часов (https://youtu.be/aXflVfvoLdU).Полную программу можно посмотреть на сайте мероприятия (https://cloud.yandex.ru/events/799). Если будут готовы презентации - добавлю в комментарии.
Мне было интересно в первую очередь из-за YDB и YTsaurus - первые три доклада (1.5 часа) про это:
- Олег Бондарь, “Платформа YDB: год после выхода в Open Source и перспективы развития”
- Андрей Ривкин, “YTsaurus: как устроена платформа обработки больших данных Яндекса”
- Алексей Дмитриев, “Yandex Data Streams: как передавать 80/120 ГБ данных в секунду”
То, что Яндекс открыл YDB - не новость, хотя мне был в целом интересен ретроспективный первый доклад и планы на развитие. Здорово, что ребята стараются поддержать семантику SQL, как она принята в PostgreSQL.
Но главное, что там в экосистеме сейчас происходит - это появление аналога Кафки (YDB Topics), и код этого дела теперь тоже открыт. В прошлом ноябре на московском хайлоаде был доклад, но я его пропустил. Про это два других доклада. Программа была большой - там так же доклады от Ozon (про кастомную Кафку), от Bitrix24 (ультра-позитивный поток сознания про Open Source), GreenPlum и другие. Enjoy.
P.S. мне удалось договориться о митапе “AI для разработчика” - про использование современных AI-методов и сервисов для решения повседневных инженерных задач (Программа: ChatGPT для разработчиков и архитекторов, CoPilot для быстрой разработки, GPT Engineer как новый шаг в автоматизации работы, альтернативные сервисы и интересные способы использования). Вещание будет в Youtube 19-го июля 2023 года, там же появится запись. Более полный анонс состоится сегодня в группе ФБ и канале @feedmetoo.
—
devhands.io - хайлоад буткэмп для девелоперов (продолжаю пилотный набор: своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Мне было интересно в первую очередь из-за YDB и YTsaurus - первые три доклада (1.5 часа) про это:
- Олег Бондарь, “Платформа YDB: год после выхода в Open Source и перспективы развития”
- Андрей Ривкин, “YTsaurus: как устроена платформа обработки больших данных Яндекса”
- Алексей Дмитриев, “Yandex Data Streams: как передавать 80/120 ГБ данных в секунду”
То, что Яндекс открыл YDB - не новость, хотя мне был в целом интересен ретроспективный первый доклад и планы на развитие. Здорово, что ребята стараются поддержать семантику SQL, как она принята в PostgreSQL.
Но главное, что там в экосистеме сейчас происходит - это появление аналога Кафки (YDB Topics), и код этого дела теперь тоже открыт. В прошлом ноябре на московском хайлоаде был доклад, но я его пропустил. Про это два других доклада. Программа была большой - там так же доклады от Ozon (про кастомную Кафку), от Bitrix24 (ультра-позитивный поток сознания про Open Source), GreenPlum и другие. Enjoy.
P.S. мне удалось договориться о митапе “AI для разработчика” - про использование современных AI-методов и сервисов для решения повседневных инженерных задач (Программа: ChatGPT для разработчиков и архитекторов, CoPilot для быстрой разработки, GPT Engineer как новый шаг в автоматизации работы, альтернативные сервисы и интересные способы использования). Вещание будет в Youtube 19-го июля 2023 года, там же появится запись. Более полный анонс состоится сегодня в группе ФБ и канале @feedmetoo.
—
devhands.io - хайлоад буткэмп для девелоперов (продолжаю пилотный набор: своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
YouTube
Data Open Source Day
Первая конференция Yandex Cloud про Open Source инструменты для обработки данных и создания корпоративных хранилищ.
Data Open Source Day — это доклады экспертов, которые создают решения с открытым исходным кодом для реальных задач бизнеса. Это дискуссии…
Data Open Source Day — это доклады экспертов, которые создают решения с открытым исходным кодом для реальных задач бизнеса. Это дискуссии…
👍3
Lessons learned по пилотам DevHands.
На этой неделе я запускаю третий пилотный поток “хайлоад-буткемпа” DevHands.io. Видимо, это будет последний или предпоследний пилот. Сегодня, 18-го июля, в 18:30 msk открытая встреча для тех, кто уже попал в июльский поток, и всех интересующихся: https://meet.google.com/odo-nyox-fqs, приходите.
За два месяца работы с несколькими пилотными группами я понял несколько прикольных вещей.
(1) Очень полезно разделять участников и предлагать разные образовательные пути. Основные дифференциаторы: по ожидаемому формату и по времени, которое участники готовы тратить на самостоятельную практику.
Большая часть участников, покупая образовательный продукт, представляет себе, что произойдет магический “перенос” между состояниями “я сейчас” и “я в будущем, лучше”. Прочитал текст, просмотрел видео - и перенесся из одного состояния в другое. Это хорошо работает, если знание упаковано в набор рецептов. В теме, за которую я взялся - это невозможно, путь длинный, должно быть много практики. Основная задача - чтобы люди научились новому, сделали буст в понимании архитектуры, ифнраструктуры, поняли ценность и советовали этот трек. Путь между состояниями нетривиальный, его нельзя пройти без серьёзной работы. И на неё не все готовы. Подавляющее большинство людей работает, у них мало времени. Асинхронная практика помогает, но этого мало - нужно больше поддержки. Нужно подготовить значительно больше дополнительных материалов, чего я не делал, считая, что в противном случае получится слишком много “бездумной копипасты”. Без этих материалов снижается ретеншен, конверсии по этапам обучения, NPS. Это вроде было понятно с самого начала, но мотивация и усилия участников разные.
(2) Следствие п.1 #1: нужен фаст-трек для занятых, без практической части вообще.
(3) Следствие п.1 #2: нужно давать возможнось переходить между потоками тем, кто не успевает. Называть это “академом” не хочется, но и бесконечно переходить тоже давать нельзя.
(4) Хороший продукт в этой сфере - PAAS. С первого дня участник получает инфраструктуру и работает с ней полгода: настраивает свой стек, изучает производительность, выжимает максимум из одной ноды, учится масштабировать на много нод. Это превращает провайдера из “традиционного” EdTech в клауд-компанию. Я это понимал изначально, но не понимал как много там работы. Сейчас задача – найти правильный балланс между автоматизацией и полу-облачными услугами.
(5) Буду больше уделять времени объяснению ценности модуля нагрузочного тестирования. Даже многие опытные разработчики не очень понимают, чем в обучении помогает тестирование производительности: “ведь это работа devops”. Мне совершенно не хочется бороться с ветряными мельницами, просто констатирую факт, который оказался неожиданным. Вероятно, стоит унести этот модуль в отдельный трек, но продолжить “пропагандировать" его важность для разработчиков.
(6) Очень важен маркетинг и каналы продаж. Но с ростом охвата хорошо растёт число пришедших от друзей, коллег и знакомых. Это приятно.
На этой неделе я запускаю третий пилотный поток “хайлоад-буткемпа” DevHands.io. Видимо, это будет последний или предпоследний пилот. Сегодня, 18-го июля, в 18:30 msk открытая встреча для тех, кто уже попал в июльский поток, и всех интересующихся: https://meet.google.com/odo-nyox-fqs, приходите.
За два месяца работы с несколькими пилотными группами я понял несколько прикольных вещей.
(1) Очень полезно разделять участников и предлагать разные образовательные пути. Основные дифференциаторы: по ожидаемому формату и по времени, которое участники готовы тратить на самостоятельную практику.
Большая часть участников, покупая образовательный продукт, представляет себе, что произойдет магический “перенос” между состояниями “я сейчас” и “я в будущем, лучше”. Прочитал текст, просмотрел видео - и перенесся из одного состояния в другое. Это хорошо работает, если знание упаковано в набор рецептов. В теме, за которую я взялся - это невозможно, путь длинный, должно быть много практики. Основная задача - чтобы люди научились новому, сделали буст в понимании архитектуры, ифнраструктуры, поняли ценность и советовали этот трек. Путь между состояниями нетривиальный, его нельзя пройти без серьёзной работы. И на неё не все готовы. Подавляющее большинство людей работает, у них мало времени. Асинхронная практика помогает, но этого мало - нужно больше поддержки. Нужно подготовить значительно больше дополнительных материалов, чего я не делал, считая, что в противном случае получится слишком много “бездумной копипасты”. Без этих материалов снижается ретеншен, конверсии по этапам обучения, NPS. Это вроде было понятно с самого начала, но мотивация и усилия участников разные.
(2) Следствие п.1 #1: нужен фаст-трек для занятых, без практической части вообще.
(3) Следствие п.1 #2: нужно давать возможнось переходить между потоками тем, кто не успевает. Называть это “академом” не хочется, но и бесконечно переходить тоже давать нельзя.
(4) Хороший продукт в этой сфере - PAAS. С первого дня участник получает инфраструктуру и работает с ней полгода: настраивает свой стек, изучает производительность, выжимает максимум из одной ноды, учится масштабировать на много нод. Это превращает провайдера из “традиционного” EdTech в клауд-компанию. Я это понимал изначально, но не понимал как много там работы. Сейчас задача – найти правильный балланс между автоматизацией и полу-облачными услугами.
(5) Буду больше уделять времени объяснению ценности модуля нагрузочного тестирования. Даже многие опытные разработчики не очень понимают, чем в обучении помогает тестирование производительности: “ведь это работа devops”. Мне совершенно не хочется бороться с ветряными мельницами, просто констатирую факт, который оказался неожиданным. Вероятно, стоит унести этот модуль в отдельный трек, но продолжить “пропагандировать" его важность для разработчиков.
(6) Очень важен маркетинг и каналы продаж. Но с ростом охвата хорошо растёт число пришедших от друзей, коллег и знакомых. Это приятно.
Google
Real-time meetings by Google. Using your browser, share your video, desktop, and presentations with teammates and customers.
👍6
Latency и число открытых соединений wrk2
Хадкорным технарям вопрос, который мне не дает покоя, и на который я пока не могу найти ответ. Последние несколько недель мы активно “стреляем” в разные конфигурации сервисов в модуле “Производительность” бекенд-буткемпа. Наш основной инструмент - wrk2. Он умеет открыть m соединений, пошерить их между k>=m тредов и начать стрелять с заданным rate (число запросов в секунду), а на выходе умеет отдать гистрограммы распределений latency (время ответа).
Так вот экспериментально было обнаружено минорное, но непонятное свойство. Стреляем в nginx, который отдает всего один небольшой статический url. При числе открытых соединений около ста latency запросов к nginx получается минимальным - несколько миллисекунд при общем потоке в тысячи запросов в секунду. Далее при движении вправо-влево от этого минимума (при увеличении и при уменьшении числа открытых соединений) latency только растет. Почему оно растет в пределе при увеличении числа соединений понятно - чем больше обслуживать соединений, тем больше тратится ресурсов. Почему оно может расти при уменьшении числа соединений тоже понятно, если это число становится меньше числа ядер на ноде стрелялки или числа ядер на стороне обстреливаемого сервера - тогда получится просто неполное использование ресурсов. Но речь идёт о числах, заметно превышающих число ядер!
Помимо прочих оптимизаций, в nginx ключевая особенность, которые позволяет делать ряд операций “один раз для многих соединений”. Это современный “еполлинг” ядра: nginx за один системный вызов получает список всех дескрипторов соединений, которые “готовы” для обработки, и далее работа ведется последовательно только с этими соединениями. Это позволяет писать “мультиплексирующие” сервера, когда один воркер может обработать очень много соединений. Но в таком случае при обработке одного и того же потока запроса условно M и 2M соединениями будет следующее отличие. В первом случае будет больше поллинг-вызовов но короче циклы, а втором случае меньше поллинг-вызовов но длиннее циклы. Но общее число операций в циклах будет одинаковым, так как за единицу времени приходит одинаковое количество запросов - поэтому в целом наличие минимума latency в раойне ста соединений непонятно.
Короче, тут может кроется причина наблюдаемого поведения, но я в деталях не понимаю: почему всё-таки в каком-то интервале быстрее обрабатывать больше соединений, но затем это становится невыгодным, причем речь идет всего о каких-то сотнях соединений. Я так же охотно верю, что в результате окажется, что это особенность не сервера, а стрелялки, wrk2.
В целом это минорная штука, всё-таки основная цель модуля “Производительность” в том, чтобы научиться проводить осмысленное нагрузочное тестирование и на пальцах понять порядки RPS, которые можно “выжать” с каждой ноды, а также убедиться, как сильно отличается “кост” запросов к разным компонентам. Но тем не менее, интересно. Напишите, пожалуйста, если есть какие-то идеи, почему такое наблюдается: я и все участники буткемпа будут очень признательны, если кто-то поможет найти этому чёткое ткое объяснение.
—
devhands.io - хайлоад буткэмп для девелоперов (последний пилотный набор в августе: своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Хадкорным технарям вопрос, который мне не дает покоя, и на который я пока не могу найти ответ. Последние несколько недель мы активно “стреляем” в разные конфигурации сервисов в модуле “Производительность” бекенд-буткемпа. Наш основной инструмент - wrk2. Он умеет открыть m соединений, пошерить их между k>=m тредов и начать стрелять с заданным rate (число запросов в секунду), а на выходе умеет отдать гистрограммы распределений latency (время ответа).
Так вот экспериментально было обнаружено минорное, но непонятное свойство. Стреляем в nginx, который отдает всего один небольшой статический url. При числе открытых соединений около ста latency запросов к nginx получается минимальным - несколько миллисекунд при общем потоке в тысячи запросов в секунду. Далее при движении вправо-влево от этого минимума (при увеличении и при уменьшении числа открытых соединений) latency только растет. Почему оно растет в пределе при увеличении числа соединений понятно - чем больше обслуживать соединений, тем больше тратится ресурсов. Почему оно может расти при уменьшении числа соединений тоже понятно, если это число становится меньше числа ядер на ноде стрелялки или числа ядер на стороне обстреливаемого сервера - тогда получится просто неполное использование ресурсов. Но речь идёт о числах, заметно превышающих число ядер!
Помимо прочих оптимизаций, в nginx ключевая особенность, которые позволяет делать ряд операций “один раз для многих соединений”. Это современный “еполлинг” ядра: nginx за один системный вызов получает список всех дескрипторов соединений, которые “готовы” для обработки, и далее работа ведется последовательно только с этими соединениями. Это позволяет писать “мультиплексирующие” сервера, когда один воркер может обработать очень много соединений. Но в таком случае при обработке одного и того же потока запроса условно M и 2M соединениями будет следующее отличие. В первом случае будет больше поллинг-вызовов но короче циклы, а втором случае меньше поллинг-вызовов но длиннее циклы. Но общее число операций в циклах будет одинаковым, так как за единицу времени приходит одинаковое количество запросов - поэтому в целом наличие минимума latency в раойне ста соединений непонятно.
Короче, тут может кроется причина наблюдаемого поведения, но я в деталях не понимаю: почему всё-таки в каком-то интервале быстрее обрабатывать больше соединений, но затем это становится невыгодным, причем речь идет всего о каких-то сотнях соединений. Я так же охотно верю, что в результате окажется, что это особенность не сервера, а стрелялки, wrk2.
В целом это минорная штука, всё-таки основная цель модуля “Производительность” в том, чтобы научиться проводить осмысленное нагрузочное тестирование и на пальцах понять порядки RPS, которые можно “выжать” с каждой ноды, а также убедиться, как сильно отличается “кост” запросов к разным компонентам. Но тем не менее, интересно. Напишите, пожалуйста, если есть какие-то идеи, почему такое наблюдается: я и все участники буткемпа будут очень признательны, если кто-то поможет найти этому чёткое ткое объяснение.
—
devhands.io - хайлоад буткэмп для девелоперов (последний пилотный набор в августе: своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
👍3
Cтрасть против опыта
Для участия в буткемпе по производительности/масштабированию (DevHands.io) я по-прежнему ориентируюсь на тех, кто имеет несколько лет опыта в бэкенде. Это создает определенный входной барьер, многие потенциальные слушатели считают его довольно высоким. Люди вообще считают темы производительности/масштабируемости "ракетостроением", что создает иллюзию чрезвычайно высокой планки само по себе. На самом деле эта планка гораздо ниже, и это задача наша - провести людей через эту "планку" в ходе обучения.
Но пробел в знаниях ещё менее важен: главное - это увлеченность. Вообще, это тривиально, и я много раз наблюдал это во многих инженерных командах: страсть всегда побеждает недостаток знаний. И сейчас я вижу, что есть куча людей, пришедших из фронтенда, из менеджмента, даже из мобильной разработки. С большим энтузиазмом и самыми базовыми навыками - и они успешно двигаются вперед. А опытные бэкендеры и девопсы, которые либо сильно ограничены во времени, либо менее увлечены - их прогресс ниже.
Так что мой список "трех добродетелей программиста" выглядит так: "Последовательность, постоянство и настойчивость". Impatience, но не Lazyness и не Hubris IYKWIM;)
--
devhands.io: хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн, 100% асинхронной практики и еженедельные онлайн-сессии)
@feedmetoo - новости про разработку, статьи, презентации
Для участия в буткемпе по производительности/масштабированию (DevHands.io) я по-прежнему ориентируюсь на тех, кто имеет несколько лет опыта в бэкенде. Это создает определенный входной барьер, многие потенциальные слушатели считают его довольно высоким. Люди вообще считают темы производительности/масштабируемости "ракетостроением", что создает иллюзию чрезвычайно высокой планки само по себе. На самом деле эта планка гораздо ниже, и это задача наша - провести людей через эту "планку" в ходе обучения.
Но пробел в знаниях ещё менее важен: главное - это увлеченность. Вообще, это тривиально, и я много раз наблюдал это во многих инженерных командах: страсть всегда побеждает недостаток знаний. И сейчас я вижу, что есть куча людей, пришедших из фронтенда, из менеджмента, даже из мобильной разработки. С большим энтузиазмом и самыми базовыми навыками - и они успешно двигаются вперед. А опытные бэкендеры и девопсы, которые либо сильно ограничены во времени, либо менее увлечены - их прогресс ниже.
Так что мой список "трех добродетелей программиста" выглядит так: "Последовательность, постоянство и настойчивость". Impatience, но не Lazyness и не Hubris IYKWIM;)
--
devhands.io: хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн, 100% асинхронной практики и еженедельные онлайн-сессии)
@feedmetoo - новости про разработку, статьи, презентации
👍7
Screen Shot 2023-09-06 at 18.22.36.png
1 MB
Как отмасштабировать что угодно?
Сделал такой попсовый слайд и понял, что чем-то он мне напоминает ТРИЗ. А к ТРИЗ у меня всегда было такое отношение, настороженное: слишком общо.
К сожалению, плохо помню все его принципы - там есть что-то про универсальные подходы к масштабированию? В-общем, если вы знаток ТРИЗ, я буду вам очень признателен, если подскажете, как разложить “алгоритм масштабирования” в терминах приемов ТРИЗ.
Кстати, в буткемпе стартует сентябрьский поток. Осталось всего три места. На следующей неделе во вторник 12 сентябре в 14:00 мск будет открытая онлайн-встреча в зуме (https://devhands.io/zoom.html). Кому интересно - приходите, и друзей/коллег приводите.
Сделал такой попсовый слайд и понял, что чем-то он мне напоминает ТРИЗ. А к ТРИЗ у меня всегда было такое отношение, настороженное: слишком общо.
К сожалению, плохо помню все его принципы - там есть что-то про универсальные подходы к масштабированию? В-общем, если вы знаток ТРИЗ, я буду вам очень признателен, если подскажете, как разложить “алгоритм масштабирования” в терминах приемов ТРИЗ.
Кстати, в буткемпе стартует сентябрьский поток. Осталось всего три места. На следующей неделе во вторник 12 сентябре в 14:00 мск будет открытая онлайн-встреча в зуме (https://devhands.io/zoom.html). Кому интересно - приходите, и друзей/коллег приводите.
👍4
Work, мать его, balance
Тема, которая меня волнует (волнует? ну хоть лучше чем ”откликается”). Заранее предупреждаю: (а) утрирую специально (б) у меня было “тяжелое детство” в стартапах, что оставило серьезный отпечаток (в) отпечаток на полном серьезе серьезный! если вам категорически не нравится (не нравилась) работа в стартапе - не читайте, этот пост причиняет страдания! я вас предупреждал.
Во времена, когда собаки не брали наш след, казалось, что мир делится на две половины:
* одни считают, что все великие дела делаются в поту и страданиях, поэтому надо херачить, а кто не херачит - тот черепашка, профессор, и вообще слюнтяй (среди этой группы прожженым самураям особенно пристально нужно приматриваться к пассионарным диссидентам, ну это знаете, такие, “фашистские суки, я гибну за вашу мечту” - при первых признаках окукливания в самурая держать их, и никуда не отпускать ни за что)
* тех, кто считает, что жизнь легка, и крайне неразумно бросать её в топку пошлой капиталистической гонки, поэтому отдых, путешествия, яхты (в аренду, конечно), виноградники и гедонизм - вот это всё достойный ответ пошлости от непошлости. Из любого стартапа таких можно гнать в шею абсолютно безболезненно; но поскольку эти граждане в целом очень негпупые, часто не то чтобы совсем бесполезные, и крайне успешно чешут языком, то бывает крайне сложно их идентифицировать на входе, требуется, как нынче принято выражаться, “недюжинная насмотренность”. К сожалению, первое, чему обучается особь этой группы - резво стелить за вопросы в лоб типа “ты сам-то чё сделал”, чем крайне усложняет работу фаундерам).
Какое бинарное мышление, удивитесь вы - и будете правы! Но все эти тона и полу-тона - запутаться в них и бесславно потонуть - я даже не о них. Не полон даже базис: категорий три. И самая главная категория – те, кто херачит, как угорелые, в условные “с десяти до семи”.
Если вы думаете, что так нельзя - заведите детей. Двух, или лучше трёх.
В связи с этим мой алгоритм разговора о work-life ballance начинается с одного единственного вопроса: братела, сколько у тебя детей. Пожалуй, это всё, что я хотел сказать про work-life ballance.
P.S. Я договорился с Сашей Горным (сооснователь United Investors, мобильного приложения Мо, и автор блога "Стартап дня"), что он придет к участникам буткемпа DevHands.io, и расскажет про работу в стартапе: какие бывают, как выбирать, как и какую просить долю и многое другое. О деталях сообщим дополнительно в чатах групп буткемпа.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Тема, которая меня волнует (волнует? ну хоть лучше чем ”откликается”). Заранее предупреждаю: (а) утрирую специально (б) у меня было “тяжелое детство” в стартапах, что оставило серьезный отпечаток (в) отпечаток на полном серьезе серьезный! если вам категорически не нравится (не нравилась) работа в стартапе - не читайте, этот пост причиняет страдания! я вас предупреждал.
Во времена, когда собаки не брали наш след, казалось, что мир делится на две половины:
* одни считают, что все великие дела делаются в поту и страданиях, поэтому надо херачить, а кто не херачит - тот черепашка, профессор, и вообще слюнтяй (среди этой группы прожженым самураям особенно пристально нужно приматриваться к пассионарным диссидентам, ну это знаете, такие, “фашистские суки, я гибну за вашу мечту” - при первых признаках окукливания в самурая держать их, и никуда не отпускать ни за что)
* тех, кто считает, что жизнь легка, и крайне неразумно бросать её в топку пошлой капиталистической гонки, поэтому отдых, путешествия, яхты (в аренду, конечно), виноградники и гедонизм - вот это всё достойный ответ пошлости от непошлости. Из любого стартапа таких можно гнать в шею абсолютно безболезненно; но поскольку эти граждане в целом очень негпупые, часто не то чтобы совсем бесполезные, и крайне успешно чешут языком, то бывает крайне сложно их идентифицировать на входе, требуется, как нынче принято выражаться, “недюжинная насмотренность”. К сожалению, первое, чему обучается особь этой группы - резво стелить за вопросы в лоб типа “ты сам-то чё сделал”, чем крайне усложняет работу фаундерам).
Какое бинарное мышление, удивитесь вы - и будете правы! Но все эти тона и полу-тона - запутаться в них и бесславно потонуть - я даже не о них. Не полон даже базис: категорий три. И самая главная категория – те, кто херачит, как угорелые, в условные “с десяти до семи”.
Если вы думаете, что так нельзя - заведите детей. Двух, или лучше трёх.
В связи с этим мой алгоритм разговора о work-life ballance начинается с одного единственного вопроса: братела, сколько у тебя детей. Пожалуй, это всё, что я хотел сказать про work-life ballance.
P.S. Я договорился с Сашей Горным (сооснователь United Investors, мобильного приложения Мо, и автор блога "Стартап дня"), что он придет к участникам буткемпа DevHands.io, и расскажет про работу в стартапе: какие бывают, как выбирать, как и какую просить долю и многое другое. О деталях сообщим дополнительно в чатах групп буткемпа.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
👍21👎2
CAP-теорема простыми словами
Если погуглить CAP-теорему, выпадет миллион ссылок, большинство из которых содержат довольно заумную муть. Чуваки, CAP-теорема - это очень просто.
Без ухода в дебри, что утверждает CAP-теорема? Что в распределенной интернет-системе, по умолчанию толерантной к “разрывам”, можно выбрать либо доступность (А - availability) либо консистентность (C - consistency). Почему немного странно, что мы это знание запоминаем как Теорему?
Да потому что этот факт на самом деле понятен любому погромисту, который пишет дейтинги на похапе:
* либо твоя транзакция раскатывается сразу на несколько нод, и тогда у тебя есть консистентность между узлами, но при разрыве система становится недоступной (недоступна запись - ты же не можешь раскатать запись по нодам из-за разрыва). Ты выбрал consistency, потерял availability.
* либо ты раскатываешь транзакцию не сразу, но тогда у тебя нет консистентности, пока не доедет изменение (обычно eventual consistency - консистентность не сразу, но когда-нибудь обязательно). Ты выбрал availability, но потерял consistency.
Всё, элементарно. Не благодарите 🙂
Если интересны эти и многие другие темы по производительности и масштабированию - приходите к нам на практический хайлоад-буткемп devhands.io. В ноябре будет скорее всего последний набор в 2023-м году: слишком много участников, и каждому подай хорошую дорогую инфру 🙂 Приходите сами, посылайте коллег, приводите друзей и подруг.
——
devhands.io - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать)
Если погуглить CAP-теорему, выпадет миллион ссылок, большинство из которых содержат довольно заумную муть. Чуваки, CAP-теорема - это очень просто.
Без ухода в дебри, что утверждает CAP-теорема? Что в распределенной интернет-системе, по умолчанию толерантной к “разрывам”, можно выбрать либо доступность (А - availability) либо консистентность (C - consistency). Почему немного странно, что мы это знание запоминаем как Теорему?
Да потому что этот факт на самом деле понятен любому погромисту, который пишет дейтинги на похапе:
* либо твоя транзакция раскатывается сразу на несколько нод, и тогда у тебя есть консистентность между узлами, но при разрыве система становится недоступной (недоступна запись - ты же не можешь раскатать запись по нодам из-за разрыва). Ты выбрал consistency, потерял availability.
* либо ты раскатываешь транзакцию не сразу, но тогда у тебя нет консистентности, пока не доедет изменение (обычно eventual consistency - консистентность не сразу, но когда-нибудь обязательно). Ты выбрал availability, но потерял consistency.
Всё, элементарно. Не благодарите 🙂
Если интересны эти и многие другие темы по производительности и масштабированию - приходите к нам на практический хайлоад-буткемп devhands.io. В ноябре будет скорее всего последний набор в 2023-м году: слишком много участников, и каждому подай хорошую дорогую инфру 🙂 Приходите сами, посылайте коллег, приводите друзей и подруг.
——
devhands.io - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать)
👍10🔥2
О loose coupling и автомобильных развязках
Одна из самых “мутных” тем в разработке больших систем - это loose coupling или слабая связанность компонент. Все знают про этот термин, но если чётко попробовать перечислить критерии, вам их никто не скажет.
Мне больше нравится термин: “развязка”, или “развязывание клиентских путей”, или “паттерны связывания клиентских путей”. Чтобы понять, loose у нас coupling либо tight, и вообще посмотреть на альтернативные конфигурации компонент, нужно
(а) всегда иметь достаточно подробную для контекста карту компонент (но не максимально подробную - свихнешься от деталей в аду аналитика), и
(б) построить все клиентсткие пути (или request lifetime), именно они и “связывают” наши компоненты
И только после того, как понятны карты и пути, можно обсудить все возможные конфигурации, и выбрать ту, где связанность “пониже”. А что значит “пониже”? Это когда выход из строя (либо существенная деградация) одного компонента рушит не всю систему (все клиентские пути), а лишь часть, и чем меньше наше “связывание”, тем меньше урон. Начинаем “развязывать” эти пути, чаще всего сразу растёт кост, и начинается игра баланса коста и риска.
Здесь уместно вообще начать вспоминать не про ИТ-системы, а про большие магазины и автомобильные развязки. Терминалы самообслуживания и кассы для покупателей с небольшими корзинами, расширение трассы в области оплаты и развязка левого поворота отдельным “мостом-рукавом” - видите, даже термин “развязка” - всё это про развязку клиенстких путей.
А с паттернами связывания сложнее: их очень много, но самые распространенные – пошеренная файловая система и пошеренная нагруженная база без кеш-слоя. Вообще было бы здорово, конечно, собрать сборник таких паттернов, может они есть уже? Подскажите, пожалуйста, свои примеры в комментариях!
P.S. Развязывание часто пересекается и даже противоречит изоляции, и тут конечно главное не переборщить, и не забыть, с чего вообще всё началось. Обратный пример веселой дискуссии о клиентском пути современных разработчиков микро-сервисных архитектур можно увидеть, например, здесь (сорян за боян):
https://www.youtube.com/watch?v=y8OnoxKotPQ
——
devhands.io - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Одна из самых “мутных” тем в разработке больших систем - это loose coupling или слабая связанность компонент. Все знают про этот термин, но если чётко попробовать перечислить критерии, вам их никто не скажет.
Мне больше нравится термин: “развязка”, или “развязывание клиентских путей”, или “паттерны связывания клиентских путей”. Чтобы понять, loose у нас coupling либо tight, и вообще посмотреть на альтернативные конфигурации компонент, нужно
(а) всегда иметь достаточно подробную для контекста карту компонент (но не максимально подробную - свихнешься от деталей в аду аналитика), и
(б) построить все клиентсткие пути (или request lifetime), именно они и “связывают” наши компоненты
И только после того, как понятны карты и пути, можно обсудить все возможные конфигурации, и выбрать ту, где связанность “пониже”. А что значит “пониже”? Это когда выход из строя (либо существенная деградация) одного компонента рушит не всю систему (все клиентские пути), а лишь часть, и чем меньше наше “связывание”, тем меньше урон. Начинаем “развязывать” эти пути, чаще всего сразу растёт кост, и начинается игра баланса коста и риска.
Здесь уместно вообще начать вспоминать не про ИТ-системы, а про большие магазины и автомобильные развязки. Терминалы самообслуживания и кассы для покупателей с небольшими корзинами, расширение трассы в области оплаты и развязка левого поворота отдельным “мостом-рукавом” - видите, даже термин “развязка” - всё это про развязку клиенстких путей.
А с паттернами связывания сложнее: их очень много, но самые распространенные – пошеренная файловая система и пошеренная нагруженная база без кеш-слоя. Вообще было бы здорово, конечно, собрать сборник таких паттернов, может они есть уже? Подскажите, пожалуйста, свои примеры в комментариях!
P.S. Развязывание часто пересекается и даже противоречит изоляции, и тут конечно главное не переборщить, и не забыть, с чего вообще всё началось. Обратный пример веселой дискуссии о клиентском пути современных разработчиков микро-сервисных архитектур можно увидеть, например, здесь (сорян за боян):
https://www.youtube.com/watch?v=y8OnoxKotPQ
——
devhands.io - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
YouTube
Microservices
it's because of the way our backend works
// more krazam scenes: https://www.patreon.com/KRAZAM
// merch: https://merch.krazam.tv
// https://www.instagram.com/krazam.tv
// https://twitter.com/krazamtv
// more krazam scenes: https://www.patreon.com/KRAZAM
// merch: https://merch.krazam.tv
// https://www.instagram.com/krazam.tv
// https://twitter.com/krazamtv
👍8
Fear of truth runs deep
Картинки экспертов ByteByteGo и DesignGurus - мягко говоря сомнительного свойства (и дело даже не в анимированных стрелочках, хотя убить можно только за них).
Чтобы в этом убедиться, можете посмотреть, например, документ “cacheing strategies”. Он предполагает, например такие паттерны как read/write-thru, но я испытываю искреннюю благодарность: у нас у всех теперь есть +1 вопрос в архитектурной секции интервью: “почему паттерны read/write-thru - фуфло?”.
А сегодня отличный тред начался в LinkedIn, в ответ на пост с рекомендациями для питонистов. Ознакомьтесь, автор Vaughn Vernon - автор монографии по DDD, например.
https://www.linkedin.com/posts/vaughnvernon_dddesign-ugcPost-7124407442628579328-EYTg/
Но старательно, старательно обходят гуру дизайна главный совет, numero uno, “use separate data storage for each microservice”. Чтош, я тепреливо жду, когда же хоть кто-то выйдет и нормально им так всем впеднюрит за инфру, за косты и за по три ненагруженных менеджед-базы на каждый сопливый микросервис: девел, стейджинг и прод.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Картинки экспертов ByteByteGo и DesignGurus - мягко говоря сомнительного свойства (и дело даже не в анимированных стрелочках, хотя убить можно только за них).
Чтобы в этом убедиться, можете посмотреть, например, документ “cacheing strategies”. Он предполагает, например такие паттерны как read/write-thru, но я испытываю искреннюю благодарность: у нас у всех теперь есть +1 вопрос в архитектурной секции интервью: “почему паттерны read/write-thru - фуфло?”.
А сегодня отличный тред начался в LinkedIn, в ответ на пост с рекомендациями для питонистов. Ознакомьтесь, автор Vaughn Vernon - автор монографии по DDD, например.
https://www.linkedin.com/posts/vaughnvernon_dddesign-ugcPost-7124407442628579328-EYTg/
Но старательно, старательно обходят гуру дизайна главный совет, numero uno, “use separate data storage for each microservice”. Чтош, я тепреливо жду, когда же хоть кто-то выйдет и нормально им так всем впеднюрит за инфру, за косты и за по три ненагруженных менеджед-базы на каждый сопливый микросервис: девел, стейджинг и прод.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Linkedin
#dddesign | Vaughn Vernon | 61 comments
My ability to comment on Alex Xu's posts has been blocked. Since I don't recall ever directly commenting on one of his posts, that "picture" is worth 1,000 words.
In general I find these posts shallow click bait that are driven by attention seeking rather…
In general I find these posts shallow click bait that are driven by attention seeking rather…
👍7
Отзывы на модуль “M2. Производительность”
Давно уже собрал, но не публиковал отзывы участников буткемпа после обучения в модуле “Производительность”. Исправляюсь. Это - реальные отзывы ребят, безо всякой литературной обработки, причем именно этой группе выпала самая “сырая" подача этого модуля, сейчас он стал несколько проще (больше вводных демо и разьяснений по автоматизации). Ребята, большое спасибо вам за отзывы!
Владимир И (10+ лет опыта, Python/uWSGI/MySQL, небольшой опыт системного администрирования, цели: highload, system design):
Модуль был полезен именно порядком цифр, в реальной жизни я никогда не занимался нагрузочным тестированием, и не понимал порядок цифр. Сейчас есть такое понимание, есть понимание, что чистый Python работает в разы быстрее Django, есть понимание, что в принципе может отдать Django, и это позволяет более “научно” подходить к вопросам скейлинга. В этом плане безусловно модуль полезен.
Андрей Л (10+ лет опыта, PHP/PostgreSQL/MySQL, опыт системного администрирования, цель: систематизация знаний):
Работал я с нагруженными системами много, но работал с органическим трафиком. Вот так специально брать тестовую машину, настраивать различные приложения, тюнить их, и уж тем более использовать различные “стрелялки” - никогда этим не занимался, и это было замечательно. Я wrk никогда не использовал, и теперь, если мне что-то нужно будет смотреть под нагрузкой - я понимаю, как это использовать, как эти данные собирать, обобщать, на что смотреть. Так же никогда специально не занимался тюнингом php-fpm, не разбирался, какие есть ручки, а теперь появился некий навык и даже потребность. Вот сейчас хочу протестировать насколько медленнее будет работать в проде php-fpm, если деплоить в контейнерах. Появляются вопросы к самому себе, как, где по работе что-то улучшить, подтюнить, поменять, сделать получше.
Андрей М (5+ лет опыта, Python/PostgreSQL, профессиональный опыт системного администрирования, цель: highload):
Я никогда не занимался таким нагрузочным тестирование на каком-то стенде. И я никогда не понимал даже порядок цифр, сколько можно вытащить RPS. Понятно, что всё это какие-то данные синтетические, далекие от реальности, потому что настоящее приложение будет вести себя по другому, но всё равно было очень интересно понять порядок цифр.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Давно уже собрал, но не публиковал отзывы участников буткемпа после обучения в модуле “Производительность”. Исправляюсь. Это - реальные отзывы ребят, безо всякой литературной обработки, причем именно этой группе выпала самая “сырая" подача этого модуля, сейчас он стал несколько проще (больше вводных демо и разьяснений по автоматизации). Ребята, большое спасибо вам за отзывы!
Владимир И (10+ лет опыта, Python/uWSGI/MySQL, небольшой опыт системного администрирования, цели: highload, system design):
Модуль был полезен именно порядком цифр, в реальной жизни я никогда не занимался нагрузочным тестированием, и не понимал порядок цифр. Сейчас есть такое понимание, есть понимание, что чистый Python работает в разы быстрее Django, есть понимание, что в принципе может отдать Django, и это позволяет более “научно” подходить к вопросам скейлинга. В этом плане безусловно модуль полезен.
Андрей Л (10+ лет опыта, PHP/PostgreSQL/MySQL, опыт системного администрирования, цель: систематизация знаний):
Работал я с нагруженными системами много, но работал с органическим трафиком. Вот так специально брать тестовую машину, настраивать различные приложения, тюнить их, и уж тем более использовать различные “стрелялки” - никогда этим не занимался, и это было замечательно. Я wrk никогда не использовал, и теперь, если мне что-то нужно будет смотреть под нагрузкой - я понимаю, как это использовать, как эти данные собирать, обобщать, на что смотреть. Так же никогда специально не занимался тюнингом php-fpm, не разбирался, какие есть ручки, а теперь появился некий навык и даже потребность. Вот сейчас хочу протестировать насколько медленнее будет работать в проде php-fpm, если деплоить в контейнерах. Появляются вопросы к самому себе, как, где по работе что-то улучшить, подтюнить, поменять, сделать получше.
Андрей М (5+ лет опыта, Python/PostgreSQL, профессиональный опыт системного администрирования, цель: highload):
Я никогда не занимался таким нагрузочным тестирование на каком-то стенде. И я никогда не понимал даже порядок цифр, сколько можно вытащить RPS. Понятно, что всё это какие-то данные синтетические, далекие от реальности, потому что настоящее приложение будет вести себя по другому, но всё равно было очень интересно понять порядок цифр.
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
👍11
Forwarded from feedmetoo (Alexey Rybak)
Современный PostgreSQL заметно обгоняет современный MySQL почти на всх тестах sysbench
Сначала Mark Callaghan аккуратно сравнил перфоманс MySQL и показал на тестах, что с новыми релизами в MySQL с CPU usage становится всё хуже. А затем и вовсе сравнил перфоманс MySQL и PostgreSQL, и вот его выводы:
* На большей части тестов sysbench старые версия MySQL 5.6 и PostgreSQL 11-й версии практически не отличались
* PostgreSQL 16.0 почти во всех тестах дает значительный прирост QPS (queries per second) чем MySQL 8.0.34
* Причина - CPU overhead, который “нарос” в MySQL, а PostgreSQL наоборот его избежал.
Подробности: https://smalldatum.blogspot.com/2023/10/postgres-vs-mysql-impact-of-cpu.html
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Сначала Mark Callaghan аккуратно сравнил перфоманс MySQL и показал на тестах, что с новыми релизами в MySQL с CPU usage становится всё хуже. А затем и вовсе сравнил перфоманс MySQL и PostgreSQL, и вот его выводы:
* На большей части тестов sysbench старые версия MySQL 5.6 и PostgreSQL 11-й версии практически не отличались
* PostgreSQL 16.0 почти во всех тестах дает значительный прирост QPS (queries per second) чем MySQL 8.0.34
* Причина - CPU overhead, который “нарос” в MySQL, а PostgreSQL наоборот его избежал.
Подробности: https://smalldatum.blogspot.com/2023/10/postgres-vs-mysql-impact-of-cpu.html
——
devhands.io/ru/ - хайлоад-буткэмп для девелоперов (своя инфра с первого дня, собираете свой стек, нагружаете, тюните, учитесь масштабировать - 6 месяцев онлайн)
@feedmetoo - новости про разработку, статьи, презентации
Blogspot
Postgres vs MySQL: the impact of CPU overhead on performance
This post documents how MySQL and Postgres performance has changed over time using sysbench. It compares QPS for Postgres 11.21 vs MySQL 5.6...
👍7