Рубрика «валидация» - 2

Любая система, которая часто используется в проекте, со временем обречена на эволюцию. Так случилось и с нашей системой реактивного связывания reactive bindings.

Что это за система? Она позволяет нам связывать данные на префабе с данными в коде. У нас есть ViewModel, лежащая на префабе. В ней есть некие ключи с разными типами. Соответственно, вся остальная логика, которая у нас привязана к UI, привязана к этим ключам и их изменениям. То есть, если у нас есть некая логическая переменная, меняя ее в коде, мы можем менять любые состояния UI автоматически.

Избавляемся от «мистических» строк в системе реактивного связывания на Unity - 1

Использование reactive bindings принесло нам как множество новых возможностей, так и ряд зависимостей. Для связи переменных кода и ViewModel, лежащей на префабе, нам необходимо было соответствие строковых имен. Это приводило к тому, что в результате неосторожной правки префаба или ошибки мерджа могли быть утеряны какие-то из этих связей, а ошибка замечалась уже на этапе поздних тестов в виде отвалившегося UI-функционала.

Росла частота использования системы — росло число подобных сложностей.

Два основных неудобства, с которыми мы столкнулись:

  • Строковые ключи в коде;
  • Нет проверки соответствия ключей в коде и ключей в модели.

Эта статья — о том, как мы дополнили систему и тем самым закрыли эти потребности.
Читать полностью »

Валидация ассетов в Unity3D - 1

Начнём с того, что я обожаю сериализацию в Unity. Она надёжна и очень проста в использовании. Я просто расширяю MonoBehaviour, ScriptableObject и подобные классы и настраиваю сериализуемые поля экземпляров в инспекторе.

Но у неё есть и слабости. Одна из них ― человеческий фактор. Представьте себе огромный проект, который живёт несколько лет и над которым работает около сотни человек. И любой из них может совершить ошибку: оставить пустую ссылку на объект, указать число вне диапазона, ввести строку в неверном формате, заполнить массив слишком маленьким или, наоборот, слишком большим количеством объектов. Уверен, у каждого из вас найдутся такие примеры из своего опыта. Причин и оправданий тоже множество: невнимательность, неожиданные последствия слияния веток, сбои редактора… И никто от этого не застрахован.

Такие ошибки до поры до времени остаются незаметными: компилятору до них нет дела, в отличие от опечаток в коде. Особенно неприятны они тем, что проявляются часто уже во время выполнения кода. Только тогда вы начинаете читать журнал сообщений и идёте проверять данные: тыкать их в редакторе или листать YAML. Но объектов может быть достаточно много, есть риск что-то пропустить или попросту залениться.

Конечно, можно добавить проверок в коде, но от этого он загрязнится. Иногда эти проверки негативно влияют на производительность. А ещё не всегда однозначно понятно, как именно обработать каждую конкретную ошибку.

Универсального или даже штатного метода бороться с подобным в Unity нет. Поэтому мы в Pixonic реализовали свою систему валидации ассетов. И это очень помогает нам жить.

Сейчас я опишу, как там всё устроено.
Читать полностью »

Программист-защитник сильнее энтропии - 1

© Dragon Ball. Goku.

Программист-защитник в любой момент и в любом месте кода ожидает появления потенциальных проблем и пишет код таким образом, чтобы заранее от них защититься. А если от проблемы нельзя защититься, то хотя бы сделать так, чтобы её последствия и влияние на пользователей были минимальными.

Вспоминается эффект FlashForward из голливудских блокбастеров, когда главный герой видит грядущую катастрофу и остаётся предельно спокойным, потому что заранее знает, что она произойдёт, и имеет от неё защиту. Идея защитного программирования в том, чтобы защититься от проблем, которые сложно или вовсе невозможно предвидеть. Программист-защитник ожидает появления ошибок в любом месте системы и в любой момент времени, чтобы предотвратить их до того, как они нанесут ущерб. При этом цель не в том, чтобы создать систему, которая никогда не падает, это всё равно невозможно. Цель в том, чтобы создать систему, которая падает изящно в случае любой непредвиденной проблемы.

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

  • Падать быстро. В случае непредвиденной ошибки все операции должны завершаться сразу же, особенно если последующие вычисления тяжёлые или могут привести к порче данных.
  • Падать аккуратно. Если возникла ошибка, программа должна освободить все ресурсы, снять локи, удалить временные и наполовину записанные файлы, закрыть соединения. Дождаться завершения критических операций, прерывание которых может привести к непредсказуемым результатам. Либо безопасным способом аварийно завершить эти операции.
  • Падать явно и красиво. Если что-то сломалось, сообщение об ошибке должно быть простым, лаконичным и содержать важные детали из того контекста системы, где возникла ошибка. Это поможет команде, которая отвечает за систему, максимально быстро разобраться в проблеме и исправить её.

