Рубрика «сериализация»

В современных корпоративных системах обработки отчетности (например, XBRL-форматы для регуляторов или банков) одна из ключевых задач это эффективное хранение и загрузка больших объёмов структу­рированных данных. В экосистеме .NET Core такие данные часто представлены в виде объектов с комплексными связями, что требует продуманной стратегии сериализации и десериализации.

Одним из таких случаев является работа с объектами ReportItem объединяющими в себе названия бизнес-факты отчета и координаты в гиперкубе (временной охват, измерения и атрибуты). При создании отчетов данные загружаются в память в виде словаря Читать полностью »

Привет!

Недавно в рамках одного из проектов на стеке KMP, Ktor и Kotlin Serialization мы с командой решили провести эксперимент и определить возможность и целесобразность минификации тел запросов / ответов на Json.

Да, мы знаем про GraphQL, Protobuf и др., но в нашем случае имел место необузданный интерес наколхозить такое решение. И при всей его наивности удалось сократить средний размер итоговых джсонов (после всех внутренних оптимизаций) на 15–20%.

Вводные данные:

  1. Большое приложение на KMP с таргетами iOS, Android, Web и Desktop;

  2. Фронтенд и бэкенд написаны на Ktor и швыряются Json'ами по HTTP;

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

Сериализация в Unity: известные атрибуты и их проблемы - 1

Любой Unity-разработчик знаком с атрибутом [SerializeField]Читать полностью »

Задача

Пару лет назад начал разрабатывать редактор текстовых квестов на JavaScript и обратил внимание на то, что неплохо было бы добавить в JSON-сериализатор поддержку ссылок на объекты. Чтобы можно было одним методом сохранить и загрузить состояние объекта, не нарушая его целостность и связь с внешним миром. Что-то подобное есть в PHP при работе метода serialize.

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

Доброго времени суток! Эта статья написана для тех, кто в общих чертах знаком с тем, что такое и для чего используется Apache Kafka, кто такие Producer и Consumer и как они друг с другом работают. Целью этой статьи является показать способ использования библиотеки modern-cpp-kafka для работы с Apache Kafka на современном C++. В общих чертах с темой можно ознакомится, например, здесь (отсюда же взяты скриншоты), а в этой статье будет рассмотрено решение проблем с владением и (де)сериализацией наиболее простым способом.

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

PProto: бинарный rpc протокол для Qt framework (часть 2) - 1

В первой части статьи было рассказано о бинарном и json форматах сериализации данных, о механизмах версионирования. В этой части речь пойдет о концепции команд, сообщениях, и механизмах их доставки.

Команда

В начале было Request/Response

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

image

Недавно мне довелось разрабатывать на Go http-клиент для сервиса, предоставляющего REST API с json-ом в роли формата кодирования. Стандартная задача, но в ходе работы мне пришлось столкнуться с нестандартной проблемой. Рассказываю в чем суть.

Как известно, формат json имеет типы данных. Четыре примитивных: строка, число, логический, null; и два структурных типа: объект и массив. В данном случае нас интересуют примитивные типы. Вот пример json кода с четырьмя полями разных типов:

{
	"name":"qwerty",
	"price":258.25,
	"active":true,
	"description":null,
}

Как видно в примере, строковое значение заключается в кавычки. Числовое — не имеет кавычек. Логический тип может иметь только одно из двух значений: true или false (без кавычек). И тип null соответственно имеет значение null (также без кавычек).

А теперь собственно сама проблема. В какой-то момент, при детальном рассмотрении получаемого от стороннего сервиса json-кода, я обнаружил, что одно из полей (назовем его price) помимо числового значения периодически имеет строковое значение (число в кавычках). Т. е. один и тот же запрос с разными параметрами может вернуть число в виде числа, а может вернуть это же число в виде строки. Ума не приложу, как на том конце организован код, возвращающий такие результаты, но видимо, это связано с тем, что сервис сам является агрегатором и тянет данные из разных источников, а разработчики не привели json ответа сервера к единому формату. Тем не менее, надо работать с тем что есть.

Но далее меня ждало еще большее удивление. Логическое поле (назовем его active), помимо значений true и false, возвращало строковые значения «true», «false», и даже числовые 1 и 0 (истина и ложь соответственно).
Читать полностью »

Здесь опишу пример сериализции данных через Avro и передача в Kafka. Для Avro есть сериализатор данных для Kafka, он использует в своей работе реестр (registry) схем и поддерживает версионность на отдельном развернутом сервере. Здесь будет только сериализатор, а версионность если потребуется, то например может быть реализована своя, например в БД.

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

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

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

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

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

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

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

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

В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть На самом деле, суть не в этом, мог быть любой другой язык, где еще нет готовой библиотеки, и соответственно автор должен пройти весь путь с нуля. Тем более, криптография дело такое — доверяй, но проверяй. С продуктом, нацеленным на безопасность, вы не можете просто взять и положиться на готовую библиотеку от производителя, слепо ему поверив (впрочем, это тема более для второй части). На данный момент библиотека вполне работает на "среднем" уровне (позволяет делать любые API-запросы).

Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?

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


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