Казалось бы, валидация данных — это одна из базовых задач в программировании, которая встретится и в начале изучения языка вместе с "Hello world!", и в том или ином виде будет присутствовать в множестве зрелых проектов. Тем не менее, Google до сих пор выдает ноль релевантных результатов при попытке найти универсальную библиотеку валидации данных с открытым исходным кодом на C++.
Когда создавалась библиотека для валидации данных quartet были поставленны следующие цели-ориентиры:
В этой статье я хотел бы рассмотреть производительность quartet и её причины.
Будем исследовать этот аспект в сравнении между quartet и другой намного более популярной ajv.
Всем привет! Я работаю в компании, QuantNet, которая проводит конкурсы алгоритмических стратегий. В недавнем времени передо мной встала важная задача — обеспечить гарантии неприкосновенности даты юзеров (это чрезвычайно важно, так как для корректной проверки эффективностей стратегий необходимо использовать данные мировых финансовых рынков в режиме реального времени).
Вот тут-то я и столкнулся с концепцией PoE (Proof of Existence). В интернете об этом написано достаточно, но специфика платформы заставила меня немного поломать голову. Поэтому я и решил написать эту статью и поделиться своим опытом в архитектуре и имплементации PoE. Думаю, особенно актуально это будет для ребят из финтеха.
Свою статью я разделил на 3 основных блока:
Я работаю фронтенд разработчиком уже на протяжение одного года. На моём первом проекте был «вражеский» бэкенд. Бывает так, что это не составляет больших проблем, когда налажена коммуникация.
Но в нашем случае было не так.
Существуют различные способы обработки ошибок в языках программирования:
Исключения используются очень широко, с другой стороны о них часто говорят, что они медленные. Но и противники функционального подхода часто апеллируют к производительности.
Последнее время я работаю со Scala, где в равной мере я могу использовать как исключения так и различные типы данных для обработки ошибок, поэтому интересно какой из подходов будет удобнее и быстрее.
Сразу отбросим использование кодов и флагов, так как этот подход не принят в JVM языках и по моему мнению слишком подвержен ошибкам (прошу прощения за каламбур). Поэтому будем сравнивать исключения и разные виды АТД. Кроме того АТД можно рассматривать как использование кодов ошибок в функциональном стиле.
UPDATE: к сравнению добавлены исключения без стек-трейсов
Доброго времени суток!
Спустя некоторое время решил вновь написать сюда и поделиться своим опытом. На этот раз статья будет о том, как кастомизировать стандартные валидаторы, и вызывать их там, где нам будет нужно, используя Spring — аспекты. Ну а сподвигло меня на написание — практически отсутствие подобной информации, особенно на русском.
Итак, суть приложения примерно такова: есть gateway — api, который принимает запрос, а в дальнейшем модифицирует и перенаправляет его соответствующему банку. Вот только запрос для каждого из банков отличался — как и параметры валидации. Поэтому валидировать изначальный запрос не представлялось возможным. Тут было два пути — использовать аннотации из javax.validation, либо писать свой отдельный слой валидации. В первом случае была загвоздка — по умолчанию объекты можно валидировать только в контроллере. Во втором случае так-же были минусы — это лишний слой, большое количество кода, да и в случае изменения моделей, пришлось бы менять и валидаторы.
Поэтому было принято решение найти способ дергать стандартные валидаторы там где это было необходимо, а не только в контроллере.
Спустя пару часов копания в гугле были найдены пару решений, самое адекватное из которых было заавтовайрить javax.validation.Validator и вызвать у него метод validate, которому в качестве параметра нужно передать валидируемый объект.
Казалось бы, решение найдено, но автовайрить везде валидатор не казалось хорошей идеей, хотелось более элегантного решения.
Недолго думая я решил попробовать адаптировать под это решение мною всеми любимые аспекты.
Логика была примерно следующей: создаём аннотацию, и вешаем её над методом который преобразует один объект в другой. Дальше в аспекте перехватываем все методы помеченные этой аннотацией и вызываем метод validate для возвращаемого ими значения. Профит.
Читать полностью »
Да-да, вам не привиделось и вы не ослышались — именно высокого рода. Род (kind) — это термин теории категорий, означающий по сути тип типа [данных].
Но вначале немного лирики.
На Хабре вышло несколько статей, где подробно описывался метод валидации данных в функциональных языках.
Эта статься — мои пять копеек в этот хайп. Мы рассмотрим валидацию данных в Хаскеле.
Ранее было рассмотрен пример методики валидации при помощи валидации типом:
type EmailContactInfo = String
type PostalContactInfo = String
data ContactInfo = EmailOnly EmailContactInfo |
PostOnly PostalContactInfo |
EmailAndPost (EmailContactInfo, PostalContactInfo)
data Person = Person
{ pName :: String,
, pContactInfo :: ContactInfo,
}При помощи этого метода просто невозможно создать некорректные данные. Однако, несмотря на то, что подобную валидацию очень просто создать и читать, использование её заставляет писать много рутины и вносить много изменений в код. А значит, использование подобного метода ограничено лишь для действительно важных данных.
В этой статье мы посмотрим иной метод валидации — при помощи данных высокого рода.
Пусть у нас есть тип данных:
data Person = Person
{ pName :: String
, pAge :: Int
}
И мы будем валидировать данные лишь в том случае, когда валидны все поля записи.
Поскольку Хаскель по функциональным возможностям на голову превосходит большинство функциональных языков, на нём можно легко избавится от большинства рутины.
Тут можно и поэтому данный метод широко используется среди авторов библиотек на Хаскеле.
Читать полностью »
Здравствуй!
Мне хотелось бы рассказать об Open Source библиотеке для WPF — ReactiveValidation, в процессе написания которой я пытался ориентироваться на FluentValidation и Reactive UI. Её задача — это валидация формы каждый раз, когда пользователь изменил данные внутри неё.
Пример работы с библиотекой. Хорошая новость — шаблон можно использовать свой
Основные фичи библиотеки:
Валидация входных данных заслуженно является одним из важнейших правил во всей сфере IT. Если сузить сферу деятельности до разработки веб-сайтов, речь пойдет в основном про валидацию данных из форм.
Я не думаю, что многие разработчики любят проверять входные данные и делают это достаточно тщательно, поэтому в современных фреймворках, таких как Yii 2, предусмотрены функции rules() для моделей и классы-Валидаторы, которые хоть и не избавляют от этой рутины, но, как минимум, делают этот процесс менее нудным.
В современной документации Yii 2 и других источниках я не нашел живой пример, как сделать так, чтобы все собственные правила валидации хранились в одном месте и их было удобно использовать, если Вы заинтересованы в решении этой проблемы, добро пожаловать под кат.
Читать полностью »
Если вспомнить все ТЗ с описаниями валидации полей — они всегда выглядили примерно так:
Требования часто приходят набором простых однозначных фраз. А мы, программисты, переводим эти требования в код.
Можно превращать их в одно ультимативное регулярное выражение, вроде
const validateLogin = login => /^[a-zA-z_d]{6,12}$/.test(login);Но лучше писать более простые функций которые легче читать и связывать с непосредственным ТЗ:
const charMatch = new RegExp('^[a-zA-Z_0-9]*$');
const validateLogin = login => {
if (login.length < 6) return false;
if (login.length > 12) return false;
if (!charMatch.test(login)) return false;
return true;
};А что если ещё сильнее упростить этот код до чего-то вроде:
const validateLogin = login =>
validate(login)
.notLessThan(6)
.notLongerThan(12)
.hasOnly(['a-z','A-Z','0-9','_']);