Рубрика «protobuf» - 3

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

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

PHP фреймворк Badoo Код нашего сайта повидал уже не одну версию PHP. Он неоднократно дополнялся, переписывался, модифицировался, рефакторился — в общем, жил и развивался своей жизнью. В это время в мире появлялись и исчезали новые best practice, подходы, фреймворки и тому подобные явления, облегчающие жизнь разработчику и готовые решить все основные проблемы, возникающие в процессе создания веб-сайтов.
В этой статье мы расскажем о нашем пути: как был организован код изначально, какие возникали проблемы и как появился текущий фреймворк.

Что было

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

С архитектурной точки зрения это выглядело так: были объекты страниц, наследуемые от целой иерархии базовых классов, отвечающих за инициализацию окружения, сессии, пользователя и т.п. Каждая страница сама решала, когда, как и что ей выводить, делать редирект и т.п. В иерархии базовых классов было собрано много вспомогательных функций для инициализации и генерации стандартных блоков страниц, проверки пользователей, показа промежуточных промо-страниц и т.п. Со временем большинство из них было переопределено наследниками до неузнаваемости, что в разы усложнило и понимание того, как работает сайт, и саму поддержку кода.
Читать полностью »

Статья состоит из двух частей. В первой части содержится вольный пересказ статьи о статьи о наследовании в protobuf. Вторая часть посвещенна назойливой рекламе самописному «велосипеду» для работы с фреймворком.

Статья не содержит ответа на вопрос «что такое google protocol buffers» и не привязана какому-то конкретному языку програмирования.

Итак, постановка задачи:

  • Как имплементировать полиморфизм, при работе с protocol buffers.
  • Как искать и находить нужные данные, имея большой файл с сообщениями.

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

Во время разработки большого проекта наступает такой момент, когда надо встроить в приложение библиотеку из мира open source с подходящей лицензией. Например, вам захотелось ускорить декодирование картинок, или понадобился sqlite3 с fts4, или нужны какие-то плюшки из libicu, которых нету в системной libicucore.

Для этого библиотеку, которая понадобилась, нужно будет собрать для 5 архитектур: armv7, armv7s, arm64, i386, x86_64. С кросскомпиляцией есть много подводных камней, на которые не хотелось бы наткнуться, когда есть уже проверенные решения. В этом коротком посте я расскажу об автоматизации сборки библиотек на примере protobuf и sqlite3.
Читать полностью »

Игра в прятки: кодогенерация против JSON Страшно подумать, но ещё каких-то десять лет назад разработка системы самого заштатного RPC была целым праздником в жизни разработчика. Болезненным и длительным праздником, как свадьба для лошади: голова в цветах, зад в мыле. Это было страшно увлекательно и одновременно невероятно запарно. Один выбор протокола чего стоил. Я уж не говорю о борьбе с могучими и чудовищными фреймворками, типа DCOM или CORBA. Реализация транспортного уровня вообще была уделом людей с длинными бородами.

В наше счастливое время жизнь программиста под iOS должна быть легка и приятна. Транспорт давно перестал быть проблемой. А RPC? Легко: достаём из кобуры Apache Thrift или на худой конец Google Protocol Buffers и пожалуйста, с минимальным напряжением головного мозга готов и протокол, и сервер, и клиент. Подавляющему количеству приложений в AppStore только это и нужно: простой и понятный интерфейс к удаленным процедурам, желательно в приятных обертках из нативных классов, и такая же простая и понятная обработка ошибок. Всё.

Но. К сожалению, и Thrift, и Protobuf заточены под одновременную разработку клиента и сервера. А такая удача случается в карьере программиста не часто. Читать полностью »

В начале прошлого года мне пришла в голову идея написать собственный язык интерфейсов (IDL), который был бы похож на Protobuf или Thrift, но предназначался бы для веба. Я надеялся закончить его где-нибудь месяца за три. До первой стабильной версии прошло чуть больше года.

Pdef (пидеф, protocol definition language) — это статически типизированный язык описания интерфейсов, который поддерживает JSON и HTTP RPC. Он позволяет один раз описать интерфейсы и структуры данных, а потом сгенерировать код для конкретных языков программирования. Пидеф подходит для публичных апи, внутренних сервисов, распределенных систем, конфигурационных файлов, как формат для хранения данных, кеша и очередей сообщений.

Основная функциональность:

  • Развитая система пакетов, модулей и пространств имен.
  • Поддержка циклических импортов и зависимостей типов (с некоторыми ограничениями).
  • Простая система типов, основанная на четком разделении интерфейсов и структур данных.
  • Наследование сообщений (аналог struct'ов) и интерфейсов.
  • Поддержка цепочек вызовов, например, github.user(1).repos().all().
  • JSON как формат данных и HTTP RPC для передачи данных.
  • Возможность использовать другие форматы и RPC.
  • Подключаемые кодогенераторы (официально поддерживаются Java, Python и Objective-C).
  • Опциональность кодогенерации, т.е. Пидеф позволяет сериализовать данные и отправлять запросы руками.

Зачем нужен Пидеф? В первую очередь для повышения производительности труда и упрощения разработки и поддержки клиент-серверного, сервисно-ориентированного и распределенного кода. Но он также объединяет документацию и описание апи и позволяет строить вертикально-интегрированные системы, в которых снижены накладные расходы на взаимодествие отдельных компонентов.

Пример описания сообщения:

message Human {
    id          int64;
    name        string;
    birthday    datetime;
    sex         Sex;
    continent   ContinentName;
}

Примеры использования (примеры сгенерированного кода):

Json

{
    "id": 1,
    "name": "Ivan Korobkov",
    "birthday": "1987-08-07T00:00Z",
    "sex": "male",
    "continent": "europe"
}

Java

Human human = new Human()
    .setId(1)
    .setName("John")
    .setSex(Sex.MALE)
    .setContinent(ContinentName.ASIA)

String json = human.toJson();
Human another = Human.fromJson(json);

Python

human = Human(id=1, name="John")
human.birthday = datetime.datetime(1900, 1, 2)

s = human.to_json()
another = Human.from_json(s)

Objective-C

Human *human = [[Human alloc]init];
human.id = 1;
human.name = @"John";
human.sex = Sex_MALE;
human.continent = ContinentName_EUROPE;

NSError *error = nil;
NSData *data = [human toJsonError:&error];
Human *another = [Human messageWithData:data error:&error];

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


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