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

Я занимаюсь исследованиями цифровых банковских сервисов много лет. И уже 10 лет мы исследуем мобильные банки для бизнеса.

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

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

В этом году мы представили результаты исследования Markswebb Business Mobile Banking Rank 2026 и решили вспомнить, какими были сервисы 10 лет назад. В этой статье хочу поделиться своими наблюдениями.

Данная статья представляет собой взгляд на установку, настройку и использование openclaw от лица простого юзера. Я не программист, не контент-мейкер, не вайбкодер, не стремлюсь обладать производительностью пяти комбайнов на одного землекопа, хотя, моя работа и строится вокруг компьютеров. Это простой мой субъективный опыт, со всеми косяками и ошибками новичка.

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

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

Агент в Сан-Франциско тратит двадцать минут на то, чтобы пофиксить баг, который агент в Лондоне решил пять минут назад. Опыт первого умрёт вместе с сессией: завтра тот же баг будет с нуля решать кто-то третий. В Stack Overflow это называют Ephemeral Intelligence Gap — и 10 июня 2026-го компания запустила под эту проблему отдельную платформу: Stack Overflow for Agents, площадку, где опытом обмениваются не люди, а агенты.

На Хабре про запуск уже писали в паре статей, а в опросе под одной из них 59% проголосовали за «проект закроется». Мне есть что к этому добавить: я почти сразу после запуска завёл туда агента — научил его ходить на площадку по API — и спустя месяц он в топ-8 лидерборда. Всё это время я смотрел на платформу не из новостей, а изнутри — и встраивал её в свой пайплайн агентной разработки.

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

Пишу свой путь разработки self-hosted сервера с полностью автоматизированным развертыванием с полным циклом состоящим из около 15 DevOps технологий, а также 7 сервисов, которые будут полезны каждому!

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

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

Разберём шесть типичных ошибок в настройке GitLab Runner и посмотрим, как найти узкое место до того, как команда привыкнет ждать сборку по двадцать минут.

Remedy у вас работает, но вендор ушёл: ни патчей, ни поддержки, ни людей, кто в этом разберётся. Разбираем, как переезжать — тащить старый кастом с собой или начинать заново.

На примере PHP хорошо видно, как внутренние оптимизации динамически типизированного языка развиваются и усложняются.

PHP‑массив выглядит универсальным, но внутри него скрыто множество оптимизаций и ветвлений, в их числе оптимизации для хранения и работы с массивами: Packed List & HashTable. Взаимодействие между ними и copy‑on‑write дают иногда неожиданное и непрозрачное поведение с точки зрения PHP программиста.

При миграции из одной корпоративной системы в другую часто встает задача репликации данных. Например, при поэтапной замене ERP по методологии Parallel Running во время опытной эксплуатации пользователи работают в двух системах, которые оперируют идентичным набором данных. Если модели данных сильно отличаются, а при репликации присутствует дополнительная логика, то команды чаще всего пытаются использовать шины данных (например Kafka). При таком подходе требуется самостоятельно реализовать механизмы копирования данных, обработки конфликтов, пересинхронизации, мониторинга и т. д. Все это увеличивает трудозатраты и потенциально может стать источником проблем. В этой статье разберем техническую реализацию репликации данных через шины, ее слабые места, а также альтернативные подходы.

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

В переводе от команды Spring АйО разбирается опыт масштабирования Java-платформы контакт-центра: почему локальные кеши начали расходиться, как повторное воспроизведение Kafka-событий почти сделало бесполезным автомасштабирование, откуда взялось получасовое отставание потребителей и почему часть критических путей пришлось вернуть к синхронному взаимодействию.

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

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

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

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

Представьте, что 12 нот хроматической гаммы и 12 оттенков цветового круга — это не просто разные физические волны, воспринимаемые нашими органами чувств, а проекции единой математической структуры. Что если законы музыкальной гармонии (аккорды) и правила художественного контраста (цветовые схемы) можно описать с помощью чистой арифметики делителей на гранях правильного многогранника?

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

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

Для кого

Фаундерам и CMO SaaS, онлайн-сервисов и платформ, которые думают запускать поисковое продвижение и хотят сначала понять, окупится ли канал на их экономике и горизонте, вместо того чтобы полгода тратить бюджет на трафик впустую.

Кратко

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

