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

Недавно я выпустил две статьи - про подход POSSE и про SEO + GEO в 2026 году. В комментариях и личных сообщениях несколько человек попросили описать техническую часть.

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

Разбор межфайловой дедупликации на версионных данных: почему обычная упаковка упирается в потолок и что меняется на CPython, Go и Node.js.

Прочитал на Хабр статью [1], в которой автор простым языком даёт достаточно глубокое представление такого сложного и важного математического объекта как фильтр Калмана и захотел предложить читателям посмотреть на него (фильтр Калмана) несколько с другого ракурса. Сразу хочу предупредить, что перед чтением данной статьи хорошо бы прочесть статью [1], так как даже формулы были специально взяты ровно оттуда, дабы данная статья базировалась на материале упомянутой работы [1].

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

Общая идея такова: берём математическую модель двигателя и в режиме реального времени «запитываем» её показаниями датчиков напряжений фаз работающего двигателя насоса. Показания датчиков тока используем для того, чтобы в реальном времени втянуть виртуальную модель в такой режим, при котором виртуальные показания квазидатчиков тока математической модели станут равны показаниям реальных датчиков тока. То есть в этом случае мы получим виртуальную real time модель из которой можем взять любую информацию, которой она располагает, в частности частоту вращения электродвигателя.

А теперь изложенную идею попробуем воплотить в виде математических абстракций.

Привет, Хабр! Меня зовут Андрей Горлов, я CEO IT-компании «Альтеркод» и программный эксперт курса «Python-разработчик» в Яндекс Практикуме. Недавно мы провели рефакторинг программы: добавили больше практики, обновили версии фреймворков и сделали обучение более сбалансированным для студентов.

В этом материале мы с продуктовым лидом Александром Скугаревым кратко расскажем об изменениях. Текст будет полезен тем, кто хочет узнать больше о том, как устроено онлайн-образование в IT, и всем, кто думает об обучении Python в Практикуме.

Привет, Хабр!

Есть вещи в Rust, которые работают незаметно, пока не ломаются, да ломаются они странно... Компилятор указывает на место, где вы ничего плохого не делали, и говорит про «lifetime mismatch» или «mismatched types» без внятного объяснения почему. Или наоборот: вы ожидаете ошибку, потому что передаёте ссылку с явно другим временем жизни, а компилятор молчит и пропускает.

Оба случая объясняются одним механизмом: variance.

Большинство останавливаются на трёх определениях и паре примеров. Пойдём глубже — до алгебры композиции, до того, как компилятор выводит variance через итерацию фиксированной точки, до #[may_dangle] и до того, почему NonNull<T> ковариантен, а *mut T нет.

Что, если идеальное устройство для руки — это устройство, которое почти невозможно напечатать на 3D-принтере? Именно в этом парадоксе мы застряли на несколько месяцев, когда начали делать Trackball Royale.

У нас в компании почти всё делается через 3D-печать. Не как маркетинговый тезис — буквально: от первого эскиза до серийного корпуса, кото…

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

Поиск и сборка датасетов. Хорошо, если есть открытые и с допустимой лицензией. Но часто приходится собирать «с миру по нитке», дополнять и балансировать данные самостоятельно.

Разметка и аугментация. Качественный датасет — залог хороших метрик. Придётся корпеть над точными detection-боксами, перепроверять, думать над нестандартными ситуациями во входных данных.

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

Но есть и другой путь. Сегодня расскажу о YOLOE — это модель, которая помогает решить эти проблемы.

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

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

Полгода назад написал первую статью про RBACX — RBAC/ABAC-движок авторизации для Python. С тех пор вышло 25+ релизов, и библиотека стала заметно мощнее: добавил ReBAC с поддержкой OpenFGA и SpiceDB, пакетную проверку прав, ИИ-генерацию политик из OpenAPI-схемы, Redis-кэш, async Django, шортхэнд для ролей и закрыл три security-бага. Рассказываю что, зачем и как это вообще делается в одного.

Всем привет!

В какой-то момент у меня появился простой вопрос: «А можно ли заставить ассистента произнести что-то, что он в норме говорить не должен?» Без API, без навыков программирования, без автоматизации и т.п.

Оказалось - можно.

Разрабатываете микросервисы и чувствуете, что бизнес-логика превращается в хаос?

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

Обсудим, почему нельзя хранить объектные ссылки между сервисами, как спроектировать агрегат на Spring Boot

Это первая часть из задуманной серии статей про ИИ. Здесь мы на немного заступим в техническую часть памяти/контекста LLM моделей. Разберем, почему они частенько забывают или выдумывают факты и врут.

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

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

Всем привет! Около года назад я публиковал здесь свои первые шаги в разработке — прототип редактора заметок. Тогда я получил много фидбека: и позитивного (+7 кармы), и критического. Признаю, второй мой пост был излишне эмоциональным и малоинформативным. Я сделал выводы, подтянул навыки и готов показать, во что вырос мой проект FocusMind.

