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

Не так давно меня приглашали тестировать Figma-like редактор от Ростелекома. Тогда он был всё-таки сильно сырой. Оказалось, что другие команды не дремлют и тоже готовят свои решения. Сегодня у нас на обзоре новый кандидат на импортозамещение Figma. Называется linia.pro. Сервис около года разрабатывается командой из Москвы.

Большинство экспертов, наставников, онлайн‑школ при запуске своего курса/обучения думают о том, как получить ту конверсию заявок и учеников, которые они поставили себе как цель. Думают также о своем продукте и его качестве, чтобы ученики получили и были довольны своими результатами. И совсем забывают обезопасить свой запуск с юридической стороны. Как итог: несут колоссальные убытки.

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

При всех достоинствах Telegram, есть у него одна особенность — он тоже оставляет следы в ВебАрхиве. То есть, при наличии желания и определенного количества свинца (не картечи) в пятой точке, мы можем найти следы жизнедеятельности того или иного персонажа в Telegram через Wayback Machine.

Для этого мы можем пойти сюда: https://web.archive.org/collection‑search/telegram и начать лопатить все вручную. Дорки нам в помощь. А можем автоматизировать наш поиск при помощи CDX API или собственных скриптов или других приспособлений. Это уж кому как больше нравится.

Механизм работы с Telegram через Wayback Machine не оригинален и принципиально не отличается от поиска по другим ресурсам. Но, как всегда, есть нюансы...
Разберемся.

Дисклаймер: изначально это был комментарий на другую статью, но та статья оперативно улетела в черновики, а @0xKubik — в readonly (?!). Так что пишу тут, в надежде что однажды автор ответит тут, или свяжется иначе.

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

Статья будет полезна тем кто работает в автоматизации retail, речь в ней пойдёт о настройке весов rongta RLS1000/1100 — с ними частенько приходиться работать на просторах СНГ.

Первая версия получилась курсом по shell-скриптингу. А я не этого хотел: мне нужно было разобраться с Linux на практике, а не в теории по книге — права, службы, журналы, монтирование, сеть. На выходе же лежала полсотня заданий вида «напиши .sh, который…». Хотя каждое по отдельности выглядело нормально.

Заметил я это, когда стал считать, что человек физически делает в каждой серии. Почти везде одно и то же: открывает редактор и пишет скрипт.

Причина скучная и техническая. Скрипт легко проверить: запустил, посмотрел вывод, сравнил. Всё остальное проверять неудобно, поэтому всё остальное вымывается само, без чьего-либо умысла. Модель, которой я всё это надиктовывал, пошла по пути наименьшего сопротивления, опираясь на курс по языку C, который я дал ей как образец.

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

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

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

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

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

Я продуктовый дизайнер, больше шести лет делаю SaaS. Программировать умею, но фулстек-разработчиком себя не назову. Уже несколько месяцев я в одиночку делаю Котомку, планировщик жизни по методу PARA: сферы, проекты, задачи, календарь, привычки, финансы. Есть веб, мобильная версия, синхронизация между устройствами и с Google и Apple календарями. Почти весь код пишет Claude Code. Я ставлю задачи, проверяю результат и принимаю решения.

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

На практике мощный вычислительный кристалл может значительную часть времени ждать, пока память и интерфейсы доставят ему данные. За десять лет производительность вычислительных блоков GPU выросла намного быстрее пропускной способности памяти, а стоимость HBM остается высокой и в последние годы росла даже в пересчете на емкость и пропускную способность. Поэтому эффективность современной ИИ‑платформы определяется уже не отдельным чипом, а всей системой: памятью, межсоединениями, хост‑процессором, компилятором и программной средой.

Может ли Россия участвовать в этой гонке, не пытаясь полностью повторить NVIDIA? Какие направления выглядят реалистичнее универсального GPU и где в подобных системах может использоваться RISC‑V?

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

Мне нужны были говорящие часы для слабовидящего человека. Купил первые попавшиеся на маркетплейсе и понял, что они непригодны, так как звук тихий, голос высокий и неразборчивый для пожилого человека.
Пришлось слепить говорящие часы самому. Использовал то, с чем был знаком. А именно, написал программу для Windows. Возможно, кому-то пригодится.

Я хотела разобраться, куда вообще движется профессия продуктового дизайнера и какое место в ней теперь занимают AI‑инструменты.

