Всем привет!

Недавно мы с приятелем обсуждали, как устроены рабочие процессы в бигтех-компаниях и какую роль в них уже играет ИИ. Речь в основном шла о зарубежных компаниях — у него там есть знакомые, которые делились опытом изнутри. Один из самых любопытных моментов — использование искусственного интеллекта для предварительного код-ревью в Pull Request: прежде чем коллеги возьмутся проверять изменения, PR уже анализирует ИИ и указывает на потенциальные проблемы.

Эта идея меня зацепила, и я решил изучить, какие готовые решения уже существуют (кроме встроенного в GitHub Copilot). Из более-менее крупных нашёл только PR Agent. Я протестировал его, но по ряду причин он мне не подошёл: хотелось больше гибкости, настройки под свои нужды и возможности запускать всё самостоятельно, без передачи кода сторонним сервисам.

Так родился проект ReVu — self-hosted инструмент для автоматического код-ревью в Pull Request с помощью ИИ. Он универсален, легко кастомизируется и не требует доверять исходный код внешним платформам.

Если вам интересны подобные материалы и проекты, подписывайтесь на Telegram-канал «Код на салфетке» — там я делюсь гайдами для новичков, историями разработки и полезными инструментами.

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

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

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

Отсюда сформулируем главные вопросы, на которые мы ответим в этой статье:

- Нужно ли вам писать юнит тесты под ваши задачи? Или лучше выбрать другой тип тестирования и ограничиться только им?

- Если все же да, то как тогда писать юнит-тесты? Какие есть подходы, и какой лучше выбрать?

Короче, всё как обычно: как и нафига?

Как пить из чашки, если у неё нет дна, а верх запаян? Эта милая загадка, которую я припоминаю ещё из старших классов школы, стала чрезвычайно мемной минувшим летом, когда выяснилось, что она ставит в тупик самые современные языковые модели. ChatGPT оказывается на удивление наивен, сталкиваясь с ней:

Привет Хабр! Меня зовут Алексей и я занимаюсь беспроводными технологиями. Собственно беспородными технологиями я занимаюсь уже около 20 лет. И сегодня хочу представить на ваш суд большой FAQ по вопросам так или иначе связаны с wi-fi. Этот список я начал формировать еще на заре свей карьеры, когда обучаясь в вузе подрабатывал в службе технической поддержки провайдера, и чуть позже когда работал монтажником и общался с клиентами. После этого было много чего, разные должности, проекты но так или иначе я возвращался к списку вопросов, актуализировал его для друзей, для новых коллег и т.д. Надеюсь он будет для вас полезен. Его можно использовать как угодно, в том числе и для тиражирования.

Анализ вредоносных программ, защищающих себя от анализа, — это всегда дополнительные трудности для вирусного аналитика. Точнее, постоянная борьба. Злоумышленники постоянно придумывают и дорабатывают свои методы обфускации или используют готовые продвинутые решения, которые были созданы для защиты легитимного программного обеспечения от анализа и взлома, как, например, протектор VMProtect. Его сейчас очень активно применяют китайские вирусописатели для защиты своих вредоносных драйверов Windows x64. Известно, что анализ подобных драйверов — головная боль для вирусных аналитиков. Получив очередной такой объект на анализ, Андрей Жданов, специалист по проактивному поиску киберугроз Group-IB, решил поделиться достаточно простыми подходами, которые облегчат анализ этих вредоносных программ.

Скажу честно: первое, о чем я подумал, когда услышал про эту тему, это Робо-няня из «Смешариков». В детстве она казалась мне немного тревожной, но ее способность делать все сразу впечатляла. Тогда я думал: как было бы хорошо, если бы такие технологии были у каждого.

Прошло всего несколько лет и они действительно появились. Нейросети сегодня повсюду: на улицах улыбаются котята с рекламных баннеров, в социальных сетях бомбардировщик с головой крокодила собирает миллионы лайков. Для многих алгоритмы стали инструментами, которые помогают решать десятки задач. Но этих инструментов стало так много, что выбрать бывает непросто.

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

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