В чем идея? Я по-прежнему считаю, что современные инструменты вроде Notion перегружены. Моя цель — создать максимально быстрый инструмент для тех, кто ценит фокус. Что уже реализовано в новом прототипе:

Космическо-лунный дизайн: Тёмная тема, которая не давит на глаза при долгой работе.

Скорость: Никаких тяжелых фреймворков, тормозящих загрузку. Приложение стартует мгновенно.

Локальность: База данных на JSON-сервере. Ваши мысли принадлежат вам и доступны даже без интернета (Offline-first).

Адаптивность: Я полностью переработал навигацию. На десктопе — удобное боковое меню, на мобильных и планшетах — отзывчивый «бургер».

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

Что дальше? Мой план — за 5 месяцев довести FocusMind до идеального MVP. Впереди переход на IndexedDB для работы с огромными массивами данных и внедрение PWA.Буду рад, если вы заглянете в обновленный прототип FocusMind и дадите технический совет. Особенно интересует ваше мнение по реализации синхронизации локальных данных.

ИИ не заменяет людей - люди просто больше работают. Так давайте хотя бы ночью пусть работает ИИ.

Как мы сделали Авто-Кодера, выжимая максимум из нашей подписки на LLM!

Не знаю, как вам, а мне кажется — не очень-то у него выходит.

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

И давайте прямо сейчас расстанемся с иллюзиями и признаем одну простую вещь: мы нужны им ровно в двух ролях — как поставщики поведенческих данных и как потребители их блестящих безделушек.

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

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

Специфика ИТ в том, что большинство конфликтов маскируются под профессиональные дискуссии. Спор об архитектуре, выборе технологического стека или способе реализации фичи выглядит как разговор «по делу». Однако исследования психологической безопасности показывают: под поверхностью технической аргументации часто скрывается нечто более глубокое. Ситуации, угрожающие психологической безопасности, чаще всего возникают именно в ходе технических активностей: код-ревью, согласования требований, оценки сроков, выбора технологий. За внешне рациональным спором могут стоять: страх показаться некомпетентным перед коллегами; ощущение, что твой опыт обесценивают; угроза профессиональной идентичности и репутации эксперта.

Пока руководитель пытается разрешить спор рациональными аргументами («давайте посмотрим метрики», «обратимся к документации»), реальная проблема остается нетронутой. И конфликт продолжает тлеть.

Как понять, что конфликт пройдет сам, а когда – нет? Не любые разногласия требуют вмешательства руководителя. Многие рабочие разногласия действительно могут быть урегулированы самими участниками или просто «сойдут на нет», если не подпитывать их эмоционально.

Всем привет! Мы создаем простую, быструю и компактную диффузионную модель, которую можно обучать и запускать на обычных видеокартах, сохранив при этом высокое качество. Simple Diffusion (sdxs-1b) – это первый результат наших опытов, мы публикуем её как альфа-версию под лицензией Apache-2.0 вместе с открытым кодом подготовки данных и обучения. https://huggingface.co/AiArtLab/sdxs-1b

TLDR; На обучение SDXL потребовалось ~6 млн долларов. Z-Image говорят обучили всего за 600к. У нас была RTX-4080 и два чемодана желание сделать небольшой прототип быстрой и дешевой модели на imagenet. В процессе мы немного увлеклись. Вероятно удалось создать модель примерно в сотни раз дешевле/быстрее относительно быстро обучаемой SDXL с генерацией близко к реальному времени в высоком разрешении, и без характерных проблем в анатомии, но качество пока в целом ниже (но надеемся будет выше).

Unchartevice 286 — свежая модель ноутбука, которая основана на популярной бюджетной платформе Intel N, в частности используется процессор N150. То есть, этот ноутбук рассчитан на простые задачи, будь то офисная работа, либо, для дома пощёлкать интернет и посмотреть киношку. Кроме всего прочего, этот ноутбук протестирован производителем на совместимость с Astra Linux, и соответственно, идёт в комплекте с некоммерческой версией Common Edition 12.8, в общем, никакого "маздая" из коробки там нет, у меня был ноутбук с Aстрой, но тогда я обошёл её стороной. А может зря? Попробую пощёлкать её и выяснить, насколько ею удобно использовать для повседневных задач, об этом, как всегда, по ходу обзора.

Вы уверены, что ваш “случайный” пароль действительно случайный?

Я тоже так думал — пока не полез разбираться, как Python на самом деле генерирует случайные значения. Оказалось, что привычный random — это не про безопасность вообще. Это генератор, который только выглядит случайным, но при определённых условиях может быть воспроизведён. Что даст нам возможность предсказать все будущие пароли и прошлые.

В статье я последовательно разбираю:

• почему классическая “энтропия пароля” часто вводит в заблуждение;

• как устроен Mersenne Twister и в чём его фундаментальная проблема;

• почему даже хороший seed (через os.urandom) не делает random безопасным;

• и что на практике можно (и нельзя) восстановить, имея время генерации, код и несколько паролей.

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

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