История появления Дня программиста началась с идеи отметить вклад программистов в развитие технологий и их важную роль в современном обществе. Одним из главных инициаторов создания этого праздника был Валентин Балтин, российский разработчик программного обеспечения. В 2002 году он предложил ввести официальную дату, посвящённую программистам, и начал собирать подписи для обращения в правительство с целью признания этого дня на государственном уровне.

Число 256 было выбрано не случайно. В мире компьютерных технологий это число играет важную роль, так как 256 — это степень двойки (2^8), которая представляет количество возможных значений в одном байте данных (8 бит). Для программистов это символическое число, связанное с основами работы компьютеров и цифровых систем.

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

В 2009 году их усилия увенчались успехом. Президент России Дмитрий Медведев подписал указ № 1034 «О Дне программиста», который установил этот праздник официально. Таким образом, День программиста был закреплён на уровне государства и стал ежегодно отмечаться на 256-й день года — 13 сентября в обычные годы и 12 сентября в високосные годы.

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

Как вы относитесь к Дню программиста?

CamelCase vs snake_case: как появился каждый стиль и где что использовать
В программировании есть несколько популярных способов именования переменных и функций, и каждый из них имеет свои особенности. CamelCase и snake_case — самые распространенные стили, которые выбирают в зависимости от языка программирования и его традиций. Появление и использование этих стилей обусловлено многими факторами, включая читабельность, удобство написания и восприятие кода. Ну и, конечно, Go тут тоже не остался в стороне со своим mixedCase.

CamelCase
Этот стиль именования получил название из-за того, что заглавные буквы в середине имени похожи на горбы верблюда. Здесь каждое новое слово начинается с заглавной буквы, но без разделителей. CamelCase чаще всего встречается в JavaScript, Java, C# и Swift. Пример: myVariableName.

Почему так? Всё просто: это делает код более компактным, особенно в языках, где используется много коротких слов. Если вспомнить JavaScript, там это прям повсеместная практика, да и в Java аналогично — это стандарт для методов и переменных.

snake_case
Этот стиль именования использует символ подчеркивания для разделения слов. Все буквы в нем пишутся строчными, что добавляет аккуратности и ясности при работе с длинными именами переменных. Snake_case широко принят в Python и Ruby. Пример: my_variable_name.

Здесь подчеркивание выступает естественным разделителем, делая переменные с несколькими словами легко читаемыми. Особенно этот стиль нравится тем, кто предпочитает четкость в коде и использует более длинные описательные имена.

mixedCase в Go
Теперь к Go. В этом языке принято использовать mixedCase, который выглядит как CamelCase, но с упрощениями. Например, myVariableName для переменных и DoSomething для методов. Отличительная черта Go — это строгое разделение между экспортируемыми и приватными именами. Если имя начинается с заглавной буквы, оно доступно в других пакетах. Если с маленькой — доступно только внутри текущего пакета.

Go избегает snake_case, делая акцент на упрощении и лаконичности. Такой подход делает код Go легко читаемым и структурированным, следуя правилу минимализма в языке.

#CamelCase #snake_case #Go #mixedCase #программирование #стилиименования #код #разработка #программист #kangaroo

Релиз СУБД PostgreSQL 17

После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 17, а PostgreSQL 12.x перестанут поддерживать уже 14 ноября.

Что нового добавлено?

🔸 VACUUM: используется новая структура данных, которая потребляет до 20 раз меньше памяти, ускоряя работу и снижая нагрузку на ресурсы.
🔸 I/O: оптимизация кода WAL повысила пропускную способность записи до 2 раз. Новый интерфейс потокового ввода/вывода ускоряет перебор данных и обновление статистики.
🔸 Оптимизация запросов: ускорены запросы с IN, улучшена работа с индексами BRIN и CTE, а также использованы SIMD-инструкции для ускорения вычислений.
🔸 JSON: добавлена поддержка SQL/JSON, включая JSON-TABLE, jsonpath, и функции для работы с JSON, такие как JSON_EXISTS и JSON_QUERY.
🔸 SQL MERGE: расширены возможности для объединения INSERT, UPDATE и DELETE, добавлена поддержка выражения RETURNING и обновления представлений.
🔸 Загрузка данных: увеличена скорость экспорта данных в команде COPY, добавлена опция ON_ERROR для продолжения импорта после ошибок.
🔸 Секционированные таблицы: добавлена поддержка уникальных идентификаторов и техники оптимизации Constraint exclusion.
🔸 Foreign Data Wrapper: поддержка передачи подзапросов EXISTS и IN на внешний сервер.
🔸 Collation: встроенный движок для обработки локали обеспечивает единое поведение сортировки и сопоставления символов на всех платформах.
🔸 Логическая репликация: упрощён переход на новый релиз без удаления слотов, добавлена поддержка failover и утилита pg_createsubscriber.
🔸 TLS: новая опция sslnegotiation для настройки защищённых TLS-соединений через ALPN.
🔸 Резервное копирование: поддержка инкрементальных бэкапов и новая утилита pg_combinebackup для их объединения. В pg_dump добавлена опция --filter.
🔸 EXPLAIN: добавлены новые опции для вывода информации о времени чтения/записи и использовании памяти.
🔸 Прогресс VACUUM: добавлен индикатор прогресса при работе с индексами.
🔸 pg_wait_events: новое системное представление для анализа причин ожидания сеансов в сочетании с pg_stat_activity.

