⚡ В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости.

Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.

Внутри — большой цикл диспетчеризации с почти 200 opcode.

И вот интересный момент: SQLite использует обычные goto, чтобы быстро прыгать между общими ветками выполнения.

В исходниках прямо написано:

«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».

По замерам разработчиков, такой подход ускоряет sqlite3_step() примерно на 1,5%.

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

Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».

#SQLite #C #Databases #Performance #SystemsProgramming

🔥 PPT Master делает презентации из PDF, DOCX и сайтов прямо внутри Claude Code и Cursor. И на выходе это настоящий редактируемый PowerPoint

ppt-master работает как skill для AI-IDE. Можно просто написать: «сделай презентацию из этого PDF», после чего агент сам разбирает материал, продумывает структуру, собирает дизайн и экспортирует .pptx. Поддерживаются PDF, DOCX, URL и Markdown.

Самая сильная часть проекта в том, что слайды не превращаются в набор картинок. Текст, фигуры, таблицы и графики экспортируются как нативные объекты PowerPoint, которые можно открыть и вручную отредактировать. Есть шаблоны, live preview, анимации, speaker notes и даже генерация озвучки с последующим встраиванием аудио в PPTX.

Работает с Claude Code, Cursor, VS Code + Copilot и другими agent harness. Сам пайплайн выполняется локально, кроме обращений к выбранной AI-модели.

По сути:

PDF / DOCX / URL → AI-agent → структура → дизайн → настоящий editable .pptx

Автор отдельно пишет, что цель не заменить финальную ручную полировку, а убрать примерно 90% работы с пустого листа.

🔗 github.com/hugohe3/ppt-master

#AI #ClaudeCode #PowerPoint #Agents #OpenSource

🐘 SQL-совет, который многие игнорируют: не используй `COUNT(*)`, если тебе нужно только проверить существование строки.

Часто пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 42;

А потом проверяют, больше ли результат нуля.

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

Лучше использовать:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS может остановить поиск сразу после первого совпадения.

На маленькой таблице разницы почти не заметишь. На миллионах строк и частых проверках это уже может серьёзно экономить ресурсы.

Если нужен ответ «да/нет» — не заставляй SQL считать всё.

SQLite-песочница в браузере

Чего мне всегда не хватало, так это аналога JSFiddle для SQLite, какой-то онлайн-песочницы, в которой можно быстро проверить SQL-запрос и поделиться с другими.

Смотреть статью

Линус Торвальдс написал и внёс изменения в драйвер графического ядра Intel Xe. Это произошло после того, как он столкнулся с «адской отладкой», но в итоге ему помог искусственный интеллект.

#ИскИн #ОС #разработка

Поиск таймаутов выполнения запросов SQL Server

Когда вы работаете с SQL Server, вы, вероятно, столкнулись с ситуацией, когда запрос занимает слишком много времени и в конечном итоге приводит к ошибке тайм-аута.

Вот некоторые советы для улучшения производительности и снижения тайм-аута:

- Используйте SQL Server Management Studio (SSMS) для управления и настройки SQL Server, а также для поиска таймаутов выполнения запросов. Используйте SQL Server Profiler для отслеживания и анализа производительности запросов.

- Используйте динамические управляемые представления, такие как sys.dm_exec_requests и sys.dm_exec_sessions, чтобы получить информацию о запросах, выполняемых на сервере, и определить, какие из них занимают слишком много времени.

- Используйте инструменты мониторинга производительности, такие как SQL Sentry, Idera SQL Diagnostic Manager и Microsoft System Center Operations Manager, для получения детальной информации о производительности сервера и запросов, выполняемых на сервере, и для получения рекомендаций по улучшению производительности и оптимизации запросов, чтобы избежать таймаутов выполнения запросов.

📌 Почему SQL работает именно так - заслуга Эдгара «Теда» Кодда

В конце 1960-х базы данных напоминали лабиринты указателей. Чтобы найти запись, программисту приходилось понимать, как именно данные расположены внутри системы.

Кодд предложил хранить данные в виде математических отношений - знакомых нам таблиц. В 1970 году он описал реляционную модель и основные операции:

* σ - выбирает строки по условию, будущий WHERE
* π - оставляет нужные столбцы, основа SELECT
* ⋈ - соединяет связанные таблицы, будущий JOIN

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

SQL появился позже, но был построен на реляционной модели Кодда. Её принципы до сих пор лежат в основе большинства запросов к базам данных.

Два клиента одновременно бронируют один номер. Как не продать его дважды?

Обычная проверка «свободен ли номер?» может пропустить оба запроса: каждый успеет увидеть свободное время до сохранения чужой брони.

В PostgreSQL можно запретить пересечения прямо в базе:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE bookings (
    room_id   INT NOT NULL,
    starts_at TIMESTAMPTZ NOT NULL,
    ends_at   TIMESTAMPTZ NOT NULL,

    CHECK (ends_at > starts_at),

    EXCLUDE USING gist (
        room_id WITH =,
        tstzrange(starts_at, ends_at, '[)') WITH &&
    )
);

Как это работает:

• room_id WITH = — проверяем брони одного номера.
• WITH && — запрещаем пересечение временных интервалов.
• '[)' — начало включено, конец исключён. Брони 10:00–11:00 и 11:00–12:00 допустимы.
• CHECK — окончание должно быть позже начала.

Ограничение действует и при одновременных запросах. Две конфликтующие брони сохранить не получится: приложение должно обработать ошибку и сообщить, что время уже занято.

