This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Логическая аналитика с LynxDB
LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера.
🚀 Основные моменты:
- Пайплайн-запросы для обработки данных
- Полнотекстовый поиск и колоночное хранилище
- Поддержка кластерного режима и материализованных представлений
- Никакой конфигурации — разумные настройки по умолчанию
- Активная разработка, обратная связь приветствуется
📌 GitHub: https://github.com/lynxbase/lynxdb
#rust
LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера.
🚀 Основные моменты:
- Пайплайн-запросы для обработки данных
- Полнотекстовый поиск и колоночное хранилище
- Поддержка кластерного режима и материализованных представлений
- Никакой конфигурации — разумные настройки по умолчанию
- Активная разработка, обратная связь приветствуется
📌 GitHub: https://github.com/lynxbase/lynxdb
#rust
❤3👍1🔥1
Обычный поиск работает так: есть вопрос - база находит top-k самых похожих фрагментов. Это удобно, если нужно вытащить один факт.
Но если ответ спрятан в нескольких местах, например в разных документах, сообщениях или частях отчёта, простого similarity search уже мало. Нужно понять, как связаны люди, события, компании, причины и последствия.
На этом и делает акцент FalkorDB GraphRAG-Bench. Самый большой отрыв у GraphRAG виден именно в сложных задачах: Complex Reasoning - 83.61 и Contextual Summarization - 85.08. То есть там, где нужно не просто найти похожий текст, а собрать смысл из нескольких связанных фрагментов.
Простой вывод: если у вас база знаний, длинные документы или корпоративные данные, одного Vector DB может быть недостаточно. GraphRAG помогает модели не просто искать, а идти по связям.
GraphRAG SDK полностью open-source: https://github.com/FalkorDB/GraphRAG-SDK
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍1
Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу.
IServiceCollection не вызывает ступора.
async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал.Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой.
ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом.А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS.
Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1🔥1
Какая утилита PostgreSQL используется для физического удаления «мертвых» строк и освобождения места в файлах данных?
Anonymous Quiz
14%
REINDEX
3%
ANALYZE
75%
VACUUM
7%
EXPLAIN
🚀 Примеры использования Cursor SDK для разработки
Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально.
🚀 Основные моменты:
- Примеры для создания агентов и работы с API.
- Веб-приложение для быстрой разработки и тестирования.
- Канбан-доска для управления агентами и артефактами.
- CLI для запуска агентов из терминала.
📌 GitHub: https://github.com/cursor/cookbook
Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально.
🚀 Основные моменты:
- Примеры для создания агентов и работы с API.
- Веб-приложение для быстрой разработки и тестирования.
- Канбан-доска для управления агентами и артефактами.
- CLI для запуска агентов из терминала.
📌 GitHub: https://github.com/cursor/cookbook
❤6👍1🔥1
project_final_v2_FINAL_truly_final - знакомо?
Значит, пора.
Большинство разработчиков знают 5 команд Git и боятся шестую. Коммитят в main, гуглят «how to undo» и копируют папку «на всякий случай».
Это не работа - это выживание.
После курса вы:
— делаете rebase, не задерживая дыхание;
— разбираете конфликт на 200 файлов по алгоритму;
— возвращаете «потерянные навсегда» коммиты за 30 секунд через reflog;
— пишете историю, которую не стыдно показать на code review.
Git Flow, trunk-based, Pull Request, защита веток, CI/CD-хуки — всё, что отличает джуна от senior в командной работе.
Скидка 53%, 48 часов: https://stepik.org/course/284799/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1🔥1💊1
Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей.
В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи.
Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности.
Математический трюк:
То есть вместо прямого произведения считаем сумму логарифмов.
Где это полезно:
Это стандартный численный прием из математики, который делает расчет стабильнее.
Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий.
Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.
В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи.
Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности.
Математический трюк:
a * b * c = exp(ln(a) + ln(b) + ln(c))
То есть вместо прямого произведения считаем сумму логарифмов.
SELECT
user_id,
EXP(SUM(LN(probability))) AS total_probability
FROM events
WHERE probability > 0
GROUP BY user_id;
Где это полезно:
SELECT
user_id,
EXP(SUM(LN(conversion_rate))) AS funnel_survival_rate
FROM funnel_steps
GROUP BY user_id;
Это стандартный численный прием из математики, который делает расчет стабильнее.
Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий.
Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.
👍8🔥5❤2
⚡️ Один SQL-запрос выполнялся за 298 мс.
Почти такой же - за 0,66 мс.
Разница в 451 раз из-за одной строки.
Ситуация обычная: cursor pagination, сортировка по
Но
То есть индекс есть, но запрос все равно тащит слишком много лишнего.
Проблема в условии:
Для разработчика это выглядит логично: сначала сравниваем дату, потом id.
Но для оптимизатора такой
Правильнее записать условие через tuple comparison:
Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу.
И результат: 298 мс превращаются в 0,66 мс.
Индекс сам по себе ничего не гарантирует.
Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.
Почти такой же - за 0,66 мс.
Разница в 451 раз из-за одной строки.
Ситуация обычная: cursor pagination, сортировка по
date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро.Но
EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter.То есть индекс есть, но запрос все равно тащит слишком много лишнего.
Проблема в условии:
`date < @date OR (date = @date AND id <= @lastId)`Для разработчика это выглядит логично: сначала сравниваем дату, потом id.
Но для оптимизатора такой
OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных.Правильнее записать условие через tuple comparison:
`(date, id) <= (@date, @lastId)`Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу.
И результат: 298 мс превращаются в 0,66 мс.
Индекс сам по себе ничего не гарантирует.
Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.
👍14🔥5❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Claude можно превратить в личного сборщика презентаций: https://www.youtube.com/watch?v=5RNTmbbyUHw
Большинство людей просят AI: «сделай слайды» - и получают обычный текст, который потом приходится вручную переносить в PowerPoint.
Но есть способ лучше: сделать для Claude отдельный Skill под презентации.
Открываете Claude, заходите в Customize, выбираете Skills, создаете новый skill и вставляете туда свои правила: какие презентации вы делаете, для какой аудитории, в каком стиле, какая структура нужна и что должно быть на каждом слайде.
После этого Claude перестает гадать.
Он уже знает, как должен выглядеть ваш deck: где нужен сильный opening slide, где краткий executive summary, где схема, где таблица, где финальный CTA.
Главная мысль простая: чем точнее instructions, тем меньше ручной переделки.
Вместо хаотичного «сделай презентацию» вы получаете повторяемый workflow: один раз настраиваете skill, а дальше Claude собирает слайды по вашим правилам.
Это не магия. Это нормальная упаковка контекста, стиля и структуры в reusable-инструмент.
Именно так AI начинает работать не как чат-бот, а как часть вашего production-процесса.
https://www.youtube.com/shorts/qyYOG338hyY
Большинство людей просят AI: «сделай слайды» - и получают обычный текст, который потом приходится вручную переносить в PowerPoint.
Но есть способ лучше: сделать для Claude отдельный Skill под презентации.
Открываете Claude, заходите в Customize, выбираете Skills, создаете новый skill и вставляете туда свои правила: какие презентации вы делаете, для какой аудитории, в каком стиле, какая структура нужна и что должно быть на каждом слайде.
После этого Claude перестает гадать.
Он уже знает, как должен выглядеть ваш deck: где нужен сильный opening slide, где краткий executive summary, где схема, где таблица, где финальный CTA.
Главная мысль простая: чем точнее instructions, тем меньше ручной переделки.
Вместо хаотичного «сделай презентацию» вы получаете повторяемый workflow: один раз настраиваете skill, а дальше Claude собирает слайды по вашим правилам.
Это не магия. Это нормальная упаковка контекста, стиля и структуры в reusable-инструмент.
Именно так AI начинает работать не как чат-бот, а как часть вашего production-процесса.
https://www.youtube.com/shorts/qyYOG338hyY
❤5👍1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Открыл Claude, написал большой промпт - получил обычный нейротекст.
Рабочая схема другая.
Сначала делаете файл about-me.md.
Туда кладёте:
кто вы,
для кого пишете,
какой стиль нужен,
что бесит в текстах,
какой результат хотите получать.
Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей.
И только после этого даёте реальную задачу:
пост, план, письмо, разбор, аудит.
Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу.
В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст.
https://youtube.com/shorts/JjGrRyt_HBM
Рабочая схема другая.
Сначала делаете файл about-me.md.
Туда кладёте:
кто вы,
для кого пишете,
какой стиль нужен,
что бесит в текстах,
какой результат хотите получать.
Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей.
И только после этого даёте реальную задачу:
пост, план, письмо, разбор, аудит.
Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу.
В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст.
https://youtube.com/shorts/JjGrRyt_HBM
❤8👍4🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Разработчик сделал тренажёр, где вы проходите уровни, находите терминалы и «взламываете» их SQL-запросами.
Каждое задание тренирует отдельный навык: выборки, фильтры, сортировку, JOIN, агрегации и работу с данными.
Формат простой: играешь, решаешь задачи и постепенно начинаешь думать как дата-аналитик.
Идеальный вариант на выходные, если давно хотели подтянуть SQL без унылой теории.
http://sqlprotocol.com/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤1👍1
🤖 Machine Learning Roadmap: от базы до гуру вайбкодинга
Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API.
https://github.com/justxor/MachineLearningRoadmap/tree/main
Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API.
https://github.com/justxor/MachineLearningRoadmap/tree/main
❤8👍1🔥1
🔥 Huawei хочет обойти санкции не нанометрами, а задержками в чипе
Huawei представила Tau Scaling Law - подход, который должен ускорять чипы не только за счёт уменьшения транзисторов, а за счёт сокращения времени прохождения сигнала внутри схемы.
Идея простая: если нельзя быстро догнать TSMC и Intel по литографии, нужно выжимать больше из архитектуры, трассировки, памяти, interconnect и софта. Меньше лишнего пути для сигнала - меньше задержка, выше плотность и эффективность.
Ключевая техника называется LogicFolding. Связанные логические блоки размещают ближе друг к другу, укорачивают критические провода, снижают сопротивление и паразитную ёмкость. Это даёт прирост без полноценного скачка на новый техпроцесс.
Huawei утверждает, что за последние шесть лет уже спроектировала и массово выпустила 381 чип с этим подходом, а будущие Kirin осенью 2026 года станут первым крупным тестом LogicFolding.
Самая громкая заявка - к 2031 году выйти на плотность уровня 14Å, то есть примерно 1,4 нм, без прямой зависимости от классического shrink.
Звучит амбициозно, но контекст важен: после санкций Huawei фактически вынуждена искать обходные инженерные пути. Если доступ к лучшей литографии ограничен, приходится оптимизировать всё остальное - от транзистора и схемы до системной шины и планировщика.
Это не отменяет физику и не делает Huawei новым TSMC завтра. Но показывает, куда может сдвинуться гонка чипов: не только «у кого меньше нанометры», а «кто лучше сокращает задержки по всему стеку».
huawei.com/en/news/2026/5/ieee-iscas-tau-scaling
Huawei представила Tau Scaling Law - подход, который должен ускорять чипы не только за счёт уменьшения транзисторов, а за счёт сокращения времени прохождения сигнала внутри схемы.
Идея простая: если нельзя быстро догнать TSMC и Intel по литографии, нужно выжимать больше из архитектуры, трассировки, памяти, interconnect и софта. Меньше лишнего пути для сигнала - меньше задержка, выше плотность и эффективность.
Ключевая техника называется LogicFolding. Связанные логические блоки размещают ближе друг к другу, укорачивают критические провода, снижают сопротивление и паразитную ёмкость. Это даёт прирост без полноценного скачка на новый техпроцесс.
Huawei утверждает, что за последние шесть лет уже спроектировала и массово выпустила 381 чип с этим подходом, а будущие Kirin осенью 2026 года станут первым крупным тестом LogicFolding.
Самая громкая заявка - к 2031 году выйти на плотность уровня 14Å, то есть примерно 1,4 нм, без прямой зависимости от классического shrink.
Звучит амбициозно, но контекст важен: после санкций Huawei фактически вынуждена искать обходные инженерные пути. Если доступ к лучшей литографии ограничен, приходится оптимизировать всё остальное - от транзистора и схемы до системной шины и планировщика.
Это не отменяет физику и не делает Huawei новым TSMC завтра. Но показывает, куда может сдвинуться гонка чипов: не только «у кого меньше нанометры», а «кто лучше сокращает задержки по всему стеку».
huawei.com/en/news/2026/5/ieee-iscas-tau-scaling
👍4
🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить?
С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат.
На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам.
Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE.
🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков».
Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК.
🔗 Регистрация открыта: https://tglink.io/e6a3872408e743?erid=2W5zFJG1JPK
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат.
На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам.
Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE.
🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков».
Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК.
🔗 Регистрация открыта: https://tglink.io/e6a3872408e743?erid=2W5zFJG1JPK
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
❤1
Какой верный ответ на задачку выше? ⤴️
Anonymous Quiz
18%
SELECT COUNT(product_id) FROM product;
38%
SELECT COUNT(DISTINCT product_id), COUNT(product_id) FROM product;
25%
SELECT COUNT(DISTINCT product_id) FROM product;
19%
SELECT SUM(product_id), COUNT(product_id) FROM product WHERE product_id IS NOT NULL;
🤔15👨💻1
Кажется, аналитика подошла к моменту больших изменений.
Ещё недавно подготовка отчётов занимала дни: данные собирались вручную, цифры перепроверялись, а бизнес слишком долго ждал ответы. Сегодня искусственный интеллект меняет сам подход к работе с данными — делает аналитику быстрее, проще и доступнее.
3 июня Visiology проведёт большой онлайн-эфир Cortex LIVE о новом поколении аналитики.
На бесплатном эфире покажут:
— как ускорить получение аналитики
— как сократить объём ручной работы
— как быстрее находить ответы для бизнеса
— как компании уже меняют подход к работе с данными
Без сложной теории — только реальные примеры и практические сценарии.
Если вы работаете с аналитикой, отчётностью или управлением, этот эфир точно стоит посмотреть.
До мероприятия осталось совсем немного времени — успейте зарегистрироваться заранее, чтобы не пропустить эфир.
Ещё недавно подготовка отчётов занимала дни: данные собирались вручную, цифры перепроверялись, а бизнес слишком долго ждал ответы. Сегодня искусственный интеллект меняет сам подход к работе с данными — делает аналитику быстрее, проще и доступнее.
3 июня Visiology проведёт большой онлайн-эфир Cortex LIVE о новом поколении аналитики.
На бесплатном эфире покажут:
— как ускорить получение аналитики
— как сократить объём ручной работы
— как быстрее находить ответы для бизнеса
— как компании уже меняют подход к работе с данными
Без сложной теории — только реальные примеры и практические сценарии.
Если вы работаете с аналитикой, отчётностью или управлением, этот эфир точно стоит посмотреть.
До мероприятия осталось совсем немного времени — успейте зарегистрироваться заранее, чтобы не пропустить эфир.
❤1🔥1
🔥 Полное внимание возвращается: 9× ускорение префилла на 1M токенов
Alibaba и Нанкинский университет показали метод RTPurbo. На контексте в миллион токенов префилл ускоряется до 9,36× относительно FlashAttention-2, декодинг - примерно вдвое. Качество на длинных бенчмарках остаётся близким к full attention, а адаптация лёгкая: переобучать модель с нуля не нужно.
Идея в том, что внутри уже обученной модели с full attention есть скрытая разреженность. Не все attention heads реально ходят за дальними токенами. Большинство работает локально, а за retrieval из далёкого контекста отвечает только небольшая часть голов.
RTPurbo считает полное внимание только для этих retrieval-голов. Остальным хватает соседнего окна.
Для поиска нужных токенов используется дешёвый 16-мерный индексатор. Он не заменяет настоящее внимание, а работает как разведчик: быстро отбирает кандидатов из прошлого контекста, после чего честное внимание считается уже на маленьком наборе токенов в полной размерности.
Длинный контекст стоит дорого не потому, что вся история одинаково важна, а потому что мы часто считаем внимание там, где оно почти ничего не меняет.
RTPurbo показывает, что значительную часть вычислений можно срезать инженерно, без полного переобучения модели и без заметной потери качества.
В full attention много лишней работы, и её можно убирать гораздо аккуратнее, чем просто резать контекст или надеяться на магию sparse attention.
arxiv.org/abs/2605.16928v1
Alibaba и Нанкинский университет показали метод RTPurbo. На контексте в миллион токенов префилл ускоряется до 9,36× относительно FlashAttention-2, декодинг - примерно вдвое. Качество на длинных бенчмарках остаётся близким к full attention, а адаптация лёгкая: переобучать модель с нуля не нужно.
Идея в том, что внутри уже обученной модели с full attention есть скрытая разреженность. Не все attention heads реально ходят за дальними токенами. Большинство работает локально, а за retrieval из далёкого контекста отвечает только небольшая часть голов.
RTPurbo считает полное внимание только для этих retrieval-голов. Остальным хватает соседнего окна.
Для поиска нужных токенов используется дешёвый 16-мерный индексатор. Он не заменяет настоящее внимание, а работает как разведчик: быстро отбирает кандидатов из прошлого контекста, после чего честное внимание считается уже на маленьком наборе токенов в полной размерности.
Длинный контекст стоит дорого не потому, что вся история одинаково важна, а потому что мы часто считаем внимание там, где оно почти ничего не меняет.
RTPurbo показывает, что значительную часть вычислений можно срезать инженерно, без полного переобучения модели и без заметной потери качества.
В full attention много лишней работы, и её можно убирать гораздо аккуратнее, чем просто резать контекст или надеяться на магию sparse attention.
arxiv.org/abs/2605.16928v1
❤2
Какая команда используется для создания индекса по результату выражения или функции, а не по конкретному столбцу?
Anonymous Quiz
45%
CREATE INDEX ... ON table (upper(column))
35%
CREATE FUNC INDEX
10%
ALTER TABLE ADD EXPRESSION
10%
CREATE VIRTUAL INDEX
This media is not supported in your browser
VIEW IN TELEGRAM
⚡Когда аналитика разнесена по отдельным системам, бизнес долго ждет данные и платит за лишние кластеры, ETL и серверы.
🐘Postgres Pro AXE — аналитическая СУБД от Postgres Professional на знакомом PostgreSQL. Ускоряет доставку аналитики и снижает TCO на хранение и обработку данных.
✔️До 20 раз быстрее Greenplum
На сложных запросах в тестах ClickBench, TPC-H и TPC-DS.
✔️До 10 раз меньше ресурсов
При сопоставимой нагрузке с MPP-аналогами.
✔️Аналитика ближе к рабочим данным
Postgres Pro AXE работает как отдельная аналитическая СУБД или расширяет Postgres Pro Enterprise аналитическими возможностями на существующих узлах.
✔️Быстрый старт для команды
Знакомый PostgreSQL снижает порог входа для администраторов и разработчиков.
✔️Свобода хранения и BI
Локальный сервер, сетевая шара или S3. Данные — в формате Parquet.
🔗Приходите 28 мая на бесплатный вебинар: покажем, как построить аналитику без зоопарка технологий.
🐘Postgres Pro AXE — аналитическая СУБД от Postgres Professional на знакомом PostgreSQL. Ускоряет доставку аналитики и снижает TCO на хранение и обработку данных.
✔️До 20 раз быстрее Greenplum
На сложных запросах в тестах ClickBench, TPC-H и TPC-DS.
✔️До 10 раз меньше ресурсов
При сопоставимой нагрузке с MPP-аналогами.
✔️Аналитика ближе к рабочим данным
Postgres Pro AXE работает как отдельная аналитическая СУБД или расширяет Postgres Pro Enterprise аналитическими возможностями на существующих узлах.
✔️Быстрый старт для команды
Знакомый PostgreSQL снижает порог входа для администраторов и разработчиков.
✔️Свобода хранения и BI
Локальный сервер, сетевая шара или S3. Данные — в формате Parquet.
🔗Приходите 28 мая на бесплатный вебинар: покажем, как построить аналитику без зоопарка технологий.
❤1
Forwarded from Machinelearning
Media is too big
VIEW IN TELEGRAM
Власти Китая ввели обязательное согласование зарубежных поездок для ключевых ИИ-специалистов из частных компаний, включая Alibaba и DeepSeek. Теперь инженерам, исследователям и основателям стартапов требуется официальное разрешение на выезд из страны вместо прежнего уведомительного порядка.
Ведомства формируют ограничительные списки, оценивая фактическую значимость конкретного разработчика для технологической отрасли, а не его должность в штатном расписании.
Ранее государство контролировало перемещения преимущественно чиновников, топ-менеджеров госкорпораций и ученых из стратегических секторов экономики.
bloomberg.com
Anthropic выпустила плагин Security Guidance для автоматического поиска уязвимостей в Claude Code. Инструмент работает на базе хуков и выявляет баги безопасности в процессе написания кода.
Проверка проходит на 3-х уровнях: при редактировании файлов система ищет опасные паттерны и ошибки использования библиотек; после генерации кода анализирует diff, а на этапе коммита проверяет окружающий контекст.
По данным Anthropic, использование этой системы как предварительного фильтра перед код-ревью снизило количество замечаний по безопасности PR на 30–40%. Расширение доступно в маркетплейсе плагинов Claude Code.
Claude Devs в сети Х
xAI открыла доступ к CLI-ассистенту Grok Build подписчикам SuperGrok и X Premium+. На этапе беты инструмент работал только на флагманском тарифе SuperGrok Heavy за $300 в месяц.
Grok Build предназначен для отладки и рефакторинга локального кода. Режим Plan Mode предварительно анализирует весь проект и составляет пошаговый план изменений - кодовая база обновляется только после подтверждения разработчиком.
Инструмент поддерживает MCP, параллельную работу нескольких агентов и режим для сред без графической оболочки. Дополнительно в CLI интегрирована Imagine для генерации изображений и видео напрямую из терминала.
xAI в сети Х
Вторая версия модели для генерации музыки получила поддержку перегенерации отдельного фрагмента трека, без изменения всей композиции.
Также добавлена возможность создания сложных вокальных структур, смена музыкального жанра по ходу воспроизведения и интеграция немузыкальных звуковых эффектов.
Модель обучена на лицензированных датасетах, сгенерированные треки разрешены к коммерческому использованию. В ближайшее время доступ к ней откроют через API со сниженной на 50% стоимостью вызовов.
elevenlabs.io
Автоматическая система модерации Google безвозвратно заблокировала аккаунт японского художника Масахиро Итосуги. Он потерял доступ к Gmail, YouTube и всем файлам в Google Drive.
Внутренний ИИ-алгоритм без предупреждения пометил приватные черновики художника в облаке как недопустимый контент. Апелляция на восстановление доступа была отклонена.
От непредсказуемой модерации, основанной на ИИ страдают не только художники, но и технические специалисты. Ранее в IT-сообществе вызвал резонанс случай конца 2025 года, когда разработчик из Греции лишился всех рабочих файлов на облачном диске из-за ошибочных действий Gemini 3 Pro.
Masahiro Itosugi в сети Х
@ai_machinelearning_big_data
#news #ai #ml
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1