>> много времени уходит не на код, а на уточнения, гипотезы и согласования Тарифицируйте это время по ставке достаточного дорогого руководителя проекта со своей стороны и, о чудо - непроизводительные затраты начнут сокращаться ))
Нет, не всё. В вашей юрконструкции упущен очень важный, даже ключевой документ - заказ.
Без документа, который явно называется "Заказ", исходит от заказчика (!) и содержит его требования по составу, объему и ориентировочной стоимости услуг на очередной период - вы однажды попадете в ситуацию, когда вам заказчик не подпишет очередной акт, мотивируя это тем, что он ваши услуги не заказывал и что работы вы делали по собственной инициативе и за свой же счет.
Ваш "допник" имеет похожий смысл, но это немного не то.
Ну и в целом T&M требует ряда специфичных моментов в договоре, о которых вы не упомянули, а зря.
Человечество разделится на две неравные группы, причем меньшая, сохранившая способность читать и искать информацию, выстраивать в уме операции анализа и синтеза, быстро и навсегда обгнонит большую - пользующуюся "услугами" "ИИ"
Мы - это компания "Human+", как генподрядчик разработки и ответственные за "железную часть", и "Спринт-Ф", как основной разработчик бэкенда и фронтенда системы.
Альтернатива Редмайну существует ровно одна - это Jira. На своем сервере с «китайской» лицензией. Всё остальное - это попыики имитировать часть функций Jira, причем самую неважную часть.
Очень интересно, зачем каждый раз это разрабатывать заново, если еще 8 лет назад мы на Ямале внедрили в эксплуатацию полностью функциональное решение, причем по функциям на порядок более богатое, чем вы описываете?
>> Чистая архитектура независима от информационных хранилищ. Можно поменять PostgreSQL на MongoDB или на любую другую СУБД. При этом работа бизнес-правил не изменится.
Сложно представить себе более вредное утверждение. В реальности оно звучит так:
- Откажитесь от всех преимуществ специализированных хранилищ ради нулевого шанса на их смену.
Ни один подобный проект никогда не приводил к бизнес-успеху. И этот не приведет. Будет потрачен охулиард денег, чтобы сделать плохую и неточную копию того, что уже давно было сделано.
А учитывая, что позиции уровня архитекторов в ВК зачищены от ненужных людей, и учитывая, что ВК отказывается нанимать разработчиков в штат, предпочитая договора с региональными однодневными аутстафф-агентствами - можно себе представить качество этого нового кода.
Запуск делается через менеджер процессов, тоже написанный на PHP. Он следит за тем, чтобы число активных процессов-воркеров не превышало заданный лимит, получает задание для каждого воркера, запускает его, пишет метрики - когда запущен, когда закончился, какой результат.
А как вам поможет супервизор в случае "залипания" процесса на какой-нибудь логической ошибке, вводящей его в бесконечный цикл? Процесс работает, живой. Супервизор не видит проблем, процесс не перезапускает.
Вам в любом случае для долгоживущих процессов нужен свой мониторинг их работы, основанный не на "работает/не работает", но на учете бизнес-логики таких процессов.
Живой пример - делали на таких "управляемых процессах" обработку прайс-листов. Десятков тысяч в сутки, на миллионы позиций каждый (если что - это торговля запчастями). Там естественной метрикой была строка прайс-листа. Пишем в редис раз в секунду инфу, на какой мы сейчас строке файла. Отличная метрика, позволяет сразу же понять, работает ли процесс так, как нам надо, или нет.
Ну и вторая принципиальная разница по сравнению с супервизором - когда вам нужен интерфейс мониторинга и управления процессами, которым сможет пользоваться вторая линия поддержки, вам супервизор не подойдет. Он не наглядный. А нам пришлось делать наглядную панель управления.
В комментарии поделиться не получится - места мало. Но в целом да, делали такое и не раз. Банально на тики, или чуть сложнее - на SIGALRM вешаем хэндлер, который в очень быстрое хранилище, например Redis, записывает идентификатор процесса и прогресс работы. Нет записи три секунды подряд - желтый статус, пять сек - красный.
Это не проблематично, совершенно реально, делалось сотни раз, работает в проде и PHP прекрасно для такой задачи "предназначен", чтобы вы ни имели в виду.
>> 2. Сам будет массово откликаться на релевантные вакансии и писать уникальные сопроводительные письма.
Отлично. Давайте доломаем механики найма окончательно.
Пусть теперь в сутки на вакансию QA Middle будет благодаря вам не 500 откликов, а 5000. И работодатели окончательно плюнут на найм и уйдут в аутстафф.
Не очень понятен ваш вопрос. Для многих это не возможность - это текущая реальность.
Единственный реальный аргумент "за" удалёнку - это возможность работать на несколько работодателей.
И это же является единственным реальным аргументом "против". Но уже с другой стороны.
Всё остальное - социально приемлемый буллшит.
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. Но хайпа на этом не словишь, тут вы правы.
Учитывая, что я статью писал с объяснением этого понятия для начинающих, нет, наверное, пока до конца еще не знаю ))