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

Всем привет, меня зовут Илья.

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

Уже больше 7 лет я работаю в ИТ, и, как многие мои коллеги, я стремлюсь постоянно обучаться - читать статьи, смотреть видео и ходить на конференции и митапы. Особенное у меня отношение к статьям крупных ИТ-компаний, как, например, Google, Amazon, но также и к нашим отечественным: Яндекс, Авито, Ozon и так далее. И если проблему чтения отечественных коллег я решил тем, что пару раз в неделю захожу на Хабр и читаю, то для чтения новых техстатей Amazon и других FAANG-компашек нужно было найти другие способы + есть различные нишевые крутые разрабы, которые пишут в своих веб-блогах и редко выкладывают что-то на общие площадки.

Так начался мой путь к формированию лучшего инструмента для чтения статей.

Бывает так: сидишь, листаешь ленту, и в очередной раз натыкаешься на пост, где стафф-инженер из солнечной Калифорнии крутит свежую модельку на паре RTX PRO 6000 общей стоимостью с подержанную машину. Ты смотришь на свою RTX 4060 в ноутбуке, который покупал «не только для игр», и понимаешь: ну ладно, это не для нас.

Так вот, это как раз для нас. На той самой ноутбучной 4060 с восемью гигабайтами и урезанным вдвое PCIe-линком можно получить 39.3 tok/s на 35-миллиардной модели — быстрее, чем медианная скорость декода Codex в проде. Вопрос был не в железе, а в софте, который это железо обслуживает.

Разбираем FreeToken — движок для локального инференса MoE-моделей от команды, которая до этого сделала vLLM и SGLang.

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

И вот я не давно опять вернулся к пересказам. Но теперь уже не в школе и с тетрадкой, а в метро и с телефоном. Пользоваться гуглом транслейтом оказалось не так уж и удобно и я подумал а почему бы самому не сделать специализированное приложение с подстветкой нужной строки, с текстом на русском и английском и самое главное синхронной прокруткой двух окон на разных языках. Так и родился приложение "Удобный пересказ"

Реализация Raft на TypeScript под сидированной симуляцией: каждый тик, каждая задержка сообщения и каждое падение узла берутся из сида. На двадцать пятом прогоне две реплики применили разные значения — при том, что правила алгоритма выполнялись все до одного.

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

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

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

AI-агента сегодня можно собрать за несколько часов. Но это не значит, что бизнес понимает, где его действительно стоит внедрять.

Компании часто начинают с Build: выбирают модель, подключают Jira, GitHub, MCP, собирают workflow. А уже потом пытаются понять, какую проблему они вообще решили.

В статье разбираю другой подход: сначала найти места, где команда теряет время на восстановление контекста, ручную координацию и переключение между системами. Для этого мы в Laplace используем Context Audit и понятие контекстного долга.

Поговорим о том, как увидеть такие проблемы в Jira, Confluence и GitHub, почему не каждую из них стоит автоматизировать и что делать после аудита.

Discover → Build → Measure.

Буквально в паре предложений расскажу о своих впечатлениях после прохождения Mortal Shell 2. Полноценный обзор я писать не собираюсь, так как об игре мне сказать особо нечего. Перед нами типичный, но при этом добротно сделанный соус-лайк, коих в наше время до неприличия много. Главная особенность - отсутствие стамины. Эта деталь делает бои более динамичными и снимает с игрока обязанность постоянно следить за выносливостью. Графика хорошая, но не более. Главным минусом для меня стало окружение, состоящее из скучной серой массы (в некоторых моментах буквально). К тому же я в принципе не большой любитель соулсов, так что качества вроде чрезмерной сложности и отсутствия внятного сюжета, ставшие обязательными в таких играх, отрицательно влияют на мое субъективное мнение. В остальном все неплохо, и перед нами качественный представитель жанра, который можно смело посоветовать как ветерану подобных проектов, так и новичку, ищущему точку для входа в соулсы.

В комментариях к моей недавней статье про фейл с ГОСТ сертификатом сайта ГосУслуг возникла дискуссия о доверии к российским корневым сертификатам Минцифры и о рисках их установки (в систему, в отдельный браузер, или риск использования Яндекс браузера, где они встроены).

Здесь вдаваться в подробности и повторять сказанное много раз не буду, включу только некое саммари из основных тезисов для тех, кто не погружен в тему:

Разбор всех видов SCD (slowly changing dimensions) по Кимбаллу:
- от простого к сложному
- на примерах
- с цитатами Кимбалла

В конце обзора - заполненная шкала со всеми типами и подсказками

Мне казалось, что проблемы неконтролируемого техдолга и потери знаний о проекте командой уже решены (середина 2026 на дворе!), но нет.

В этой статье разбираю эти проблемы на основе своего практического опыта работы с AI Coding.

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

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

Во-первых: живёт ли протон вечно?

Во-вторых: откуда, собственно, берётся его спин?

Эти проблемы относятся к разным разделам физики, но их объединяет одна тема. В обоих случаях протон демонстрирует разрыв между аккуратными представлениями о частицах, которые работают в учебниках, и более странными механизмами, лежащими в их основе: квантовой теорией поля, сильным взаимодействием и, возможно, физикой за пределами Стандартной модели.