Приятного чтения!

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

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

Почему это важно? Такой сдвиг — не просто удобство для разработчиков, а первый реальный шаг к тому, чтобы ИИ начал по-настоящему работать с физическим миром. Как это получилось, где скрыты ключевые идеи и почему новая архитектура может стать стандартом для всего IoT — рассказываю простыми словами.

Всем привет! Меня зовут Илья. Я давно читаю habr, не так долго занимаюсь программированием и еще чуть меньше времени хочу написать здесь статью. Не то, чтобы это идея фикс (или hotfix), но лучше опубликоваться и жалеть, чем поставить в план на «когда-нибудь потом», ничего не сделать, и «получить за это премию». Таких задач у меня уже накопилось на несколько жизней вперед, поэтому, приняв волевое решение, я выделил время на графоманию.

В прошлом мне доводилось писать околонаучные статьи и вести блог про путешествия, совершенные в разных стадиях трезвости (на рецензируемые статьи ВАК про пьяные авантюры, к сожалению, не хватило грантов). Но поскольку срок давности по этим событиям давно прошел, а все самое значимое я забыл, то опишу свой недавний опыт, связанный с OpenSource. 

Идея открытого программного обеспечения мне нравится. Люди, создающие OpenSource проекты вызывают интерес, особенно, когда их продукты востребованы и конкурентноспособны. Двигать индустрию IT в свободное от работы время, вместо того, чтобы предаваться гедонизму — достойно уважения. Особенно, когда сам активно пользуешься подобными продуктами, вместо платных аналогов или ручного труда.

Недавно на работе передо мной возникла задача максимально быстро погрузиться в автоматизированное тестирование с ранее мной не использовавшимся фреймворком pytest. Почитав порядка десяти статей на Хабре я понял, что в каждой из статей есть много всего интересного, а чтобы системно погрузиться — необходимо идти читать документацию. Я решил, в привычной мне манере, разобраться и систематизировать самый сок для того, чтобы быстро въехать в суть и важные тонкости положив основу для дальнейшего использования. 

Всем интересующимся — добро пожаловать под кат!

Хочу поделиться своим опытом перехода с Chrome браузеров на Firefox.
Изначально я хотел добавить комментарий к одноименной статье, но в процессе написания понял, что комментарий будет слишком длинным и его увидит мало людей. Отдельная статья лишней не будет в продвижении остатков свободы в виде браузера от Mozilla Corporation.

Долгого предисловия не будет, в телеграм не приглашаю. Идём сразу к делу.

Разбираем создание «Сапёра» на Python. Идеальный проект для начинающих, чтобы на практике освоить Pygame и основы геймдева.

Внутри — подробное пошаговое руководство, где мы:
• Настроим рабочее окружение с venv.
• Напишем игровую логику с нуля, отделив её от графики.
• Реализуем рекурсивный алгоритм для открытия пустых полей.
• Отрисуем всё на экране и научим игру реагировать на клики.

Я раньше работал обычным безопасником. Кто-то называет таких «ИБшниками», кто-то — «параноиками», кто-то — «тем самым занудой, который мешает жить».
Каждый день у меня был один и тот же диалог:

• Тимлид: «У нас релиз в пятницу, отстань со своим сканированием».
• Менеджер: «В бюджете только Jira и пицца, какие ещё 15 миллионов за софт?»
• Разработчик: «Код сгенерил AI, билд прошёл, значит, всё норм».

Я тут периодически пишу про всякие штуки, с использованием shell‑скриптов и разных linux‑утилит — в частности, чтобы лишний раз продемонстировать, что в линуксе не обязательно требуется «найти программу которая умеет делать ХХХХХ» — во многих случаях у вас уже есть всё необходимое, нужно только знать как использовать.

Вот, например, такая задача. У меня выход в интернет через роутер Keenetic. Роутеры эти неплохие, умеют, в частности, вести контроль работоспособности нескольких подключений, автоматически переключаться между ними.
Отвалилось соединение по каналу А — переходим на канал Б. Восстановилось — переходим обратно. Очень удобная функция.

