Java-разработчики знают, что язык и платформу создал Джеймс Гослинг, но зачастую на этом знания о нём и заканчиваются. Кто это вообще такой? Что ещё он делал в жизни? Почему перестал участвовать в работе над Java?

Мы считаем, что такие люди заслуживают большего внимания. Поэтому, во-первых, Джеймс появится на нашей онлайн-конференции JPoint и ответит там на многие вопросы. А во-вторых, в этом посте мы расписали заметные вехи его жизни до, во время и после работы над Java. Как он успел насолить Ричарду Столлману? Почему по изначальному плану язык Java вообще не должен был появиться? Какое отношение Гослинг имеет к подводным роботам?

Примечание переводчика

Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:

• использовать язык Protocol Buffers для описания взаимодействия сервисов;
  
• генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
  
• реализовать авторизацию между взаимодействующими компонентами;
  
• использовать как синхронное, так и асинхронное взаимодействие.
  

gRPC показался мне довольно интересным фреймворком, и мне было интересно узнать про реальный опыт компании Dropbox по построению системы на его основе. В статье есть масса деталей, связанных с использованием шифрования, построением надёжной, наблюдаемой и производительной системы, процессом миграции со старого RPC-решения на новое.

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

Экосистема Rust еще не до конца устоялась. В ней часто появляются новые библиотеки, которые заметно лучше предшественников, а ранее популярные фреймворки устаревают. Именно это произошло с веб-фреймворком Iron, который мы использовали при разработке Exonum.

В качестве замены Iron был выбран actix-web. Дальше я расскажу, как мы портировали существующий код на новое решение, используя приемы обобщённого программирования.

UPD 2018.03.15: Git давно использует свой вариант compact varint. Различия в послесловии.

Внимание: Код представленный в статье немного отличается от оригинальных EncodeVarint и DecodeVarint и даёт другие результаты. Будьте внимательны.

В multiformats/unsigned-varint обсуждении правильной записи числа в varint было замечено что многие числа в оригинальном varint могут быть записаны в последовательности разной длинны. Это даст разные блоки и их хеши при идентичных значениях кодированных в протобуфер.

Оригинальный varint

Оригинальный varint просто делит число на кусочки по 7 бит. И записывает их в порядке от младшего к старшему добавляя к каждому кусочку старший 8ой бит (MSB — most significant bit). Значение этого бита зависит от того последний это кусочек (0) или нет (1).

Таким образом например значение 0 мы можем записать во многих вариантах:

1. 0000 0000 (0x00) varint = 0
2. 1000 0000 0000 0000 (0x8000) varint = 0
3. 1000 0000 1000 0000 0000 0000 (0x808000) varint = 0
   и так далее.

Compact varint

Я подумал что можно начинать значения контейнера большего размера от максимального значения предыдущего контейнера + 1. Ведь если мы используем контейнер такого размера то число должно быть больше максимума предыдущего контейнера.

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

 

Так, формат 16-разрядных беззнаковых целых при размере такой таблицы около 13 килобайт вмещает всего лишь 6542 простых числа: вслед за числом 65531 идут значения более высокой разрядности. Такая таблица годится разве что в качестве игрушки.

 

Наиболее ходовой в программировании формат 32-разрядных целых выглядит значительно солиднее — он позволяет хранить около 203 млн простых. Но такая таблица занимает уже около 775 мегабайт.

 

Еще больше перспектив у 64-разрядного формата. Однако при теоретической мощности порядка 1e+19 значений, таблица имела бы размер 64 экзабайта.