GitHub *

Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория. 

На первый взгляд кажется, что коммит исчез, но на самом деле GitHub его не стирает. «Удаленный» коммит остается доступен по хэшу — пусть и без прямых ссылок. GitHub продолжает хранить такие коммиты вечно.

В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.

Привет Хабр! Меня зовут Олег, я являюсь действующим QA Engineer в компании Intelsy. Это моя вторая статья после этой (тут могла бы быть ваша реклама), уж очень понравилось делиться информацией и получать обратную связь от читателей! Статья для тех, кто хочет улучшить процессы поставки кода в прод или понять, где можно сэкономить время! Постараюсь немного раскрыть эту тему, поделиться своим мнением (которое ни в коем случае не претендует на звание "истина в последней инстанции"), и да, по традиции помним "у каждого своя кухня". Надеюсь прочтение будет интересным и полезным!

В современных IT-командах границы между ролями стираются: разработчики пишут тесты, DevOps внедряют мониторинг, а тестировщики всё чаще участвуют в процессах, выходящих за рамки классического QA. Один из самых спорных вопросов — должен ли QA инженер заниматься релиз-менеджментом?

Некоторые компании нанимают отдельного релиз-менеджера, другие доверяют этот процесс DevOps, но всё больше организаций приходят к выводу, что именно QA инженер — лучший кандидат на эту роль (Так собственно все работает и у меня на проекте).

 В этой статье мы разберём:

· Почему QA идеально подходит для управления релизами?
· Плюсы и минусы
· Как внедрить релиз-менеджмент в обязанности тестировщика
· Почему отдельная роль релиз-менеджера часто избыточна
· Какие инструменты и метрики использовать для успешного контроля выпусков

 1. Что такое релиз-менеджмент и почему QA должен в нём участвовать?

Релиз-менеджмент — это комплекс процессов, связанных с планированием, подготовкой и развертыванием новой версии продукта. Он включает:

Мы никогда не скрывали, что используем ИИ в своей работе. Более того, считаем, что такие инструменты, как Cursor – это настоящее спасение для разработчиков. Cursor не только ускоряет рутину, но и помогает поддерживать крутое качество кода (если правильно им пользоваться, конечно же), а главное – снимает с команды кучу головной боли, связанной с повторяющимися задачами. 

В то же время у нас есть и собственная гордость – open source фреймворк Admiral, которую мы развиваем для быстрой и удобной разработки административных панелей. В нем уже реализовано множество готовых решений: бери нужные, кастомизируй и запускай свой проект без лишних усилий.

Познакомиться с ней можно тут

Недавно нам пришла идея объединить два продукта. Так мы интегрировали систему правил .cursor/rules прямо в Admiral, чтобы создавать админки можно еще быстрее. Например, теперь не нужно каждый раз перепроверять, правильно ли оформлены CRUD-страницы, корректно ли используются компоненты или соблюдаются стандарты при написании хуков. Все эти моменты изначально заданы в правилах, и Cursor подскажет, если что-то идет не так. Это экономит время, снижает количество ошибок и позволяет сосредоточиться на действительно важных задачах. 

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

Фундаментальная проблема веб-агентов заключается не в автоматизации — а в восприятии. Как позволить LLM навигировать и действовать на веб-сайтах, погребённых в слоях HTML?

В статье рассмотрим, как начать работу с ElBear ACE-UNO в Mac OS. Постарался для вас сделать выжимку, чтобы можно было скорее приступить к работе с платой и потратить на это на пару-тройку суток меньше)

P.S. Для пользователей Windows статья также может быть полезной.

После релиза первой версии стало ясно: Telegram порой ограничивает размер и скорость передачи файлов, а ещё появляется зависимость от внешнего API. Чтобы обойти эти ограничения, я решил встроить официальный сервер Telegram Bot API прямо в своё приложение.

Это позволило:

Раскрываем Docs as Code: как этот подход меняет создание документации, какие инструменты стоит изучить в первую очередь, и с чего начать внедрение.

Подключение датчика VL53L0X к микроконтроллеру STM32F103 и вывод расстояния в реальном времени. Рассмотрены особенности инициализации датчика, настройка I²C-интерфейса и обработка данных. Приведен пример кода на языке C для работы с периферией STM32.

Долго собирался с духом, чтобы написать первую статью. В открытых источников СТОЛЬКО интересной и полезной информации, что вызывает восхищение уровень подготовленности коллег по цеху. 

Сразу предупрежу: вы не найдёте здесь сенсационных "ноу-хау", которыми можно поразить гуру информационной безопасности. Зато тем, кто только выстраивает защиту с нуля или топ менеджменту, эти заметки, я уверен, окажутся практичными.

Чем дольше наблюдаю за отраслью, тем чаще ловлю себя на мысли: публичные дискуссии о развитии SOC сводятся к витрине из мощных SIEM-ов, SOAR-ов и "прокачанных" ML-движков. Да, для компаний с крупным бюджетом и зрелой инфраструктурой это актуально. Но что делать тем, кто только выходит на рынок или просто не дорос до подобных затрат?

