Алексей, вы, как многоопытный человек, не можете не понимать, что agile-методологии предназначены для эффективной работы команд и перекладывании на команды значительной области ответственности менеджмента. Формирование команд с сопутствующим значительным повышением общей эффективности — непреложный и надёжно зафиксированный исследованиями факт, так же как и «неформирование» команд при наличии неразрешённых проблем. Понятно, что не всё в этом мире идеально и от любого изменения состава команды её будет «трясти». Но дело в том, что agile-методологии позволяют технические задачи по организации команд переложить на сами команды, а на этапе ввода — на консультантов agile'а.
Можно, конечно, и дальше запираться и утверждать, что все они сектанты и это не работает, если бы не было удачных примеров. Например, команды, работающие над веб-платформой скайпа, перешли на скрам, и весьма довольны результатом.
Алексей, что вы имеете ввиду под «саппортом», которого — «в большом проекте грубо половина» — фикс багов? Почему, например, фикс багов в сочетании с рефакторингом проблемной области не может вписывать в agile?
Так же, что вы имеете ввиду под «выведением команды в транс извне», когда команду нужно принуждать к эффективной работе? — вы предполагаете, что команда не сформировалась и требуется внешнее воздействие, или что команда занимается не тем, что нужно для бизнеса? В последнем случае, причём здесь agile?
Алексей, расскажите, пожалуйста:
1. gbps — это хитрый секретный протокол, или просто означает, что сервисы общаются по сети? По сути оригинального вопроса: у вас сервисы общаются на голых tcp-запросах, используется свой формат данных, или что-нибудь известное, от json до protobuf? Используется ли общение между C и PHP сервисами через scribe?
2. По параллельным вычислениям: ваш фреймворк сделан на основе форков, или позволяет распределённые вычисления? В последнем случае — как это работает?
Я только не понял, зачем сравнивать персистентный redis с заметно большим фунционалом, а не с банальным memcache'ом. Кроме того, нет сравнения производительности операций по префиксам, что нивелирует эффект от бенчмарков, оставляя пустое «Под мои задачи должна вписаться идеально».
Плюс есть специфически работающий лок, под который я сходу не могу придумать кейсов.
+1. Правда, аутсорсинг там, где я его видел, к сожалению, не даёт знаний и навыков для действительно крупных распределённых систем (и, как следствие, понимания архитектуры для хайлоада — все эти блокировки и прочие шардинги). А так, при желании и способности разобраться во всём этом ничего сложного нет — объём вышеуказанных знаний для «full stack» и правда небольшой и «типичный».
Объясните, пожалуйста, что такое и сколько это — «авторские исчисления» — в контексте поверхностного знания соответствующего российского/американского термин определению в вашем контексте не поддаётся.
Вас не расстраивает, что ваш сервис, идеологом которого вы являетесь, который вы делали месяцами без реальной денежной итп отдачи, отдаляясь от семьи, принадлежит не вам?
Фреймворк создаётся, чтобы конечный программист реализовывал бизнес-логику, а не техническое обеспечение. Это формирует бизнес-требования к фреймворку. Они содержат в себе как роутинг, так и шардинг — всё, что нужно, чтобы писать только бизнес-логику.
Проблема в том, что роутинг, валидация и прочие задачи, которые решают распространённые фреймворки — настолько малая часть от требований к фреймворку в рамках хайлоада, что используется он, или не используется — вообще не важно. То есть, преимущества от реализованных классов компенсируются ограничениями фреймворка и быстро растущим оверхедом от всяческих IoC контейнеров.
Раньше бесплатным было. На мой вкус приложение быстрое, пока не пытается подгрузить сотни новых сообщений из десятков чатов — то есть при запуске приложения после длительной неактивности при очень большом количестве новых сообщений приводит к фризу приложения на десятки секунд. Исключая это, и периодическую дупликацию сообщений при подгрузке очень большого количества сообщений в чате, я с проблемами не сталкивался, при весьма активном использовании. Телефон старый, одноядерный.
Роутинг? — regexp'ы по количеству контроллеров хоть в nginx'е?
Валидация? — десяток статических методов?
Да, это всё можно обернуть в красивый ООП, сделать удобное API, неявный вызов, xml-конфиги и прочий интерпрайз — просто в минимально-необходимой реализации это и правда мелочи.
Кому на текущий момент принадлежит сервис — вам, работодателю, если не секрет — какими долями? Какой примерный порядок денег, вложенный в проект вашим работодателем?
Если серьёзно, то это не слишком правильно, когда берут эникейщика и требуют как с it-директора, но такова жизнь. И если вам не хватает амбиций или совсем другие цели — идти работать в такие условия несколько нелогично.
Я хорошо понимаю и участвовал вживую в подобной ситуации. И мой опыт говорит однозначно, что здесь ваша терминология не соответствует реальности. То есть, любой такой глобальный конфликт админов с сотрудниками говорит о неумении админа договариваться, искать компромиссы и точки для приложения усилий — то есть, непрофессионал как менеджер (а бытиё менеджером навязывает зона ответственности). Да, большинство пользователей — идиоты, они не хотят учиться и что-то менять в своей жизни и рабочем процессе — это нормально и с этим нужно уметь работать, если считаешь себя профессионалом — как минимум на уровне «донести, зачем это нужно конкретному пользователю», «вписаться в существующие требования, если это возможно», и «в особо болезненных случаях найти выход в аккуратном самостоятельном эскалировании конфликта».
ИМХО, этот список нужнее даже не сис.админам, а руководству компании — чтобы выдать своему админу и аккуратно попросить следовать. Советы, по хорошему, банальны, не требуют сильных вложений, и выгодны в первую очередь именно компании. (хотя бы потому, что это организуют работу и даёт хорошую оценку рисков).
Аналогично, имхо, те админы, которые сопротивляются этому, попросту не хотят быть или не видят себя IT-директорами, вне зависимости от реальной зоны ответственности.
Вообще-то в посте практически все пункты про взаимодействие с руководством компании — так что о каких 10 сотрудниках вы говорите? Единственный пункт про взаимодействие с пользователями — 10-ый, и, возможно, частично 11-ый.
В 10-ом просто говорится, что попробуйте найти общий язык с пользователями и нормально выстроить взаимодействие по рабочим задачам. Если пользователи категорически не хотят нововведений — это тоже вариант построения рабочего взаимодействия.
В 11-ом, по-хорошему, почти все пользователи теряли данные, и хорошо понимают последствия — поэтому именно здесь проблем не должно быть даже у застенчивого косноязычного заикающегося красноглазика.
Фрейморк — ничем не помешает. Так же как и не поможет — шардинг, распределённые блокировки, многоуровневое хранение и кеширование данных, распределённая шина событий, демоны, отложенное исполнение задач, итд — всего этого распространённые фреймворки не умеют — другие цели и задачи.
2GIS — это в первую очередь поиск (который, очевидно, не на php делается) и статические данные — в этом случае не важно, что использовать. Я всё-таки про большие интерактивные сервисы для миллионов пользователей.
Facebook точно так же может заблокировать очень крупное (десятки миллионов пользователей) приложение и игнорировать в запросы в поддержку, после чего разблокировать приложение в неработоспособном состоянии, с последующим игнорированием.
Не удивлюсь, если подобным отношением грешат и Одноклассники.
Можно, конечно, и дальше запираться и утверждать, что все они сектанты и это не работает, если бы не было удачных примеров. Например, команды, работающие над веб-платформой скайпа, перешли на скрам, и весьма довольны результатом.
Так же, что вы имеете ввиду под «выведением команды в транс извне», когда команду нужно принуждать к эффективной работе? — вы предполагаете, что команда не сформировалась и требуется внешнее воздействие, или что команда занимается не тем, что нужно для бизнеса? В последнем случае, причём здесь agile?
1. gbps — это хитрый секретный протокол, или просто означает, что сервисы общаются по сети? По сути оригинального вопроса: у вас сервисы общаются на голых tcp-запросах, используется свой формат данных, или что-нибудь известное, от json до protobuf? Используется ли общение между C и PHP сервисами через scribe?
2. По параллельным вычислениям: ваш фреймворк сделан на основе форков, или позволяет распределённые вычисления? В последнем случае — как это работает?
Плюс есть специфически работающий лок, под который я сходу не могу придумать кейсов.
Вас не расстраивает, что ваш сервис, идеологом которого вы являетесь, который вы делали месяцами без реальной денежной итп отдачи, отдаляясь от семьи, принадлежит не вам?
Проблема в том, что роутинг, валидация и прочие задачи, которые решают распространённые фреймворки — настолько малая часть от требований к фреймворку в рамках хайлоада, что используется он, или не используется — вообще не важно. То есть, преимущества от реализованных классов компенсируются ограничениями фреймворка и быстро растущим оверхедом от всяческих IoC контейнеров.
Валидация? — десяток статических методов?
Да, это всё можно обернуть в красивый ООП, сделать удобное API, неявный вызов, xml-конфиги и прочий интерпрайз — просто в минимально-необходимой реализации это и правда мелочи.
Имхо, пост не стоит рекавери мода.
Если серьёзно, то это не слишком правильно, когда берут эникейщика и требуют как с it-директора, но такова жизнь. И если вам не хватает амбиций или совсем другие цели — идти работать в такие условия несколько нелогично.
Аналогично, имхо, те админы, которые сопротивляются этому, попросту не хотят быть или не видят себя IT-директорами, вне зависимости от реальной зоны ответственности.
В 10-ом просто говорится, что попробуйте найти общий язык с пользователями и нормально выстроить взаимодействие по рабочим задачам. Если пользователи категорически не хотят нововведений — это тоже вариант построения рабочего взаимодействия.
В 11-ом, по-хорошему, почти все пользователи теряли данные, и хорошо понимают последствия — поэтому именно здесь проблем не должно быть даже у застенчивого косноязычного заикающегося красноглазика.
Не удивлюсь, если подобным отношением грешат и Одноклассники.