GitHub *

Если вы ищите работу и у вас много телеграм-каналов с вакансиями, слова апи, python, гитхаб вам знакомы, то вам будет полезно. Мой кейс: когда я искала работу то смотрела по 50+ постов в день в десятках каналов в телеге, из них подходящих вакансий было штук 10, одна и та же вакансия висит в четырёх каналах, половина постов это курсы и "ищу работу", фильтров никаких. Платить за агрегатор мне не хотелось.

Собрала свой сервис, который вы можете адаптировать под любую роль: скрипт читает папку каналов в Telegram, отсеивает не-вакансии, вытаскивает компанию, грейд, город и зарплату, склеивает дубли и раз в день выкладывает одну страницу с фильтрами на GitHub Pages. Стоимость - ноль, ключи нужны только от Telegram.

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

Экспортер написан на Go и совмещает функции сборщика метрик, логов, проверки обновлений образов и встроенной панели мониторинга в одном легковесном образе.

MCP-сервер - это по переходник между ИИ и внешним сервисом. Например, один MCP читает файлы на ПК, другой - программирует, третий - ищет инфу в интернете. 

То есть ИИ в основном отвечает на вопросы, анализирует и генерит картинки, а через MCP он может еще подключаться к Figma, Google Drive, базе данных, браузеру, почте и тысячам других сервисов.

В этой подборке я собрал 100 самых популярных MCP-серверов - вместе они набрали ⭐3.1 млн звезд на GitHub.

Мода на квантизацию скоро закончится...когда появятся они: модели, обученные на тернарной/тритовой/троичной логике.

Или нет?

Пройдемся по форматам обучения от FP32 до FP4, а потом сделаем аналог модели Microsoft Bitnet 1.58 на C#, размером 29Кб (в экстремальном варианте — 17,1 КБ).

Я написал бота на Python, используя библиотеки kurigram, yt‑dlp и ffmpeg. Данный бот умеет скачивать что‑то (в зависимости от площадки) из следующих платформ: YouTube, TikTok, Instagram, Pinterest, Rutube, VK, Spotify, Shazam, Yandex Music, SoundCloud, VK Music, Deezer, Apple Music, Tenor, JioSaavn, Twitch (только клипы), Snapchat, Reddit, Kinopoisk.

Как завести свой Git на небольшом VPS и не превратить его обслуживание в отдельный проект? Показываю свой путь с Gitea: настройку пользователей и SSH, перенос репозиториев из GitHub и подключение CI через Gitea Actions. А затем проверяю бэкап делом - восстанавливаю из внешней копии. С командами, ошибками и оговорками по безопасности - для личных проектов и небольших команд.

Привет! В предыдущей статье https://habr.com/ru/articles/1042328/ я рассказал о математической оценке коэффициента шума (КШ) методом отношения сигнал-шум. Сегодня перейдем от теории к практике - к автоматизации радиоизмерений. Покажу, как построить гибкую систему управления измерительными приборами на Python, которая не боится разношёрстного парка оборудования в лаборатории.

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

Если вы так же знакомы с этими проблемами, а также с другими проблемами при работе с Git — эта статья для вас.

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

Как я навайбкодил панель для Wireguard ASC 3.x чтобы не просто безопасно выходить в Интернет, но и объединять устройства в одну сеть.

Привет, Хабр! Однажды я подумал, что вот не умеют разработчики жить. В каждом из языков есть свои напасти (от которых, в принципе, спасаются разве что разработчики-полиглоты). Возьмем хотя бы C++ — даже без его шаблонов, исключений, и т.д., там все еще много мраков. Возьмем хотя бы iostream — он, блин, весит 2 МБ в последней версии GCC при компиляции под Windows! Или, вот, std::string — динамическая строка. Звучит интересно на бумаге, учитывая, что язык не из добрейших, но на практике...

README редко ломается в один момент.

Обычно он просто постепенно перестаёт соответствовать проекту: переименовали команду, перенесли файл, удалили .env.example, сменили package manager — а инструкция осталась прежней.

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

Мне стало интересно: можно ли автоматически находить хотя бы часть таких расхождений, не выполняя команды из README и не отправляя исходный код в LLM?

Так появился RealityLint — open‑source CLI, который статически сверяет проверяемые утверждения из README с реальным состоянием репозитория.

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

С диагностикой нам уже помогает агент из первой и второй частей — но это только полдела. Дальше начинается самое муторное: инженер должен понять, где именно нужно внести изменения, оценить, сможет ли он сделать их сам или тут нужен разработчик, найти нужный репозиторий среди десятков похожих, внести правку, прогнать её через 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 году по числу затронутых пакетов. Называть её «крупнейшей хакерской атакой года» вообще некорректно: такой вывод потребовал бы сопоставления с атаками на телекоммуникационные сети, государственные системы и крупные корпорации, для которого открытых данных нет.