В большинстве материалов всё звучит примерно так: "нужно внедрить средства защиты, и ИБ обязана всё контролировать". А что означает это "всё"? Конкретные болевые точки команды безопасности остаются за кадром. Выходит, что советов много, но реальной опоры для тех, кто начинает с чистого листа - минимум.

И ещё одна ремарка. Дорогой и прокаченный софт - не "золотая пуля", а лишь инструмент, который помогает вам, если прежде проделана подготовительная работа: описаны процессы, понятна модель угроз и расставлены приоритеты. Без этого даже самый "умный" продукт рискует стать очередной дорогой коробкой в серверной.

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

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

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

Меня зовут Андрей. Я техник и системный админ. И хоть я незрячий, продолжаю разрабатывать инструменты для автоматизации, системного мониторинга и просто удобной жизни за компьютером. Этот пост — о моём первом публичном проекте, который я решил выложить на GitHub и рассказать о нём на Хабре.

Проект называется AutoCraft Bot. Это гибрид: Telegram-бот и десктопное приложение на Python. Он управляет компьютером, запускает плагины, делает скриншоты, работает с голосом, поддерживает REPL и Telegram API — и всё это в виде одного .exe

Разрабатываем и растим «цифрового губера» - консультанта по вопросам государственного политического управления, демографии и миграции. Решаем задачу оптимизации экономики и миграционной политики для устойчивого демографического роста в 89 регионах с помощью   взаимодействующих друг с другом и обменивающихся опытом ИИ-агентов, на основе мутаций, скрещивания и эволюции.   Мультиагентное обучение,  Multi-Agent Deep Deterministic Policy Gradient и Darwin Gödel Machine.

Привет! Меня зовут Влад и занимаюсь Python backend-разработкой. Довольно долго я работал над большим продуктом, который объединял несколько команд разработки. В нем было много микросервисов, базовые фичи кочевали из одного в другой, и часто разработчики делали одни и те же инфраструктурные компоненты по-разному. А когда переходили с одного микросервиса на другой, им приходилось долго осмыслять кодовую базу нового решения.

Код полнился ошибками, а разработчики тратили время на их отладку и исправление. Так мы вживую воплотили печальную статистику: разработчики ПО в среднем тратят на написание кода лишь [52 минуты в день](https://www.software.com/reports/code-time-report), остальное — исправление ошибок и другие сопутствующие задачи.

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

Современные голосовые помощники это мощные приложения, сочетающие обработку речи, машинное обучение и интеграцию с внешними API. В этой статье мы разберём, как создать базовый проект персонального ассистента на Python, используя библиотеки whisper, webrtcvad, gTTS и другие. Наш ассистент будет: слушать микрофон; определять начало и конец речи с помощью VAD (Voice Activity Detection); преобразовывать речь в текст через модель Whisper; отправлять запросы на локальный LLM для генерации ответа; читать ответ вслух с помощью gTTS; начинать/останавливать запись по нажатию клавиши.
Проект может служить как началом для экспериментов, так и для прототипирования реальных решений.

Большой обзор: от идеи и структуры — до неожиданных выводов и практических сценариев применения

SLAVA — это открытый русскоязычный бенчмарк, разработанный экспертами РАНХиГС и ИСП РАН для проверки, как большие языковые модели справляются с фактологическими и ценностно нагруженными вопросами по истории, обществознанию, географии и политологии. 

В корпусе — 14 199 заданий пяти форматов и трёх уровней провокационности. Уже протестировано более 40 моделей: от GPT‑4o и Claude‑3.5 до GigaChat и Llama‑3 8B. Это открытый русскоязычный бенчмарк, созданный для проверки, как большие языковые модели справляются с фактологическими и ценностно нагруженными вопросами из истории, географии, обществознания и политологии. 

Научись использовать Git как профессионал. Эта статья поможет тебе освоить самые популярные команды Git на реальных примерах. Узнай, как добавлять изменения, создавать коммиты, переключаться между ветками, объединять изменения и синхронизировать проект с удалённым репозиторием.

После первой статьи про стандарты разработки и зарождение Open vAIR остался резонный вопрос: «А что там под капотом?». Отвечаем.

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

Внутри — модульный backend, изоляция через RabbitMQ, REST API и документация, которая обновляется вместе с кодом, а не спустя квартал.

В этой статье разберём, чем Open vAIR отличается от тяжёлых решений, что умеет прямо сейчас, какие модули в приоритете — и в каких сценариях он уже «заходит в прод».

Сегодня расскажу, как построил систему, которая клонирует и сканирует тысячи публичных GitHub-репозиториев — и находит в них утекшие секреты.

В каждом репозитории я восстанавливал удаленные файлы, находил непривязанные («висячие») объекты, распаковывал .pack-файлы и находил API-ключи, активные токены и учетки. А когда сообщил компаниям об утечках, заработал более $64 000 на баг-баунти.

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

Продолжение истории о том, как я пытался реализовать подпись файлов с помощью сертификата на USB-устройстве, но уже с использованием USB-токена Рутокен 3.0, а дополнительно сделал шифрование и расшифрование директории.