GitHub *

За свои 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 ранних стартапов, контрибьюторы в опенсорс. Они формируют репутацию инструмента до того, как о нём напишут медиа, их мнение распространяется быстрее любого пресс-релиза.

Что будет, если взять один HTML-файл, браузер, localStorage и git-хостинг с CRUD API? Получится мессенджер. Без backend, базы данных, регистрации, npm и WebSocket. В статье показываю, как устроен Macaroni Messenger: хранение сообщений в .macaroni/, outbox, git-agnostic adapters, storage branch, plugin API и опциональное шифрование.

Это история о том, как я нашел 10.000 репозиториев в GitHub, в которых находится ссылка на скачивание zip архива. В этом архиве — троян. Все эти репозитории от разных контрибьюторов, с разным названием и не являются форками других репозиториев. Даже если мы найдем один такой репозиторий, мы не сможем по нему найти другие репозитории. Но у всех них есть одинаковый паттерн, который и позволил написать скрипт для поиска таких репозиториев.

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

Что он обещает? Идея простая — скилл указывает нейронке говорить, как пещерный человек, убирать артикли, говорить коротко и думать лаконично. На первых строках README обещается экономия до 75%. При этом без потери качества!

Но работает ли все это на самом деле? Ведь 75 000 звёзд на репозитории не могут ошибаться?

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал».

Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено.

В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет.

Если у вас приватные репозитории на GitHub и команда, которая регулярно упирается в лимит времени GitHub Actions, эта статья сэкономит вам пару недель экспериментов. Рассказываем, как мы подняли self-hosted раннеры в Docker, настроили их репликацию через Docker Compose и почему в итоге пришли к Docker-in-Docker. Разобрали по шагам эволюцию решения от Bare Metal раннеров до докеризованной конфигурации. Репозиторий с настройкой находится в открытом доступе.

Как превратить крик души в работающую утилиту и попасть в официальную ArchWiki? Мне 17 лет, и мне просто надоело тянуть HDMI-кабель от ноутбука к телевизору через всю комнату. В этой статье я расскажу, как написал свой стример экрана FluxCast на Python, с какими багами Smart TV пришлось столкнуться и как устроен «слепой» дебаг проприетарного железа по логам пользователей со всего мира.

Звук сегодня является важным интерфейсом. Работа с чат-ботом своей "ИИшечки" упрощается в разы. Кроме того, помимо вайб-кодинга - есть еще и обычная жизнь - с совещаниями, лекциями, собраниями, которых столько, что не успеваешь фиксировать все, о чем было обсуждение. С этими мыслями, а также увидев потрясающий по своей внешней эстетике приборчик - был заказан ИИ-диктофон PLAUD. Но. Ограничения для России такие, что заплатить за сервис (ок 20 тыс. руб.) - не получилось. Но, уже появилось желание и даже потребность в удобном цифровом распознавании. Конечно, были установлены все простые приложения на телефон, а также распознавание в Telegram, но все это было не то. Сформилировал требования, которые у меня есть:

Если ваш проект перерос стадию “просто собрать” и теперь требует бесперебойной работы в проде, простого пайплайна больше недостаточно. Главная боль — как исключить downtime и иметь возможность мгновенного отката? В третьей части цикла разбираемся с GitLab Container Registry.

Мы настроим хранение версий Docker-образов, разберем подводные камни Docker in Docker (dind) и SELinux, а также автоматизируем тестирование перед выкатом. Наконец простейший скрипт для запуска контейнера на production-сервере из вашего приватного Gitlab Registry.

KODE.market: Как я написал первый в мире поисковик по GitHub и GitLab + P2P-раздатчик open-source кода + Антивирус.

Без модерации, комиссий и SEO-мусора. Мгновенный поиск, проверка идей + гибридная раздача релизов в одном инструменте.

Привет, Хабр! На связи TechnoL0g. Если вы хоть раз пробовали опубликовать своё детище в официальных сторах или годами поддерживали open-source репозиторий, то прекрасно знаете, сколько боли приносит классическая дистрибуция.

В 2026 году уже не нужно гадать, человек писал GitHub-репозиторий или AI. Я сделал Chrome-расширение, которое оценивает репозиторий по прозрачным эвристикам: README, коммиты, структуру файлов и метаданные. Без нейросети, без чёрного ящика — только понятные правила и объяснимый вердикт.

В статье рассказываю, как появился детектор, почему просто “число AI-похожести” оказалось недостаточно, как я перешёл к профилям вроде “AI-код”, “AI-документация” и “код человека”, и какие сигналы реально помогают отличать vibe-coded репозиторий от ручной работы.

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

Реализация построена на FluxCD с использованием директивы postBuild для шаблонизации манифестов через переменные. Каждое окружение получает собственный namespace, базу данных, TLS‑сертификат и уникальный URL — и всё это без ручного вмешательства. Разбираем структуру CI/CD пайплайна, слоёвую организацию GitOps‑репозитория и автообновление образов через ImagePolicy.

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

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

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Всем снова привет!

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

В этой статье мы разберём, как действовать и, главное, мыслить в таких ситуациях. Проблема в том, что конфликтов в git может случиться куча: может сломаться ручной git merge, при git pull, может полететь при git rebase , git cherry-pick и т.д. Из-за этого одного конкретного решения нет, но зато есть общий принцип решения.