Kurgan-Telecom Ru | Информационные технологии

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

Во что играть? Я собрал проекты российских разработчиков – от небольших инди-студий до крупных компаний мирового уровня. В списке шутер от первого лица, ностальгический квест с умным юмором, головоломки и настоящая легенда (вполне ожидаемая). Все эти игры работают в офлайн-режиме. Прямо как во времена, когда диски вставляли в компьютер (уходит эпоха), а «Змейка» на телефоне не знала об интернете. 

Обязательно дополняйте список своими любимыми играми.

Для команд, разрабатывающих приложения, базы данных должны ощущаться как решённая задача. Команде нужен PostgreSQL, MariaDB, Redis или другой сервис данных, она отправляет запрос, получает учётные данные и начинает разработку. На практике всё редко оказывается настолько просто.

В 2026 году многие организации заметно продвинулись в платформенной инженерии и внедрении Kubernetes, но подготовка баз данных остаётся фрагментированным. Команды, которым нужен cloud-native-опыт разработчика, часто сталкиваются с неудобным компромиссом: операционная ответственность против зависимости от платформы.

С одной стороны, разработчики могут сами эксплуатировать базы данных с помощью операторов Kubernetes. С другой стороны, платформенные команды могут предоставить управляемый опыт через внутренние платформы и системы провиженинга, часто опираясь на управляемые облачные сервисы. Оба подхода работают, но у обоих есть ограничения.

В итоге организации снова и снова изобретают решения одной задачи, ставшей распространённой платформенной проблемой: предоставление возможностей Database-as-a-Service (DBaaS, база данных как сервис, выдача БД по запросу как готового сервиса), которые работают одинаково в разных окружениях.

Команда VK Cloud перевела статью о том, как в 2026 году устроен provisioning баз данных в Kubernetes-инфраструктуре: почему модель service broker из Cloud Foundry не прижилась в облачных экосистемах и как open source-проект Klutch.io пытается создать Kubernetes-native стандарт для Database-as-a-Service. Материал будет полезен платформенным инженерам, DevOps- и SRE-специалистам, а также техническим руководителям, которые выстраивают внутренние платформы для баз данных в гибридных и on-prem-окружениях.

В конце июня по соц. сетям разлетелась новость от РБК про претензии от налоговой к 50 резидентам «Сколково». В сообществе начали говорить о том, что  государство взяло под прицел резидентов, льготы заканчиваются, а сам статус превращается в источник дополнительных рисков. Что же произошло на самом деле?

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

Как измерить человеческую глупость? На первый взгляд, кажется, легко: измерить IQ, делов то! Но не все так однозначно. Как Вы сподвигнете человека на 2 часа интенсивных умственных нагрузок (а столько времени занимает прохождение теста)? Но даже замерив IQ, можно ли однозначно по нем делать вывод о глупости человека? К примеру, если замерить IQ Дон Кихоту и Санчо Пансо, у кого он окажется выше? А кто из них более глупый? В данной статье не только предлагается операциональное определение глупости, но и готовый бесплатный open source инструмент для ее измерения в течении 3-х минут. Поехали!

Запустить ИИ-агента на багбаунти — дело пяти минут. Зато превратить его поток сознания в принятые отчеты, чтобы не словить бан за спам и минус в рейтинге, — задача со звездочкой.

Привет, Хабр! Меня зовут Владислав, я работаю в отделе реагирования на инциденты в Бастионе и около полутора лет активно ханчу на багбаунти. Под Новый год мы с другом так пробили ИБ-интегратора (он, кстати, остался доволен), а недавно я выиграл Bug Zone 7.0. Подобные активности — хорошая возможность поэкспериментировать и выработать новые подходы, и последние полгода я ищу баги при помощи LLM. Так что с ИИ можно добиваться хороших результатов, а не сдавать мусор. Но как это делать? 

Под катом вас ждут: 

• четыре подхода к ИИ-багхантингу; 

• четыре способа платить за модель; 

• три слоя верификации;

• пайплайн из двух агентов; 

• живой разбор blind SSRF. 

Спойлер: готовой кнопки «сделать хорошо» не ждите. 

Статья будет интересна всем, кто уже натравливал ИИ на BB-программу и тонул в фолз-позитивах, а также новичкам и матерым этичным хакерам — хотя последним отдельные рекомендации наверняка покажутся очевидными.

Представьте, что вы купили беспроводную колонку. Колонка отработала полгода, а в одно утро просто перестала включаться. В сервисе разводят руками: дело в плате, чинить дороже, чем купить новую.

