Hacker News Digest

Основанная на блоковых элементах, а не на документах, архитектура Notion позволяет каждому элементу контента быть гибко перестраиваемым, вкладываемым и превращаемым в базы данных или другие структуры. Это превращает Notion из простого редактора в операционную систему для работы, где все интегрировано. В отличие от этого, Google Docs остается в рамках устаревшей модели "документ как файл", что ограничивает его возможности. Notion's модель данных делает его более универсальным и адаптируемым, позволяя ему масштабироваться как платформа, а не просто как инструмент.

• Дискуссия вращается вокруг идеи, что победит не тот, кто предложит больше функций, а тот, кто заложит правильную модель данных, и что именно она определяет судьбу продукта.
• Участники обмениваются примерами: Slack vs. HipChat, Notion vs. Airtable, Google Docs vs. Microsoft Office, и обсуждают, как именно модель данных влияет на возможности и ограничения продукта.
• Обсуждается, что модель данных определяет, как продукт может развиваться и какие фичи можно будет добавлять, и какие нет.
• Участники также обсуждают, что выбор модели данных влияет на то, как продукт может масштабироваться и как он может эволюционировать.
• Также поднимается вопрос, что важнее: модель данных или умение ее реализовать, и как эти два фактора взаимодействуют.

PostgreSQL 18 добавляет нативную поддержку UUID v7 через функцию uuidv7(), что позволяет использовать UUID в качестве первичных ключей без потери производительности благодаря их последовательной природе. Это устраняет необходимость в сторонних расширениях или реализации генерации на уровне приложения.

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

• Участники обсуждают преимущества вычисляемых столбцов в базах данных, отмечая их полезность для миграций схем и единообразия логики между разными клиентами.
• Поднимается вопрос о производительности: выполнение вычислений на стороне БД может быть эффективнее, чем в клиентских приложениях, особенно при использовании индексов.
• Высказываются опасения о возможном злоупотреблении этой функцией и усложнении схемы, но признаётся, что иногда это единственное решение.
• Упоминается конкретный пример использования для преобразования временных зон, чтобы упростить запросы.
• Обсуждение начинается с упоминания функции pg_get_acl() и сложности составления запросов для проверки привилегий.

Почему Protobuf плохи

Protobuf — это любительская, непродуманная технология, созданная для задачи, которую в действительности имеет только Google. Их главная беда — убогая типовая система: нет композиции, куча произвольных запретов (oneof нельзя повторять, map нельзя параметризовать, ключ map не может быть bytes или enum и т.д.). Всё это — следствие донавешивания фич «как получится» вместо проектирования.

Достаточно трёх простых конструкций: обязательные поля (произведение типов), oneof как отдельная копроизводная и параметрические типы. На них можно выразить optional, repeated, map без всяких хаков.

Ещё protobuf разделяет «скаляры» и «сообщения». Скалярные поля всегда «есть»: даже если ты их не заполнял, они инициализируются нулём/пустой строкой. Отличить «поле не прислали» от «прислали 0» невозможно — источник багов и лишних костылей.

• Критика protobuf сводится к «плохо, но альтернатив ещё хуже»: ни одна другая схема не даёт таких же гарантий обратной совместимости + встроенный линтер.
• Главные боли: нулевые значения неотличимы от «не установлено», нет композиции/алгебраических типов, oneof и repeated ограничены, инструментарий (protoc) громоздок.
• Часть проблем — культурное наследие Google: «не давать пользователю обобщений, зато добавить 100 специальных случаев».
• Реальный совет: использовать protobuf только как быстрый бинарный wire-формат, а внутри приложения держать свою доменную модель и писать явные конвертеры.
• Живые альтернативы обсуждаются (Avro, FlatBuffers, Cap’n Proto, JSON+схема), но у каждой свои компромиссы; серебряной пули пока нет.

Булево значение почти всегда маскирует более точный тип.
Проверь, не дата-время ли это: is_confirmed лучше заменить на nullable confirmed_at. Вы получите момент подтверждения и сможете анализировать баги по времени.

Если поле описывает роль или статус (is_admin, failed), превращайте в enum.

enum UserRole { User, Admin, Guest, SuperAdmin }
enum JobStatus { Queued, Started, Failed, Done }

Enum упрощает добавление новых состояний и защищает от забытых веток.

Проверка прав тоже не должна возвращать bool.

enum PermissionCheck { Allowed, NotPermitted(reason: String) }

Так код читабельнее и можно вернуть причину отказа.

Когда же использовать bool? Только как временную переменную-флаг для сложного условия, чтобы не вычислять его дважды или дать имя.

• Основной спор: стоит ли хранить «события» как булевы флаги или как nullable-даты/enum’ы, чтобы не терять данные (время события).
• Противники: это нарушает KISS, раздувает схему и вводит двусмысленность (null = не случилось или ошибка?).
• Сторонники: булевы поля не «помнят» контекст, легко образуют недопустимые комбинации флагов, а дата или enum выразительнее.
• Для параметров функций булевы флаги считаются плохо читаемыми; спасают именованные аргументы, отдельные функции или бит-маски.
• Встраиваемые/индустриальные системы часто считают булевы типы оптимальными по памяти и не применяют совет к себе.