Ещё парочку

Этот дайджест мы посвятили двум крутым фреймворкам: Glimmer и Camping. Первый позволяет создавать крутые GUI-приложения на Ruby, а второй — делать веб-приложения. Бонусом обсудили, являются ли векторы «новым JSON».

Строим GUI через Glimmer

Если нужно создать нативное приложение с графическом интерфейсом на Ruby, советуем обратить внимание на DSL-фреймворк Glimmer. Название произошло от сокращённого выражения «Glimmer of Ruby in Graphical User Interfaces», то есть «проблеск Ruby в графических пользовательских интерфейсах». Аббревиатура DSL (Domain-specific language) в названии указывает на использование синтаксиса, «заточенного» под описание графических интерфейсов. Получается такой мини-язык внутри языка.

Автор Glimmer, канадский программист Энди Малех (Andy Maleh) изначально задумывал Glimmer, как простую библиотеку, добавляющую графический интерфейс. Позже она превратилась в полноценный фреймворк. Идея родилась в 2007 году, когда Энди со своим коллегой занимались парным программированием. Им обоим пришло в голову, что синтаксис связывания данных неплохо было бы упростить.

На тот момент они частенько писали что-то вроде:

dbc.bind(nameTextBox, new Property(person, "name"), null);
dbc.bind(ageSpinner, new Property(person, "age"), null);

В качестве идеи родился абстрактный вариант:

(nameTextBox, text) <=> (person, name)
(ageSpinner, selection) <=> (person, age)

Который в Ruby выглядел вообще шикарно:

[@name_text_box, :text] <=> [@person, :name]
[@age_spinner, :selection] <=> [@person, :age]

Оператор <=>, остроумно прозванный космическим кораблём, в DSL Glimmer означает двустороннее связывание данных. Одностороннее связывание обозначалось бы оператором <=. С лёгкой руки этот синтаксис назвали Shine. 

Собственно, Glimmer состоит из двух частей: DSL-движка и библиотеки связывания данных. Его синтаксис ограничен mixin-классами, что позволяет не засорять пространство имён. Разработчик всё также пишет на обычном Ruby, но когда надо, использует синтаксис Glimmer. Вот, как выглядит Hello, world с использованием DSL Glimmer для LibUI:

require 'glimmer-dsl-libui'
include Glimmer
window('hello world').show

Стоит ли повнимательнее изучить возможности Glimmer? На мероприятии Fukuoka Ruby Awards в 2022 Glimmer заслужил специальную награду и пожелание успеха от самого Матца. Отличный повод попробовать и сделать собственные выводы.

Микрофреймворк Camping

Давно ли вы ходили в поход? Главное правило сбора рюкзака — соблюсти баланс между пользой и весом. Каждая вещь может расширить ваши возможности, но увеличит вес. Если переборщить с весом, то до применения дело может вовсе не дойти. А если взять слишком мало, то нехватка возможностей также не даст шанс завершить поход успешно.

Главная фича микрофреймворков: они предоставляют лишь базовые возможности, а весь дополнительный функционал приходится добавлять за счёт сторонних библиотек. Этим достигается компактность приложения и присутствие в нём только необходимых компонентов. Но даже с таким минималистичным каркасом приложения, можно делать крутые проекты.

Camping изначально был создан легендарным Джонатаном Джиллеттом (Jonathan Gillette), более известным под псевдонимом why the lucky stiff. Наряду с Matz и DHH, он одна из ключевых фигур сообщества Ruby, хоть и полностью исчезнувший из инфополя 11 лет назад (об этом можно узнать в статье Where’s _why?). Развитие Camping было продолжено сообществом разработчиков.

Идея Camping в том, чтобы всё веб-приложение умещалось в один файл и при этом было построено по модели MVC (Model-View-Controller). Да и сам микрофреймворк получился крошечным, менее 5 килобайт. Чтобы «выезд на природу» был проще, у Camping есть структурированная документация: The Camping Book. В ней есть и общая информация, и простые примеры.

Отдельно отметим, что запущенный camping-сервер не требуется перезапускать при изменениях файлов. Вы просто их редактируете, а camping автоматически выполнит перезапуск. Если у вас есть несколько веб-приложений на этом фреймворке со своими индивидуальными моделями, контроллерами и маршрутизацией, то из них можно сделать единое целое. Camping умеет обслуживать такой объединённый код и это делает его ещё интереснее.

Векторы — новый JSON

Именно так утверждает программист из Нью-Йорка, Джонатан Кац (Jonathan S. Katz). Мнение достаточно странное, ведь векторы — это математическая структура, а JSON — формат обмена данными. Но бурное развитие генеративных нейронных сетей уже создаёт запрос на удобные способы хранения и выполнения запросов к ним. И удовлетворить такой запрос могут векторы, которые давным-давно используют массивы в качестве базовой структуры данных. Ну а для хранения векторов вполне можно использовать PostgreSQL.

Всё это очень напоминает 2012 год. У многих тогда была необходимость где-то хранить данные в JSON. Релиз PostgreSQL 9.2, в котором впервые был добавлен текстовый тип JSON, стал очень ожидаемым событием. Изначальная поддержка была весьма скромной: встроенной индексации не было, система могла выполнять лишь простые действия по извлечению данных и гарантировала пользователю, что в базе находится только валидный JSON.

Эксперимент получился успешным и уже в PostgreSQL 9.4 появился формат JSONB, представляющий бинарный, а не текстовый тип JSON. Это дало возможность создавать индексы GIN (Generalized Inverted Index) и поставило производительность PostgreSQL в один ряд со специализированными базами данных. Приятным бонусом становятся все преимущества хранения в реляционной БД.

Современные AI и ML-системы на выходе дают векторы, которые можно хранить в PostgreSQL. Но есть целый ряд ограничений, которые мешают это делать. В частности, такой тип данных, как cube, позволяет хранить векторы максимум с 100 измерениями. По нынешним меркам этого мало. Расширение pgvector добавляет новый тип данных vector и метод индексации IVF FLAT. Этого уже вполне достаточно, чтобы хранить векторные данные в PostgreSQL и выполнять семантический поиск по ним.

pgvector пока тоже сильно ограничен в возможностях, но интерес к его развитию растёт. Основной упор, по мнению Джонатана, следует сделать на добавлении большего параллелизма и аппаратном ускорении вычислений. Это позволит избавиться от множества ограничений и сделает выполнение операций быстрее. Ну а для PostgreSQL это станет очередным этапом развития, который даст ему гордое звание векторной базы данных.

Интересно посмотреть

Пропустили наш предыдущий митап? Не страшно! Видеозаписи докладов уже выложены на нашем YouTube-канале в кинематографическом качестве 4K и со студийным звуком.

Подписывайтесь и ставьте 🔔колокольчик, чтобы получать уведомления о будущих трансляциях и видео! А ещё присоединяйтесь к Telegram-каналу и будьте в курсе всех наших будущих мероприятий.

Митапы