Как устроена машина Тьюринга и где проходит граница вычислимого
Интерактивная статья ведёт от устройства машины к пределам вычислений. У неё четыре части: лента, головка, программа и состояние. Пять команд позволяют печатать символ, двигать головку, менять состояние и останавливать выполнение.
Примеры запускаются в тексте и прокручиваются пошагово вперёд или назад. Сначала машина бесконечно печатает нули, затем чередует 0 и 1 и складывает 2 и 6 в двоичной записи.
Дальше разбор «Turing Machines» переходит к задаче остановки: нельзя написать программу, которая по любой программе и входным данным наверняка определит, завершится вычисление или будет идти вечно. Через этот предел объясняется полнота по Тьюрингу: система полна, если может смоделировать машину Тьюринга.
Читать стоит тем, кто хочет связать определение с исполняемыми примерами и понять границы алгоритмов.
Интерактивная статья ведёт от устройства машины к пределам вычислений. У неё четыре части: лента, головка, программа и состояние. Пять команд позволяют печатать символ, двигать головку, менять состояние и останавливать выполнение.
Примеры запускаются в тексте и прокручиваются пошагово вперёд или назад. Сначала машина бесконечно печатает нули, затем чередует 0 и 1 и складывает 2 и 6 в двоичной записи.
Дальше разбор «Turing Machines» переходит к задаче остановки: нельзя написать программу, которая по любой программе и входным данным наверняка определит, завершится вычисление или будет идти вечно. Через этот предел объясняется полнота по Тьюрингу: система полна, если может смоделировать машину Тьюринга.
Читать стоит тем, кто хочет связать определение с исполняемыми примерами и понять границы алгоритмов.
30 паттернов распределённых систем
Это карта готовых решений для систем, где узлы отказывают, сеть задерживает сообщения, а копии данных нужно синхронизировать.
Материал можно читать от своей задачи:
• упорядочить изменения: логические часы Лэмпорта, гибридные часы и векторы версий;
• синхронизировать копии: ведущий с последователями, реплицируемый журнал и консенсус Paxos;
• ускорить запросы: чтение с ведомых узлов, пакеты и конвейер запросов;
• обслуживать журналы: отмечать последнюю репликацию и часть, которую уже можно удалить.
Catalog of Patterns of Distributed Systems даёт краткое описание каждого решения и ссылки на главы онлайн-книги. Архитекторам и бэкенд-разработчикам стоит сопоставить сбой или узкое место своей системы с готовым механизмом, прежде чем проектировать свой протокол.
Это карта готовых решений для систем, где узлы отказывают, сеть задерживает сообщения, а копии данных нужно синхронизировать.
Материал можно читать от своей задачи:
• упорядочить изменения: логические часы Лэмпорта, гибридные часы и векторы версий;
• синхронизировать копии: ведущий с последователями, реплицируемый журнал и консенсус Paxos;
• ускорить запросы: чтение с ведомых узлов, пакеты и конвейер запросов;
• обслуживать журналы: отмечать последнюю репликацию и часть, которую уже можно удалить.
Catalog of Patterns of Distributed Systems даёт краткое описание каждого решения и ссылки на главы онлайн-книги. Архитекторам и бэкенд-разработчикам стоит сопоставить сбой или узкое место своей системы с готовым механизмом, прежде чем проектировать свой протокол.
❤1
Forwarded from Точка входа в программирование
Как устроена база данных: собираем клон SQLite на C
Это обстоятельная серия для тех, кому знаком SQL, но путь данных от запроса до файла скрыт за интерфейсом СУБД. Автор строит клон SQLite с нуля на C и документирует каждый слой. Всего 15 частей: маршрут идёт от цикла чтения команд и компилятора SQL к многоуровневому B-дереву.
Сначала появляются цикл чтения команд, простейший компилятор SQL и виртуальная машина. Затем одна таблица в памяти получает тесты, сохранение на диск и курсор для обхода записей. Дальше автор разбирает формат узлов B-дерева, двоичный и рекурсивный поиск, разделение узлов и обновление их родителей.
В серии How Does a Database Work? удобно идти по порядку и смотреть, как знакомые операции превращаются в структуры данных. Читать стоит разработчикам, которые работают с SQL и хотят разобраться в индексах, полном сканировании таблицы и границе между памятью и диском.
Это обстоятельная серия для тех, кому знаком SQL, но путь данных от запроса до файла скрыт за интерфейсом СУБД. Автор строит клон SQLite с нуля на C и документирует каждый слой. Всего 15 частей: маршрут идёт от цикла чтения команд и компилятора SQL к многоуровневому B-дереву.
Сначала появляются цикл чтения команд, простейший компилятор SQL и виртуальная машина. Затем одна таблица в памяти получает тесты, сохранение на диск и курсор для обхода записей. Дальше автор разбирает формат узлов B-дерева, двоичный и рекурсивный поиск, разделение узлов и обновление их родителей.
В серии How Does a Database Work? удобно идти по порядку и смотреть, как знакомые операции превращаются в структуры данных. Читать стоит разработчикам, которые работают с SQL и хотят разобраться в индексах, полном сканировании таблицы и границе между памятью и диском.
Let’s Build a Simple Database
How Does a Database Work?
Writing a sqlite clone from scratch in C
Как агенты тестируют код и почему одного промпта мало
В исследовании агенты реализовывали Zstd на Rust и по указанию применяли TDD (разработку через тесты), фаззинг, тестирование свойств или формальные методы. Автор сравнил 26 вариантов промпта и 4 навыка, по 80 запусков на условие и уровень рассуждений.
Режим без дополнительных инструкций оказался выше среднего. На максимальном уровне фаззинг и тестирование свойств были чуть лучше формальных методов, а рекомендованные навыки и TDD показали слабые результаты.
Агенты доказывали малозначимые свойства или перебирали случайные данные, часто попадая в отбраковку. Тест с 4 одинаковыми входными потоками не замечал их перестановку. Исследование How well do agents use test/verification techniques? стоит прочитать тем, кто принимает агентный код: проверяйте, какую ошибку способен обнаружить тест, а не только зелёный результат.
В исследовании агенты реализовывали Zstd на Rust и по указанию применяли TDD (разработку через тесты), фаззинг, тестирование свойств или формальные методы. Автор сравнил 26 вариантов промпта и 4 навыка, по 80 запусков на условие и уровень рассуждений.
Режим без дополнительных инструкций оказался выше среднего. На максимальном уровне фаззинг и тестирование свойств были чуть лучше формальных методов, а рекомендованные навыки и TDD показали слабые результаты.
Агенты доказывали малозначимые свойства или перебирали случайные данные, часто попадая в отбраковку. Тест с 4 одинаковыми входными потоками не замечал их перестановку. Исследование How well do agents use test/verification techniques? стоит прочитать тем, кто принимает агентный код: проверяйте, какую ошибку способен обнаружить тест, а не только зелёный результат.
Как Uber переписала шардирование Schemaless на Go без простоя
Подробный технический разбор миграции хранилища. Материал ценен схемой перехода между реализациями: новая сначала пропускала запросы к старой, затем команда переносила по одной операции.
Карта материала:
1. чтение выполняли обе реализации, после чего ответы сравнивали;
2. долю проверки меняли настройкой, поскольку она удваивала запросы к узлам хранения;
3. запись проверяли интеграционными тестами и тестовым трафиком: один запрос мог успешно выполниться лишь раз.
После миграции медианная задержка всех запросов уменьшилась на 85%, 99-й перцентиль на 70%, загрузка процессора более чем на 85%.
В разборе Uber Engineering стоит изучить совместимость и переключение долей трафика. Для критичного сервиса заранее разделите проверки чтения и записи.
Подробный технический разбор миграции хранилища. Материал ценен схемой перехода между реализациями: новая сначала пропускала запросы к старой, затем команда переносила по одной операции.
Карта материала:
1. чтение выполняли обе реализации, после чего ответы сравнивали;
2. долю проверки меняли настройкой, поскольку она удваивала запросы к узлам хранения;
3. запись проверяли интеграционными тестами и тестовым трафиком: один запрос мог успешно выполниться лишь раз.
После миграции медианная задержка всех запросов уменьшилась на 85%, 99-й перцентиль на 70%, загрузка процессора более чем на 85%.
В разборе Uber Engineering стоит изучить совместимость и переключение долей трафика. Для критичного сервиса заранее разделите проверки чтения и записи.
Go 1.27: что проверить перед обновлением сервисов
Практический обзор Go 1.27 отделяет ускорение после пересборки от изменений, которые требуют проверки кода. Для типичных серверных нагрузок автор приводит прирост 3–5%, для отдельных микротестов до 10%. Причины: более точное встраивание функций компилятором и меньше расходов на выделение памяти.
Отдельно разобраны сборщик мусора для сервисов с сотнями гигабайт живых данных и встроенная функция
В практическом гайде на DEV Community можно сверить детали перед обновлением. Сохраните его, если поддерживаете Go-сервисы: пересоберите стенд и сравните скорость, паузы сборщика мусора и отладку на своей нагрузке.
Практический обзор Go 1.27 отделяет ускорение после пересборки от изменений, которые требуют проверки кода. Для типичных серверных нагрузок автор приводит прирост 3–5%, для отдельных микротестов до 10%. Причины: более точное встраивание функций компилятором и меньше расходов на выделение памяти.
Отдельно разобраны сборщик мусора для сервисов с сотнями гигабайт живых данных и встроенная функция
clear. Она очищает срезы и карты без нового выделения памяти, что пригодится при повторном использовании буферов. Данные DWARF помогают отладчику лучше показывать переменные, а go mod tidy оставляет меньше шума в изменениях go.mod.В практическом гайде на DEV Community можно сверить детали перед обновлением. Сохраните его, если поддерживаете Go-сервисы: пересоберите стенд и сравните скорость, паузы сборщика мусора и отладку на своей нагрузке.
Как отсекать партиции PostgreSQL при поиске не по ключу разбиения
Таблица событий разбита по времени, но запрос по
Приём применим, когда события только добавляются, ID сессий растут последовательно, а сессии обычно длятся минуты или часы. Тогда ID связан со временем: для каждой партиции можно задать его диапазон через
В обстоятельной статье Хаки Бениты разобраны локальные и глобальные индексы, выбросы и схема «пробелы и острова». Материал пригодится тем, кто выбирает ключ разбиения таблицы: проверьте связь данных и план через
Таблица событий разбита по времени, но запрос по
session_id обращается ко всем партициям. Локальный индекс ускоряет поиск в каждой, однако их число не сокращает: при сотне партиций это похоже на запрос к сотне таблиц.Приём применим, когда события только добавляются, ID сессий растут последовательно, а сессии обычно длятся минуты или часы. Тогда ID связан со временем: для каждой партиции можно задать его диапазон через
CHECK. Оптимизатор исключит партицию, где нужного ID быть не может. В примере для ID 1000 сканируется только партиция 2025 года вместо двух.В обстоятельной статье Хаки Бениты разобраны локальные и глобальные индексы, выбросы и схема «пробелы и острова». Материал пригодится тем, кто выбирает ключ разбиения таблицы: проверьте связь данных и план через
EXPLAIN, прежде чем закреплять диапазоны ограничениями.Почему одинаковый nvJPEG2000 даёт разные результаты в тестах
Обстоятельный разбор показывает, как границы таймера и подача кадров меняют результаты nvJPEG2000 на RTX 4090. Асинхронная очередь GPU делает методику частью результата.
В образце NVIDIA декодирование замеряют CUDA-событиями корректно, но разбор сжатого потока считают в целых секундах. Миллисекунды превращаются в ноль, поэтому число охватывает лишь часть работы. В подробном разборе методики авторский стенд включает оба этапа; код и логи открыты.
Есть и второй подвох: восемь потоков с двумя кадрами в работе дают 16 одновременных задач, хотя пакетного вызова у библиотеки нет. Разбор пригодится разработчикам GPU-конвейеров и авторам бенчмарков: сверяйте не только кадры в секунду, но и границы таймера, синхронизацию и число активных кадров.
Обстоятельный разбор показывает, как границы таймера и подача кадров меняют результаты nvJPEG2000 на RTX 4090. Асинхронная очередь GPU делает методику частью результата.
В образце NVIDIA декодирование замеряют CUDA-событиями корректно, но разбор сжатого потока считают в целых секундах. Миллисекунды превращаются в ноль, поэтому число охватывает лишь часть работы. В подробном разборе методики авторский стенд включает оба этапа; код и логи открыты.
Есть и второй подвох: восемь потоков с двумя кадрами в работе дают 16 одновременных задач, хотя пакетного вызова у библиотеки нет. Разбор пригодится разработчикам GPU-конвейеров и авторам бенчмарков: сверяйте не только кадры в секунду, но и границы таймера, синхронизацию и число активных кадров.
❤1
Как собрать GraphRAG для данных ServiceNow на Python и Neo4j
Обстоятельная книга о пути от данных ServiceNow до ответов языковой модели. Python читает записи, Neo4j связывает их в граф, а найденные сущности становятся контекстом для ответа.
На 39 заранее записанных вопросах автор сравнивает восемь методов извлечения: от ключевых слов до обхода графа. Ни один не ответил на исходный вопрос книги.
Материал пригодится разработчикам поиска и внутренних баз знаний: он показывает, как заранее определить тесты, сравнить подходы и зафиксировать провалы.
Обстоятельная книга о пути от данных ServiceNow до ответов языковой модели. Python читает записи, Neo4j связывает их в граф, а найденные сущности становятся контекстом для ответа.
На 39 заранее записанных вопросах автор сравнивает восемь методов извлечения: от ключевых слов до обхода графа. Ни один не ответил на исходный вопрос книги.
Материал пригодится разработчикам поиска и внутренних баз знаний: он показывает, как заранее определить тесты, сравнить подходы и зафиксировать провалы.
Как настроить распределённую трассировку Java-микросервисов с OpenTelemetry
Обстоятельный разбор OpenTelemetry показывает, как связать путь запроса через Java-микросервисы и найти сервис, запрос к базе или внешний вызов, который добавляет задержку.
Карта материала:
1. почему разрозненные логи и метрики не восстанавливают путь запроса;
2. как SDK собирает трассы, метрики и логи, а процессоры фильтруют и группируют их;
3. как подключить Maven, экспорт по OTLP, Jaeger и собственные участки трассы.
Примеры рассчитаны на Spring Boot 3.x и OpenTelemetry 1.35.0: стартер автоматически охватывает HTTP, JDBC, JPA, Kafka и RabbitMQ. Локальный Jaeger запускается через Docker Compose; бизнес-операции можно размечать собственными участками трассы.
Подойдёт Java-бэкендерам и SRE: на тестовом стенде проверьте сквозной идентификатор trace_id, а перед рабочей средой пересмотрите выборку в 100%.
Обстоятельный разбор OpenTelemetry показывает, как связать путь запроса через Java-микросервисы и найти сервис, запрос к базе или внешний вызов, который добавляет задержку.
Карта материала:
1. почему разрозненные логи и метрики не восстанавливают путь запроса;
2. как SDK собирает трассы, метрики и логи, а процессоры фильтруют и группируют их;
3. как подключить Maven, экспорт по OTLP, Jaeger и собственные участки трассы.
Примеры рассчитаны на Spring Boot 3.x и OpenTelemetry 1.35.0: стартер автоматически охватывает HTTP, JDBC, JPA, Kafka и RabbitMQ. Локальный Jaeger запускается через Docker Compose; бизнес-операции можно размечать собственными участками трассы.
Подойдёт Java-бэкендерам и SRE: на тестовом стенде проверьте сквозной идентификатор trace_id, а перед рабочей средой пересмотрите выборку в 100%.
Как вынести тени в отдельные проходы Custom SRP в Unity
Обстоятельное продолжение серии о собственном конвейере рендеринга на Unity 6000.5.8f1. Рефакторинг ведут поэтапно: после каждого раздела тени остаются рабочими, поэтому материал читается как карта безопасного изменения архитектуры.
Сначала объект Shadows уходит из LightingPass под управление CameraRenderer. Затем LightingPass получает структуру Handles и возвращает только буферы освещения. После появляется отдельный ShadowsPass: он строит списки отрисовки, запускает рендеринг теней и отдаёт их дескрипторы.
Дальше код из Shadows переносят в новый проход, чтобы затем разделить обработку направленных и остальных источников света.
Разбор с правками кода полезен тем, кто уже строит Custom SRP. Ориентир для рефакторинга: разделяйте владение состоянием и запись проходов небольшими шагами, проверяя тени после каждого.
Обстоятельное продолжение серии о собственном конвейере рендеринга на Unity 6000.5.8f1. Рефакторинг ведут поэтапно: после каждого раздела тени остаются рабочими, поэтому материал читается как карта безопасного изменения архитектуры.
Сначала объект Shadows уходит из LightingPass под управление CameraRenderer. Затем LightingPass получает структуру Handles и возвращает только буферы освещения. После появляется отдельный ShadowsPass: он строит списки отрисовки, запускает рендеринг теней и отдаёт их дескрипторы.
Дальше код из Shadows переносят в новый проход, чтобы затем разделить обработку направленных и остальных источников света.
Разбор с правками кода полезен тем, кто уже строит Custom SRP. Ориентир для рефакторинга: разделяйте владение состоянием и запись проходов небольшими шагами, проверяя тени после каждого.
Как устроена криптография Ethereum-кошелька на Go
Статья о цепочке «создать ключ, получить адрес, подписать транзакцию»: автор собирает учебный CLI-кошелёк на Go и показывает детали, от которых зависят совместимость и безопасность.
В практическом разборе разбираются BIP39, путь BIP44 и соглашения для поля
Тест «зашифровали и расшифровали» не нашёл ошибку в параметрах scrypt: обе операции повторяли её. Нужен эталонный набор данных.
CLI создан для обучения, не для реальных средств. Читайте, если хотите проверить реализацию Ethereum-стандартов в Go.
Статья о цепочке «создать ключ, получить адрес, подписать транзакцию»: автор собирает учебный CLI-кошелёк на Go и показывает детали, от которых зависят совместимость и безопасность.
В практическом разборе разбираются BIP39, путь BIP44 и соглашения для поля
v, защищающего транзакции от повторного воспроизведения.Тест «зашифровали и расшифровали» не нашёл ошибку в параметрах scrypt: обе операции повторяли её. Нужен эталонный набор данных.
CLI создан для обучения, не для реальных средств. Читайте, если хотите проверить реализацию Ethereum-стандартов в Go.