Обновить
1024K+

Программирование *

Искусство создания компьютерных программ

1 129,16
Рейтинг
Сначала показывать
Порог рейтинга

Как управлять окружениями — venv / pip vs pipenv vs poetry?

Привет, Хабр! Продолжаем нашу рубрику с быстрыми ответами на некоторые часто встречающиеся вопросы. Сегодня разберем такую проблему: проекты постоянно ломаются из-за конфликтов зависимостей. Что выбрать для новых проектов и как сделать так, чтобы код работал одинаково, в том числе в CI?

Обычно начало всех проблем — смешение глобальных и локальных пакетов или отсутствие фиксированных версий библиотек. Главный совет: у каждого проекта должно быть собственное окружение с явно указанными зависимостями и сохраненным lock‑файлом в репозитории.

Если говорить о базе, то это связка venv и pip. Плюс она встроена в сам Python. Вы вручную создаете окружение, устанавливаете нужные пакеты и фиксируете их в requirements.txt. 

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

Сейчас это, пожалуй, наиболее сбалансированное решение: он создает и управляет окружениями, отслеживает версии, собирает wheel‑пакеты и умеет публиковать их в PyPI. Lock‑файл (poetry.lock) обеспечивает воспроизводимость сборок, а сам формат pyproject.toml — это стандарт. В итоге вы получаете чистое окружение, детерминированные зависимости и понятное поведение CI.

Вот пример рабочего цикла:

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install poetry
poetry install
poetry run pytest

В CI чаще используют схему с экспортом зависимостей:

poetry export -f requirements.txt --without-hashes -o reqs.txt
pip install -r reqs.txt
pytest

Отдельно стоит упомянуть uv — относительно новый инструмент, созданный командой Astral (авторы Ruff). Он написан на Rust и совместим с Python. По сути, это те же функции pip, venv и частично poetry, но быстрее. От Poetry он отличается отсутствием публикации пакетов, но при этом умеет сам устанавливать и менять версии Python через .python-version

UV работает с pyproject.toml и имеет собственный uv.lock. Может использоваться вместе с Poetry, но лучше создавать единый uv.lock для строгой воспроизводимости. Для CI это удобно, вы пишите:

pip install uv

Далее есть два варианта:

  • uv venv — создает виртуальное окружение. Это аналог python3.13 -m venv .venv, но работает быстрее и с автоустановкой версии Python.

  • uv init — помимо .venv, добавляет шаблон проекта с pyproject.toml для зависимостей, Git-репозиторий и базовые файлы. Идеально для нового проекта.

И окружение в CI полностью совпадает с локальным, а билд воспроизводится без сюрпризов. Но чаще всего комбинируют два решения: Poetry для разработки и uv — для быстрых сборок и деплоймента.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Теги:
+8
Комментарии0

Что изучить на неделе: 23 бесплатных урока по разработке, ИИ и инфраструктуре

С 20 по 23 июля пройдут открытые уроки по разработке, тестированию, архитектуре, сетям, управлению и работе с ИИ. На них можно разобрать конкретную тему с практикующим экспертом, задать вопросы и закрыть отдельные пробелы в знаниях.

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

ИИ и машинное обучение

  • 20 июля, 20:00. «ИИ для продуктового discovery: как анализировать рынок, конкурентов и пользователей быстрее». Записаться

  • 21 июля, 20:00. «Алгоритм DQN — учим нейросеть принимать решение без помощи человека». Записаться

  • 21 июля, 20:00. «Разработка ИИ‑приложений с Claude Code». Записаться

  • 21 июля, 20:00. «Выбор между Serverless и Kubernetes для AI‑ворклоадов: как определить оптимальную платформу под задачу». Записаться

  • 22 июля, 20:00. «Что надо знать про работу LLM‑моделей». Записаться

  • 22 июля, 20:00. «От рутины к влиянию: как HR использовать ИИ в ежедневной работе». Записаться

  • 23 июля, 20:00. «Когнитивные архитектуры: ReAct, Reflection и RAG». Записаться

Разработка и архитектура

  • 20 июля, 20:00. «Асинхронное программирование в Android». Записаться

  • 20 июля, 20:00. «Как перестать писать на Java внутри Go‑проекта». Записаться

  • 21 июля, 20:00. «Данные в TOGAF. Где скрыты? Разбираемся в деталях». Записаться

  • 22 июля, 20:00. «Архитектура программ на C++: как управлять разработкой и функциями приложения». Записаться

  • 22 июля, 20:00. «DAO на Spring JDBC». Записаться

  • 23 июля, 20:00. «Основы многопоточности в Java». Записаться

  • 23 июля, 20:00. «malloc — кто же ты на самом деле?». Записаться