Читать полностью »

Травим данные с travajs - 1

В своем предыдущем посте я описал основные моменты при разработке другой opensource библиотеки. Забыл упомянуть еще один: если никому не рассказывать про библиотеку, какая бы нужная она ни была, скорее всего никто про нее так и не узнает.

Итак, встречайте trava.js — сочная валидация на пользу проекту. К слову траву мы используем уже больше полугода, и я подумал, пришло время рассказать вам о преимуществах ее использования. Уже даже подсушили, так что задержите дыхание. И вперед.
Читать полностью »

Доброго времени суток!

Спустя некоторое время решил вновь написать сюда и поделиться своим опытом. На этот раз статья будет о том, как кастомизировать стандартные валидаторы, и вызывать их там, где нам будет нужно, используя Spring — аспекты. Ну а сподвигло меня на написание — практически отсутствие подобной информации, особенно на русском.

Проблема

Итак, суть приложения примерно такова: есть gateway — api, который принимает запрос, а в дальнейшем модифицирует и перенаправляет его соответствующему банку. Вот только запрос для каждого из банков отличался — как и параметры валидации. Поэтому валидировать изначальный запрос не представлялось возможным. Тут было два пути — использовать аннотации из javax.validation, либо писать свой отдельный слой валидации. В первом случае была загвоздка — по умолчанию объекты можно валидировать только в контроллере. Во втором случае так-же были минусы — это лишний слой, большое количество кода, да и в случае изменения моделей, пришлось бы менять и валидаторы.

Поэтому было принято решение найти способ дергать стандартные валидаторы там где это было необходимо, а не только в контроллере.

Дергаем валидаторы

Спустя пару часов копания в гугле были найдены пару решений, самое адекватное из которых было заавтовайрить javax.validation.Validator и вызвать у него метод validate, которому в качестве параметра нужно передать валидируемый объект.

Казалось бы, решение найдено, но автовайрить везде валидатор не казалось хорошей идеей, хотелось более элегантного решения.

Добавляем АОП

Недолго думая я решил попробовать адаптировать под это решение мною всеми любимые аспекты.

Логика была примерно следующей: создаём аннотацию, и вешаем её над методом который преобразует один объект в другой. Дальше в аспекте перехватываем все методы помеченные этой аннотацией и вызываем метод validate для возвращаемого ими значения. Профит.
Читать полностью »

Разработка форм — один из самых ответственных и сложных этапов создания веб-интерфейсов. Проект должен получить пользовательские данные, проверить их и дать пользователю обратную связь. Современные браузеры предоставляют разработчику встроенный API, позволяющий поэтапно реализовать валидацию данных методом progressive enhancement — от HTML/CSS к JS. Можно ли уже сегодня отказаться от тяжеловесных библиотек для валидации? Какие преимущества обеспечивает нативная валидация и насколько тернист путь её использования? В своём докладе на конференции FrontTalks технический директор LOVATA Павел Ловцевич рассмотрел основные аспекты работы с HTML5 Constraint Validation API.

— Всем привет, меня зовут Павел, я приехал из Минска. Я расскажу про валидацию веб-форм на основе нативных, встроенных в браузер, технологий.
Читать полностью »

Меня зовут Пётр Ромов, я — data scientist в Yandex Data Factory. В этом посте я предложу сравнительно простой и надежный способ начать карьеру аналитика данных.

