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

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

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

Однажды на остров приезжает гостья, которой все доверяют, и приятно проводит там некоторое время. В конце своего визита, перед отъездом, когда всё сообщество собирается её проводить, она замечает:

«По крайней мере у одного из вас голубые глаза».

Ровно через сто дней происходит следующее: на рассвете все островитяне устраивают большое эффектное представление и покидают остров.

Почему? Можете объяснить, каким образом каждый из островитян именно в этот день пришёл к знанию того, что у него голубые глаза?

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

В статье описан пример решения для логирования на базе Spring AOP, с помощью которого можно автоматически логировать входящие HTTP-запросы в контроллерах, отслеживать исходящие запросы через WebClient, гибко управлять видимостью чувствительных данных через аннотации, а также автоматически отключать маскирования в зависимости от уровня логирования.

Структуру, о которой ниже пойдёт речь, знали в древней Индии за тысячу лет до самого Фибоначчи и переоткрыли в 1988 году двое математиков, при этом весь граф целиком строится из строк, состоящих только из цифр 1 и 2, или если мы вычтем единицу, то получим 0/1 и бинарный вид.

Берём любую конечную строку из цифр 1 и 2, например такую "11212" и складываем цифры 1 + 1 + 2 + 1 + 2 = 7 и получаем ранг этой строки. Теперь простой вопрос: сколько существует строк заданного ранга? Строку такого же ранга можно получить двумя способами, либо дописав цифру 2 к строке ранга r-2, либо дописав цифру 1 к строке ранга r-1, и других вариантов нет, потому что других цифр в нашем алфавите из единиц и двоек нет.

ранг 0: “” → 1
ранг 1: 1 → 1
ранг 2: 11, 2 → 2
ранг 3: 111, 12, 21 → 3
ранг 4: 1111, 112, 121, 211, 22 → 5
ранг 5: … → 8

Заметили справа подозрительное 1, 1, 2, 3, 5, 8? Да... это последовательность Фибоначчи f® = f(r-1) + f(r-2), с небольшим условием, что f(0) = 1 (пустая строка) и f(1) = 1 (единственная строка “1”), из-за этого вся последовательность сдвинута на одну позицию относительно канонических чисел Фибоначчи, и f® = F(r+1).

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

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

Гулял я как‑то по переулкам города. Старые здания, полные историй. А я страсть как люблю историю. Чей дом, когда построили, кто жил и что еще интересного. На фасаде нет таблички, экскурсовод рядом не материализовался. Постоянно доставать телефон, искать в интернете, открывать несколько сайтов то еще занятие. Можно сфотографировать здание и потом разобраться. Потом наступает примерно никогда.

Так и родилась идея Yerick City Explorer — Android‑приложение для самостоятельных городских прогулок.

Допустим, у тебя есть несколько AI-агентов. Один разбирает тикет, второй меняет код, третий запускает тесты, четвёртый готовит релиз.

Задача закрыта, тесты зелёные, артефакт собран. Метрика success_rate показывает успех.

Можно праздновать?

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

Финальное состояние корректное. Процесс — нет.

Именно эту проблему пытается измерить CoCoBench — новый бенчмарк для проверки координации нескольких AI-агентов. Его разработали исследователи из Нанкинского университета, Tsinghua и AgiBot.

Главная идея исследования полезна далеко за пределами робототехники:

Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

КПТ-дневник - главное домашнее задание в когнитивно-поведенческой терапии, и от него заметно зависит её результат. Разобрал его по полям: что писать в каждом, когда садиться за запись, какой шаг решает всё и что можно себе не усложнять. С примерами записей и цифрами из исследований.

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

Именно так всё и произошло на прошлой неделе с DLSS 5 – скандальной штукой от Nvidia. Официального анонса не было, зато была ранняя версия игры NBA 2K27, в которой была незаметная DLL-ка nvngx_dlssnr.dll на 158 мегабайт... и понеслось.

За считанные дни модеры натянули нейросетевой рендер на добрых три десятка игр, от Cyberpunk 2077 до GTA San Andreas, которой уже двадцать лет в обед (хотя ремастеру чуть меньше).

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

Всем привет!

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

