мне вначале тоже так казалось, но обычно при 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 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
(2) Фактически вы спрашиваете: сколько получают сотрудники. По понятным причинам я не могу это разглашать, но вот утверждение о "существенно низкой базе" — неверное, выше обьяснял, почему, это вообще антипаттерн и я был бы вам крайне признателен, если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление, я обязательно его исправлю.
Отвечать буду частями. (1) влияет ли и как бонусная часть. Да, влияет, обычно практика такая: база в рынке, а с бонусами получится выше ожидаемой — но есть масса ньюансов, конечно. Бонус — десятки процентов. Недовольство = минимальная премия = нет полного соответствия ожиданиям, тут очень важно, чтобы руководитель это подробно разьяснял, и ревью воспитывает и эту культуру тоже. При трудоустройстве можно всегда спросить, какой средний бонус был в этой группе — и вам скажут.
Надо понять про "руководство не реагирует", обычно за этим стоят проблемы коммуникации, разговор на разных языках, забивания друг на друга, всякиое горделивое типа "если надо обьяснять, то не надо обьяснять" и прочее… надо обьяснять! Продакшн-качество, стабильность — бизнес-метрика, если вдруг что-то не получает должного внимания — приучать. В любом случае нужно по-партизански или открыто сделать команду, которая будет фиксить долг. Лучше открыто, по-партизански можно только очень ненадолго и в большой конторе (минимально зааффектит бизнес).
Зачем: Badoo перевёл позицию главы разработки в Лондон. Несколько лет мы проводили достаточно серьёзную «перебалансировку» инженерных групп, лондонский офис сильно вырос, так что это абсолютно разумно. По личным причинам я не захотел переезжать. Каково: уточните вопрос. Весело, работы — море. Но вы не правы, что Badoo делает один сервис. Badoo начинался как соц-сеть, у меня на Badoo, например, до сих пор сотни фотографий с тех времён. Были фото-альбомы, ленты активности друзей, комментарии, что-то наподобии «групп» — мы выли воодушевлены тем, что тогда называлось web 2.0 и экспериментрировали очень много, даже сделали однажды аналог чат-рулетки (и быстро закрыли, потому что там началось адище). Совершенно другой сервис, но мы его делали на той же архитектуре, ничего не меняли, что лишний раз подтверждает, что мы изначально выбрали удачные подходы в разработке. Затем большая часть аудитории стала мобильной, Badoo стал mobile-first компанией. Затем Badoo стал превращаться в платформу, на базе которой растет уже несколько продуктов. Ну и для меня лично этот опыт был как три-четыре разные работы — совершенно разный и очень полезный опыт.
не надо грязи, пожалуйста, это называется "выявим закономерности" ;)
мне вначале тоже так казалось, но обычно при 500 респондентах вероятность большой ошибки уже минимальна. здесь возможно есть вот какая проблема: если докер есть хоть где-то в проде - может быть это мешает, все-таки проекты у многих немаленькие с кучей частей.
Так одно другому не противоречит: утверждение "кубер использует примерно половина респондентов" означает, что половине людей знания кубера не нужно (ну тут конечно надо смотреть в динамике год к году). Но контейнеры все-таки использует очень много людей, и использовать контейнеры != использовать кубер, и одна из целей как раз - узнать сколько именно. Почему 21% вам кажется маленьким процентом?
Часть тем есть выше в тексте поста. Мы не проверяем какие-то конкретные гипотезы, вероятно мы их обозначим после разбора результатов и скорректируем вопросы будущих исследований, т.к. на многие цифры интересно смотреть в динамике год к году. Сейчас скорее мы стараемся выстроить процесс адекватного сбора и обработки данных о состоянии рынка, причем не столько с эйчарной точки зрения, сколько с точки зрения технического менеджмента, мы специально объединили две части: собрать базовую картину по инфраструктуре и "кирпичикам", из которых строятся проекты, и понять уровень зарплат и ожиданий в зависимости от роли/сегмента.
Это опыт с админом ;) кстати, пул соединений в отличие от постгреса (когда баунсер вовнутрь завезут?) ставить не нужно, и формулировка «выдавать мертвый коннекшн» к mysql неприменима.
www.facebook.com/groups/feedme.ru/permalink/3218143878217976
Идея теста и исполнение интересные, но вообще, похоже, вы померили менеджеры процессов со слишком простым кодом приложения, и скорее всего бОльшую часть процессорного времени в вашем тесте занимает работа менеджера, а не кода приложения. В то время как практическую ценность имел бы тест: как менеджер процессов ускоряет приложение, которое само по себе в режиме php-fpm ожирает хотя бы 0.05 процессорных секунд (не за счет моделей обработки соединений, а за счёт экономиях на инициализациях, например). Но здесь наверное основная проблема в том, что «правильный» тест нельзя сделать одним и тем же кодом.
Стек почти не имеет значения.
(3) в разных командах по-разному. Подчинение обычно такое: Тим-лид/менеджер — директор — глава разработки с вариациями. KPI — в зависимости от команды, но главный: сделать что обещал, в срок. Формулы доли программирования и размера нет, поскольку может быть разный профиль, разное число стейкхолдеров и соотвественное разное время на общение/синхронизации. Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).
(2) Фактически вы спрашиваете: сколько получают сотрудники. По понятным причинам я не могу это разглашать, но вот утверждение о "существенно низкой базе" — неверное, выше обьяснял, почему, это вообще антипаттерн и я был бы вам крайне признателен, если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление, я обязательно его исправлю.
Отвечать буду частями. (1) влияет ли и как бонусная часть. Да, влияет, обычно практика такая: база в рынке, а с бонусами получится выше ожидаемой — но есть масса ньюансов, конечно. Бонус — десятки процентов. Недовольство = минимальная премия = нет полного соответствия ожиданиям, тут очень важно, чтобы руководитель это подробно разьяснял, и ревью воспитывает и эту культуру тоже. При трудоустройстве можно всегда спросить, какой средний бонус был в этой группе — и вам скажут.
Ну а если никак — смириться и терпеть или найти место получше, это уж как кто привык.
Надо понять про "руководство не реагирует", обычно за этим стоят проблемы коммуникации, разговор на разных языках, забивания друг на друга, всякиое горделивое типа "если надо обьяснять, то не надо обьяснять" и прочее… надо обьяснять! Продакшн-качество, стабильность — бизнес-метрика, если вдруг что-то не получает должного внимания — приучать. В любом случае нужно по-партизански или открыто сделать команду, которая будет фиксить долг. Лучше открыто, по-партизански можно только очень ненадолго и в большой конторе (минимально зааффектит бизнес).