Меня зовут Дмитрий Шестаков, основатель компании Сайткрафт. Чаще всего ко мне приходят с запросом в стиле: нам нужно SEO, конкуренты в топе, мы отстаём. И почти всегда мой первый честный ответ — давайте сначала посчитаем, окупится ли это у вас в ближайший год. Потому что для подписочного сервиса поиск умеет приносить дешёвые заявки годами, а умеет полгода жечь бюджет на трафик, с которого никто не покупает. Дело тут не в подрядчике и не в усердии. Решает то, готов ли продукт к этому каналу.

Содержание

1. Почему SEO советуют всем подряд

2. Признак первый: вы не знаете, по каким запросам у вас покупают

3. Признак второй: экономика не сходится даже на платном трафике

4. Признак третий: сайт не превращает визиты в заявки

5. Признак четвёртый: нет запаса хода на длинную окупаемость

6. Признак пятый: SEO некому вести в долгую

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

В мае 2026 года департамент Threat Intelligence экспертного центра безопасности Positive Technologies обнаружил очередную кампанию APT-группировки CloudAtlas, в рамках которой использовались характерные документы Microsoft Office с техникой внедрения вредоносных шаблонов и многоступенчатая цепочка доставки вредоносных HTA- и VBS-компонентов.

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

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

Асимптотика на практике: Сравнение алгоритма сортировки вставками и выбором

Автор: Шуравин Александр, к. т. н., доцент, в IT более 20 лет.

Введение

В теории алгоритмов мы привыкли оперировать абстракциями: O(n²), O(n log n), O(1). Но что скрывается за этими обозначениями в реальном продакшене? Насколько критичен выбор алгоритма для вашей системы?

В этой статье я исследую два классических алгоритма сортировки — сортировку выбором (Selection Sort) и сортировку вставками (Insertion Sort) — на трёх типах входных данных:

1. Случайный массив.

2. Уже отсортированный массив (best case).

3. Массив, отсортированный в обратном порядке (worst case).

 Эксперимент проведён на Python с замером времени выполнения для размеров массива от 100 до 1000 с шагом 100.

Теоретическая справка

Сортировка выбором (Selection Sort)

Идея: На каждой итерации находим минимальный элемент в неотсортированной части массива и меняем его с первым элементом этой части.

У обычной ноды Kubernetes жёсткий потолок в 110 подов (формально настраиваемый kubelet-флаг --max-pods, но поднимать его руками не рекомендуется даже апстримом: упирается в размер Pod CIDR на ноду, и выше 110 Kubernetes просто не валидируют, так что на практике это потолок дефакто), плюс налог на каждый контейнер: containerd или CRI-O (справедливости ради, у CRI-O ~20 МБ, но на хост, и около 1 МБ на под), ~20 МБ containerd-shim на каждый контейнер, а сам CRI добавляет заметный delay в операциях. На мощном железе это заставляет выбирать между недоутилизацией и гипервизорным слоем (KubeVirt, Kata) с его собственным налогом на microVM. На слабых VPS стандартный стек тяжёл ещё даже до первого workload: kubelet + containerd + kube-proxy + CNI — это уже 300-600+ МБ RSS прежде, чем в кластере появится хоть один рабочий под.

У меня была мечта: Kubernetes + systemd. Я начал свой путь не зная куда это приведет, проект за время разработки сменил 7 разных направлений, думаю я нашел главную цель: освобождение Kubernetes.

Результат на двух моих машинах (Xeon E5-2690 v4 + Intel N150): 1772 пода, 33 ноды, 2.5 миллиона запросов под нагрузкой с нулём ошибок и медианой 257 мкс. RSS демона — 365 МБ (замер от 04.04.26, сейчас уже ниже) на 1660 подов (~225 КБ на под).

Дальше расскажу, что такое Periapsis, как у меня появилась эта идея и что уже работает.

Привет, Хабр! Меня зовут Илья Кербатов, я старший консультант в компании «ДАР» (ГК «КОРУС Консалтинг»). В прошлой статье я разобрал, как с помощью ИИ ускорил KPI-панель Qlik Sense. В этот раз кейс другой: странный баг с переменными, который сам по себе оказался редким, но привел к созданию небольшого набора инструментов для аудита приложений. Собрать его получилось за несколько промптов, и это сильно сэкономило время.

Странный баг

Все началось с необычного поведения в одном из приложений. После частичной перезагрузки (partial reload) часть переменных переставала отдавать вычисленное значение. В скрипте при перезагрузке переменные не переопределялись, их определение наследовалось с прошлой полной перезагрузки (full reload). На листах вместо результата было пусто.

Создаю собственный DSL на C#: рассказываю о том, как я добавляю семантическую модель. Рассказываю архитектуру семантической модели.

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