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

Как работает ядро 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‑кернелов — с парой неожиданных находок по дороге.

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

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

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

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

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

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

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

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

За последние полгода мне довелось использовать AI практически во всех своих проектах. В какой-то момент я поймал себя на мысли, что почти перестал писать код руками. Именно тогда я задумался: действительно ли ИИ заменит программистов или мы просто неправильно понимаем, что именно сейчас происходит с нашей профессией?

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

Все мы наблюдаем как меняется индустрия и что уже много вакансий в IT становятся не актуальными. Да многие говорят что это ИИ пузырь и он скоро лопнет, и мы придем и все исправим что написал ИИ. НО мне кажется это не так. Обратной дороги нет, мы вступаем на новую дорогу. Компании максимально ужимают бюджеты, наем junior программистов потерял совсем смысл. Череда сокращений уже прошла, и сейчас компании после первого бума ИИ пытаются понять как теперь строить команды и оптимизировать бюджеты. Но как мне кажется есть важная деталь, которую все упускают. И эта деталь звучит примерно так: ИИ это эффективный инструмент в руках квалифицированного программиста. И здесь речь идет не только о программировании, так же и дизайн и доставка кода, организация всех процессов.

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

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

Почему? Ну, большинство мидл-менеджеров просто передают информацию сверху вниз — передают задачи — и снизу вверх — поставляют отчёты. То есть они занимаются тем, что распределяют информацию по команде.

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

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

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

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

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

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

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

Это вторая статья из цикла статей о создании компактной кросс‑платформенной библиотеки для разработки приложений с графическим интерфейсом на языке C++ — Frenchie. Для тех, кто привык изучать исходный код самостоятельно, репозиторий с исходным кодом библиотеки находится по ссылке. В данном материале я расскажу, про ту часть библиотеки, которая управляет состоянием контекстного окна и отслеживает связанные с ним события - platform backend.

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