Тестирование и безопасность

  • 21 июля, 19:00. «Оценка трудозатрат в QA: как перестать ошибаться в сроках». Записаться

  • 21 июля, 20:00. «UI‑ и API‑тестирование с Java и Playwright». Записаться

  • 23 июля, 20:00. «Тестирование интернет‑магазина: от каталога до оплаты». Записаться

  • 23 июля, 20:00. «Фаззинг и реверс: как понять, что делает программа, и найти в ней ошибки». Записаться

Инфраструктура и сети

  • 20 июля, 20:00. «Проектирование адресного пространства. Основы сетей ЦОД». Записаться

  • 22 июля, 20:00. «VLAN на пальцах: изоляция трафика и маршрутизация». Записаться

Управление продуктами и командами

  • 22 июля, 20:00. «Как CTO управляет неопределённостью: оценки, планы и ожидания бизнеса». Записаться

  • 22 июля, 20:00. «Как собрать полный CJM — карту клиентского пути». Записаться

  • 22 июля, 20:00. «Операция "Воркшоп": как получить поддержку руководства для новой инициативы». Записаться

Больше открытых уроков июля смотрите в дайджесте.

Теги:
+9
Комментарии0

Как настроить TLS в клиенте Python при HTTPS-запросах?

Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.

После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).

import ssl
import httpx

ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')

with httpx.Client(verify=ctx, timeout=10.0) as client:
    r = client.get('https://api.example.com')
    r.raise_for_status()
    print(r.status_code)

В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.

Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Теги:
+7
Комментарии0

Участвуй в МТС True Tech Champ 2026 — всероссийском чемпионате по программированию с призовым фондом 10 250 000 рублей 🔥

Выбирай, какой трек тебе интереснее 👇

  • Алгоритмический (индивидуальный зачет, 2 750 000 ₽). Решай задачи по алгоритмам и структурам данных, которые помогут прокачать навыки для технических собеседований и работы в ведущих ИТ-командах. Лучшие участники пройдут в финал, где в режиме реального времени будут соревноваться в правильности решений и скорости мышления.

  • Программирование роботов (командный формат, 7 500 000 ₽). Напиши алгоритмы для робособаки и робота-манипулятора и проведи их через три этапа соревнований. Сначала — через цифровой симулятор, где нужно пройти трассу и выполнить задания по передаче предметов. Затем — подключись к реальному полигону через удаленный доступ и выполни задания на физических роботах дистанционно. А в очном финале лучшим командам предстоит управлять роботами на площадке, дорабатывать алгоритмы под новые условия и бороться за победу на глазах у зрителей.

Шоу-финал с кодерскими челленджами и выступлениями спикеров состоится 22 октября в МТС Live Холл. А лучшие участники получат шанс на стажировку в MTC Web Services (MWS).

Так после МТС True Tech Hack 2026 к команде присоединились три стажера:

1. Илья Матвеев из команды MCLover, 18 лет, студент 1-го курса бакалавриата Института интеллектуальных кибернетических систем (НИЯУ МИФИ). Вышел на позицию стажера frontend-разработчика в MWS Octapi.

2. Роман Субботин из команды DEP_IT_MISIS, 19 лет, студент 2-го курса бакалавриата НИТУ МИСИС по направлению «Прикладная математика» в институте компьютерных наук. Вышел на позицию стажера Python-разработчика в MWS Octapi.

3. Кирилл Ефимович из команды Моторный шуруповерт, 20 лет, студент третьего курса бакалавриата направления «Разработка ПО», Университет Иннополис, GPA: 4.6. Вышел на позицию стажера DevOps в MWS Tables.

➡️ Зарегистрируйся и стань участником масштабного ИТ-чемпионата.

Теги:
+4
Комментарии0

