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

Anthropic отчиталась, что больше 80% её кода теперь пишет Claude, — а её же автоматический проверяющий ловит лишь треть прошлых ошибок, то есть две трети пропускает. Если код пишет один ИИ, а проверяет такой же — они слепнут в одних и тех же местах, и второй контур даёт не защиту, а общую слепую зону. Разбираю на инженерном уровне, почему «проверка ИИ» не равна независимой проверке, как измерить слепое пятно и как сюда ложится двухконтурная схема из мира промышленной безопасности (IEC 61508).

Балансировщики нагрузки в России за последние несколько лет превратились из «серой коробочки где‑то в инфраструктуре» в фундаментальный элемент отказоустойчивости инфраструктуры. И если на старте импортозамещения все просто искали чем быстро заменить ушедших F5 и Citrix, то сегодня фокус сместился на производительность, безопасность и то, насколько решение вписывается в существующие практики DevOps/NetOps.

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

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

Знакомим с API для автоматизации в nanoCAD BIM Строительство, фокусируясь на COM-интерфейсе: объясняем, что это такое, какие у него есть объекты, свойства, методы и коллекции, как работать с ними в Мастере функций.

Это вторая часть серии туториалов, где мы реализуем Third Person Controller на MonoGame. В этой части мы заменим капсулу персонажа на анимированную модель. И прицепим меч на спину.

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

Вы купили умную лампочку на маркетплейсе. Вкрутили, подключили к домашнему Wi-Fi. Всё работает. Но вот в чем штука: вы только что впустили в свой дом полноценный линукс-компьютер с неизвестной прошивкой и нулевым уровнем защиты. Более того, вы дали ему полный доступ к своей локальной сети. Теперь этот девайс за 500 рублей видит ваш рабочий ноутбук, домашнее хранилище бэкапов и смартфон, с которого вы подтверждаете банковские переводы.

Привет! Это команда Яндекс Практикума PRO. В марте у нас прошёл вебинар с Александром Мальцевым, директором по маркетингу Яндекс Браузера, экспертом курса «Нейросети для маркетинга» и автором телеграм-канала «Мальцев: Карьера с AI». 

Саша рассказал, как его команда с помощью ИИ-агентов персонализировала коммуникации для одной из фич браузера — и выросла на 20% по всем рекламным кампаниям. Над кейсом работали всего два человека: перфоманс- и коммуникационный маркетологи. Рассказываем, как им это удалось, и делимся примерами промптов и фреймворков. 

Эта статья — не ревью чужого кода и не пересказ абстрактных паттернов. Это практическое описание того, как я подхожу к проектированию сетевого слоя, какие решения считаю удачными, какие — опасными, и почему. Основа текста — реальный подход к построению сети в production iOS-приложении: с явной EndpointPolicy, RequestContext, interceptor-pipeline, безопасным логированием, отдельной обработкой refresh flow, snapshot-first чтением и выделенным transport для долгих upload-сценариев.

Мой главный тезис простой: сетевой слой — это не “место, где отправляются запросы”, а инфраструктура приложения. URLRequest и URLSessionConfiguration в Foundation уже работают как объекты, которые несут не только URL, но и правила поведения запроса; Swift Concurrency даёт структурированную асинхронность и безопасную модель доступа к разделяемому состоянию через actors. На практике это значит, что retry, auth, timeout, cache, logging и metrics лучше проектировать как часть контракта, а не как случайный набор if внутри одного большого send(). 

Если сжать статью до одного абзаца, получится так: я начинаю не с URLSession, а с вопросов кто имеет право знать о transport, где живёт policy, кто отвечает за retry, как не утечь токенами в логах, где source of truth для UI и как выяснить, что именно сломалось в production. Всё остальное — код вокруг этих решений.

2,5 км оптики — в земле, генплан на 24 МВт — утверждён. Май в Марфино был про связь и масштаб: показываем, как площадка превращается из чертежа в стройку.

Разбираю, почему нативного EventSource часто недостаточно для production SSE: авторизация через headers, контролируемый reconnect, backoff, race conditions, stale-stream watchdog и синхронизация нескольких вкладок через Web Locks + BroadcastChannel.

На базе этих проблем я вынес real-time слой из AI SaaS-продукта в open-source библиотеку sse-runtime и заменил ей самописную инфраструктуру: −3 455 строк кода в production PR, один useSSE-хук вместо ручного reconnect, leader election и отладочного boilerplate.

«Солнечный бум» последнего десятилетия слабо ощущается в РФ, но хорошо заметен в США, Европе и Китае, где строят гигантские солнечные фермы на тысячи гектаров. На потребительском рынке тоже ажиотаж, ведь в солнечных широтах можно полностью обеспечивать дом электроэнергией, если покрыть крышу солнечными панелями. И даже на зарядку автомобиля хватит, если крыша большая.

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

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