До недавнего времени работало идеально, в том смысле что всё происходило само собой, и об обрыве канала А я узнавал только из воплей в местном чате.
Но с некоторого времени провайдер Б начал блокировать что не надо, и создавать проблемы на ровном месте, а поэтому потребовалось принимать некоторые меры безопасности.

Но для этого надо отлавливать факт переключения. И как это сделать, если роутер не умеет об этом как‑либо оповещать?

Компьютерные игры прошли громадный путь — от аркад 70-х до современных AAA-проектов, стоимость которых сопоставима с крупнейшими инженерными постройками. Геймдев — это не только искусство создания миров, но и многомиллиардная индустрия, где экономика играет ключевую роль.

Разработка AAA-игр требует бюджетов в десятки и сотни миллионов долларов, а рынок инди-игр и пользовательского контента ежегодно приносит миллионы благодаря платформам вроде Steam и моддинг-комьюнити. Моддеры, создавая дополнения для таких игр, как Skyrim или Minecraft, не только расширяют игровой опыт, но и формируют целые экосистемы с собственной экономикой: от донатов на Patreon до продаж модов. В этом мире Python становится всё более полезным инструментом — как для разработчиков, так и для продвинутых геймеров.

Захотелось рассказать про один из своих старых концептов. Уже можно, NDA закончилось.
На 2023 год задачка была и правда не тривиальной.

А еще, визуально закрепить, что идея не обязана выглядеть как вылизанный проект на Dribbble.

Сегодня мы заходим на сайты, пользуемся приложениями, скачиваем данные — всё это через протокол HTTP. Он стал стандартом более 30 лет назад и до сих пор остаётся основой Всемирной паутины. Но он не идеален. Централизация, уязвимости к цензуре, проблемы масштабируемости подталкивают разработчиков к поиску альтернатив. Одной из самых известных идей стала технология IPFS. Эта идея обещает создать новый, децентрализованный интернет, где информация будет жить дольше, быть доступнее и устойчивее. Но непонятно, готовы ли мы к такому переходу? И действительно ли IPFS может заменить HTTP?

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

Меня зовут Ирина, я IT-рекрутер в компании SENSE. И сегодня хочу поговорить о проблеме, которую сложно не заметить, если вы так или иначе связаны с наймом, обучением или карьерой в сфере технологий. Вокруг нас полно курсов и карьерных консультантов, которые заманивают яркими обещаниями быстрого успеха, а в итоге создают коллапс на уровне джунов и даже задевают мидлов. Под красивой обёрткой скрываются псевдоэксперты и псевдопрограммы, последствия которых приходится разгребать работодателям, рекрутерам и самим соискателям.

Привет! Это эксперты курсов английского в Практикуме. Возможно, вы замечали, что в начале изучения английского прогресс гораздо более явный: с каждым уроком становится больше знакомых слов, понятнее тексты и диалоги. Но со временем развитие замедляется.

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

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

Привет, Хабровчане! Этот цикл (надеюсь) статей будет посвящён моему пути в создании своего собственного решения по струйной печати. Это будет что-то вроде блога или дневника разработчика в котором постараюсь изучить как же всё таки работает печатающая головка у принтера и как ей можно управлять с помощью микроконтроллера. А также нас ждёт интригующий ответ на вопрос: "Если ли место DIY и OpenSourse в мире струйной печати".

Открытый порт — это не «дырка в фаерволе», а процесс, который слушает сокет. В материале разбираемся, где заканчивается приложение и начинается сетевой фильтр: как корректно отличать listening от доступности снаружи, чем проверять (ss, lsof, nmap), и как на практике управлять правилами в nftables, firewalld и UFW. Поговорим о well-known портах и CAP_NET_BIND_SERVICE, типовых политиках (allow/deny), логировании и безопасной последовательности действий, чтобы не уронить прод. Текст для системных администраторов и DevOps/SRE, которым нужна понятная и проверяемая методика без мифов и магии.