Многие из вас наверняка знают или хотя бы слышали про Kaggle. Для тех, кто не слышал: Kaggle — это площадка, на которой компании проводят конкурсы по созданию прогнозирующих моделей. Её популярность столь велика, что часто под «кэглами» специалисты понимают сами конкурсы. Победитель каждого соревнования определяется автоматически — по метрике, которую назначил организатор. Среди прочих, Kaggle в разное время опробовали Facebook, Microsoft и нынешний владелец — Google. Яндекс тоже несколько раз отметился. Как правило, Kaggle-сообществу дают решать задачи, довольно близкие к реальным: это, с одной стороны, делает конкурс интересным, а с другой — продвигает компанию как работодателя с солидными задачами. Впрочем, если вам скажут, что компания-организатор конкурса задействовала в своём сервисе алгоритм одного из победителей, — не верьте. Обычно решения из топа слишком сложны и недостаточно производительны, а погони за тысячными долями значения метрики не настолько и нужны на практике. Поэтому организаторов больше интересуют подходы и идейная часть алгоритмов.

Спортивный анализ данных, или как стать специалистом по data science - 1

Kaggle — не единственная площадка с соревнованиями по анализу данных. Существуют и другие: DrivenData, DataScience.net, CodaLab. Кроме того, конкурсы проводятся в рамках научных конференций, связанных с машинным обучением: SIGKDD, RecSys, CIKM.

Для успешного решения нужно, с одной стороны, изучить теорию, а с другой — начать практиковать использование различных подходов и моделей. Другими словами, участие в «кэглах» вполне способно сделать из вас аналитика данных. Вопрос — как научиться в них участвовать?

Читать полностью »

Поздравляю. C сегодняшнего дня вы никогда не будете тратить время, подбирая самое оптимальное регулярное выражение для проверки адреса электронной почты. И вы никогда больше не отклоните адрес, который к вашему удивлению оказался действительным.

Хитрость в том, чтобы сразу определить значение слова «действительный».

Мы разработчики — технические ребята, так что наиболее логичным будет проверить на соответствие официальным критериям. Вот некоторые примеры валидных адресов email, которые соответствуют критериям.

На 100% правильный способ проверки адресов электронной почты - 1
en.wikipedia.org/wiki/Email_address#Valid_email_addresses

Читать полностью »

Все разработчики рано или поздно сталкиваются с регулярными выражениями. Практически в 100% случаев нам совершенно не нравится их составлять, считая это побочной работой, не связанной с программированием.

Большинство из нас, впервые столкнувшись с данной проблемой, начинают забивать в поисковых системах что-то типа: «regexp online generator» и к своему великому сожалению осознают что гугл сломался все результаты в поиске являются сервисами для проверки корректности уже составленного регулярного выражения (или я плохо гуглил).

А как же составить это самое регулярное выражение?

image

До недавнего времени существовало 2 ответа на этот вопрос:

  1. Изучить документацию по регулярным выражениям и составить регулярку самому
  2. Попросить кого-то более опытного сделать это за вас

Теперь, после нескольких месяцев разработки, рад представить и 3-й ответ:

» Генератор регулярных выражений

История

Давным давно, в одном проекте пришел довольно интересный и сложный запрос от внутренних пользователей. Персоналу технической поддержки нужно было самим задавать правила валидации для определенных полей, разным пользователям. Правила должны были часто и очень оперативно изменяться.
Читать полностью »

Обратите внимание, что хотя пост написан от первого лица, это перевод статьи из блога Jimmy Bogard, автора AutoMapper.

Меня часто спрашивают, особенно в контексте архитектуры вертикальных слоев (vertical slice architecture), где должна происходить валидация? Если вы применяете DDD, вы можете поместить валидацию внутри сущностей. Но лично я считаю, что валидация не очень вписывается в ответственность сущности.

Часто валидация внутри сущностей делается с помощью аннотаций. Допустим, у нас есть Customer и его поля FirstName/LastName обязательны:

public class Customer
{
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
}

Проблем с таким подходом две:

  • Вы изменяете состояние сущности до валидации, то есть ваша сущность может находиться в невалидном состоянии
  • Неясен контекст операции (что именно пытается сделать пользователь)

И хотя вы можете показать ошибки валидации (обычно генерируемые ORM) пользователю, не так-то просто сопоставить исходные намерения и детали реализации состояния. Как правило, я стараюсь избегать такого подхода.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js