Давненько ничего не писал здесь. В свободное время засел за работу, которую хотел взять в качестве дипломной, но не взял, так как тогда не был уверен в собственных силах. Если кратко, что здесь происходит: я нахожу на лице модели белые маркеры (свзяка из LoG-фильтра и поиска локальных экстремумов методом Китчена-Розенфельда) и пытаюсь отследить их движение в кадре (венгерский алгоритм, он же метод Куна-Манкерса в связке с фильтром Калмана). Модель отслеживания обладает инерцией (в реальности маркер не может телепортироваться и двигается согласно законам реального мира) - требуется стабилизация первые несколько кадров, есть запаздывание и возможна путаница, если движения напоминают конвульсии :) В остальном результат достаточно стабилен. Я хочу прикрутить к получившемуся Proof of Concept графический интерфейс, оптимизировать код (в черновом варианте я создаю кучу лишних объектов, что приводит к частой сборке мусора) и использовать записи с нескольких камер для восстановления положения маркеров в пространстве. Полученные данные в свою очередь можно отправить в любимый графический пакет. Это конечно не коммерческое решение для захвата движений уровня Vicon Nexus, скорее забавный велосипед, но всё же. Ждите эпичного результата и подробной статьи.

Теги:
+4
Комментарии1

Корпорация ценой в три триллиона силами целой армии разработчиков выпустила свою фирменную IDE (Visual Studio 2026) после четырёх лет упорной разработки (предыдущая Visual Studio была 2022):

«Как, и что-то не готово?!» «Не готово, что ж такого».
«Как, и что-то не готово?!» «Не готово, что ж такого».

В наши дни если ты не успевал к релизу перевести настройки в новый формат, тебя били до тех пор, пока ты не успевал. Теперь в мажорном релизе после многих лет разработки можно просто написать: Лифт не работает, пользуйтесь пожарной лестницей. Кажется, это называется «новая искренность»?

Теги:
+3
Комментарии12

Ошибки, которых не видно в сигнатуре: зачем C++ нужен std::expected

Функция выглядит предсказуемо, пока один из вызовов не бросает исключение, о котором никто не вспомнил. Типы ошибок остаются в документации, управление расползается по try/catch, а изменение глубоко в стеке неожиданно ломает обработку выше.

Недавно в статье разобрали std::expected из C++23: как сделать ошибку частью сигнатуры, собирать цепочки через and_then и transform, разделять типы ошибок между слоями и постепенно внедрять подход в legacy-код. Заодно увидели, где std::expected действительно полезен, а где добавит лишнюю сложность.

16 июля в 20:00 продолжим тему на бесплатном уроке «Выразительный C++: кодируем намерения». На практике разберём, как переносить неявные договорённости в типы, сигнатуры и структуру программы. Присоединяйтесь.

Полный список бесплатных уроков июля смотрите в дайджесте.

Теги:
+8
Комментарии1

Робот Физтеха попытается установить мировой рекорд по сборке мегаминкса

15 июля в Физтехе пройдет официальная попытка установить мировой рекорд по сборке головоломки мегаминкс роботом. Команда лаборатории интеллектуальных технологий робототехники МФТИ готовится к финальной стадии проекта, о котором я писал в начале весны.

Робот-солвер МФТИ для сборки мегаминкса
Робот-солвер МФТИ для сборки мегаминкса

Инженеры физтеха сконструировали робота, способного собирать одну из самых сложных механических головоломок в мире. Пространство состояний додекаэдра под названием "мегаминкс" оценивается примерно в 10⁶⁸, что на порядки превышает сложность классического кубика Рубика. Проект прошел путь от инженерного прототипа до полноценной системы, объединяющей робототехнику и продвинутые алгоритмы поиска на графах состояний.

Что известно о рекорде

По данным разработчиков, текущая версия системы показывает результаты, которые:

  • в 68 раз превосходят предыдущий мировой результат среди роботов, который был установлен роботом Megaminxer Дэвида Гилдея 15 лет назад и составляет 8 минут 4 секунды;

  • примерно вдвое быстрее лучшего результата человека (текущий рекорд принадлежит спидкуберу из Китая Ziyu Wu и составляет 21.04 секунды).

За счет чего достигается скорость

Рекордные показатели планируется обеспечить не только быстрым манипулятором, но и глубокой алгоритмической работой:

  • Оптимизация планирования движений. Робот выполняет вращения независимых граней параллельно, что критично на коротких дистанциях.

  • Сокращение длины решения. Вокруг проекта сформировалось сообщество энтузиастов, которые через open-source проект CayleyPy и соревнования на Kaggle работают над поиском кратчайших путей в графах Кэли. Участники применяют Pattern Databases, алгоритм Корфа, Beam Search и другие методы. За последние недели среднюю длину решений на тестовых выборках удалось уменьшить на 15–20% до ~90 ходов. Лучшие решения сейчас дают порядка 70 ходов (правда считаются долго).

