GitHub *

В 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 стал центральной точкой любого современного проекта.

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

После появления ChatGPT и массового распространения GitHub Copilot, Cursor, Claude Code, Windsurf и других AI-инструментов разработка стала заметно быстрее. Код, тесты, README, комментарии и небольшие utility-функции теперь можно получить за секунды.

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

В этой статье я проверяю эту гипотезу на данных GitHub за 2019-2025 годы: через GH Archive, BigQuery, commit messages, README, имена функций и собственный GitHub Uniformity Index.

Хочу рассказать про недавний кейс из своей практики и своих трудовых будней.
Заказчик пришёл с задачей: «Хочу QR-код на сертификатах, чтобы можно было проверить подлинность». У него в голове это выглядело так: он дает мне гугл таблицу с перечнем фамилий, датой, и номером сертификата, скрипт генерирует QR единый для всех сертификатов и как бы этот вопрос закрывается по его мнению. Но при этом должна закрываться самая главная боль - защита от подделки путем переноса QR на другой сертификат. Фактически получалась фикция. С моими возражениями заказчик согласился и я расскажу как мы пришли к криптографическому решению без бэкенда, и покажу конкретный код.

Проблема
Мне как бэкэнд-разработчику приходится работать с деплоем своих проектов, каждый раз одна и та же рутина: настройка сервера, nginx, ssl, безопасность сервера(fail2ban, user), CD и многое другое. Это отнимает очень много времени.

Что сделал
После десятков задеплоенных проектов я понял, что все эти действия можно автоматизировать, и решил написать скрипт.

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.

Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).

Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.

npm install — такая привычная многим из читателей команда, но за последние пару месяцев она обернулась сущим кошмаром для инженеров по безопасности. И ладно бы всё сводилось к проверке 5 пакетов из package.json, но у каждой зависимости по 10 своих зависимостей, а у тех ещё по 10. В итоге мы тянем 2000, а не 5 пакетов, и тут, кажется, уже руками не проверишь. И именно на этой боли всех безопасников, поддерживающих JS-проекты, сыграла команда TeamPCP. В этой статье я хочу подробно, от А до Я, разобраться, в чём опасность, почему так произошло и как от этого защититься.

Привет, Хабр!

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

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

Что такое Git-конфликт?

Во-первых, Git позволяет нам, разработчикам, независимо работать над одним проектом в отдельных ветках. Пока изменения затрагивают разные файлы или разные независимые участки одного файла, Git обычно способен объединить их автоматически. Но что произойдет, если они затронут одинаковый участок файла? Давайте разберемся.

На примере FastAPI-чата показываю, как выстроить автотесты для API с двумя транспортами: REST используется для подготовки состояния, WebSocket — для проверки событий. В статье разбираем архитектуру тестов на Python: клиенты, фикстуры, Pydantic-схемы, контрактные проверки, Allure и CI/CD.

Если вы работаете с Codex, то наверняка замечали  следующее - нажимаешь кнопку “Обновить”, Codex перезапускается, но визуально ничего не меняется.

На самом деле изменения есть - просто чаще всего это не что-то глобальное, а внутреннее: скорость, MCP-инструменты, работа с Git и т.д.

Я посмотрел свежие релизы Codex за последние сутки: 0.142.2, 0.142.1 и несколько 0.143.0-alpha.*. В статье разберём, что уже вышло в свет, а что пока тестируется и возможно выйдет в ближайших обновлениях.

Спойлер: возможно скоро будет новый режим модели Ultra!

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

Как README превращается в PR-актив: структура, нарратив, quickstart

Когда кто-то впервые сталкивается с техническим продуктом, он открывает репозиторий. Инфлюенс, которому прислали питч, инвестор после дежурного «посмотрите наш продукт» делает то же самое, и разработчик, который наткнулся на тред в X, идёт туда же. Репозиторий - первая точка касания для аудитории с реальным весом: инженеры, тимлиды, CTO ранних стартапов, контрибьюторы в опенсорс. Они формируют репутацию инструмента до того, как о нём напишут медиа, их мнение распространяется быстрее любого пресс-релиза.