А в итоге разобрала файлы проектов Claude Design по кусочкам, потратила месяц на отладку и сделала плагин, который переносит готовый проект из Claude Design прямо в Figma — с редактируемыми слоями, auto‑layout, текстами и данными.

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

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

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

Днём я пишу код в Claude Code, вечером хожу в зал: у меня пауэрлифтинг, тренировки тяжёлые, часа по два. Тренера я сделал для себя. Хотелось, чтобы тот же Claude, в котором я работаю, вёл и мои тренировки.

Так появился claude-gym-coach, open-source тренер по силовым внутри Claude Code. Один раз рассказываете ему, кто вы и чего хотите, и дальше он ведёт сам: составляет программу под ваш зал, перед каждой тренировкой расписывает веса по вашей истории, после тренировки записывает то, что вы скажете в телефон, и раз в блок разбирает, что сработало. Если раньше был дневник, его можно перенести, и новые тренировки тренер строит от него. Отдельное приложение и отдельная подписка не нужны: всё работает внутри Claude Code, на той подписке Claude, которая у вас и так есть.

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

Дисклеймер. Все описанное выполнялось в изолированной лаборатории на вымышленном приложении, которое я собрал специально для статьи. Совпадения имен с реальными продуктами случайны. Материал образовательный — для AppSec, .NET-разработчиков и всех, кому интересно, как «сохранить объект в файл» превращается в удаленное выполнение кода. Не применяйте это к системам, на которые у вас нет письменного разрешения.

Есть распространенный страх: анализ защищенности — это что-то темное, для избранных, с ассемблером и магией. На деле большая часть работы — это чтение кода по понятным правилам. Сейчас разберем реальный по механике баг (небезопасная десериализация в .NET → выполнение произвольной команды) так, будто читаем букварь: сначала буквы, потом слоги, потом целые слова.

К концу статьи вы будете уметь: декомпилировать .NET-приложение, находить в нем точки сериализации и десериализации, читать свойства и сеттеры, отличать безобидный класс от «gadget» и по одной строчке понимать, есть ли уязвимость. Все воспроизводится на приложенном стенде.

Про цвет. Листинги с подсветкой даны картинками. Цвета: желтый — имя класса/тип, синий — имя свойства, зеленый — значение (данные), красный — опасное место (sink, уязвимая строка, побочный эффект). В «было/стало» красный — что убираем, зеленый — что ставим.

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

Например, как писать бэкенд — понятно, я это делаю уже 7 лет. Но когда разрабатываешь свой продукт, этого вообще недостаточно. Нужно писать и бэкенд, и фронтенд, уметь рисовать дизайн, как-то анализировать и самому себе ставить задачи: что делаем, а что не делаем. Потом всё это добро должно где-то крутиться — нужны CI/CD-процессы, если есть желание развивать продукт, а не просто один раз выложить первую версию.

Короче, если на работе ты отвечаешь за один участок, то в своём проекте отвечаешь вообще за всё. Хорошо, что занимаюсь этим не я один, а вдвоём с братом. Ответственность за разработку поделили: он — CI/CD, деплой и фронтенд; я — дизайн, продуктовые решения и бэкенд.

В итоге запустились. Ура, мы сделали это: приложение работает, и мы этим гордимся. Но теперь началась новая история — в том, чего мы не умеем. Маркетинг.

Наивность, fail-fast, fallback, failback, оптимизация и стратегия — на слизне, на кухне и на JavaScript

Эти слова программисты произносят каждый день, и почти каждый понимает их немного по-своему. Можно было бы начать со словаря: шесть терминов, шесть определений. Это был бы наивный план — в том самом смысле, о котором пойдёт речь ниже, — и к концу статьи станет видно, почему я от него отказался.

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

Резкий рост подписчиков, высокий охват и тишина в комментариях ещё не доказывают накрутку.

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

Внутри схема проверки, таблица наблюдений и пример того, как один вирусный пост искажает средний охват.

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

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

Последнее — про цену проверки при компиляции. Шаблоны лежат в ресурсах приложения, а структура отчёта — в Java-классах, значит любая правка идёт через сборку и деплой. Если отчёты у вас меняются чаще, чем выкатывается приложение, подход вас затормозит — и лучше знать об этом заранее.