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

Когда говорят про SaaS, чаще всего представляют продукты для бизнеса: системы учета, аналитики или автоматизации бизнеса.

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

Сегодняшняя история как раз про такой проект.

Михаил и его партнер Дмитрий запустили сервис музыкальной дистрибуции для независимых артистов. За несколько лет они прошли путь от WordPress-сайта, собранного практически без понимания того, как строятся SaaS-продукты, до компании с двумя инвестиционными раундами, командой из 30 человек и выручкой около $220 000 в месяц.

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

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

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

В подсистеме nf_tables ядра Linux обнаружена уязвимость CVE-2026-23111, которую вызвал единственный лишний символ «!» в исходном коде. Логическая ошибка в функции nf_tables_addchain() создаёт условие use-after-free, позволяющее локальному непривилегированному пользователю выполнить код в контексте ядра и получить полные привилегии root

Патч сводится к удалению этого одиночного символа, но до его выпуска миллионы систем с активным пакетным фильтром nftables оставались открытыми для полного компрометирования хоста

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

Все эти вопросы правильные. Но если мы говорим про корпоративный клиентский сервис — ответов на эти вопросы критически недостаточно.

Как работает ядро Joomla 6 на уровне Приложения (Application)? Сколько видов Приложений на самом деле есть в Joomla и в чём между ними разница? Какой жизненный цикл каждого Приложения Joomla, включая роутинг, диспетчеризацию и события плагинов? На эти и другие вопросы попытается дать ответ эта статья, опирающаяся на кодовую базу Joomla 6.1.0. Также в статье хронология вызова триггеров плагинов в разных сценариях.

Почему одни рекламные креативы собирают заявки, а другие — только лайки? Дело далеко не всегда в дизайне.

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

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

Наш любимый доходяга Яндекс частенько показывает вверху выдачи готовый ответ и ссылается в нём на три‑четыре сайта. При этом по такому же запросу в обычной выдаче сотни, а то и тысячи страниц. Позвольте спросить, по какому такому принципу нейроответ отбирает из этих сотен именно те самые избранные, которые собирают весь куш? Я решил проверить свои (бестолковые) гипотезы на реальных данных.

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

Сразу про масштаб. Это одна ниша и всего 60 обращений, так что на вселенскую истину я не претендую, хотя очень хотелось бы. Но даже на таком объёме картинка получилась на удивление устойчивой, пусть и не такой, как мнение Греты Тунберг обо всём на свете.

Начнем с самых основ.

История API берет начало в 1945-1951 году, когда появляются первые библиотеки подпрограмм и модульный подход к разработке. В это время растет количество программного кода и появл

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

Сегодня воздержимся от их сравнения и сконцентрируемся на разговоре о том, какие удобства при работе может предоставить FluxCD.

Привет! Я Катя Образцова, AI-продакт-лид и заместитель руководителя развития продукта в Битрикс24.

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

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

Я аналитик, а не разработчик. Весь код для созданной нами платформы написал Claude Opus через Claude Code. Рассказываю без хайпа: как выглядит реальный workflow, где нейросеть незаменима, где она бесполезна, и какая инженерная дисциплина обязательна, чтобы это не превратилось в тыкву на боевом.

Сразу обозначу рамку, чтобы снять половину вопросов из комментариев.

Я не умею писать продакшн‑код. Я аналитик: читаю код, рассуждаю о системах, проектирую поведение — но профессионально не кодю. Тем не менее у нас в проде работает нетривиальное веб‑приложение, и каждую строчку кода написала нейросеть (Claude Opus, агент Claude Code). Моя роль — архитектор, продакт и QA. Второй ключевой специалист по разработке — дизайнер вебинтерфейсов, также освоивший Claude.

Это не пост «ИИ сам всё сделал, программисты не нужны». Скорее наоборот: я хочу показать, что инженерия никуда не делась — просто из неё вынули операцию «набирать код руками». Всё остальное (проектирование, компромиссы, ловля прод‑онли багов, дисциплина релизов) осталось на человеке. И вот об этом «остальном» — интереснее всего.

