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