Место встречи

Установление рекорда запланировано на 15 июля, 17:30–21:30 в Физтех.Клубе МФТИ в Долгопрудном.

Кроме того, разработчики расскажут о своих инженерных решениях: кинематика, захват, конструкция манипулятора. А также раскроют алгоритмическую часть: как графы Кэли и методы поиска помогают роботу «думать».

Если хотите стать свидетелями рекорда в стенах МФТИ, то регистрируйтесь по ссылке.

Количество мест, как понимаете, ограничено, поэтому будет организована трансляция на YouTube.

Присоединяйтесь и к группе проекта в Telegram.

 

Теги:
+17
Комментарии0

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

Теги:
+7
Комментарии0

Почему ИИ-агент для кода промахивается мимо нужного метода

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

Агент, который ищет код текстом, физически не отличает OrderService.validate от UserDto.validate: для него это просто совпадение символов «validate». Агент, который спрашивает у IDE «кто на самом деле вызывает этот метод», получает точный ответ, потому что IDE знает типы, разрешённые ссылки и видимость каждого символа. Разница между этими двумя подходами не абстрактная, она измеряется в конкретных цифрах.

Точка отсчёта: почему grep и RAG промахиваются

Кодовый агент ищет по проекту двумя способами: grep/ripgrep по содержимому файлов и векторный поиск по эмбеддингам кусков кода. На маленьком проекте оба варианта работают сносно. На enterprise-репозитории на миллионы строк с десятками модулей поведение ломается одинаково: запрос «найди использования метода validate» возвращает тысячу с лишним совпадений, из которых подавляющее большинство - другие методы с тем же именем в других классах. Векторный поиск находит куски кода, которые «похожи по смыслу», но это может быть валидация в совершенно другом домене.

Что показали цифры на 27 задачах

Мы сравнили три версии агента на 27 задачах вида «найди все места, где используется метод X» из реальных тикетов трёх внутренних репозиториев на Java и Kotlin: агент на ripgrep, агент на ripgrep с векторным RAG и агент на PSI-индексе IntelliJ (find_usagesfind_declarationclass_hierarchy вместо текстового поиска).

Вариант поискаPrecisionRecallF1Контекст, токенов$/ответripgrep0,410,820,5578 4001,12ripgrep + векторный RAG0,580,790,6792 1001,38PSI-индекс0,960,930,9416 7000,21
Вариант поискаPrecisionRecallF1Контекст, токенов$/ответripgrep0,410,820,5578 4001,12ripgrep + векторный RAG0,580,790,6792 1001,38PSI-индекс0,960,930,9416 7000,21

Precision показывает, сколько из найденного агентом оказалось реальными использованиями метода, а не случайным совпадением имён. Recall показывает, сколько из всех реальных использований в коде агент вообще нашёл, ничего не пропустив.

У ripgrep recall высокий (0,82): текстовый поиск почти никогда не пропускает совпадения по имени. Но precision низкий (0,41): больше половины найденного - чужие методы с тем же именем, и их приходится разбирать вручную. У PSI-индекса высоки обе величины (0,96 и 0,93): агент находит почти все нужные места и почти не приносит лишнего. F1 сводит обе величины в одно число, и у ripgrep он проседает именно из-за мусора в выдаче, хотя нужные места он и находит.

Отсюда пятикратная экономия контекста и в пять с лишним раз более дешёвый ответ при кратно более высокой точности: агент на PSI-индексе не читает тысячи лишних строк, которые вернул бы текстовый поиск.

Точный поиск не отменяет проверку

Даже когда агент точно нашёл все места, где используется метод, и внёс правку во все, это не гарантирует, что правка корректна: точный поиск решает только задачу «найти нужные места», а не «проверить, что код после правки работает». Поэтому прежде чем объявить об успехе, агент должен прогнать компилятор и тесты: тест зелёный, ошибок компиляции нет, покрытие не просело. Пока в выводе компилятора или тестового прогона есть хоть одна ошибка, агент обязан либо исправить её, либо сообщить о проблеме, а не писать об успехе.

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

Теги:
+10
Комментарии2