В основную ветку CPython смерджили пулл-реквест, добавляющий поддержку алиаса «𝜋thon» для виртуальных окружений Python версии 3.14.

Выпущен Linux, внешне неотличимый от Windows пол названием Wubuntu.
Дистрибутив основан на Kubuntu 24.04.1 LTS (Ubuntu с оболочкой KDE). При этом все элементы интерфейса очень похожи на оригиналы в Windows.
Скопирована даже раздражающая надпись об активации системы в правом нижнем углу рабочего стола. Правда, это окно с надписью можно просто закрыть.
Здесь по умолчанию установлен Edge для максимального сходства с Windows, а для тех, кто не желает пользоваться браузером Microsoft, есть предустановленный Google Chrome.
В систему по умолчанию встроен Wine для запуска программ, написанных для Windows
Имеется среда выполнения PrimeOS Android для работы с Android-приложениями. Для геймеров по умолчанию установлен клиент Steam от Valve. Есть даже магазин приложений KDE Discover, заменивший собой Microsoft Store.
https://www.theregister.com/2024/12/05/wubuntu/
https://wubuntu.org/

Технологии для управления зелёной инфраструктурой в городах

Как города могут сохранить свои зелёные насаждения и сделать процесс их учёта проще и эффективнее? Сегодня большинство методов мониторинга деревьев и зелёных зон требуют выезда специалистов на место, что делает процесс медленным, затратным и подверженным человеческим ошибкам. Мы задались целью изменить подход, используя современные технологии.

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

Дальше больше. Мы представили проект на Форуме Инновационных Центров, где он получил высокую оценку как универсальный инструмент для управления зелёной инфраструктурой. Эксперты отметили, что эта разработка способна значительно изменить подход к мониторингу зелёных насаждений, делая процесс прозрачным, доступным и масштабируемым.

Сейчас система позволяет собирать данные из различных источников, включая фотографии, спутниковые снимки и реестры. Модель машинного обучения была дообучена для распознавания деревьев, что значительно увеличивает точность анализа. Также реализован личный кабинет для специалистов, где они могут загружать фотографии, проверять результаты анализа и выгружать отчёты.

На данном этапе мы работаем над доработкой платформы и созданием мобильного приложения, чтобы сделать систему ещё удобнее и доступнее. В будущем проект станет частью концепции «умного города», что позволит использовать его в крупных мегаполисах, в том числе странах БРИКС. Наша цель — дать городам инструмент, который сделает управление зелёной инфраструктурой быстрым, эффективным и максимально точным.

#инновации

🚀 codex-harness 0.1.2
Что нового:
🔒 Закрыл возможность обхода хуков при сбоях. Раньше агент мог продолжать работу, даже если проверка не запустилась. Теперь такие ошибки обнаруживаются и не считаются успешной проверкой.
🔍 Добавил диагностику установки и работы хуков.
🛠 Добавил новое правило Ruff — запрет импортов внутри функций и классов.
📦 PyPI: https://pypi.org/project/codex-harness/

Codex Harness. Зачем я написал собственную систему контроля кода для ИИ

Недавно публиковал обновление Codex Harness, но, думаю, стоит немного подробнее рассказать, что это вообще за проект и для чего я его разрабатываю.
Сейчас я довольно активно использую Codex в разработке. Инструмент действительно полезный, особенно когда нужно работать с большими проектами. Но есть одна проблема, с которой наверняка сталкивались многие.
Можно сколько угодно описывать правила разработки в AGENTS.md, подключать навыки, требовать соблюдения архитектуры и стандартов кода. Однако всё это остаётся инструкциями для языковой модели. Она может их неправильно интерпретировать, проигнорировать или просто допустить ошибку.
Мне хотелось сделать так, чтобы соблюдение хотя бы части этих правил зависело не от поведения модели, а от обычного программного кода.
Так появился Codex Harness — моя открытая система контроля изменений для Codex CLI.

