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

Показываю, как за один вечер настроить WireGuard VPN с Nginx и закрыть сервисы от всего интернета, без сложной сетевой инженерии.

Когда я собирал свой первый ЧПУ-лазер, все гайды по электрике самодельных станков жили на YouTube. Только видео. В реальной сборке это мучение. Найди нужный момент. Запомни. Поставь на паузу. Промотай назад. Снова пауза. И так по кругу.

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

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

За 36 часов их надо было научить прикладному дроноводству, где база — умение паять.
У меня 2 паяльных места и 15 человек. У всех в итоге должно что-то заработать, в идеале — полететь.

Собирали мы Клевера от COEX. Дети учились паять на «мертвых» PDB, но при переходе на живые платы от стресса умудрялись капнуть припоем на цепи преобразования напряжения и сделать КЗ. А я не понимала, как выполнять роль инженера-наставника, когда надо следить за паяльниками одних, при этом чем-то занимать других и бегать отвечать на текущие вопросы, когда даже ПК всего 5 штук.

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

А точно ли это то, чему я хотела научить детей?

Иногда может возникнуть необходимость запрашивать данные из ClickHouse в реальном времени при выполнении запросов или хранимых процедур на MS SQL. Последний "из коробки" представляет для этого средства только через Linked Server, OLE DB for ODBC и ClickHouse ODBC.

Если запрос возвращает немного данных - это вполне рабочий путь. Но если запрос к ClickHouse возвращает десятки тысяч строк, то производительность связки OLE DB for ODBC и ClickHouse ODBC не выдерживает никакой критики.

Я до сих пор бомблю от редизайна Duolingo.

Чтобы тренироваться без отвлечения на геймификацию, написал небольшой тренажер грамматики английского языка. Супер простой (vanilla JS + HTML), но со своими особенностями.

Особенности решения — под катом.

В прошлой статье мы познакомились с основными понятиями протокола Model Context Protocol и написали простейшее приложение, которое позволило LLM читать файлы.
Для этого мы использовали tools с оговоркой, что сделали это для упрощения, чтобы не лететь с места в карьер.
Мы уже говорили, что если tool можно сравнить с методом POST, то resource сравнивали с GET. Ресурсы (Resources) — это пассивные источники данных, которые MCP-сервер отдает клиенту для чтения.
Такими источниками могут быть содержимое файла, лог консоли, строка в базе данных.

Привет! Меня зовут Владислав Лаптев, я директор по инновациям в 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 в корпоративной среде.