Пару статей назад я устал возиться с кучей VPN и поставил Xray на роутер. Дома проблема закрылась: все устройства сами ходят куда надо — локальные и российские сервисы напрямую (без лишнего крюка и потери скорости), остальное через мой собственный сервер, реклама режется на лету. Красота.

А потом я поехал. И выяснилось, что весь этот уют остаётся дома.

В отеле — чужой Wi-Fi, которому я не доверяю ни на грамм. Симка в роуминге даёт IP, от которого у банка дёргается глаз, и он на всякий случай просит «подтвердить вход» третий раз за день. Хочется то полностью в туннель, то наоборот напрямую — чтобы пройти captive-портал в аэропорту. Таскать с собой ноутбук ради ssh в роутер — так себе развлечение в очереди на посадку.

Мне нужен был карманный роутер, у которого режимы переключаются пальцем, без веб-морды и SSH. Я взял GL.iNet Mudi 7 (GL-E5800) — и, забегая вперёд, довёл его до состояния «достал из кармана, ткнул нужный профиль на экране, поехал». Семь профилей-тумблеров, сквозной kill switch и даже выход через домашний IP без белого IP дома.

Но сначала — обзор самого железа, потому что на Хабре я его не нашёл, а зверь любопытный.

Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.

Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.

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

Эксперты Positive Technologies и «МТС» совместно изучили основные цифровые риски, с которыми семьи могут столкнуться в период подготовки к новому учебному году, и собрали практические рекомендации, которые помогут защитить аккаунты, устройства, телефонные номера и деньги детей и родителей.

Важной вехой в математических исследованиях с использованием ИИ стал пример команды компании Axiom Math, которая впервые автоматически проверила доказательство теоремы, касающейся простых чисел — в просторечии известной как «теорема 246» — с помощью собственной системы искусственного интеллекта AxiomProver.

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

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

В рабочем чате: «Сайт не открывается, сертификат истёк», следом — скриншот с 502. Первый рефлекс — certbot renew и перезагрузить nginx. Иногда помогает. Иногда сайт после этого не поднимается совсем.

Дело в том, что «всё из-за сертификата» — это на самом деле две разные поломки с разными решениями: сертификат не продлился или продлился, но сервер отдаёт старое. В выдаче их валят в кучу, поэтому советы вроде «просто сделай certbot renew» либо не помогают, либо роняют сайт по-настоящему.

Разбираем по шагам: как за десять минут понять, какая из двух у вас, вернуть HTTPS и настроить продление так, чтобы это не повторилось.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

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

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

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

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

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

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

Отток в массовом B2B SaaS почти всегда рождается не в недовольстве продуктом, а в первых днях после покупки, до того как клиент дошёл до реального результата. Чинит его онбординг, а не запуск программы удержания.

Привет, Хабр! Если судить по новостям, то до повсеместного распространения автономного транспорта осталось совсем чуть-чуть: Waymo расширяет парк роботакси в США, Baidu через Apollo Go возит пассажиров в двух десятках китайских городов, а Volvo и Einride готовят автономные грузовики к серийной эксплуатации на автомагистралях. Пилотные проекты идут один за другим, растут показатели безопасности, а инвесторы вкладывают миллиарды. Но время идет, а прорыва все нет и нет.

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

Прежде чем начать, короткое предупреждение. Это, вероятно, самая тяжёлая статья всего цикла. Не в смысле сложности материала, а в смысле того, чем он закончится. Первая половина - это чистый интеллектуальный восторг. Вторая - один из самых горьких сюжетов в истории технологий двадцатого века. Я не буду обходить это стороной, но и имеющиеся на территории РФ законы постараюсь не нарушить, так что если вы готовы, то начинаем.

Это вторая статья из цикла “Код как борьба: Кратчайшая история IT”. В прошлый раз мы говорили про Лейбница, Бэббиджа и Аду Лавлейс. Про то, как три человека нащупали идею компьютера за полтора века до электричества. Сегодня мы встречаем человека, который наконец дал этой идее строгий математический фундамент. И одновременно человека, чью жизнь разрушила его собственная страна за то, что не имело вообще никакого отношения к его работе.