Ты научишься делать те, которые живут в проде.
Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:
• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов
Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.
В итоге ты сможешь:
• забирать данные для своих проектов
• автоматизировать чужую рутину
• делать инструменты для аналитики
• брать коммерческие заказы на сбор данных
Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.
🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Закрой базу от интернета - БД не должна слушать 0.0.0.0 без нужды. Открывай доступ только из подсети приложения (VPC, private network).
Используй принцип наименьших прав - отдельный пользователь на каждое приложение, только нужные SELECT/INSERT/UPDATE, без SUPER/OWNER.
Пароли и секреты - длинные, уникальные, храни в Secret Manager/.env вне репозитория, регулярно ротируй.
Шифрование - включи TLS для соединений, шифруй бэкапы и диски (at-rest).
Обновления - патчи БД и ОС ставь регулярно, отключай лишние расширения и фичи.
Защита от SQL-инъекций - только параметризованные запросы, никакой конкатенации строк в SQL.
Логи и аудит - включи логирование входов, ошибок, подозрительных запросов, алерты на “подбор паролей”.
Бэкапы + проверка восстановления - делай бэкапы и обязательно тестируй restore, иначе это не бэкап.
Ограничь опасные команды - запрети DROP/ALTER в проде для app-юзеров, разнеси миграции и рантайм доступ.
Rate limiting и защита периметра - firewall/SG, fail2ban/pgbouncer limits, VPN/bastion для админки.
Postgres hardening (quick example)
ufw allow from 10.0.0.0/8 to any port 5432
psql -c "CREATE ROLE app LOGIN PASSWORD 'STRONG';"
psql -c "REVOKE ALL ON DATABASE prod FROM PUBLIC;"
psql -c "GRANT CONNECT ON DATABASE prod TO app;"
psql -c "ALTER SYSTEM SET ssl=on;"
psql -c "ALTER SYSTEM SET log_connections=on;"
psql -c "ALTER SYSTEM SET password_encryption='scram-sha-256';"
systemctl reload postgresql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4🔥4
Как PostgreSQL обрабатывает конфликт при одновременном обновлении одной строки в разных транзакциях с уровнем изоляции READ COMMITTED?
Anonymous Quiz
11%
A) Обе транзакции выполняются без конфликтов
60%
B) Вторая транзакция блокируется до завершения первой
11%
C) Вторая транзакция получает ошибку serialization_failure
18%
D) Последняя транзакция перезаписывает данные без ошибок
🔥10❤4👍4
🚀 MongoDB Memory Leak Exploit (CVE-2025-14847)
Прототип эксплойта для уязвимости в MongoDB, позволяющий неаутентифицированным злоумышленникам утекать конфиденциальную память сервера. Уязвимость связана с некорректной обработкой длины данных при декомпрессии, что приводит к утечке неинициализированной памяти.
🚀 Основные моменты:
- Позволяет утекать данные из памяти MongoDB.
- Использует уязвимость zlib для создания поддельных BSON документов.
- Может раскрывать внутренние логи и конфигурацию MongoDB.
- Включает Docker Compose для тестирования уязвимости.
📌 GitHub: https://github.com/joe-desimone/mongobleed
Прототип эксплойта для уязвимости в MongoDB, позволяющий неаутентифицированным злоумышленникам утекать конфиденциальную память сервера. Уязвимость связана с некорректной обработкой длины данных при декомпрессии, что приводит к утечке неинициализированной памяти.
🚀 Основные моменты:
- Позволяет утекать данные из памяти MongoDB.
- Использует уязвимость zlib для создания поддельных BSON документов.
- Может раскрывать внутренние логи и конфигурацию MongoDB.
- Включает Docker Compose для тестирования уязвимости.
📌 GitHub: https://github.com/joe-desimone/mongobleed
👍5❤3🔥2
Здесь на пальцах объясняют не только как писать SQL-запросы, а строить настоящие backend-сервисы с базой данных как у профи.
В этом курсе ты шаг за шагом создашь REST API на FastAPI + PostgreSQL:
от установки среды и первых таблиц - до масштабируемого приложения с безопасностью и CRUD-операциями.
🔹 На практике разберете:
• SQL-запросы, фильтры, агрегаты и подзапросы
• Связи между таблицами и нормализацию БД
• Взаимодействие Python и PostgreSQL
• Реализацию REST API и подключение базы
• Оптимизацию и разбор реальных задач с собеседований
⚡ После курса у вас будет свой работающий API-проект и реальные навыки работы с PostgreSQL в продакшене.
🎁 Торопись пока действует скидка в честь нвого года!
🚀 Прокачаю свои знания: https://stepik.org/course/255542/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3🥰1
Это полноценный учебник + практика в одном месте.
Что внутри:
- База без воды
SELECT, WHERE, ORDER BY, LIMIT, условия и логика запросов
- Продвинутые темы
агрегатные функции, GROUP BY, HAVING, подзапросы, JOIN’ы
- Много практики
упражнения и задачи, чтобы довести работу с БД до автоматизма
- Подробные объяснения
материал подойдёт даже тем, кто никогда не работал с базами данных
Почему это полезно:
SQL — один из самых универсальных навыков в IT.
Он нужен разработчикам, аналитикам, data-инженерам и всем, кто работает с данными.
Этот репозиторий даёт именно то, что нужно для реальной работы:
- понимание, как устроены запросы
- уверенную работу с данными
- базу для перехода к аналитике или backend-разработке
GitHub: https://github.com/dwyl/learn-postgresql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤4👎3🥰1
Мошенники использовали данные ФССП для незаконного взыскания долга: разбор схемы🧐
Специалисты вскрыли изощренную схему, где преступники, используя технологии социальной инженерии, представились судебными приставами.
Цель — запугать жертву и вынудить к «срочному» платежу.
В ходе расследования был детально разобран случай, когда сотрудник компании-клиента получил SMS от «пристава» с угрозой немедленного ареста имущества за долг родственницы.
Злоумышленники, владея информацией о реальных сотрудниках ФССП и процедурах, создали психологическое давление. Жертве передавалась ссылка на оплату, ведущая на поддомен сайта МФО.
Эксперты Securizor провели цифровую верификацию, оперативно выявили предлог совместно с настоящими приставами и установили связь мошенников с коллекторами.
Данный кейс — не просто история о мошенничестве. Он демонстрирует важность социальной инженерии как инструмента кибератаки и необходимость проактивного аудита информационной безопасности для сотрудников.
❗️Читайте полный разбор расследования по ссылке
Реклама. ООО "Секьюризор", ОРГН 1247700543694
Erid: 2W5zFFzBkTs
Специалисты вскрыли изощренную схему, где преступники, используя технологии социальной инженерии, представились судебными приставами.
Цель — запугать жертву и вынудить к «срочному» платежу.
В ходе расследования был детально разобран случай, когда сотрудник компании-клиента получил SMS от «пристава» с угрозой немедленного ареста имущества за долг родственницы.
Злоумышленники, владея информацией о реальных сотрудниках ФССП и процедурах, создали психологическое давление. Жертве передавалась ссылка на оплату, ведущая на поддомен сайта МФО.
Эксперты Securizor провели цифровую верификацию, оперативно выявили предлог совместно с настоящими приставами и установили связь мошенников с коллекторами.
Данный кейс — не просто история о мошенничестве. Он демонстрирует важность социальной инженерии как инструмента кибератаки и необходимость проактивного аудита информационной безопасности для сотрудников.
❗️Читайте полный разбор расследования по ссылке
Реклама. ООО "Секьюризор", ОРГН 1247700543694
Erid: 2W5zFFzBkTs
👎3❤1😁1
Postgres: best practices для AI-агентов (и почему это важно)
Supabase выпустили Postgres Best Practices - набор правил/“скиллов” для AI coding agents (Claude Code, Cursor, Copilot и т.д.), чтобы они писали не просто рабочий SQL, а нормальный продовый Postgres.
Потому что классическая проблема такая:
агент сгенерит “правильный” запрос, тесты пройдут,
а через 2 недели это превратится в:
- медленные JOIN’ы
- seq scan на миллионы строк
- взрыв коннектов
- блокировки
- RLS, которая внезапно тормозит всё
Что внутри “Postgres Best Practices”
Это структурированный набор правил по 8 темам (от самых критичных к менее критичным):
- Query Performance (Critical) - как писать запросы, чтобы не убивать базу
- Connection Management (Critical) - пулы, лимиты, правильная работа с коннектами
- Schema Design (High) - индексы, типы, ключи, нормальные схемы
- Concurrency & Locking (Medium-High) - как не словить дедлоки и долгие locks
- Security & RLS (Medium-High) - RLS без боли и сюрпризов
- Data Access Patterns (Medium) - как правильно читать/писать данные в приложении
- Monitoring & Diagnostics (Low-Medium) - что мониторить и как дебажить
- Advanced Features (Low) - продвинутые приёмы
Самое полезное:
это не “статья”, а готовый набор инструкций, который агент может автоматически применять, когда он:
- пишет SQL
- проектирует схему
- предлагает индексы
- оптимизирует запросы
- настраивает RLS / connection pooling
То есть агент начинает думать ближе к DBA, а не как генератор SQL.
https://supabase.com/blog/postgres-best-practices-for-ai-agents
Supabase выпустили Postgres Best Practices - набор правил/“скиллов” для AI coding agents (Claude Code, Cursor, Copilot и т.д.), чтобы они писали не просто рабочий SQL, а нормальный продовый Postgres.
Потому что классическая проблема такая:
агент сгенерит “правильный” запрос, тесты пройдут,
а через 2 недели это превратится в:
- медленные JOIN’ы
- seq scan на миллионы строк
- взрыв коннектов
- блокировки
- RLS, которая внезапно тормозит всё
Что внутри “Postgres Best Practices”
Это структурированный набор правил по 8 темам (от самых критичных к менее критичным):
- Query Performance (Critical) - как писать запросы, чтобы не убивать базу
- Connection Management (Critical) - пулы, лимиты, правильная работа с коннектами
- Schema Design (High) - индексы, типы, ключи, нормальные схемы
- Concurrency & Locking (Medium-High) - как не словить дедлоки и долгие locks
- Security & RLS (Medium-High) - RLS без боли и сюрпризов
- Data Access Patterns (Medium) - как правильно читать/писать данные в приложении
- Monitoring & Diagnostics (Low-Medium) - что мониторить и как дебажить
- Advanced Features (Low) - продвинутые приёмы
Самое полезное:
это не “статья”, а готовый набор инструкций, который агент может автоматически применять, когда он:
- пишет SQL
- проектирует схему
- предлагает индексы
- оптимизирует запросы
- настраивает RLS / connection pooling
То есть агент начинает думать ближе к DBA, а не как генератор SQL.
https://supabase.com/blog/postgres-best-practices-for-ai-agents
🔥5❤3🥰1
Forwarded from Machinelearning
Alibaba открыла исходный код Zvec - встраиваемой векторной СУБД, которую авторы называют «SQLite для векторных баз данных».
Проект заточен на локальные RAG-пайплайны, семантический поиск и агентские сценарии на ноутбуках, мобильных устройствах или другом edge-железе.
Идея в том, что разворачивать отдельный сервер ради векторного поиска и фильтрации по метаданным избыточно. Zvec встраивается в процесс Python-приложения и не требует ни отдельного демона, ни сетевых вызовов.
Существующие решения не подходят для маломощных устройств: Faiss дает только ANN-индекс без скалярного хранилища и крэш-рекавери; DuckDB-VSS ограничен в опциях индексирования; Milvus и облачные векторные хранилища требуют сеть.
Под капотом - Proxima, векторный движок продакшен-уровня, который Alibaba сама использует в собственных сервисах. Поверх него сделали лаконичный Python API:
Это позволяет собирать локальных ассистентов, которые одновременно используют семантический поиск, множественную фильтрацию и несколько эмбеддинг-моделей - все в одном движке.
По производительности Zvec заявляет победу на бенче VectorDBBench с датасетом Cohere 10M - более 8 000 QPS при сопоставимом реколле. Это вдвое больше, чем у лидера ZillizCloud и с более быстрым построением индекса.
Авторы объясняют успех глубокой оптимизацией под CPU: SIMD, кэш-эффективные структуры, многопоточность и prefetching.
Пока платформенная поддержка ограничена
@ai_machinelearning_big_data
#AI #ML #VDB #ZVEC #Alibaba
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍2🔥2
Да - и это начинает менять то, как мы работаем с данными.
Идея простая, но мощная: большие языковые модели могут переводить натуральный язык и выражения из Polars DataFrame API в эквивалентный SQL. Это мост между Python-подходом к анализу данных и миром аналитических баз.
Что это даёт на практике:
Пишешь трансформации в стиле Polars - быстро, in-memory, удобно для Python-разработчика
LLM превращает логику в SQL - можно запускать в DWH, BI-системах, дата-платформах
Не нужно вручную переписывать логику из DataFrame-цепочек в SELECT, JOIN, GROUP BY
Особенно полезно, когда:
прототип делается локально в Polars, а прод работает на SQL-движке
аналитики думают SQL, а инженеры - DataFrame API
нужно быстро объяснить, что делает код, в виде SQL-запроса
Комбинация Polars (скорость и удобство in-memory) + LLM (понимание семантики кода) позволяет использовать знакомые SQL-паттерны, даже если ты изначально не писал сырой SQL.
Это не просто перевод синтаксиса. Модель восстанавливает семантику трансформаций - фильтры, агрегации, группировки, оконные операции - и выражает их в терминах SQL.
По сути LLM становится слоем совместимости между DataFrame-мышлением и SQL-мышлением. И это серьёзный сдвиг для аналитических пайплайнов.
https://labs.quansight.org/blog/llm_polars_to_sql
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Последний шанс подать доклад на PGConf.Russia 2026
Прием заявок закрывается уже сегодня!
Если хотите выступить на PGConf.Russia 2026 — присылайте тему и тезисы: программный комитет рассмотрит заявку, свяжется с вами и поможет подготовиться.
🐘 PGConf.Russia 2026 — крупнейшая российская конференция по PostgreSQL и решениям на ее основе, главная встреча сообщества в России.
📍 23-24 марта, онлайн и офлайн в Москве: обсудим новые фичи СУБД, обменяемся практикой, идеями и опытом эксплуатации. Будут доклады ведущих российских специалистов, практические мастер-классы и демо-стенды разработчиков Postgres Pro.
Будет более 40 докладов на разные темы:
✔️ Новости PostgreSQL
✔️ Оптимизация запросов, мониторинг, отказоустойчивость и безопасность
✔️ Облегченная миграция с Oracle, Microsoft SQL Server и других систем
✔️ Искусственный интеллект в СУБД
✔️ Масштабируемость, шардирование и секционирование
✔️ Совместимость PostgreSQL с другим ПО
✔️ И другие темы
Подайте доклад до 16 февраля: поделитесь опытом и сделайте вклад в сообщество.
Если не планируете выступать, а хотите прийти послушать — регистрируйтесь до 28 февраля со скидкой 15%.
Реклама ООО «ППГ» Инн: 7707083893 Erid: 2Vtzqw9iCtU
Прием заявок закрывается уже сегодня!
Если хотите выступить на PGConf.Russia 2026 — присылайте тему и тезисы: программный комитет рассмотрит заявку, свяжется с вами и поможет подготовиться.
Будет более 40 докладов на разные темы:
Подайте доклад до 16 февраля: поделитесь опытом и сделайте вклад в сообщество.
Если не планируете выступать, а хотите прийти послушать — регистрируйтесь до 28 февраля со скидкой 15%.
Реклама ООО «ППГ» Инн: 7707083893 Erid: 2Vtzqw9iCtU
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Как PostgreSQL обрабатывает CHECK ограничения при массовой вставке с COPY?
Anonymous Quiz
13%
A) Все проверки выполняются сразу после вставки
19%
B) Проверки игнорируются при использовании COPY
41%
C) Проверки выполняются построчно во время вставки
27%
D) Проверки выполняются после вставки каждой партии
👍5🔥2
🌟 Топ-10 open-source AI-моделей на февраль 2026.
Открытые модели больше не «облегчённая версия».
Сегодня многие из них уже конкурируют с коммерческими решениями и подходят для реальных продуктов, агентов и локального запуска.
Вот модели, на которые стоит обратить внимание:
1. GLM-5 — автономная разработка и создание приложений
https://github.com/THUDM/GLM-5
2. MiniMax M2.5 — мощная модель для кодинга (80%+ на SWE-bench)
https://github.com/MiniMax-AI
3. Kimi K2.5 — мультимодальность, код и продвинутое reasoning
https://github.com/MoonshotAI
4. DeepSeek V3.2 — эффективная sparse-архитектура, конкурент GPT-уровня
https://github.com/deepseek-ai
5. Qwen 3 — сильная логика и отличная поддержка множества языков
https://github.com/QwenLM
6. MiMo V2 Flash — высокая эффективность и низкая стоимость инференса
https://github.com/MiMo-AI
7. Mistral Large 3 — большой контекст и удобная коммерческая лицензия
https://github.com/mistralai
8. LongCat Flash Chat — для сверхдлинных диалогов и памяти контекста
https://github.com/LongCatAI
9. Gemma 3 — открытая модель от Google с хорошим качеством диалогов
https://github.com/google/gemma
10. INTELLECT-3 — полностью открытый стек обучения модели
https://github.com/IntellectAI
Почему это важно:
- open-weights ≈ уровень топ-моделей
- можно запускать локально
- полный контроль над данными
- база для своих AI-агентов и продуктов
- экономия на API при масштабировании
Открытые модели больше не «облегчённая версия».
Сегодня многие из них уже конкурируют с коммерческими решениями и подходят для реальных продуктов, агентов и локального запуска.
Вот модели, на которые стоит обратить внимание:
1. GLM-5 — автономная разработка и создание приложений
https://github.com/THUDM/GLM-5
2. MiniMax M2.5 — мощная модель для кодинга (80%+ на SWE-bench)
https://github.com/MiniMax-AI
3. Kimi K2.5 — мультимодальность, код и продвинутое reasoning
https://github.com/MoonshotAI
4. DeepSeek V3.2 — эффективная sparse-архитектура, конкурент GPT-уровня
https://github.com/deepseek-ai
5. Qwen 3 — сильная логика и отличная поддержка множества языков
https://github.com/QwenLM
6. MiMo V2 Flash — высокая эффективность и низкая стоимость инференса
https://github.com/MiMo-AI
7. Mistral Large 3 — большой контекст и удобная коммерческая лицензия
https://github.com/mistralai
8. LongCat Flash Chat — для сверхдлинных диалогов и памяти контекста
https://github.com/LongCatAI
9. Gemma 3 — открытая модель от Google с хорошим качеством диалогов
https://github.com/google/gemma
10. INTELLECT-3 — полностью открытый стек обучения модели
https://github.com/IntellectAI
Почему это важно:
- open-weights ≈ уровень топ-моделей
- можно запускать локально
- полный контроль над данными
- база для своих AI-агентов и продуктов
- экономия на API при масштабировании
🔥6👍4❤3
This media is not supported in your browser
VIEW IN TELEGRAM
Oracle на самом деле ушел из России? И может ли PostgreSQL заменить его в корпоративных системах? Обсуждаем в первом выпуске подкаста «Слон в IT-лавке» с генеральным директором Postgres Professional Иваном Панченко и Марком Ривкиным.
Марк много лет работал в Oracle и был одним из авторов внутреннего документа «Почему PostgreSQL никогда не заменит Oracle». Сейчас он руководит отделом технического консалтинга Postgres Professional.
Postgres Professional — российская компания-разработчик СУБД Postgres Pro и решений на базе PostgreSQL для бизнеса и государства.
В подкасте:
Разберем, что изменилось после ухода Oracle: офис, техподдержка и облачные сервисы, и почему Oracle как СУБД продолжает жить в ряде компаний.
Обсудим, когда PostgreSQL и Postgres Pro могут заменить Oracle, а когда все упирается в масштаб, архитектуру и требования к системе.
Поговорим про зависимость от Oracle и про переход на PostgreSQL и Postgres Pro. Коротко пройдемся по этапам миграции и местам, где чаще всего возникают сложности.
За час узнаете, что именно Oracle обрубил в России, где он все еще незаменим и почему. И услышите взгляд человека, который много лет продвигал Oracle, а теперь помогает компаниям переходить на Postgres Pro.
Смотрите подкаст на VK Видео.
Реклама ООО «ППГ» Инн: 7707083893 Erid: 2VtzqvsViVa
Марк много лет работал в Oracle и был одним из авторов внутреннего документа «Почему PostgreSQL никогда не заменит Oracle». Сейчас он руководит отделом технического консалтинга Postgres Professional.
Postgres Professional — российская компания-разработчик СУБД Postgres Pro и решений на базе PostgreSQL для бизнеса и государства.
В подкасте:
Разберем, что изменилось после ухода Oracle: офис, техподдержка и облачные сервисы, и почему Oracle как СУБД продолжает жить в ряде компаний.
Обсудим, когда PostgreSQL и Postgres Pro могут заменить Oracle, а когда все упирается в масштаб, архитектуру и требования к системе.
Поговорим про зависимость от Oracle и про переход на PostgreSQL и Postgres Pro. Коротко пройдемся по этапам миграции и местам, где чаще всего возникают сложности.
За час узнаете, что именно Oracle обрубил в России, где он все еще незаменим и почему. И услышите взгляд человека, который много лет продвигал Oracle, а теперь помогает компаниям переходить на Postgres Pro.
Смотрите подкаст на VK Видео.
Реклама ООО «ППГ» Инн: 7707083893 Erid: 2VtzqvsViVa
❤1
⚡ Anthropic выложили 6 полноценных курсов по ИИ - бесплатно.
По уровню это легко заменяет обучение на десятки или даже сотни тысяч рублей.
Внутри:
- сотни уроков и практики
- интерактивные задания и квизы
- реальные кейсы работы с Claude
- сертификаты после прохождения
Если работаешь с AI, агентами или API - это база, которую сейчас проходят разработчики в топ-компаниях.
Что можно изучить:
• Работа с Claude API
https://anthropic.skilljar.com/claude-with-the-anthropic-api
• Введение в Model Context Protocol (MCP)
https://anthropic.skilljar.com/introduction-to-model-context-protocol
• Claude в Amazon Bedrock
https://anthropic.skilljar.com/claude-in-amazon-bedrock
• Claude в Google Cloud (Vertex AI)
https://anthropic.skilljar.com/claude-with-google-vertex
• Продвинутый MCP
https://anthropic.skilljar.com/model-context-protocol-advanced-topics
• Claude Code на практике
https://anthropic.skilljar.com/claude-code-in-action
Это не «обзорные лекции».
Это реальные навыки для тех, кто хочет строить AI-продукты, агентов и автоматизацию.
По уровню это легко заменяет обучение на десятки или даже сотни тысяч рублей.
Внутри:
- сотни уроков и практики
- интерактивные задания и квизы
- реальные кейсы работы с Claude
- сертификаты после прохождения
Если работаешь с AI, агентами или API - это база, которую сейчас проходят разработчики в топ-компаниях.
Что можно изучить:
• Работа с Claude API
https://anthropic.skilljar.com/claude-with-the-anthropic-api
• Введение в Model Context Protocol (MCP)
https://anthropic.skilljar.com/introduction-to-model-context-protocol
• Claude в Amazon Bedrock
https://anthropic.skilljar.com/claude-in-amazon-bedrock
• Claude в Google Cloud (Vertex AI)
https://anthropic.skilljar.com/claude-with-google-vertex
• Продвинутый MCP
https://anthropic.skilljar.com/model-context-protocol-advanced-topics
• Claude Code на практике
https://anthropic.skilljar.com/claude-code-in-action
Это не «обзорные лекции».
Это реальные навыки для тех, кто хочет строить AI-продукты, агентов и автоматизацию.
👍12❤4🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
Самый полезный апгрейд, который реально экономит часы: не "оптимизировать запрос на глаз", а заставить базу самой показать, что она делает.
На больших таблицах скорость почти всегда решают 3 вещи: правильный индекс, правильная форма запроса и правильный JOIN-порядок.
Железное правило: прежде чем трогать код, запускают EXPLAIN ANALYZE и смотрят две красные зоны - Seq Scan на большой таблице и огромные строки после JOIN. Если видишь Seq Scan - значит фильтр не поддержан индексом или условие написано так, что индекс не используется. Если после JOIN получаются миллионы строк - значит нужно сначала отфильтровать и/или агрегировать, а потом соединять.
Самый мощный прием для больших таблиц: сначала выбрать маленький набор ключей (CTE или подзапрос), и только потом JOIN к тяжелой таблице. Это резко уменьшает работу базы, потому что она перестает "перемножать" всё со всем.
ПЛОХО: тяжелый JOIN сразу, база тащит миллионы строк
SELECT u.id, COUNT(e.*) AS events_30d
FROM users u
JOIN events e ON e.user_id = u.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
AND u.country = 'TH'
GROUP BY u.id;
-- ХОРОШО: сначала сузить пользователей до маленького набора, потом JOIN
WITH target_users AS (
SELECT id
FROM users
WHERE country = 'TH'
)
SELECT tu.id, COUNT(*) AS events_30d
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;
-- Индексы, которые реально помогают этому паттерну
CREATE INDEX IF NOT EXISTS idx_users_country_id ON users (country, id);
CREATE INDEX IF NOT EXISTS idx_events_user_time ON events (user_id, created_at);
-- Всегда проверяй, что база использует индекс, а не Seq Scan
EXPLAIN (ANALYZE, BUFFERS)
WITH target_users AS (
SELECT id FROM users WHERE country = 'TH'
)
SELECT tu.id, COUNT(*)
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13🔥5👍3😁2
This media is not supported in your browser
VIEW IN TELEGRAM
📌 UI-TARS-desktop — открытое приложение-агент с GUI, которое превращает ваш компьютер в **интерактивного AI-ассистента** с визуальным восприятием и управлением интерфейсом.
Что это и зачем:
🤖 AI-агент, который видит и кликает
Проект основан на модели UI-TARS (User Interface — Task Automation & Reasoning System). Агент реально *видит экран*, распознаёт элементы интерфейса и может управлять мышью, клавиатурой и браузером по простым естественным командам.
🖥️ Контроль компьютера на естественном языке
Вместо интеграций через API вы пишете команды, а модель сама ищет кнопки, поля ввода и прочие UI-элементы, затем *выполняет действия*. Это работает с приложениями, браузером и элементами рабочего стола.
⚙️ Open-source и кросс-платформа
Проект распространяется под Apache-лицензией, есть релизы, активная история версий и документация для запуска на Windows и macOS. :
📦 Цели проекта
UI-TARS-desktop — это не просто демонстрация: это полноценный мультимодальный AI-агентный стек, который можно использовать для автоматизации повседневных задач без ручного вмешательства.
Страница репозитория: github.com/bytedance/UI-TARS-desktop
Что это и зачем:
🤖 AI-агент, который видит и кликает
Проект основан на модели UI-TARS (User Interface — Task Automation & Reasoning System). Агент реально *видит экран*, распознаёт элементы интерфейса и может управлять мышью, клавиатурой и браузером по простым естественным командам.
🖥️ Контроль компьютера на естественном языке
Вместо интеграций через API вы пишете команды, а модель сама ищет кнопки, поля ввода и прочие UI-элементы, затем *выполняет действия*. Это работает с приложениями, браузером и элементами рабочего стола.
⚙️ Open-source и кросс-платформа
Проект распространяется под Apache-лицензией, есть релизы, активная история версий и документация для запуска на Windows и macOS. :
📦 Цели проекта
UI-TARS-desktop — это не просто демонстрация: это полноценный мультимодальный AI-агентный стек, который можно использовать для автоматизации повседневных задач без ручного вмешательства.
Страница репозитория: github.com/bytedance/UI-TARS-desktop
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
📌 EXISTS РАБОТАЕТ БЫСТРЕЕ COUNT
SQL-совет: перестаньте считать всё через COUNT(*)
Многие пишут так:
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;
Чтобы проверить — есть ли записи.
Проблема:
COUNT(*) считает все строки, даже если нужна просто проверка существования.
На больших таблицах это лишняя нагрузка и медленный запрос.
Правильнее использовать EXISTS.
Почему это лучше:
- База останавливается на первой найденной строке
- Меньше чтения данных
- Быстрее на больших таблицах
- Использует индексы эффективнее
Пример:
SQL-совет: перестаньте считать всё через COUNT(*)
Многие пишут так:
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;
Чтобы проверить — есть ли записи.
Проблема:
COUNT(*) считает все строки, даже если нужна просто проверка существования.
На больших таблицах это лишняя нагрузка и медленный запрос.
Правильнее использовать EXISTS.
Почему это лучше:
- База останавливается на первой найденной строке
- Меньше чтения данных
- Быстрее на больших таблицах
- Использует индексы эффективнее
Пример:
-- Плохо
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;
-- Хорошо
SELECT EXISTS (
SELECT 1
FROM orders
WHERE user_id = 123
);
-- Или в условии
SELECT *
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
);
🔥19👍9❤3👎1😱1
В Python 3.14 появилось решение, которое помогает избавиться от SQL-инъекций - t-strings 🔒
Проблема
Когда вы используете f-strings для SQL:
пользовательский ввод напрямую попадает в запрос.
Если злоумышленник передаст:
— база выполнит вредоносную команду.
Это классическая SQL injection.
Почему это неудобно сейчас
Безопасный способ — параметризованные запросы:
Но приходится:
• запускать шаблон отдельно
• передавать значения отдельно
• поддерживать две структуры
Что изменилось в Python 3.14
Появились template string literals (t-strings).
В отличие от f-strings, они:
• не возвращают готовую строку
• возвращают объект Template
• отдельно хранят текст и подставленные значения
Пример:
Теперь можно:
• получить все интерполяции
• проверить значения
• экранировать или валидировать их
• и только потом собрать финальный SQL
Результат:
• вредоносный ввод очищается
• SQL-инъекции блокируются
• таблицы остаются на месте
Почему это важно
f-strings - быстрые, но опасные для SQL.
t-strings позволяют сохранить удобство шаблонов и добавить контроль безопасности.
Python движется к безопасным шаблонам по умолчанию, меньше ручной защиты, меньше уязвимостей в продакшене.
Проблема
Когда вы используете f-strings для SQL:
query = f"SELECT * FROM users WHERE name = '{user_input}'"
пользовательский ввод напрямую попадает в запрос.
Если злоумышленник передаст:
admin'; DROP TABLE users; --
— база выполнит вредоносную команду.
Это классическая SQL injection.
Почему это неудобно сейчас
Безопасный способ — параметризованные запросы:
cursor.execute(
"SELECT * FROM users WHERE name = %s",
(user_input,)
)
Но приходится:
• запускать шаблон отдельно
• передавать значения отдельно
• поддерживать две структуры
Что изменилось в Python 3.14
Появились template string literals (t-strings).
В отличие от f-strings, они:
• не возвращают готовую строку
• возвращают объект Template
• отдельно хранят текст и подставленные значения
Пример:
query = t"SELECT * FROM users WHERE name = {user_input}"
Теперь можно:
• получить все интерполяции
• проверить значения
• экранировать или валидировать их
• и только потом собрать финальный SQL
safe = safe_sql(query)
Результат:
• вредоносный ввод очищается
• SQL-инъекции блокируются
• таблицы остаются на месте
Почему это важно
f-strings - быстрые, но опасные для SQL.
t-strings позволяют сохранить удобство шаблонов и добавить контроль безопасности.
Python движется к безопасным шаблонам по умолчанию, меньше ручной защиты, меньше уязвимостей в продакшене.
🔥15👍4❤1