>> много времени уходит не на код, а на уточнения, гипотезы и согласования Тарифицируйте это время по ставке достаточного дорогого руководителя проекта со своей стороны и, о чудо - непроизводительные затраты начнут сокращаться ))
Нет, не всё. В вашей юрконструкции упущен очень важный, даже ключевой документ - заказ.
Без документа, который явно называется "Заказ", исходит от заказчика (!) и содержит его требования по составу, объему и ориентировочной стоимости услуг на очередной период - вы однажды попадете в ситуацию, когда вам заказчик не подпишет очередной акт, мотивируя это тем, что он ваши услуги не заказывал и что работы вы делали по собственной инициативе и за свой же счет.
Ваш "допник" имеет похожий смысл, но это немного не то.
Ну и в целом T&M требует ряда специфичных моментов в договоре, о которых вы не упомянули, а зря.
Человечество разделится на две неравные группы, причем меньшая, сохранившая способность читать и искать информацию, выстраивать в уме операции анализа и синтеза, быстро и навсегда обгнонит большую - пользующуюся "услугами" "ИИ"
Мы - это компания "Human+", как генподрядчик разработки и ответственные за "железную часть", и "Спринт-Ф", как основной разработчик бэкенда и фронтенда системы.
Альтернатива Редмайну существует ровно одна - это Jira. На своем сервере с «китайской» лицензией. Всё остальное - это попыики имитировать часть функций Jira, причем самую неважную часть.
Очень интересно, зачем каждый раз это разрабатывать заново, если еще 8 лет назад мы на Ямале внедрили в эксплуатацию полностью функциональное решение, причем по функциям на порядок более богатое, чем вы описываете?
>> Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Сложно представить себе более вредное утверждение. В реальности оно звучит так:
- Откажитесь от всех преимуществ специализированных хранилищ ради нулевого шанса на их смену.
Ни один подобный проект никогда не приводил к бизнес-успеху. И этот не приведет. Будет потрачен охулиард денег, чтобы сделать плохую и неточную копию того, что уже давно было сделано.
А учитывая, что позиции уровня архитекторов в ВК зачищены от ненужных людей, и учитывая, что ВК отказывается нанимать разработчиков в штат, предпочитая договора с региональными однодневными аутстафф-агентствами - можно себе представить качество этого нового кода.
Запуск делается через менеджер процессов, тоже написанный на PHP. Он следит за тем, чтобы число активных процессов-воркеров не превышало заданный лимит, получает задание для каждого воркера, запускает его, пишет метрики - когда запущен, когда закончился, какой результат.
А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке, вводящей его в бесконечный цикл? Процесс работает, живой. Супервизор не видит проблем, процесс не перезапускает.
Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов.
Живой пример - делали на таких "управляемых процессах" обработку прайс-листов. Десятков тысяч в сутки, на миллионы позиций каждый (если что - это торговля запчастями). Там естественной метрикой была строка прайс-листа. Пишем в редис раз в секунду инфу, на какой мы сейчас строке файла. Отличная метрика, позволяет сразу же понять, работает ли процесс так, как нам надо, или нет.
Ну и вторая принципиальная разница по сравнению с супервизором - когда вам нужен интерфейс мониторинга и управления процессами, которым сможет пользоваться вторая линия поддержки, вам супервизор не подойдет. Он не наглядный. А нам пришлось делать наглядную панель управления.
В комментарии поделиться не получится - места мало. Но в целом да, делали такое и не раз. Банально на тики, или чуть сложнее - на SIGALRM вешаем хэндлер, который в очень быстрое хранилище, например Redis, записывает идентификатор процесса и прогресс работы. Нет записи три секунды подряд - желтый статус, пять сек - красный.
Это не проблематично, совершенно реально, делалось сотни раз, работает в проде и PHP прекрасно для такой задачи "предназначен", чтобы вы ни имели в виду.
Вот здесь я с вами категорически не согласен. Они не "не нужны", их просто приходится придумывать самим. Силами программистов, чья квалификация по определению ниже, чем квалификация тех, кто создавал nginx или PHP-FPM.
>> очень низкая у apache+php, это когда сервер апач при каждом запросе читает с диска php-скрипт и выполняет его
Простите за резкость, но зачем этот бред в статье? Никто уже не использует Apache + PHP таким образом. Для работы PHP стандартное решение это FPM (Fast CGI Process Manager) плюс, к примеру, nginx перед ним. И поверьте, это ничуть не медленнее и ничуть не уже по пропускной способности, чем условная NodeJS в задачах "Сделать запрос к БД, отдать JSON". А уж про память и говорить нечего - разница будет на порядок не в пользу NodeJS.
Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий: запихнуть в одно целое сервер приложений, менеджер процессов/потоков и прикладной код. да еще и заставить одних и тех же людей их писать? Вы действительно считаете, что напишете nginx лучше Сысоева? )))
Meethub
Как Pornhub, только Meet ))
Если кто-то захочет затестить все фичи, а не только ограниченные бесплатным тарифом или затащить к себе в закрытый контур - обращайтесь.
>> много времени уходит не на код, а на уточнения, гипотезы и согласования
Тарифицируйте это время по ставке достаточного дорогого руководителя проекта со своей стороны и, о чудо - непроизводительные затраты начнут сокращаться ))
>> Всё
Нет, не всё. В вашей юрконструкции упущен очень важный, даже ключевой документ - заказ.
Без документа, который явно называется "Заказ", исходит от заказчика (!) и содержит его требования по составу, объему и ориентировочной стоимости услуг на очередной период - вы однажды попадете в ситуацию, когда вам заказчик не подпишет очередной акт, мотивируя это тем, что он ваши услуги не заказывал и что работы вы делали по собственной инициативе и за свой же счет.
Ваш "допник" имеет похожий смысл, но это немного не то.
Ну и в целом T&M требует ряда специфичных моментов в договоре, о которых вы не упомянули, а зря.
Человечество разделится на две неравные группы, причем меньшая, сохранившая способность читать и искать информацию, выстраивать в уме операции анализа и синтеза, быстро и навсегда обгнонит большую - пользующуюся "услугами" "ИИ"
почти (С)
Мы - это компания "Human+", как генподрядчик разработки и ответственные за "железную часть", и "Спринт-Ф", как основной разработчик бэкенда и фронтенда системы.
Нашел для вас статью: https://vc.ru/tribuna/75525-kak-optimizirovat-krupnoe-proizvodstvo-kontroliruya-rabotu-sotrudnikov , там как раз вспоминают про наш опыт на Ямале и дальнейшее развитие темы.
Альтернатива Редмайну существует ровно одна - это Jira. На своем сервере с «китайской» лицензией. Всё остальное - это попыики имитировать часть функций Jira, причем самую неважную часть.
Очень интересно, зачем каждый раз это разрабатывать заново, если еще 8 лет назад мы на Ямале внедрили в эксплуатацию полностью функциональное решение, причем по функциям на порядок более богатое, чем вы описываете?
>> Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Сложно представить себе более вредное утверждение. В реальности оно звучит так:
- Откажитесь от всех преимуществ специализированных хранилищ ради нулевого шанса на их смену.
Дико тормозить и иметь целый букет ляпов он начал примерно в то же время, когда была разогнана старая команда.
Ну вот и всё, можно начинать отсчет конца ВК.
Ни один подобный проект никогда не приводил к бизнес-успеху. И этот не приведет. Будет потрачен охулиард денег, чтобы сделать плохую и неточную копию того, что уже давно было сделано.
А учитывая, что позиции уровня архитекторов в ВК зачищены от ненужных людей, и учитывая, что ВК отказывается нанимать разработчиков в штат, предпочитая договора с региональными однодневными аутстафф-агентствами - можно себе представить качество этого нового кода.
Запуск делается через менеджер процессов, тоже написанный на PHP. Он следит за тем, чтобы число активных процессов-воркеров не превышало заданный лимит, получает задание для каждого воркера, запускает его, пишет метрики - когда запущен, когда закончился, какой результат.
А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке, вводящей его в бесконечный цикл? Процесс работает, живой. Супервизор не видит проблем, процесс не перезапускает.
Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов.
Живой пример - делали на таких "управляемых процессах" обработку прайс-листов. Десятков тысяч в сутки, на миллионы позиций каждый (если что - это торговля запчастями). Там естественной метрикой была строка прайс-листа. Пишем в редис раз в секунду инфу, на какой мы сейчас строке файла. Отличная метрика, позволяет сразу же понять, работает ли процесс так, как нам надо, или нет.
Ну и вторая принципиальная разница по сравнению с супервизором - когда вам нужен интерфейс мониторинга и управления процессами, которым сможет пользоваться вторая линия поддержки, вам супервизор не подойдет. Он не наглядный. А нам пришлось делать наглядную панель управления.
В комментарии поделиться не получится - места мало. Но в целом да, делали такое и не раз. Банально на тики, или чуть сложнее - на SIGALRM вешаем хэндлер, который в очень быстрое хранилище, например Redis, записывает идентификатор процесса и прогресс работы. Нет записи три секунды подряд - желтый статус, пять сек - красный.
Где хоть он "популярен"? В статьях на хабре? ))
Это не проблематично, совершенно реально, делалось сотни раз, работает в проде и PHP прекрасно для такой задачи "предназначен", чтобы вы ни имели в виду.
Без всяких "супервизоров, роадраннеров и свулов".
Мне доводилось переписывать достаточно сложный проект с nodejs на php. Но хайпа на этом не словишь, тут вы правы.
Учитывая, что я статью писал с объяснением этого понятия для начинающих, нет, наверное, пока до конца еще не знаю ))
Вот здесь я с вами категорически не согласен. Они не "не нужны", их просто приходится придумывать самим. Силами программистов, чья квалификация по определению ниже, чем квалификация тех, кто создавал nginx или PHP-FPM.
>> очень низкая у apache+php, это когда сервер апач при каждом запросе читает с диска php-скрипт и выполняет его
Простите за резкость, но зачем этот бред в статье? Никто уже не использует Apache + PHP таким образом. Для работы PHP стандартное решение это FPM (Fast CGI Process Manager) плюс, к примеру, nginx перед ним. И поверьте, это ничуть не медленнее и ничуть не уже по пропускной способности, чем условная NodeJS в задачах "Сделать запрос к БД, отдать JSON". А уж про память и говорить нечего - разница будет на порядок не в пользу NodeJS.
Никогда не понимал, в чем же на самом деле преимущество, за которое так топят сторонники node, go и прочих альтернативных технологий: запихнуть в одно целое сервер приложений, менеджер процессов/потоков и прикладной код. да еще и заставить одних и тех же людей их писать? Вы действительно считаете, что напишете nginx лучше Сысоева? )))
Вы просто не умеете ее готовить.
Да и аналогов всё равно нет - с чем сравниваете-то?