Из новостей: продажи Mina the Hollower превысили 300к копий, продажи 007 First Light перешли за 3 миллиона, Valve обновила дизайн главной страницы Steam, в разработке находится ремейк Baldur’s Gate II.

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

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

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

В одном из проектов этот узел был собран так, первый платеж создается с capture=False, входящий webhook проверяется по IP, каждое событие сначала пишется в журнал, потом маршрутизируется в обработчик, capture подтверждается стабильным idempotence key, успешный платеж валидируется по сумме, валюте и metadata, а на случай расхождения остается отдельный ручной confirm, который умеет дочитать фактический статус из ЮKassa и синхронизировать локальную базу.

То есть задача тут не просто принять webhook, а построить платежный контур, которому можно верить.

Всем привет! Я хочу поделиться историей о том, как обычная пользовательская боль заставила меня открыть Android Studio и сделать свой первый серьезный проект.

Я очень люблю читать с телефона (особенно ранобэ, новеллы и книги в оригинале). Но в последнее время индустрия мобильных читалок свернула куда-то не туда. Открывая популярные приложения, я чувствовал себя пилотом Боинга: десятки перегруженных меню, всплывающие баннеры, просьбы купить Premium-подписку и интерфейсы прямиком из 2012 года.

Но моей главной болью был перевод. Когда ты читаешь книгу на английском и встречаешь незнакомое слово, тебе приходится выделять его, копировать, открывать Google Переводчик, вставлять, читать, возвращаться в книгу… Погружение в историю рушится моментально.
Есть, конечно, Circle to Search или читалки с функцией перевода, но мне они показались максимально неудобными

Я искал минималистичную читалку со встроенным удобным переводчиком. Не нашел. И решил написать её сам.

Бухгалтерия прислала акт на списание 200 станций. ИТ открывает список — а 60 из них работают прямо сейчас. Разбираем, почему бухгалтерский и ИТ-учёт живут в параллельных реальностях, сколько это стоит компании и как перестать списывать рабочую технику.

Третья часть написания своего языка программирования на Rust с нуля: Парсинг первых стейтментов языка: вывод и присвоение.

Когда нажимаешь кнопку Thinking и видишь, как модель несколько секунд «размышляет» перед ответом — легко решить, что она просто старается сильнее. Работает усерднее. Думает глубже. Может, перебирает больше вариантов из какой-то внутренней базы знаний.

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

Если ориентироваться только на публичные обсуждения, может сложиться впечатление, что большинство проектов уже давно перешло на Spring Boot 3.x. В крайнем случае команда прямо сейчас выполняет миграцию, закрывает несовместимости и движется к актуальному стеку.

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

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

Просто публично такие детали обычно не выносят. Или говорят о них очень осторожно.

Отсюда появляется важный вопрос: если это распространённая практика, почему её так неудобно обсуждать? Почему факт использования старой версии фреймворка воспринимается почти как признание в инженерной неаккуратности?

Попробуем разобрать это без морализаторства.

Представьте ситуацию: вы открываете какой-нибудь файл в проекте, которому уже года три (чаще всего это форма). И в голове всплывает мысль:  «А что тут вообще происходит?». Причём не в смысле «кто виноват», а в смысле «как мы вообще сюда пришли?».

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

Когда возникает идея создать браузерный IRC-клиент без JavaScript, приходится сталкиваться с классической проблемой фронтенда: все насколько привыкли гнать динамику через JavaScript, что перестали замечать возможности HTML/CSS с щепоткой серверной магии по реализации многих фич. HTTP Streaming существует с давних времён, а CSS эволюционировал настолько, что может справиться с логикой состояний — но мы упорно продолжаем грузить мегабайты JavaScript (и иногда даже WebAssembly) для решений, которые вполне можно реализовать иначе.

Идея создать IRC клиент без JavaScript не совсем нова (хоть это и выяснилось уже после создания такого :) ). Ещё в нулевых появился CGI:IRC — настоящий IRC клиент, который может работать полностью без JavaScript, позволяя людям общаться в реальном времени через браузер, даже если JavaScript по каким-то причинам не работал. Но это было в эру table-layouts, и когда CSS не был так развит, как сейчас. Сегодня возможностей больше, и мы воспользуемся ими, чтобы навернуть функциональность, которая не видана CGI:IRC.

Результат можно глянуть (хоть и с дополнительной стилизацией и изменениями, которые не так важны для статьи) здесь, а ещё на GitHub