По-моему, вы перебарщиваете, он особенно никого не поливает, но в его словах безусловно есть нотки обиды. Послушайте, я не знаю, что он делал для nginx последние 2 года, но для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать и постараться договориться.
Про ядро - @ximaeraкоторый уже каментил выше, тут подметил крайне точно один факт, и это произошло именно 14-го февраля, в тот же день: "коллективный Торвальдс", который как раз плакал, получил таки возможность управлять процессом создания CVE:
к докладам от лидеров open sourсe проектов такого уровня могло бы быть другое отношение :) вот энжи докладывался на хайлоаде - и ничего. будет что рассказать - думаю примем с большим удовольствием.
Слово "омерзительный" всё же too much. Всё что вы пишете, справедливо в нормальной ситуации, когда есть компания, есть коллектив разработчиков, который в ней работает, все работают заодно. В данной ситуации были явные трения, возможно продиктованные by design ситуацией, когда один из главных людей в проекте - волонтер, фактически не имеющий к компании уже никакого отношения, но судя по всему продолжающий выполнять очень важные функции. Неизвестно, какие были договоренности - Максим пишет, что договоренности были о полном невмешательстве.
По поводу CVE - по мне стоило сделать исключение, я не понимаю, если честно, почему в обсуждении разработчики решили не делать релиз. По-моему вообще стоило относиться к HTTP/3 иначе, чем к остальным экспериментам. С другой стороны, когда заведение CVE у части ИБ-шников превратился в вид спорта, открыть ящик Пандоры - дать возможность писать CVE ещё и на эксперимент - вот это прям шаг скользкий.
А зачем вообще вы мигрировали на постгрес? помимо модной строчки (что конечно большой плюс) вы упомянули "плюшки", но citext сам по себе кажется сомнительной причиной для переезда.
мне вначале тоже так казалось, но обычно при 500 респондентах вероятность большой ошибки уже минимальна. здесь возможно есть вот какая проблема: если докер есть хоть где-то в проде - может быть это мешает, все-таки проекты у многих немаленькие с кучей частей.
Так одно другому не противоречит: утверждение "кубер использует примерно половина респондентов" означает, что половине людей знания кубера не нужно (ну тут конечно надо смотреть в динамике год к году). Но контейнеры все-таки использует очень много людей, и использовать контейнеры != использовать кубер, и одна из целей как раз - узнать сколько именно. Почему 21% вам кажется маленьким процентом?
Часть тем есть выше в тексте поста. Мы не проверяем какие-то конкретные гипотезы, вероятно мы их обозначим после разбора результатов и скорректируем вопросы будущих исследований, т.к. на многие цифры интересно смотреть в динамике год к году. Сейчас скорее мы стараемся выстроить процесс адекватного сбора и обработки данных о состоянии рынка, причем не столько с эйчарной точки зрения, сколько с точки зрения технического менеджмента, мы специально объединили две части: собрать базовую картину по инфраструктуре и "кирпичикам", из которых строятся проекты, и понять уровень зарплат и ожиданий в зависимости от роли/сегмента.
если это прямо драйвер то он не должен отвечать за пул соединений, мб это пул — тогда да, нужно либо проверки делать, либо конфигурироваться через время жизни. но вообще ЕМНИП оно в mysql достаточно большое по умолчанию, странно, что вы в это уперлись.
Это опыт с админом ;) кстати, пул соединений в отличие от постгреса (когда баунсер вовнутрь завезут?) ставить не нужно, и формулировка «выдавать мертвый коннекшн» к mysql неприменима.
чуть раньше. вот тут в комментариях есть подробности с наложением роста выручки Амазона и популярности постгреса по отношению к другим субд по версии db-engines (они считают упоминания). www.facebook.com/groups/feedme.ru/permalink/3218143878217976
индексов много, но нужно внимательно смотреть, что считается. самый правильные индексы — числа разработчиков (опросы, которые я привел, либо, опосредованно — открытых позиций).
Да, где-то есть 80 где-то нет — понял, спасибо.
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
(3) в разных командах по-разному. Подчинение обычно такое: Тим-лид/менеджер — директор — глава разработки с вариациями. KPI — в зависимости от команды, но главный: сделать что обещал, в срок. Формулы доли программирования и размера нет, поскольку может быть разный профиль, разное число стейкхолдеров и соотвественное разное время на общение/синхронизации. Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
Серьезно или сарказм? Если вдруг серьезно, то нужно изучать лицензионную политику Хабра, я не изучал. Ваш КО
ну в этой истории копаться довольно опасно, скорее всего всем был предложен переезд (другое дело, куда, помогали ли и тд).
По-моему, вы перебарщиваете, он особенно никого не поливает, но в его словах безусловно есть нотки обиды. Послушайте, я не знаю, что он делал для nginx последние 2 года, но для многих core-чуваков в open source их проект - это ребенок, особенно когда они над ним работают 10+ лет, нужно делать на это скидку, менеджмент должен был это понимать и постараться договориться.
Про ядро -
@ximaeraкоторый уже каментил выше, тут подметил крайне точно один факт, и это произошло именно 14-го февраля, в тот же день: "коллективный Торвальдс", который как раз плакал, получил таки возможность управлять процессом создания CVE:
https://openssf.org/blog/2024/02/14/linux-kernel-achieves-cve-numbering-authority-status/
к докладам от лидеров open sourсe проектов такого уровня могло бы быть другое отношение :) вот энжи докладывался на хайлоаде - и ничего. будет что рассказать - думаю примем с большим удовольствием.
Слово "омерзительный" всё же too much. Всё что вы пишете, справедливо в нормальной ситуации, когда есть компания, есть коллектив разработчиков, который в ней работает, все работают заодно. В данной ситуации были явные трения, возможно продиктованные by design ситуацией, когда один из главных людей в проекте - волонтер, фактически не имеющий к компании уже никакого отношения, но судя по всему продолжающий выполнять очень важные функции. Неизвестно, какие были договоренности - Максим пишет, что договоренности были о полном невмешательстве.
По поводу CVE - по мне стоило сделать исключение, я не понимаю, если честно, почему в обсуждении разработчики решили не делать релиз. По-моему вообще стоило относиться к HTTP/3 иначе, чем к остальным экспериментам. С другой стороны, когда заведение CVE у части ИБ-шников превратился в вид спорта, открыть ящик Пандоры - дать возможность писать CVE ещё и на эксперимент - вот это прям шаг скользкий.
А зачем вообще вы мигрировали на постгрес? помимо модной строчки (что конечно большой плюс) вы упомянули "плюшки", но citext сам по себе кажется сомнительной причиной для переезда.
спасибо! да, и про графану уже писали, и про ипотеку я понял, что не хватает такого разделения
не надо грязи, пожалуйста, это называется "выявим закономерности" ;)
мне вначале тоже так казалось, но обычно при 500 респондентах вероятность большой ошибки уже минимальна. здесь возможно есть вот какая проблема: если докер есть хоть где-то в проде - может быть это мешает, все-таки проекты у многих немаленькие с кучей частей.
Так одно другому не противоречит: утверждение "кубер использует примерно половина респондентов" означает, что половине людей знания кубера не нужно (ну тут конечно надо смотреть в динамике год к году). Но контейнеры все-таки использует очень много людей, и использовать контейнеры != использовать кубер, и одна из целей как раз - узнать сколько именно. Почему 21% вам кажется маленьким процентом?
Часть тем есть выше в тексте поста. Мы не проверяем какие-то конкретные гипотезы, вероятно мы их обозначим после разбора результатов и скорректируем вопросы будущих исследований, т.к. на многие цифры интересно смотреть в динамике год к году. Сейчас скорее мы стараемся выстроить процесс адекватного сбора и обработки данных о состоянии рынка, причем не столько с эйчарной точки зрения, сколько с точки зрения технического менеджмента, мы специально объединили две части: собрать базовую картину по инфраструктуре и "кирпичикам", из которых строятся проекты, и понять уровень зарплат и ожиданий в зависимости от роли/сегмента.
Это опыт с админом ;) кстати, пул соединений в отличие от постгреса (когда баунсер вовнутрь завезут?) ставить не нужно, и формулировка «выдавать мертвый коннекшн» к mysql неприменима.
www.facebook.com/groups/feedme.ru/permalink/3218143878217976
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
Стек почти не имеет значения.
(3) в разных командах по-разному. Подчинение обычно такое: Тим-лид/менеджер — директор — глава разработки с вариациями. KPI — в зависимости от команды, но главный: сделать что обещал, в срок. Формулы доли программирования и размера нет, поскольку может быть разный профиль, разное число стейкхолдеров и соотвественное разное время на общение/синхронизации. Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).