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

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

Вы купили умную лампочку на маркетплейсе. Вкрутили, подключили к домашнему 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

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

Если вы технарь и работаете с инфраструктурой, то регулярно слышите слова GPU, HBM, NVLink, Tensor Cores, FP8, PCIe и тому подобное. Термины вроде знакомые, но как показывает практика, далеко не всегда люди понимают, что за ними скрывается и как одно связано с другим.

Привет! Я Евгений Зенухин, руководитель отдела развития и сопровождения физической инфраструктуры в Selectel. С запросами в духе «а можно ли вместо одной H100 использовать 10 штук RTX 1080, ведь суммарно VRAM получается столько же?» я сталкиваюсь чаще, чем хотелось бы. В этой статье я решил ответить на базовые, но очень важные вопросы о GPU, развеять некоторые мифы и показать, на что при выборе графического ускорителя нужно смотреть помимо цифр в его спецификации.

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

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

Привет! Я Павел Кокошников, главный разработчик в контактных политиках Т-Банка. Расскажу про кейс с Cassandra. Базу мы выбрали неслучайно: под наш профиль нагрузки, модель доступа и требования к TTL она подходила хорошо. Уже в работе обнаружилась одна особенность TTL, которую мы упустили на этапе проектирования. Из-за нее в полностью исправной базе появлялись логически битые строки.

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