GitHub *

Представьте парк аттракционов, фуд-корт на фестивале, корпоративную столовую или сеть автомоек. Что их объединяет? Всем им нужна своя закрытая платёжная система или внутренняя программа лояльности (клубные карты).

Обычно внедрение такой системы — это боль. Нужно покупать дорогие терминалы, нанимать интеграторов и пилить самописный софт. А что делать, если система нужна «на один раз» (для трёхдневного фестиваля) или у малого бизнеса просто нет бюджета?

Меня зовут Никита, и я решил закрыть эту боль, заодно прокачав своё портфолио. Я разработал легковесную, open-source альтернативу закрытым платёжкам, которая работает прямо в браузере, не требует скачивания приложений и сложного железа.

Под капотом — классический стек React + Node.js и капелька технологии в виде WebNFC.

Мне давно нравится идея хранить заметки обычными Markdown-файлами в своём репозитории на GitHub. Файлы остаются твоими, их можно открыть на github.com или в любом редакторе, а история изменений достаётся даром: это просто коммиты.

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

Я переписал его так, чтобы сервер был не нужен вовсе. Получился Notewing: браузер сам ходит в GitHub API, изменения копятся офлайн и отправляются одним коммитом, а конфликтующие правки не теряются. В статье расскажу, как устроена синхронизация через Git Data API, где были подводные камни и как всё это тестировать, не трогая настоящий GitHub.

За месяц дайджест трендов GitHub про ИИ-агентов принёс мне 138 уникальных репозиториев. Я взвесил каждый, ничего не запуская: скачал архив через API и посчитал отдельно код, прозу, тесты и сгенерированное. 56 % оказались платформами, которые форкают только с намерением сопровождать. Лёгких, которые можно переписать под себя за вечер, всего 24, и половина из них вообще не инструменты. Лицензия оказалась фильтром раньше веса: у 9 репозиториев её нет совсем, а один файл начинается словами MIT и ниже запрещает коммерческое использование. В статье метод, таблицы и три признака накрутки звёзд, которые я пытался автоматизировать и которые не сработали.

Если вы ищите работу и у вас много телеграм-каналов с вакансиями, слова апи, 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".