Написал новую, третью статью из серии «Как работают большие языковые модели»

Почему дорогая LLM дороже: экономика инференса, которую видно в твоём 5-часовом лимите


Что внутри ⤵️

1. Про открытые модели и почему мы используем их как пример
2. Из чего складывается цена токена
3. Про Dense и MoE архитектуры
4. Как считается attention и активные параметры
5. Total ≠ active: тренд на MoE архитектуру
6. Почему output-токены дороже input
7. Reasoning-токены как невидимый output, за который тоже приходится платить
8. Context Window и KV-cache — почему длинный контекст дорогой
9. Как посчитать вес одного токена и из чего он складывается
10. В чем разница между KV-cache и prompt caching
11. За счет чего фронтир модели стоят в разы дороже
12. Почему дорогая модель чаще всего реально «умнее»
13. Как всё это итого собирается в 5-часовой лимит

14. И как бонус — сортировка open-weight моделей по active и total

---------------

Вот две предыдущие статьи из этой же серии

Прочитав эту серию постов, вы станете намного лучше понимать принцип работы современных LLM и агентных систем

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0

Как все так ловко ИИ пользуются... Обзоры кода делают...

Не знаю, то ли я туповат, то ли невезучий, то ли кругом сказочники. Пытаюсь исследовать, какие новые интересные виды ошибок может находить ИИ в С++ коде, о которых не знает PVS-Studio. Claude Opus то нормально мне про интересные баги рассказывает, то на ровном месте с ума сходит.

Даю файл на вход, а он тревожно:

В присланном файле есть места, где содержимое обрезано/повреждено вставкой </context>, поэтому их я не рассматриваю как «баги кода» — это артефакты форматирования. Разберу реальные логические ошибки.

Шо? Какой context? Там максимум — это #include "context.hxx". Ну ладно, давай ошибки посмотрим.

Так, парочка сообщений по делу. Например, найден лишний аргумент при использовании функции форматирования.

addErrorMessage(&sciErr, API_ERROR_CREATE_ZDOUBLE_IN_NAMED_LIST,
    _("%s: Unable to create list item #%d in Scilab memory"),
    "createComplexZMatrixOfDoubleInNamedList", _iItemPos + 1, _pstName);

В строке форматирования два спецификатора %s и %d, а передаются три аргумента: funcName, _iItemPos+1, _pstName. Да, это баг. Про подобные паттерны PVS-Studio уже знает, хотя, возможно, нужно подсказать, что addErrorMessage — это printf-подобная функция. В целом, тут неинтересно, идём дальше.

Ооо, и тут начинается...

checkListItemPosition — неправильное сравнение границы:

// check a valid item
if (_iItemPos > iItem)
{
    addErrorMessage(...);
    return sciErr;
}

Здесь проверка «позиция валидна» использует >, хотя позиции 1-based, а iItem — количество элементов. Это выглядит как граничный дефект, но по сути _iItemPos == iItem допустимо, _iItemPos > iItem — ошибка. Это в порядке — правильная граница. Не баг. (Указываю, чтобы было понятно, что я это проверил.)

Так баг или не баг? Я три раза прочитал текст и посмотрел функцию с кодом. В итоге я не только не понимаю, есть ли здесь ошибка, но и не понимаю, что Claude пытается мне сказать.

Дальше ещё хуже шарики за ролики зашли.

Баг 5 (реальный): утечка в readCommonMatrixOfPolyInNamedList и др. — нет, это API отдаёт указатели наружу. Не баг.

Это всё описание пятого бага, больше ничего нет. Комментировать — только портить.

Я не понимаю, как на всём этом можно строить хоть сколько-то надёжные процессы автоматических обзоров кода, про которые в последнее время из разных утюгов вещают.

На сегодня мне ИИ достаточно. Пойду лучше пройдусь по парку, пока погода хорошая.

Теги:
Всего голосов 14: ↑14 и ↓0+18
Комментарии6

Fable 5 вернули в Claude Code. Как не сгенерировать себе техдолг

Fable 5 снова доступен в Claude, и это хороший повод вернуться к более практичному вопросу: что именно делать разработчику с Claude Code, кроме генерации отдельных кусков кода.

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

