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

Привет! Меня зовут Владислав Лаптев, я директор по инновациям в Fork-Tech. Сегодня РБК выпустил материал о том, что замедление Telegram срывает релизы мобильных приложений в России. Мы дали комментарий для этого материала, и я решил рассказать подробнее, потому что проблема не в Telegram. Проблема в том, что российские мобильные разработчики третий раз за четыре года теряют инструмент доставки сборок.

Мы создали PWS (Product Web Services) — платформу для управления цифровыми продуктами. Сегодня речь про модуль App Distribution: как мы к нему пришли, где взяли лучшее от Firebase, почему этого было мало, и как всё работает под капотом. С примерами кода из документации. Платформа включена в реестр российского ПО.

Продолжаем цикл статей с обзором изменений 19 версии. Сегодня о январском коммитфесте 2026 года.

Самое интересное из предыдущих коммитфестов можно прочитать здесь: 2025-07, 2025-09, 2025-11.

В статье рассматривается реальная ограниченность современных больших языковых моделей (LLM) при разработке сложных электромеханических систем, включающих аналоговые и цифровые датчики, шаговые и серво‑приводы, а также различные исполнительные устройства. Показано, что хотя нейросети способны быстро генерировать черновые схемы, фрагменты кода и шаблоны технической документации, они не обладают знанием физического контекста, параметров компонентов, нормативных требований и бизнес‑целей проекта. Поэтому без участия инженера‑генератора идеи и программиста‑интегратора полученный результат остаётся непроверенным и потенциально ошибочным. Приведены практические примеры из реальных проектов (генерация драйверов для шаговых двигателей, автоматическое написание тест‑скриптов, составление ТЗ и подбор компонентов), где LLM выступали лишь ускоряющим инструментом. Описаны рекомендации по эффективному использованию нейросетей: чёткое ТЗ, разбиение задачи на небольшие блоки, обязательная верификация и сохранение контекста. Делается вывод, что нейросети сейчас являются полезными помощниками, но не заменой человеку в роли идеи и интеграции.

В мировой практике ДЗЗ в построении архитектур наземных сегментов (НС) космических систем можно условно выделить три периода:

1) 1990s: One-Off System (условно, НС под конкретный КА) - Уникальные, "штучные" системы. Каждый спутник имел свой собственный, специально спроектированный наземный сегмент: уникальные приемные станции, центры обработки, формат данных, ПО. Нет совместимости. Типичный пример: ранние миссии Landsat, SPOT, ERS.

2) 2000s: Common Ground Architecture (условно, НС под серию КА) - Единая базовая архитектура. Появление стандартов (например, CCSDS). Агентства (как ESA с их "Generic Ground Segment") создают повторно используемые компоненты и инфраструктуру, на базе которых можно относительно быстро разворачивать сегменты для новых миссий. Снижаются затраты и сроки. Многие миссии ESA и NASA этого периода строятся на общих принципах и программных компонентах.

3) 2010-2020s: Mission Independent Architecture (многоцелевые унифицированные) - Архитектура, независимая от миссии. Это концептуальный скачок. Вместо того чтобы адаптировать наземный сегмент под миссию, данные миссии адаптируются под универсальную, уже существующую наземную платформу. Ключевые принципы: виртуализация (абстрагирование от физического "железа"), сервисно-ориентированная архитектура (SOA), стандартизация интерфейсов и метаданных (чтобы любая миссия могла "подключиться" к платформе). Цель: Обрабатывать данные от множества разнородных миссий на одной инфраструктуре, обеспечивать гибкость, масштабируемость и быстрый доступ пользователям.

В феврале 2026 года open-source сообщество получило редкий жанр контента — AI-драму с полноценным публичным конфликтом.

Когда мы пишем код под микроконтроллер, за привычными инструкциями компилятора скрывается вполне конкретная логика – регистры, ALU, прерывания, шины и тайминги, которые живут по своим правилам.

В статье разберём, как устроены базовые механизмы выполнения команд и что именно происходит на уровне микроархитектуры, когда «просто вызывается функция». Это попытка посмотреть на embedded-разработку через призму железа и понять, какие инженерные решения стоят за кажущейся простотой исходного кода.

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

Традиционный подход к диагностике производительности PostgreSQL зачастую опирается на эвристики, «типовые чек‑листы» и интуицию администратора. Администратор видит всплеск ожиданий, находит самый массовый тип события и принимает решение: «увеличить shared_buffers» или «выключить параллельные запросы». Такой метод работает в очевидных случаях, но оказывается бессилен, когда система находится в состоянии сложного баланса между разными механизмами, а первопричина торможения скрыта за вторичными эффектами.

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

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

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

Есть такая пугающая теория — «Теория мёртвого интернета».

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

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