Как это работает?
Harness подключается к Codex через хуки, которые вызываются при работе агента с инструментами.
Перед изменением Python-файлов через apply_patch система сохраняет их исходное состояние. После изменения запускает анализаторы кода и сравнивает результаты.
Для проверки используются Ruff, Flake8, а также поддерживаются Pylint, Black и MyPy.
Проверяется не только наличие ошибок, но и сложность функций, количество ветвлений, вложенность, длина функций и другие показатели.
При этом есть важный момент: Harness не требует исправлять все старые проблемы проекта. Он не позволяет создавать новые или усугублять существующие.
Например, в проекте уже есть функция на 90 строк при установленном ограничении в 80. Это существующая проблема, и сама по себе она не блокирует работу.
Если Codex увеличит её до 100 строк, проверка обнаружит ухудшение. Если сократит до 85 — такое изменение допустимо.

Что происходит при ошибке?
Harness передаёт Codex конкретные замечания, после чего агент может самостоятельно исправить код и повторить попытку.
Количество неудачных попыток ограничено. По умолчанию их три. После исчерпания лимита дальнейшие изменения через apply_patch в рамках текущего запроса блокируются.
Отдельно предусмотрена обработка ошибок самой системы проверки. Если анализатор не запустился или проверка завершилась с ошибкой, такой результат не должен считаться успешным.

Что дальше?
Сейчас основное внимание уделено Python и проверкам изменений через apply_patch. Полный контроль изменений через другие инструменты, проверка перед завершением задачи и архитектурные ограничения пока остаются направлениями дальнейшей разработки.
В перспективе хочу добавить контроль зависимостей между слоями приложения, архитектурных правил и поддержку других языков.
Главная идея проекта довольно простая: качество кода должно проверяться конкретными правилами, а не только обещаниями языковой модели их соблюдать.

Проект распространяется с открытым исходным кодом под лицензией Apache 2.0.
📦 Установка: pip install codex-harness
💻 GitHub: https://github.com/r-tatarinov/codex-harness
📦 PyPI: https://pypi.org/project/codex-harness/

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

⚡️ Небольшая просьба к подписчикам с Telegram Premium.

Если у вас есть свободные бусты, можете поддержать Kangaroo. Это бесплатно, а каналу поможет открыть дополнительные возможности оформления и публикации историй.

https://t.me/boost/channelpy

Спасибо за поддержку 🙂

MCP на пальцах

Сейчас много говорят про MCP, иногда чуть ли не как про таблетку от всего. Поэтому решил на пальцах объяснить, что это такое и что там есть, кроме инструментов.

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

Начнём с tools. Это обычные функции, которым разработчик дал описание и указал параметры. Модель по описанию выбирает подходящую, приложение отправляет запрос серверу и получает результат. Внутри может быть обращение к API, поиск, работа с файлами — обычный код, который кто-то написал.
Но функциями дело не ограничивается. Есть resources — данные, которые сервер предоставляет для контекста модели. Например, документация проекта или описание структуры базы. У ресурса есть свой идентификатор, по которому можно запросить его содержимое. Что прочитать и передать модели, решает приложение.
То есть подключить MCP-сервер с документацией — не значит, что модель уже всю её прочитала. Доступ к данным и сами данные в контексте — разные вещи.
Ну и prompts. Те самые промпты, только заготовленные на стороне сервера. Пользователь выбирает нужный, при необходимости указывает параметры и получает подготовленные сообщения для модели. Чтобы каждый раз не писать одни и те же инструкции. Сам по себе такой шаблон никаких действий не выполняет.

В другой раз расскажу, когда MCP нужен, а когда проще без него. Заодно разберёмся, экономит ли он токены и что ещё ему приписывают, хотя сам протокол этого не обещает.

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

🛡 Гвардрейлы: зачем ограничивать искусственный интеллект?
В последнее время всё чаще можно услышать слово guardrails, особенно когда речь заходит об ИИ-агентах. Давайте разберёмся, что это такое, зачем они нужны и почему одних инструкций для модели бывает недостаточно.
Представьте, что вы поручили агенту исправить небольшую ошибку в проекте. Он изучил код, нашёл проблему и приступил к работе. Но попутно решил обновить зависимости, переписать конфигурацию и удалить несколько файлов, которые посчитал ненужными.
Возможно, из лучших побуждений. Только вы его об этом не просили.
Конечно, можно заранее написать в инструкциях: «Не изменяй ничего лишнего, не удаляй файлы, не трогай базу данных». И в большинстве случаев агент будет стараться этим инструкциям следовать.

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

И ещё один интересный момент: гвардрейлы необязательно должны использовать другую нейросеть.
Это могут быть обычные проверки, валидаторы, линтеры, ограничения доступа, хуки и другие вполне привычные разработчику инструменты.
Я с этим столкнулся при работе над собственным проектом codex-harness.
Оказалось, что мало просто добавить проверки. Нужно ещё убедиться, что они действительно запускаются и агент не может продолжить работу, если одна из них завершилась с ошибкой. Иначе получается довольно забавная ситуация: защита вроде бы существует, но в определённых условиях её можно обойти.
Собственно, этим и отличается реальный контроль от очередной строчки в системном промпте.
Разумеется, гвардрейлы не делают агента безошибочным и не заменяют нормального разграничения прав. Но позволяют существенно снизить вероятность того, что одна неудачная команда превратится в проблему для всего проекта.