Подходит для гостиниц, переговорных, аренды оборудования и записи к специалистам.

Энтузиаст попросил GPT-6 Astra и Claude Fable сделать для него бесплатный «аналог» Adobe Photoshop. На токены ушло $2000 или 168 тысяч рублей.

У моделей получилась работающая версия со слоями, масками, смарт-объектами, кривыми, эффектами и другими инструментами. Пользователь выложил программу для Windows 11, macOS и Linux — бесплатно

vc.ru/ai/3142780

3 AI-навыка для работы с архитектурой AI-систем

Переходим к задачам, которые выходят за пределы отдельно взятого файла. Здесь нужен системный взгляд — как встроить нейросети в ваш продукт, чтобы они работали стабильно, дёшево и безопасно.

Навык 1: Работа с LLM API

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

Пример простой интеграции: приложение получает запрос от пользователя, отправляет в Claude API с заданной температурой (контролирует креативность ответа) и максимальным количеством токенов, получает ответ в потоковом режиме (streaming) и отдаёт его пользователю по частям.

Инструменты: официальные API OpenAI, Anthropic, OpenRouter (единый интерфейс к десяткам моделей), Google Gemini API.

Почему важно: базовый навык для любого AI-инженера. Без него следующие два навыка просто не имеют смысла — RAG и выбор моделей надстраиваются именно поверх API.

Навык 2: Построение RAG-систем

RAG-системы подключают к языковой модели собственную базу знаний: документы, инструкции, внутренние регламенты, статьи или переписку. Пользователь задаёт вопрос, система находит в вашей базе релевантные документы и отправляет их модели вместе с вопросом в промпте. Модель отвечает на основе ваших документов — а не общих знаний, которые могут быть устаревшими или неполными.

Инструменты: LangChain, LlamaIndex, векторные базы данных (Chroma, Pinecone, Weaviate).

Почему важно: чистая LLM знает то, на чём её обучили год назад. RAG — это работа с живыми, актуальными и корпоративными данными. Без него AI-продукт для бизнеса сегодня почти не построишь.

Навык 3: Оценка и выбор моделей под задачу

Умение сравнивать большие языковые модели не по маркетинговым описаниям, а по конкретным параметрам: размер контекстного окна, скорость ответа, цена за токен, качество на вашей задаче.

Инструменты: OpenRouter (сравнение моделей по цене и скорости), бенчмарки SWE-bench, AIME, собственные бенчмарки на ваших данных.

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

📌 Сохраните, чтобы не потерять, и приходите качать AI-навыки в Практикум.

Журнал «Код» | Промокод Практикума | Новости мира IT и технологий

🧩 SQL-задача: почему `LAG()` здесь подведёт?

Есть интервалы работы сервера. Время указано в минутах:


id | start_at | end_at
---+----------+-------
1 | 1 | 10
2 | 2 | 3
3 | 9 | 12
4 | 15 | 16
5 | 16 | 20

Объедините пересекающиеся и соприкасающиеся интервалы. Вложенные интервалы тоже учитываются.

Ожидаемый результат:

start_at | end_at
---------+-------
1        | 12
15       | 20

Попробуйте решить до просмотра ответа 👇

Решение для PostgreSQL:

WITH bounds AS (
  SELECT *,
    MAX(end_at) OVER (
      ORDER BY start_at, end_at, id
      ROWS BETWEEN UNBOUNDED PRECEDING
               AND 1 PRECEDING
    ) AS prev_max
  FROM intervals
),
marked AS (
  SELECT *,
    CASE WHEN prev_max IS NULL
           OR start_at > prev_max
         THEN 1 ELSE 0 END AS new_group
  FROM bounds
),
grouped AS (
  SELECT *,
    SUM(new_group) OVER (
      ORDER BY start_at, end_at, id
      ROWS UNBOUNDED PRECEDING
    ) AS grp
  FROM marked
)
SELECT MIN(start_at) AS start_at,
       MAX(end_at) AS end_at
FROM grouped
GROUP BY grp
ORDER BY start_at;

Подвох: LAG(end_at) для интервала [9,12] вернёт 3 и ошибочно начнёт новую группу. Но более ранний интервал [1,10] всё ещё перекрывает его.

Нужен максимальный конец среди всех предыдущих строк, а не только конец соседней.

Claude помог обнаружить новую планету
Наверное.

Пользователь reddit проанализировал данные, собранные телескопом TESS, и обнаружил, что звезда на расстоянии 116 лет от нас каждые 3,18 дня становится на 0,05% тусклее. Вместе с Opus 5.5 и Fable 5.1 он прошерстил информацию за все годы наблюдений, начиная с 2018, и увидел, что этот цикл повторяется на протяжении всех этих лет. 
 
Возможной причиной этих периодических затемнений может быть планета примерно в полтора раза больше Земли. А может и не быть — эта гипотеза пока не подтверждена, но, возможно, скоро мы узнаем об этом небесном теле чуть-чуть больше. 

В ноябре NASA опять вернется к наблюдению за этим участком неба, и автор поста написал им о своей находке и попросил сделать несколько снимков этой звезды с промежутком в 2 минуты. И в NASA согласились! Автор (и Claude) уже сделал расчеты, когда должно быть видно мерцание звезды, и если на снимках его будет видно, это станет очередным подтверждением его теории. 

Он даже сделал 3D-модель системы. На ней видно звезду и две предполагаемые планеты: А, про которую идет речь в посте, и B, про которую данных у него пока совсем мало. 

Вот такой небанальный способ использовать ИИ, где никто никого не взломал.