GitHub *

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

С диагностикой нам уже помогает агент из первой и второй частей — но это только полдела. Дальше начинается самое муторное: инженер должен понять, где именно нужно внести изменения, оценить, сможет ли он сделать их сам или тут нужен разработчик, найти нужный репозиторий среди десятков похожих, внести правку, прогнать её через PR и ревью. В релизный кранч эти «ещё пятнадцать минут» на каждое обращение складываются в часы, а переключение контекста добивает остатки концентрации. Знакомо? У нас это выглядело так: агент за две минуты выдаёт диагноз «в workflow не передаётся input окружения», а потом инженер ещё полчаса ищет, в каком из реюзабельных workflow это чинить.

Именно поэтому мы решили пойти дальше и дать возможность просто сказать:

Selective Remote начинался как небольшой RDP-клиент для macOS, а к версии 0.22.0 вырос в рабочее пространство для RDP, SSH, SFTP и SSH-туннелей. Рассказываю, зачем SFTP понадобилась передача Server → Server, почему Drag & Drop пришлось спускать со SwiftUI на AppKit и как несколько отдельных экранов превратились в связанные Workspace.

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

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

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

В этой статье я часто упоминаю слово «актуальность». Под актуальностью я имею в виду, что конкретная технология используется достаточно большим количеством разработчиков.

Сегодня мы будем говорить преимущественно о таких гигантах, как Django, FastAPI и Flask, а также затронем не менее важные библиотеки: для работы с базами данных, тестирования, сборки проектов. Поговорим о таких противостояниях, как uv vs poetry, pytest vs unittest и других. В общем, будет интересно. Усаживайтесь поудобнее и погнали!

Вы, скорее всего, встречались с кардинально противоположными мнениями: "Django умер, да здравствует FastAPI", "Сейчас на FastAPI уже не пишут, встречай LiteStar", "Вообще на FastAPI особо ничего не пишем, только на Django".

С развитием ИИ себестоимость кода стремительно падает. Его становится все больше, а команды не растут пропорционально количеству. AI-инструменты генерации кода (Copilot, Cursor, Codex, Claude Code) увеличивают скорость написания, но не скорость проверки кода.

Узким горлышком становится сам PR, они могут висеть днями в вашей компании или opensource-проекте, контекст может теряться, на его оценку тратится время, и иногда впустую.

В среднем, команда на ревью тратит ~20% рабочего времени, особенно если это большой PR, или PR от новичка.

Но как же решить эту проблему? Ведь беда не в том, что ревьюверы плохие, или что им нужно давать больше работы, а в том, что объем кода растет быстрее возможности осмысленно его проверить.

В этой статье я расскажу о том, как помочь вашему корпоративному или опенсорс-проекту, если он тонет в код-ревью, и расскажу о существующих решениях — devin ai, context7, deepwiki, rabbit code review и других.

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

Суть проекта:

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

Цели проекта:

За несколько часов вредоносный код попал как минимум в 452 npm‑пакета и 2265 опубликованных артефактов. Червь крал ключи от GitHub, облаков и платёжных сервисов, а затем использовал чужие учётные записи, чтобы выпускать новые заражённые версии.

4 августа 2026 года злоумышленник получил возможность действовать от имени сопровождающего Keyv — одной из самых загружаемых библиотек экосистемы JavaScript. В официальный репозиторий попал вредоносный код, после чего версия keyv@6.0.0 была опубликована в npm через настоящий механизм GitHub Actions и получила корректную аттестацию происхождения.

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

По состоянию на 5 августа живой трекер Socket учитывал 452 уникальных пакета и 2265 заражённых артефактов. Это крупнейшая публично задокументированная волна заражений npm в 2026 году по числу затронутых пакетов. Называть её «крупнейшей хакерской атакой года» вообще некорректно: такой вывод потребовал бы сопоставления с атаками на телекоммуникационные сети, государственные системы и крупные корпорации, для которого открытых данных нет.

- Пробовали сделать цифрового сотрудника на LLM?
- У вас получилось?
- Долго старались?
- Насколько он качественный?
- Сколько он стоит в обслуживании?
Очень много вопросов возникает к технологии ведения диалогов нейросетями.

Коротко, о чём речь, — для тех, кто пришёл по слову «Яндекс» и предыстории не знает. Когда ИИ-ассистент помогает чинить баг, самое ценное — не сочинить ответ с нуля, а вспомнить: похожий симптом уже разбирали, вот issue, вот причина, вот PR с фиксом. Вопрос ровно один — достаёт ли ассистент это прошлое решение из памяти. Мы это померили на своём корпусе тикетов и получили две цифры. Обычный семантический поиск (по смыслу слов) находит нужный прошлый фикс по симптому лишь в 38% случаев; обход явных причинных связей «issue → закрывший его PR» — в 87%. То есть сходство слов упирается в треть, а явные связи поднимают recall в разы.

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