Заявления Илона Маска о роботе Tesla Optimus поражают своей масштабностью. Он утверждал, что Optimus принесёт $10 триллионов долгосрочной прибыли для Tesla, что в конечном итоге робот составит 80% стоимости Tesla, и что он увеличит оценку компании до впечатляющих $25 триллионов. Однако предыдущие обещания не всегда сбывались: Маск говорил, что Tesla запустит пилотную производственную линию готового Optimus и произведёт 5000 единиц к концу 2025 года, но этого не произошло. Фактически, Tesla недавно анонсировала новую «готовую к производству» третью версию Optimus (что подразумевает, что версия, запланированная к производству в 2025 году, так и не была готова), и что к концу 2027 года производство начнётся на заводе Tesla во Фримонте, где ранее производились Model S и X. Возможно, стоит воспринимать эти громкие заявления с определённой долей скептицизма? Во время недавних отчётных звонков Tesla Маск упомянул нечто, что не только демонстрирует разрыв между реальностью и обещаниями, но и ставит вопросы о понимании технологии.

Программист часто копирует и вставляет, переименовывает и рефакторит.Вот бы сразу видеть в статусной строке количество переменных или функции в редактируемом файле. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

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

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

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

От самых базовых "сохранить –> откатиться" мы постепенно эволюционировали до продвинутых инструментов контроля версий. Глобально системы контроля версий можно поделить на три типа:

Идея вынести вычисления в космос звучит как научная фантастика, но крупнейшие игроки уже делают на неё ставку. SpaceX просит разрешение на орбитальные дата-центры мощностью до 100 ГВт, Google запускает Project Suncatcher, стартапы планируют десятки тысяч спутников. Логика проста: солнечная энергия в космосе дешевле и доступнее, а значит и вычисления со временем станут выгоднее.

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

Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки уже существовали проекты с применением ИИ, но как отдельные компоненты, не хватало единой платформы управления. По мере роста количества и сложности бизнес-задач возникла необходимость в создании ML-платформы как сервиса с едиными стандартами авторизации. Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Go 1.26 уже вышел! Официальные релизноты довольно скудны на детализацию и приходится изучать глубже. Сделал для тебя большой обзор нововведений, можешь использовать эту статью как шпоргалку. В начале коротко опишу то что лично мне понравилось больше всего. Изменения затрагивают runtime, компилятор, стандартную библиотеку и поддержку платформ. Команда Go сосредоточилась на производительности и удобстве разработки.

В этом материале мы разберём хронологию войны РКН (Роскомнадзора) с самым популярным мессенджером в РФ: начиная с первых разногласий в 2017 году, мемов “Дуров, отдай ключи!” и бумажных самолётиков, выпускаемых из окон нашей общаги на Волгина, и заканчивая недавними заявлениями РКН и Госдумы относительно будущего Telegram в нашей стране.

Содержание:

Начало. Идеология создания Telegram

2017 год. Первые проблемы Telegram с российскими регуляторами

2018 год. Первые судебные решения по Telegram и начало блокировок

Бумажные самолётики и согласованные акции в Москве и других городах России в поддержку Telegram

2018–2019 годы. Открытая технологическая война РКН с Telegram

2020 год. РКН снимает ограничения. Дуров договорился или РКН меняет стратегию?

2025 год. Ограничение звонков в Telegram и региональные ограничения

Что изменилось? Как сегодня РКН и регуляторы борются с Telegram. Появление мессенджера MAX

2026 год. Новые проблемы и ограничения Telegram

Главная ошибка российских регуляторов в борьбе с Telegram

Почему РКН не победит и почему “заблокировать влияние извне” невозможно?

Опрос читателей Хабра: как вы относитесь к блокировке Telegram?

Привет! Меня зовут Андрей Попов, я SEO-специалист в AGIMA. И сегодня хочу развеять один популярный миф: искусственный интеллект не убил копирайтинг. Он действительно уничтожил низкокачественный информационный SEO, где тексты создавались ради кликов, а не ради реального влияния на аудиторию. Но сегодня важно не просто привлекать трафик, а убеждать и внятно позиционировать бренд, показывая, какую проблему он решает. И без пишущего человека здесь по-прежнему не выжить. В этой статье — мои аргументы.

Нет лучше способа в чем-то разобраться, чем написать свою реализацию.

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

Много раз проскакивало желание у многих получить простой инструмент, позволяющий следить за истекающими сертификатами SSL. Ниже представляю инструмент для самостоятельного развертывания в среде docker.

Код написан для python14, но работать будет и на других версиях (12, 13, 14 и т.д.).

Что включает проект (все в одном):

Привет, я Максим Королев из Петрович-ТЕХа. В предыдущей статье рассказывал, как мы сделали семейство Telegram-ботов для ITSM. Один из ключевых - «Дежурный»: с ним администраторы фиксируют аварии, регламентные работы и прочее, создают задачи в Jira, публикуют уведомления в каналы и в интранет компании.

И тут Telegram ограничивают. Когда у дежурного в разгар аварии «не грузится телега» - это риск для бизнеса. Нужно было срочно решать проблему.

Единственной стабильной альтернативой оказался - да-да - MAX. У него есть Bot API, он не попадает под ограничения РКН и уверенно работает на территории РФ.

Задача не «сделать второго бота с нуля», а сохранить одного логического Дежурного и дать ему второй вход из MAX. В статье расскажу, как я изменил архитектуру: вынес всю бизнес-логику в отдельный слой CORE, а Telegram и MAX сделал вызовами команд этого ядра.