Причина такой поломки бывает старше устройства. Ошибку сделали ещё на компьютере, когда проектировали плату. Она пережила производство, проверки, сборку и полгода работы. Внутри с первого дня осталась заводская химия, которая за полгода “съела” важный проводник.

Я ловлю такие ошибки, пока проект печатной платы не ушёл в производство. Почти вся моя работа состоит из вопросов к такому проекту. Сейчас расскажу, откуда в файлах берутся ошибки, которые не видит даже их автор, и как против них работают правильные вопросы.

Я заменил std::deque на boost::circular_buffer в надежде получить прирост производительности. В реальности получил загрузку процессора в 25% вместо 2%.

Картинка: Peter F. Yanczer, earlytelevision.org

Всем известно такое устройство, как видеопроектор. Они широко используются для целей образования, бизнеса и даже для дома.

Перечень их основных технологий тоже известен — DLP, 3LCD, LCoS.

Однако как вам понравится, пожалуй, один из самых странных (и потрясающих с технической точки зрения!) проекционных аппаратов в истории — видеопроектор на электронно-лучевой трубке?! О_о Где электронно-лучевая трубка — это только маааленький кусочек странностей!

Как старый поклонник видеопроекторов, я никак не мог пройти мимо этой темы… :-) Итак…

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

Быстрые команды удобнее не только пользователям, но и системе: запросы через слово «Алиса» требуют обращения к модели распознавания речи ASR, которой из‑за её размеров необходимы серверные вычислительные ресурсы, а модель быстрых команд устроена гораздо компактнее. Она работает прямо на устройстве, а значит, ограничена вычислительными ресурсами самой колонки — её CPU и оперативной памятью. Из‑за этого модель нельзя сильно увеличить: ей приходится оставаться компактной, зато запрос обрабатывается быстрее. 

За распознавание быстрых команд отвечает нейросеть. Её архитектура почти полностью совпадает с решением для наушников Яндекс Дропс, которое подробно описал в своей статье Григорий Афанасенко. Разница в основном в масштабе: наша модель весит всего от 0,5 до 1,5 МБ в зависимости от железа конкретного устройства.

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

В начале июля разработчик Ноа Кейгл выпустил Hannah Montana Linux v26.0 — современный ремастер того самого розового дистрибутива-мема из 2008 года. Тут можно улыбнуться, поностальгировать и решить, что вся новость закончена, но давайте не будем спешить. За этой несерьезной обложкой прячется на редкость наглядный пример того, что такое дистрибутив Linux на самом деле. А заодно становится понятно, почему нельзя просто оставить старую версию и жить дальше. Тут надо разобраться во всем по порядку и ответить на некоторые вопросы. Этим и займемся.

Более 40 лет архитектура x86 оставалась незыблемой основой индустрии вычислений. Именно на ней построены практически все процессоры Intel и AMD, а вместе с ними — настольные компьютеры, рабочие станции и серверы.

Однако в 2020 году ситуация начала меняться. Компания Apple объявила об отказе от процессоров Intel в пользу собственных чипов Apple Silicon на базе архитектуры ARM, которая до этого ассоциировалась преимущественно со смартфонами и планшетами. Для корпорации из Купертино это был один из самых рискованных шагов за последнее десятилетие: вместе с архитектурой нужно было изменить операционную систему и инструменты разработки, а также обеспечить совместимость огромного массива программ, написанных для x86.

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

Вслед за Apple на ARM сделали ставку Qualcomm и Microsoft, а весной 2026 года к ним присоединилась Nvidia. Когда сразу несколько крупнейших игроков отрасли начинают двигаться в одном направлении, это становится важным сигналом для всего рынка.

Действительно ли компьютерная индустрия стоит на пороге крупнейшей трансформации со времен появления IBM PC, или же успех Apple так и останется исключением из правил? Чтобы ответить на этот вопрос, разберемся, как x86 стала мировым стандартом, почему сегодня ее позиции начинают слабеть и какое будущее эксперты прогнозируют рынку вычислительной техники.

Привет, Хабр! Мы — команда разработки кредитных продуктов для физических лиц в Т-Банке. Делимся опытом нагрузочного тестирования workflow-движка Zeebe (основы Camunda 8), который проводили, когда искали альтернативу Camunda 7.

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

Решение встроить PDCA (цикл Деминга) в рутину топ-менеджмента выросло из стратегических сессий. Инициатив после каждой оставалось много, но проверенных выводов ни одного.