Ведь чем больше самостоятельности мы даём ИИ, тем важнее понимать не только то, что он умеет делать, но и что ему делать нельзя.

Моё руководство к чистому коду

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

1. Один класс — один файл.
Не понимаю, зачем собирать десяток классов в одном файле. Гораздо удобнее, когда у каждого класса своё место. И искать проще, и разбираться в чужом коде.

2. Одна ответственность — один компонент.
Если класс и с базой работает, и письма отправляет, и бизнес-логику обрабатывает, я бы его разделил.
Не нужно пытаться запихнуть всё в один сервис только потому, что так быстрее написать.

3. Одна предметная область — свой пакет.
Пользователи, заказы, платежи — всё по своим пакетам.
Особенно не люблю, когда в проекте появляется папка utils, а через полгода там уже половина приложения. С helpers и common примерно та же история.

4. Наследование, mixins и композиция.
Общую логику выношу в базовые классы, отдельное поведение — в mixins. Но если два компонента могут существовать независимо, предпочитаю композицию.
Не вижу смысла строить сложные цепочки наследования ради нескольких общих методов.

5. Структура проекта должна отражать его архитектуру.
Открыв проект, хочется понимать, где что находится, а не изучать историю решений предыдущих разработчиков.
Когда бизнес-логика разбросана между services, core, common и utils, работать с таким проектом становится не очень приятно.

И ещё один момент. Я не сторонник дробления ради дробления. Если задачу можно решить парой функций, не нужно создавать под неё пять классов и три абстракции.
Для меня чистый код — это когда через полгода открываешь собственный проект и без особых усилий понимаешь, что там происходит.

Коллеги из Фактосборки решили проверить Codex Harness на практике.

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

Проверили Codex Harness: где он держит, а где его обходят

Это хуки для Codex: после каждой правки гоняют Ruff и Flake8 и не пускают ухудшения кода. Мы прогнали 13 сценариев. Новый лишний import, раздутую старую функцию и попытку ослабить правила — блокирует. А # noqa и правки через shell проходят. Главная дыра: если после блока агент не исправил код, а правит дальше, ошибка тихо уходит в «старый долг».

ИИ стал писать больше кода. А разработка быстрее не стала?

Попалось довольно интересное исследование двух учёных из Гарварда — Fiona Chen и James Stratton. Они решили проверить, как внедрение ИИ влияет на реальную работу команд разработки.
Для этого изучили около 300 миллионов событий в 718 компаниях за период с 2021 года по март 2026-го. Анализировали коммиты, pull request'ы, закрытые задачи и работу с ИИ-инструментами.

Результаты после внедрения ИИ-агентов получились любопытные:
На 30% больше написанных строк кода.
На 20% больше коммитов.
На 23% больше pull request'ов.
На 49% увеличилось время от создания PR до его слияния.
На 35% выросло количество комментариев при ревью.
Причём доля PR, которые отправляли на доработку, выросла примерно с 13% до 25%.

Статистически значимого увеличения количества закрытых задач и эпиков исследователи не обнаружили.
Получается, кода стали писать больше, изменений тоже, а вот сопоставимого прироста готового результата пока не видно.
Авторы связывают это с узким местом в процессе разработки — проверкой кода. Агент может быстро написать реализацию, но её ещё нужно проверить, исправить замечания, протестировать и довести до рабочего состояния.
Правда, тут есть нюансы. Те самые 49% — это время от создания PR до слияния, а не непосредственно часы, потраченные разработчиком на ревью. Да и само исследование основано на наблюдениях, а не контролируемом эксперименте. Поэтому говорить, что ИИ делает команды медленнее, было бы неправильно.

И возникает вопрос: а что вообще считать продуктивностью разработчика в эпоху ИИ? Количество написанного кода или количество задач, действительно доведённых до результата?

Оригинал исследования: Artificial Intelligence in the Firm: Bottlenecks in Software Production

База данных быстрее файловой системы? Оказывается, бывает и такое.

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

Разработчики SQLite решили проверить это экспериментально.
Они взяли 100 тысяч небольших объектов размером около 10 КБ и сравнили чтение из обычных файлов с чтением из SQLite.
Результат оказался неожиданным:
— SQLite читала данные примерно на 35% быстрее.
— Хранение в базе потребовало примерно на 20% меньше места.

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

📖 Эксперимент разработчиков SQLite

Synaptic Garden: что происходит в AI-индустрии сегодня и к чему готовиться завтра

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

Для тех, кто создает будущее, а не наблюдает за ним: @synaptic_garden