21 июля в 20:00 на бесплатном уроке разберём, как использовать Claude Code в разработке ИИ-приложений: от Telegram-ботов и агентов до внутренних сервисов, API и автоматизаций. Отдельно поговорим о работе с большими задачами — как дробить их на этапы, вести разработку итерациями, дорабатывать код и находить ошибки. Присоединяйтесь.

Все июльские разборы по ИИ, разработке, архитектуре и инфраструктуре собрали в дайджесте мероприятий.

Теги:
Всего голосов 5: ↑4 и ↓1+7
Комментарии1

Ближайшие события

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

В продолжение курса я подготовил ещё один бесплатный материал — книгу, которая поможет изучать SQL ещё удобнее.

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.

Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.

Что представляет собой книга

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

Её можно использовать как:

  • офлайн-версию курса для повторения материала;

  • удобный конспект при выполнении практических заданий;

  • справочник для быстрого повторения основных конструкций SQL.

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

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

  • студентов IT-специальностей;

  • начинающих разработчиков;

  • будущих аналитиков данных;

  • тестировщиков;

  • всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

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

https://github.com/Awilum/sql-introduction/releases

Буду рад вашим отзывам, предложениям и замечаниям как по курсу, так и по книге. Надеюсь, этот дополнительный материал сделает изучение SQL ещё более удобным и понятным.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии3

Нарезка кода: что скрывает OrcaSlicer

Как не пропустить опасные участки кода при ревью? Можно воспользоваться инструментами статического анализа. Возьмём для примера OrcaSlicer — популярную программу, которая подготавливает 3D-модель к печати. Заглянем внутрь и посмотрим, какие сюрпризы нас ждут.

Посмотрим на одно из предупреждений статического анализатора PVS-Studio:

V1047 Lifetime of the lambda is greater than lifetime of the local variable ‘do_stop’ captured by reference. FillBedJob.cpp 250

void FillBedJob::process(Ctl &ctl)
{
  // ....
  bool do_stop = false;
  // ....
  params.on_packed = 
    [&do_stop] (const ArrangePolygon &ap)
    {
      do_stop = ap.bed_idx > 0 && ap.priority == 0;
    };
  // ....
}

Лямбда-выражение захватывает локальную переменную do_stop по ссылке, а затем сохраняется в params.on_packed. При этом do_stop уничтожается при выходе из метода process, так как заканчивается время жизни локального объекта. Если лямбда будет вызвана после выхода из этой функции-члена, произойдёт обращение к разрушенному объекту, и поведение в этой ситуации не определено.

Можно было бы сделать захват по значению, но в этой лямбде происходит перезапись переменной do_stop, а значит такой вариант не подходит. Поэтому можно сделать do_stop членом класса FillBedJob.

Это лишь один фрагмент, показывающий, что даже в работающем продукте могут быть ошибки. А другие опасные места в коде OrcaSlicer разобрали в новой статье.

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

Теги:
Всего голосов 3: ↑3 и ↓0+6
Комментарии0

Листая на C++ Reference список принятых в C++29 фичей, увидел в нем пропозал с знакомым названием, «Thread attributes» (P2019R9). И, оказалось, действительно, я уже читал этот пропозал 4 года назад, но не в 9-й его редакции, а в самой первой. 4 года понадобилось комитету по стандартизации, чтобы принять пустячный пропозал, позволяющий задать имя и размер стека потока при его создании — востребованную фичу, реализованную в куче библиотек C++.

void f();
int main() {
  // Такой вид задания атрибутов предлагался в первой ревизии
  std::jthread P2019R1(
    f, std::thread_name("Worker"),
    std::thread_stack_size(512*1024));
  // А такой приняли 8 ревизий спустя
  std::jthread P2019R9(
    std::thread::name_hint("Worker"),
    std::thread::stack_size_hint(512*1024), f);
}

Не безумие ли это? И сколько действительно правильных пропозалов не вошло в C++ лишь по той причине, что их автор не был готов 4 года подряд защищать свое предложение, отвечая на все мелкие придирки различных подкомитетов?

Теги:
Всего голосов 5: ↑5 и ↓0+8
Комментарии3

18 бесплатных уроков недели: разработка, AI, тестирование и DevOps

На этой неделе в OTUS — серия бесплатных открытых уроков для разработчиков, архитекторов, тестировщиков, DevOps‑инженеров, аналитиков и руководителей технических команд.

В программе — Spring и Java, C++ и Linux, GitLab CI, тестирование, мобильная разработка, сетевые технологии, машинное обучение и практическое применение ИИ.