Помните, как в конце нулевых нам обещали, что экзоскелеты изменят медицину? В 2008‑м японская Cyberdyne начала сдавать в аренду клиникам экзоскелеты HAL. Пациенты с травмами спинного мозга снова учились ходить, а пресса писала, что реабилитация никогда уже не будет прежней. К 2012‑му в Японии работало уже больше трехсот костюмов в сотне клиник, и казалось, что вот‑вот экзоскелеты станут привычной частью медицины. Но реальность оказалась другой. В США первая клиника получила HAL только в 2018‑м. А сейчас уже 2026‑й, и счет все еще идет на единицы.

Почему так? Бионика развивается, но до массового применения ей далеко. Недавно в статье IEEE Spectrum появилось объяснение этому: в лабораторных условиях все работает идеально, а вот выйди на улицу — дождь, шум, отсутствие специалистов рядом — и начинаются проблемы. В этой статье я расскажу, как этот барьер проявляется в разных направлениях биотехники.

Работа в IT до 2025 года была устроена так, что компания получала дорогостоящих сотрудников интеллектуального труда, которые приносили компании убыток всё время, пока они не приносят какое-то вэлью либо через новые продукты (фичи), которые продаются клиентам, либо через оптимизацию какого-то процесса (и компания получает вэлью через сокращение издержек).

Как разогнать copy_if на NEON в 30+ раз без единой ветки в горячем цикле — эмулируем compress инструкцию, которой в NEON нет, через table lookup и немного битовой магии.

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

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

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

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

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

Но что, если предложить альтернативу? Существует концепция, которая пытается объединить заботу о социальном благополучии с верой в силу технологий и экспертного управления. Это гибрид социальной демократии и технократии. Звучит противоречиво, но именно в этом и суть.

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

Мы уже много лет разрабатываем и производим диктофоны для безопасности Edic-mini, самые маленькие в мире, кстати, по данным Книги Рекордов Гиннесса.

Многие слышали про модели OSI и TCP/IP. Но попробуй объяснить их простыми словами на собеседовании — и тут многие начинают путаться. В этой статье разберём обе модели на примере заказа пиццы. Просто, понятно и весело)

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

Граф из миллионов вершин не загружает современную GPU на все 100%: видеокарта почти всё время не вычисляет, а ждёт загрузки данных из памяти. Графовые нейросети, или GNN, упираются в это давно: сами операции достаточно простые, но доступ к памяти нерегулярный и разреженный. И чем мощнее GPU, тем заметнее недостаточная её утилизация.

Идея выросла из проектного курса в ШАДе. Толчком стало то, что один из самых популярных фреймворков для работы с графами, Deep Graph Library, на момент начала работы не обновлялся уже около года — это знак того, что в области что‑то застряло.

Меня зовут Федя Великонивцев, я старший исследователь Yandex Research, руковожу группой, которая занимается эффективными вычислениями на GPU. На том курсе мы с коллегами — Дарьей Фоминой из команды ML‑инфраструктуры Яндекса, Вячеславом Ждановским из команды разработки инференса — и студентами Даниилом Красильниковым, Алексеем Бойковым и Андреем Долговязовым взялись выяснить, почему графовые нейросети тормозят на современных GPU.

Так появился проект, который мы оформили в отдельную статью — On Efficient Scaling of GNNs via IO‑Aware Layer Implementations. Её приняли на ICML-2026 со статусом Spotlight. Для контекста: из 23 918 поданных работ приняли 6 352 (26,6%), а Spotlight достался только 536 работам — это 2,2% заявок с самыми высокими оценками программного комитета.

Дальше расскажу, как мы прошли путь от этого вопроса до трёх семейств специализированных GPU‑кернелов — с парой неожиданных находок по дороге.

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

Фразу из той статьи я запомнил дословно: «Он перепутал твердость с хрупкостью».

Я перечитал ее несколько раз. А разве это не одно и то же? К сожалению, в моем детстве не было Интернета и тогда я не смог найти ответа на этот вопрос. 

Но, спустя годы, я снова вспомнил эту историю и мне стало интересно с ней разобраться. Я погрузился в изучение вопроса. Почему же алмаз так легко разбить, ведь если что-то твердое — оно же должно быть и прочным? Логично ведь.

Нет, не логично.

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

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