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

Каждый, кто работает в IT, знает: технологии развиваются стремительно, а времени на то, чтобы за ними поспевать, не всегда хватает. Чтобы оставаться востребованным специалистом, нужно постоянно изучать что‑то новое. Но где искать качественную информацию, которая действительно применима на практике?

Наша команда всегда старается делать разнообразный и интересный контент. Если он вам нравится, и вы думаете: «Контент классный, я тоже так могу», — давайте делать это вместе! Ведь у нас не только можно попробовать продукт или записаться на демо. Мы открыты к коллаборациям и предлагаем множество вариантов взаимодействия. Обо всём по порядку.

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

Сама техника делегирования обычно не вызывает вопросов. Есть матрица Эйзенхауэра, есть SMART, есть чек‑пойнты, есть обратная связь. Всё это довольно понятно и давно известно. Но у многих тимлидов сложность начинается не там, где надо выбрать инструмент, а там, где надо реально отдать задачу другому человеку.

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

Клиент попросил API для подключения OpenClaw и запуска своих ИИ-агентов. Прежде чем делать своё, разобрались вместе: сколько реально стоит поднять агента с нуля (компетенции, доступы, железо) и что модели знают о Directum RX «из коробки».

Ад бесконечной переписки с аутсорсером КДП, внедрение воинского учета, подбор и интервью, организация новогоднего корпоратива, подготовка к выплате зарплаты, тушение внезапных пожаров от руководства («есть такая идея, коллеги, нам нужна концепция бренда работодателя для завтрашнего совета директоров.»), делегация из Китая и поиск чемодана участника делегации в Шереметьево. Ради того, чтобы завтра решать этот же список задач. Ну, может из Китая никто не прилетит. А если прилетит, то не перепутает багаж. Через год Вы будете делать тоже самое. Может быть чуть быстрее.

Роль HR Generalist (HRG) как вида деятельности не масштабируема. Но роль можно сменить. На HRD, HR Бизнес‑партнера. Или HR Product Owner. О последней я и предлагаю поговорить, тем более, что она особенно актуальна для HR Generalist в IT команде.

Диагноз: почему HR Generalist застревает

Роль HR Generalist исторически сложилась как универсальная сервисная функция, пытающаяся закрыть любую потребность бизнеса, связанную с людьми. На практике она превратилась в операционную ловушку. Есть заказчик с его капризами и невнятными ТЗ. И есть исполнитель чужих запросов без возможности влиять на саму архитектуру.

Вопрос о роли HR в бизнесе носит какой‑то перманентный характер. Эта дискуссия продолжается и не утихает с момента появления профессии, особенно на российском рынке труда. Редкий чат обойдется без вопросов — доколе к HR будет такое отношение и как бы заставить бизнес «нас уважать».

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

Привет, Хабр! Это Данила Трусов, директор продукта «Инферит ИТМен».

В этой статье расскажу, что изменилось в новой версии 7.2 нашей системы учета, инвентаризации и контроля ИТ‑активов, и почему эти обновления сделают управление инфраструктурой прозрачнее и проще.

Если ваша инфраструктура постоянно растет, в ней регулярно появляется новое оборудование, меняются конфигурации и проводятся плановые работы, вы наверняка знаете, как важно держать руку на пульсе. Система инвентаризации ИТ‑инфраструктуры должна быть не просто инструментом сбора данных, а предсказуемым и управляемым помощником. Именно на этом мы сфокусировались в версии 7.2.

Я довольно долго был уверен, что понимаю, как работает call stack.

Ну а что там понимать? Положил кадр, снял кадр, LIFO.

Потом открыл спецификацию. Оказалось, за «стеком вызовов» стоит каркас из пяти сущностей, а половина привычных объяснений просто не совпадает с текстом стандарта.

Замыкание — не фича языка, а побочный эффект того, что окружение живёт отдельно от кадра. «Область видимости» — вообще не сущность: такого термина там нет. А слов event loop, microtask и task queue в ECMA-262 ровно ноль. Проверяется грепом за минуту.

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

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

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

Как следует из названия, эта книга в значительной степени посвящена системе аутентификации и авторизации для веб-приложений. Более общие вопросы безопасности см. в серии “Шпаргалки OWASP” .

Если у вас возникнут какие-либо вопросы, не стесняйтесь задавать их на сервере Discord или в обсуждениях на GitHub.

Разработано и поддерживается Pilcrow. Исходный код доступен на GitHub.

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

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

Разговор всегда начинается одинаково. «Вы же делаете детекцию брака на конвейере: там деталь и дефект, тут снимок и опухоль, разница в датасете. Дайте модель, которая находит рак, точность нужна процентов 98, ну 99, чтобы наверняка».

Логика в этом есть, и я не иронизирую. Архитектурно между дефектом сварного шва и узлом в легком действительно нет пропасти, обе задачи это поиск аномалии на картинке. Человек напротив рассуждает правильно ровно до того момента, пока не произносит слово «точность».

В шведском исследовании MASAI, самом крупном рандомизированном испытании ИИ в скрининге на сегодня, участвовали 105 934 женщины. Возьмем группу, где маммограммы смотрели с ИИ-поддержкой: 53 043 участницы, рак за время наблюдения нашли у 420 из них. Распространенность 0,79%.