В новом выпуске 136 уровней вложенности XCUITest и Android Runtime под капотом, как Tinder сократил холодные старты на 47% и новые условия распространения приложений в Евросоюзе, от Event-Driven UI к State-Driven UI, что нового в Dart, как сделать MCP удобными и действительно полезными, уменьшение трения в приложениях и многое другое. Заходите!

Я проверил семь советов по видимости в нейросетях на 73 страницах, которые модели сами поставили в источники. Я прогнал каждый совет через две группы страниц из собственных логов и посчитал разницу точным тестом Фишера: 34 страницы против 39, различие по авторству 100% против 82%. Это лишь эксперимент на небольшой выборке, но всё же.

В управлении проектами есть довольно большой набор “базовых” вещей, которые принято считать само собой разумеющимися (и это не только “водопад” - “аджайл” - “скрам”). Ну, например, проект желательно хорошо спланировать, работы - оценить, риски - предусмотреть, сроки - поставить, людей - не забыть загрузить, а начатое, если уж оно начато, хорошо бы все-таки закончить.

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

Если интересно, давайте пробежимся по верхам.

Python давно стал почти стандартным инструментом для машинного обучения, анализа данных и научных задач. Однако в вычислительно сложных проектах его производительность быстро становится ощутимым ограничением. Поэтому под привычными NumPy, PyTorch и другими инструментами значительная часть вычислений выполняется компонентами на C, C++ или CUDA. Особенно заметно это становится, когда готовых библиотечных функций недостаточно и высокопроизводительные операции приходится писать самостоятельно.

Несколько лет назад за решение этой проблемы взялась компания Modular, представившая Mojo — новый язык, внешне очень похожий на Python, но построенный иначе. Первую публичную версию показали в 2023 году, после чего проект довольно быстро менялся, а некоторые его конструкции успели исчезнуть или несколько раз поменять форму. Теперь этот этап формально завершен: 11 августа 2026 года вышел Mojo 1.0. Первая стабильная версия стала хорошим поводом разобраться, откуда вообще взялся этот необычный проект и зачем понадобился еще один инструмент для высокопроизводительных вычислений.

Началось всё с довольно простой задачи. Мне понадобилось установить приложение из Microsoft Store, но для моего региона оно оказалось недоступно.

Гуглить способы обхода мне было лень, поэтому я отдал задачу ChatGPT вместе с установщиком. В результате регион Windows был временно изменён, приложение установилось.

Сам способ, конечно, не новый. Регион Windows можно поменять вручную в настройках, поставить приложение и вернуть обратно. Но после этого я подумал: если метод давно известный и с такой проблемой явно сталкиваюсь не только я, почему бы это не автоматизировать?

Так появился WinStoreRegion — небольшая утилита для Windows. На момент публикации актуальная версия — 0.1.0.

Задача звучала просто: получить список компаний определённого профиля в конкретном городе — с сайтом и способом связаться. Не телефоном, а email / Telegram / WhatsApp.

Итоговый скрипт — примерно 400 строк: Playwright для Maps, requests + BeautifulSoup для сайтов, регексы для контактов, txt на выходе. Ниже — не туториал "как повторить", а список мест, где всё ломается.

Вот весь конвейер целиком, с отмеченными точками отказа — дальше по статье разберём каждую:

Разбираю проект, где отчёт по SEO выглядел растущим и при этом почти ничего не приносил. Из 23 169 запросов, по которым сайт нашли за одиннадцать месяцев, 19 633 привели ровно по одному визиту, а раздел, собиравший половину трафика, конвертил в целевое действие на уровне 0,15 процента. Если вы отвечаете за поиск на большом каталоге интернет-магазина или онлайн-сервиса и вам надо ответить руководству, окупается SEO или нет, дальше будут реальные выгрузки, схема учёта и то, как мы считали окупаемость канала по фактическим продажам, которые дозревают уже после клика. Клиент под NDA, называю его производителем электрокарнизов и систем затенения; цифры публикуем с его разрешения, имя и домен скрыты.

Допустим, вы решили заняться беспилотными технологиями в стартапе или RnD подразделении при университете. У вас за плечами мобильный робот на условном Arduino. И вот появился заказчик, который хочет автоматизировать свои процессы и даже готов за это заплатить. Вам нужно взять некую технику, обвешать датчиками и приводами, добавить вычислитель и научить автономно двигаться, попутно решая проблему заказчика. У вас всё серьёзно: у проекта есть руководитель, электроникой занимаются электронщики, механикой - конструктора, есть специализация у программистов (системы восприятия, навигации, планирования и т.п.). Казалось бы, что может пойти не так?

Ниже я хотел бы описать ряд проблем, с которыми столкнулся (как программист) при работе над проектами по созданию беспилотных технологий. Врядли я кого-то удивлю, наверняка это всё “детские болезни”, которые решаются правильным планированием и в зрелых компаниях не встречаются. Но на начальном этапе о них полезно помнить.