На протяжении многих лет использования git я выявил для себя одну серьезную проблему, которую этот инструмент не дает возможности разрешить удобным способом. Я назвал эту проблему “проблемой длинного прыжка”. Суть такова: у вас есть старая залежавшаяся ветка, которая отстает от main-ветки на сотни и тысячи коммитов. Задача - обновить эту старую ветку до свежего main. Все усугубляется тем, что у вас тяжеловесный репозиторий: гигабайты, десятки или сотни гигабайт.

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

Такие репозитории существуют уже 2 года. У гитхаба есть миллиарды долларов, служба безопасности и искусственный интелект.

Почему они за 2 года не решили эту проблему?

Недавно я зарегистрировал fluxcast.dev и понял, что основной домен простаивает без дела. Рассказываю, как я написал свой реестр бесплатных поддоменов на Python через PR на GitHub и с какими подводными камнями DNS, Cloudflare и Git столкнулся.

В Linux с давних пор киллерфичей была возможность централизованного управления (поиск, установка, удаление, обновление, разрешение зависимостей) софтом при помощи пакетных менеджеров (apt, yum, pacman и т.д.).

Однако существует большое количество интересных и полезных программ, которые распространяются разработчиками либо через собственный сайт, либо через релизы на GitHub, либо в виде статического бинарника, либо вообще исключительно в исходниках (при этом под той же Windows у того же проекта часто есть нормальный инсталлятор с автопроверкой обновлений).

Когда таких программ накапливается достаточное количество, их сопровождение превращается в настоящий цирк.

Я решил для себя этот вопрос создав собственный apt репозиторий.

Полгода назад я пришёл в новую организацию, и мне достался парк машин. Десяток на Windows, несколько маков, пачка линуксовых ноутов у разработчиков. Невыносимым было другое. Навешанные до меня политики и блокировки со стороны ИБ связывали руки так, что здраво администрировать домен было попросту нельзя: любое рутинное действие упиралось в чужие ограничения. Тогда я и полез искать решение, которое помогло бы мне нормально админить этот парк.

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

В прошлой статье я разбирала, как превратить README в лендинг для инженера, с hero-блоком, quickstart и структурой, которая ведёт от проблемы к действию. Хороший репозиторий - это точка входа. Дальше встают два практических вопроса: как сделать так, чтобы о продукте узнали нужные люди, и как звёзды на GitHub превращаются из красивой цифры в сигнал доверия.

Обнаружил что в скриптах сборки время от времени подвисает node-pre-gyp, который скачивает прекомпилированные бинарные библиотеки.

Начал выяснять откуда он их пытается скачать - оказывается, github.

Проверил github без VPN - оказывается, релизы с release-assets.githubusercontent.com не скачиваются. Причем из консоли еще скачиваются, из браузера не открываются. Вероятно, иногда и из консоли блокируется.

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

Признаю: в прошлой статье про тестирование Caveman я в конце написал, что такие инструменты, как RTK, действительно, могут помочь сэкономить токены. Я доверял самому принципу возможности экономии токенов, но не доверял конкретным цифрам эффективности, которые заявляет Headroom. Был уверен, что, садясь за тесты, скорее всего, увижу, не 60–95% экономии токенов, а типа 10% — или что-то такое. Но результат меня удивил в худшую сторону. Итак, тестируем Headroom вместе:

Привет, Хабр! Прошло достаточно много времени с написания моей первой статьи о сканере, который принёс мне выплату в багбаунти. Кто не знает, его суть в получении технологий на сайте, после чего проверки на CVE в массовом обличье. Сегодня я бы хотел рассказать о том, как он эволюционировал, какие были исправления и новшества.

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

В предыдущих статьях мы разобрались, c Linux и Bash.

Следующая ступенька — Git.

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

На самом деле сегодня Git используют практически все инженеры, работающие с инфраструктурой. В Git хранят не только исходный код приложений, но и Dockerfile, Kubernetes-манифесты, Terraform-конфигурации, Ansible Playbook, Bash-скрипты и CI/CD-конвейеры.

Фактически Git стал центральной точкой любого современного проекта.

Но чтобы понять, почему он настолько важен, сначала стоит разобраться, какие проблемы он решает.