Теперь пишем модель. Она принимает снимок и возвращает «норма». Всегда. Никакого обучения, три строчки на питоне, разработка тридцать секунд.

Ее точность на этой выборке 99,21%.

Заказчик просил 98–99. Константа выдает 99,2 и не находит ни одной опухоли.

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

10 новых российских продуктов для выхода на клиентов вхолодную, автоматизированного тестирования интерфейса веб‑сайтов, управления корпоративными проектами, приемки квартир и строительной экспертизы, создания финансовых моделей для стартапов и бизнеса и многого другого. Битва за «Продукт недели» началась!

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

Часть 1 цикла о программировании Apple Scalable Matrix Extension (SME2) — от первых принципов до промышленной реализации GEMM.

В первой статье я разбирал RAG-модуль этого проекта и главный вывод — что RAG оказался про замеры, а не про код. Здесь — про то, как устроена вся система вокруг него: классификатор, который решает, кому вообще нужна помощь, определитель типа проблемы и архитектура, которая всё это связывает.

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

Всем привет! Я Юля Гончарова — продакт, дизайнер и... «вайбкодер». Последний год я строю продукты в одиночку с помощью Claude Code — от идеи и UX до кода и запуска. В этой статье расскажу про один из таких проектов: стартап, который я уже третий месяц развиваю как solo founder. Здесь я поделюсь тем, как мне удалось снизить затраты на токены, оставшись на модели Claude Sonnet 4.6.

Для понимания контекста: продукт, о котором идет речь — это веб-приложение с мультиагентной системой. Один агент собирает данные о пользователе при регистрации, второй помогает ему подобрать и сформулирвоать цель (продуктом пользуются оснвоатели стартапов ранней стадии), третий ведет регулярный чек-ин (синк-сессии), четвертый — ежедневный чат-помощник, через которого пользователь может управлять любым функционалом, включая заполнения профиля-питч-дека или смены расписания синков. А еще есть индивидуальные агенты у инвесторов: те, которые настроены по параметрам конкретного фонда, такие агенты проводят интро-встречу с основателем (симуляцию питча инвестору). Агенты передают друг другу эстафету (например, после сбора данных передают управление агенту постановки цели) и координируются через общие данные, которые читают и пишут все вместе (профиль пользователя, цели, журнал событий) — а не общаются друг с другом напрямую.

Каждый раз, когда AI отвечает, агенту приходится заново «прочитать» весь предыдущий разговор, накопленный контекст по проекту и все свои инструкции — и это стоит денег на каждый ответ. Представьте, что перед каждой репликой в разговоре человек должен перечитывать всю переписку с начала. AI-провайдер (Anthropic) разрешает сказать: «вот этот кусок запомни, не заставляй меня платить за перечитывание». Но у этой «памяти» есть срок годности — и именно то, как мы её использовали, дало основную экономию.

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

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

Но сотрудники всё равно продолжали пользоваться Excel.

Причина довольно простая: корпоративные системы хорошо решают заранее предусмотренные задачи, а Excel позволяет быстро сделать то, чего в них нет. Построить дополнительный расчёт, проверить данные, объединить несколько выгрузок или посмотреть на показатель под другим углом.

При этом у Excel есть проблема, которая особенно заметна в момент, когда результат работы нужно показать другим людям.

Оказывается, школьницы стран бывшего СССР умеют ваять цифровые схемы на CMOS 4000 ничуть не хуже школьников, причем не только русскоязычных школьников, но и школьников из Индии и Китая. Под конец нашей месячной «Школы не в Замке, а в Клубе Хакеров по викендам» образовалась такая теплая компашка:

27 июля Moonshot AI выложила веса Kimi K3 — модели на 2,8 трлн параметров, которая до этого работала только через платный API. Вместе с весами открыли технический отчёт и три внутренних инструмента, на которых модель обучали.

Разберём релиз по частям: что подтверждено независимыми замерами, что остаётся заявлением компании и на какие детали стоит посмотреть до того, как планировать внедрение.

27 июля Moonshot AI открыла веса Kimi K3 и опубликовала результаты модели на coding- и агентных бенчмарках. Мы проверили, как эти показатели переносятся на рабочие операции с файлами, счетами, корзинами, платежами, возвратами и отчётами.

Kimi K3 прошла 204 задачи PAC1 и ECOM1 и набрала 61/104 и 44,75/100. В статье разбираются публичные трассы успешных задач и повторяющиеся отказы: нарушение точной схемы, частично выполненные транзакции, ошибки в длинных таблицах, неоптимальные маршруты и пропущенные проверки доверия. Все запуски и трассы доступны для проверки.

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

Недавно на Хабре вышла статья: автор показал систему для развёртывания собственной инфраструктуры — почта, файлы, сервисы, всё своё. В комментариях его слили. Код закрытый, цель непонятна, «очередная обёртка над docker‑compose».

Я читал и ловил странное чувство: он делал мою идею. И делал её неправильно.

Не потому что руки кривые. А потому что цель другая. Он прощупывал рынок. А рынок молчал. И в этот момент я наконец сформулировал, что строю сам.