Каждый раз, когда нужно добавить новую модель в проект, приходится писать буквально одинаковый код: с одинаковыми проверками, с одинаковыми корректировками, с одинаковыми Codable, с одинаковыми тестами.
Полагаю, вы тоже постоянно с этим сталкиваетесь, особенно при работе с текстом, например, вот типичный код:
Читать полностью »Всем привет! 👋
Я — Дмитрий, автор Sury — самой быстрой библиотеки для работы со схемами. Если вы фанат Zod (а кто не фанат?), эта статья для вас. Сегодня я поделюсь неожиданными результатами тестов производительности Zod v4, расскажу, что это значит для вас, и как избежать подводных камней.
Zod v4: Стал в 17 раз медленнееб и никто этого не заметил 🙈
Начнём с небольшого кликбейта)
Это действительно так, но, конечно, не вся правда. Давайте разберёмся.
Недавно, готовясь к большому релизу Читать полностью »
Предусловие у вас уже скачан или скачайте sublimetext с официального сайта.
Открываем sublimetext и нажимаем сочетание клавиш ctrl+shift+p, должно открыться белое окно с поиском.
В окне поиска начинаем писать Package Control, у вас появится список, выбираем из списка Package Control: Install Package и нажимаем ЛКМ(левая кнопка мыши).
Вот и моя первая статья на Хабре.
Посвящена она будет презентации своего небольшого решения для валидации моделей с использованием запросов к БД и EntityManager.
Вариант этот пока черновой, "на коленке" и будет развиваться. Критика и рекомендации горячо приветствуются. Пока что мне важно понять, есть ли у сообщества запрос на что-то подобное и имеет ли смысл как-то публично развивать это решение.
Понятно, что статья рассчитана на тех, кто уже знаком с той же Jakarta Validation.
Допустим, мы пишем свой CRUD для какой-то сущности с обилием связей.
Казалось бы, валидация данных — это одна из базовых задач в программировании, которая встретится и в начале изучения языка вместе с "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 для возвращаемого ими значения. Профит.
Читать полностью »