Какие темы запланированы:

Backend и разработка

  • 29 июня, 20:00 — «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

  • 1 июля, 20:00 — «Алгоритмическая сложность коллекций в Java». Записаться

  • 2 июля, 20:00 — «Методы, их перегрузка и расширения». Записаться

C++ и системное программирование

  • 30 июня, 20:00 — «RAII в C++: фундамент надёжного управления ресурсами». Записаться

  • 1 июля, 20:00 — «Классические методы перехвата управления в Linux». Записаться

  • 2 июля, 20:00 — «Всё, что нужно знать об управлении памятью в C++». Записаться

AI, ML и автоматизация

  • 29 июня, 20:00 — «Обзор ИИ‑технологий для разработчиков: от идей до рабочих решений». Записаться

  • 29 июня, 20:00 — «Использование ИИ архитектором 1С: как ускорить анализ требований и подготовку документации». Записаться

  • 29 июня, 20:00 — «AI для работы с обратной связью: как анализировать отзывы клиентов, интервью и обращения в поддержку». Записаться

  • 1 июля, 18:00 — «Градиентный бустинг — мощный алгоритм ансамблирования в ML». Записаться

  • 1 июля, 20:00 — «Архитектурные паттерны AI‑агентов: как проектировать автономные решения для бизнес‑задач». Записаться

  • 6 июля, 20:00 — «Как сделать LLM‑приложение, которое отвечает клиентам по базе знаний компании». Записаться

Инфраструктура и DevOps

  • 30 июня, 20:00 — «GitLab CI как конструктор workflow». Записаться

  • 1 июля, 20:00 — «Что нужно знать для настройки стабильного интернета? OSPF и протоколы динамической маршрутизации». Записаться

Mobile и тестирование

  • 30 июня, 20:00 — «Тестирование UX для мобильных приложений: чек‑лист по основным проверкам». Записаться

  • 2 июля, 20:00 — «От API до экрана: создаём Android‑приложение на рекомендуемой архитектуре». Записаться

  • 2 июля, 20:00 — «REST Assured & JSON Schema Validator: автоматизация тестирования API на практике». Записаться

Зерокодинг

  • 2 июля, 20:00 — «Магия Lovable: как создавать готовые интерфейсы с помощью одного запроса». Записаться

А если хотите углубиться в инфраструктуру, сети и DevOps, смотрите подборку материалов в дайджесте.

Теги:
Всего голосов 3: ↑2 и ↓1+4
Комментарии0

Пока писал статью про Context Engineering, то дополнительно решил изучить вопрос, который был на хайпе 3 месяца назад

Реально ли Caveman Output Style экономит токены для агентов

Суть

Несколько месяцев назад расхайпилась казалось бы очевидная идея: если заставить модель отвечать коротко, то можно сэкономить много output-токенов

Одна таких реализаций — репо Caveman, который заставляет модель говорить как пещерный человек. Целых 77к звезд

Вот как пример

Обычный ответ модели

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object

Ответ в стиле Caveman

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo

Ну и как следствие, обещания автора

Faster response — less token to generate = speed go brrrEasier to read — no wall of text, just the answerSame accuracy — all technical info kept, only fluff removedSave money — ~71% less output token = less cost

Этот репозиторий очень сильно расхайпился — и основная суть всех новостей была в том, что с этим стилем теперь можно тратить на 40-70% меньше output токенов — который самые дорогие

Чтобы лучше понять механизм потенциальной экономии, нужно посмотреть, где агентные системы по типу CLAUDE CODE | CODEX вообще генерируют OUTPUT токены

1. Обычный ответ, который видите вы
2. THINKING блоки, которые вы можете не видеть
3. Генерация кода / схем, которые нельзя сжать
4. Вызов Tools + Цикл tool call → result → next message

В случае выбора любого OUTPUT стиля мы влияем только на пункт 1 — Обычный ответ, который видите вы

И, насколько мы все тут знаем — то, что модель выдает нам как результат ответа — в среднем ~5-10% от всех OUTPUT токенов

Ну так вот

Я по приколу сделал мини эксперимент, где взял 3 варианта Output Style's и прогнал на 5 разных задачах

1 стиль — Caveman Light (Original skill из репозитория выше)
2 стиль — Explanatory. Стиль, который наоборот, старается объяснять как можно подробнее. Я его сам всегда использую — объясняет свои решения и делится инсайтами.
3 стиль — Самописный True Caveman. Который должен общаться прям как настоящий пещерный человек