Замысел такой. Каждое значимое решение оформляется как гипотеза с ожидаемым результатом (Plan), выполняется (Do), факт сверяется с ожиданием (Check), по итогам гипотеза закрепляется в практике или отбрасывается (Act).

Расчёт был на то, что управленческие решения это те же гипотезы, просто их почти никогда не проверяют, и цикл превратит поток инициатив в накопление выводов.

В этом обзоре я разберу 10 популярных платформ через призму Day 2 Operations — того этапа жизненного цикла системы, который наступает через год после внедрения (т.е. эксплуатация, обновления, масштабирование). Попытка внедрить в этот процесс требования ИБ, транзакционность и логирование постфактум часто обходится дороже самого внедрения.

Всем привет! Меня зовут Егор Гурин и я разработчик в компании MTC Web Services. Работаю в стриме, который занимается разработкой контактного центра МТС. Практически любые обращения клиентов в компанию, будь то неработающий интернет или вопрос по заказу в интернет-магазине, проходят через нас. 

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

В этом материале я поделюсь инструментами, которые помогли наладить процессы в нашей команде в рамках методологии Document Driven Development, — возможно, вам она знакома под такими терминами как design-first или API-first. Покажу, как в удобной форме описывать контракты с помощью TypeSpec, использовать мокирующие сервера не дожидаясь реализации серверной, а еще — расскажу про инструмент кодогенерации на Go и автотесты с помощью Schemathesis.

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

С вами Кирилл Бибиков, технический архитектор СОФРОС. Буду делиться с вами полезной информацией, касаемо продукта компании СОФРОС - мониторинг сообщений OneView.

Есть технологии, которые вспыхивают ярко, несколько лет находятся на пике популярности, а затем постепенно исчезают, уступая место чему-то новому. А есть SOCKS5.

Он появился в 1996 году, когда массового HTTPS ещё практически не существовало, контейнеры оставались делом будущего, а облачные сервисы скорее напоминали научную фантастику. За это время вокруг него успело измениться почти всё. Появились NAT и IPv6, повсеместный TLS, HTTP/2, HTTP/3, QUIC, контейнеры, облачные платформы и Zero Trust. Сам SOCKS5 при этом почти не изменился и, что удивительно, продолжает прекрасно выполнять свою работу.

Его до сих пор используют OpenSSH для динамического проброса портов, корпоративные прокси, системы автоматизации, инструменты тестирования, VPN-клиенты и просто пользователи, которым нужно направить трафик через удалённый сервер.

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

Год назад я рассказывал на Хабре о ProxiFyre, небольшом инструменте для Windows, который позволяет прозрачно направлять трафик выбранных приложений через SOCKS5-прокси. Многие программы вообще не умеют работать через SOCKS5 или требуют ручной настройки. ProxiFyre берёт эту работу на себя: приложение продолжает работать как обычно, а решение о том, какие соединения следует отправить через прокси, принимается на уровне операционной системы.

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

Полтора часа на десятерых — пятнадцать человеко-часов. Само исправление занимает полчаса работы аналитика с разработчиком.

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

Ключевое здесь не в том, что кто-то поленился. Ключевое в том, что до совещания в систему не заглянул никто. Ни один пользователь не открыл форму и не посмотрел на неё с интересом. Если бы посмотрел — те же три поля стоили бы тридцать минут переписки.

Проект к этому моменту шёл третий год.

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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

В октябре 2021 года я пытался придумать хорошую тему для диплома.
Было непросто - с идеями проблем не было, но все они были какой-то отстой.
Тогда я решил придумать
100
ИДЕЙ
ДИПЛОМА!

Часть из них были перспективными, часть нет. Часть были полным отстоем и бредом.
Часть уже давно реализовали. А некоторые - нет.
Полученный список я разместил статьей на хабре (она набрала 34к просмотров и была сохранена 86 раз).

В общем, я наткнулся на эту статью пару недель назад и решил перечитать список. Это оказалось занимательное чтиво. Похоже, в 21 годик я еще гадал, чем заниматься по жизни и не подозревал, как сложно реализовать хоть что-нибудь. Особенно до бума нейронок.
Кстати да, мне же пришлось генерировать все эти идеи самостоятельно!
Чтобы поделиться с людьми удовольствием, которое я получил от прочтения, я превратил этот список в видео, где я заново знакомлюсь со списком и проверяю, какие идеи уже кто-то реализовал:
https://www.youtube.com/watch?v=ljvZ48q-e-Y