Инсайт, что строгий промптинг для True Caveman стал самым дорогим. И я думаю из-за того, что Thinking блоки заставляли модель постоянно себя перепроверять, говорит ли она в данный момент как True Caveman или нет. Так как ее это делать не учили.

Статью я написал на своем сайте, так как там много графики и элементов используется, которые на хабре не работают

Ссылка на статью на сайте, там подробно про этот эксперимент и реально ли это что-то экономит

Я несколько дней на это потратил 🥺

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии7

РБПО по ГОСТ Р 56939—2024: вебинар №27 из 30 — PVS-Studio Atlas — новая платформа контроля качества кода

Предлагаю вашему вниманию запись вебинара, где мы разбираем безопасную разработку ПО. Мы добрались до дополнительных (бонусных) вебинаров цикла. Рассмотрим "PVS-Studio Atlas — новая платформа контроля качества кода". На YouTube. Слайды.

В ходе бонусного вебинара команда PVS-Studio представила новый продукт — PVS-Studio Atlas, предназначенный для работы с результатами анализа кода: просмотра, аналитики, разметки и формирования отчётов для сертификационных лабораторий и ФСТЭК.

Общее количество вебинаров — 30. Каждому из 25 процессов ГОСТа посвящён отдельный вебинар и ещё 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Методика ВУ и НДВ в ПО приведена в соответствие с ГОСТ Р 56939—2024

Материалы будут полезны всем, кто знакомится с темой РБПО и заинтересован во внедрении зрелых подходов в работу по созданию и сопровождению качественных программных продуктов. Материал по ГОСТ Р 56939—2024 весьма актуален, так как 12 мая 2026 утверждена обновлённая "Методика ВУ и НДВ в ПО". См. заметку "Методика выявления уязвимостей и недекларированных возможностей — 2026".

PVS-Studio — статический анализатор кода для поиска критических и типовых ошибок

Также приглашаю всех познакомиться с нашим статическим анализатором PVS-Studio, который может закрыть не только 10-й процесс ГОСТ Р 56939, но и будет полезен по другим направлениям:

  1. Обучение сотрудников (п.5.2). Формирование у программистов понимание антипаттернов и уязвимых конструкций, что улучшает их техническую экспертизу;

  2. Моделирование угроз и разработка описания поверхности атаки (п.5.7). Дополняет процесс, выявляя потенциальные уязвимости, которые формируют поверхность атаки;

  3. Экспертиза исходного кода (п.5.9). Позволяет усилить проверку стороннего кода, который команда включает в проект. Например, его можно использовать для выбора сторонних библиотек, оценивая качество их кода;

  4. Поиск уязвимостей в программном обеспечении при эксплуатации (п.5.24). Можно просматривать ранее отключённые предупреждения PVS-Studio с целью дополнительного выявления дефектов в коде.

Скачать PVS-Studio.

Основные характеристики:

Теги:
Всего голосов 8: ↑8 и ↓0+11
Комментарии0

Бэкенд без слепых зон: 10 открытых уроков для разработчиков

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

Собрали бесплатные открытые уроки для бэкенд‑разработчиков разных стеков. Преподаватели‑практики покажут рабочие подходы, разберут типовые ошибки и ответят на вопросы. Заодно можно познакомиться с экспертами и проверить формат обучения OTUS.

Архитектура и взаимодействие сервисов

  • 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

  • 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

  • 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

Java и Spring

  • 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

  • 29 июня, 20:00. «Как работает @Transactional в Spring: границы транзакций и типовые ошибки». Записаться

  • 1 июля, 20:00. «Алгоритмическая сложность коллекций в Java». Записаться

  • 22 июля, 20:00. «DAO на Spring JDBC». Записаться

.NET и Go

  • 18 июня, 20:00. «Хостинг ASP.NET Core изнутри». Записаться

  • 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

  • 8 июля, 20:00. «Чистая архитектура на Go без "карго-культа": слои, DTO и интерфейсы». Записаться

Выбирайте тему под свой стек и подключайтесь к открытым урокам.

Больше бесплатных открытых уроков по другим направлениям смотрите в нашем дайджесте.

Теги:
Всего голосов 2: ↑2 и ↓0+4
Комментарии0