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

Всем привет! Я Вика. Около 2 лет занимаюсь разработкой платформы для организации разработки игр, и мне пришла идея, почему бы мне с коллегами не сделать свою игру для демонстрации её возможностей. Но, чтобы не наступать на типичные грабли, я решила посоветоваться с опытными разработчиками игр.

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

1. С какой самой большой проблемой сталкиваются начинающие разработчики игр?

2. Какие ошибки допускают начинающие геймдизайнеры?

Особо хочу отметить вклад Сергея Шуша, который не просто ответил на вопросы, а практически написал свою статью! Поэтому в следующей части я планирую опубликовать её с указанием авторства и добавлением собственных комментариев к ней. А пока давайте посмотрим на ответы. Сколько людей, столько и мнений, как говорится. 

Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации (Минцифры России) 18 марта 2026 г. опубликовало проект федерального закона «Об основах государственного регулирования сфер применения технологий искусственного интеллекта в Российской Федерации». Предполагаемая дата начала действия закона: 1 сентября 2027 г.

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

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

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

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

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

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

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

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

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

 законы, искусственный интеллект

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

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

Тридцать лет назад, летом 1996 года, весь мир обсуждал только одно: первое в мире клонированное млекопитающее, милую овечку по имени Долли. Тема не сходила с первых полос СМИ и попала в кино того времени, ее обсуждали как в популярных телешоу, так и на государственном уровне — этично ли клонировать человека? Можно ли считать такой клон отдельной личностью? Какие у него будут права?

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

Выложил Blackhole — Python ASGI mock server для тестирования black-box сканеров, обучения и воспроизводимых бенчмарков.
Пока вайбили с Уроборосом родился релиз в другом жанре, о нем ниже. Он offtopic но да простит меня Хабр великий и могучий, не смог удержаться.

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

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

Меня в тот момент зацепили не сами действия, а их архитектурная странность. Формально мои заметки лежали в обычной локальной папке и принадлежали мне. Практически же доступ к ним был завязан на конкретный десктопный клиент, плагины, sync и костыли. Попробуйте, например, нормально достучаться до своей локальной базы заметок с телефона или прикрутить к ней простую автоматизацию и быстро обнаружите БОЛЬ.

Именно тогда у меня появился не ответ, а вопрос: это моя частная боль или уже ставший привычным сценарий у других людей, которые уже ведут большие vault'ы в Obsidian, Logseq, Zim и других PKMS? И если проблема реальна, то чего им на самом деле не хватает — стабильной синхронизации, нормального плагина, ещё одного клиента... или отдельного серверного слоя?

Этот текст — не история в духе «смотрите, я сделал notes‑as‑a-service». Хотя соблазн подать его именно так есть, говорить об этом пока рано. Это дискавери о том, как из личной боли, ресерча и создания MVP у меня сложилась гипотеза, что части пользователей markdown‑заметок нужен не новый редактор и не мощные плагины, а бэкенд поверх уже существующей папки с заметками.

В посте рассмотрим модель эффективной команды под названием "Учпочмак".

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

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

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

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

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

Хороший пример — автосохранение. Когда-то закрыть документ без ручного сохранения означало потерять работу. Сегодня автосейв — базовое поведение системы, о котором пользователь даже не задумывается. Та же история с бесконечной прокруткой. Infinite scroll начинался как экспериментальная альтернатива пагинации, а сейчас это норма для лент, каталогов и социальных сервисов.

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

Знакомо чувство, когда стоишь в магазине перед полкой с йогуртами и не можешь выбрать? Мозг просто вышел из чата. Так выглядит дофаминовая яма после многочасового дебага «неуловимого» бага.

Почему 8 часов сна не возвращают нас в строй, как наш мозг эксплуатирует систему вознаграждения и что происходит с рецепторами, когда мы «в потоке»? Разбираемся в нейрофизиологии кодинга с помощью неврологов, психиатров и глимфатической системы, а в конце — мой личный «Протокол выживания», чтобы не сжечь извилины раньше времени

Недавно поймал себя на знакомом состоянии. Сел разбираться с задачей, открыл IDE, начал копаться в логике — и в какой-то момент оказалось, что прошло почти шесть часов. Без перерывов.

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

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

Получилась странная смесь нейробиологии, самонаблюдений и небольших прототипов.

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

Но в какой‑то момент я понял, что для того чтобы всё это автоматизировать не нужна какая‑то единая сложная система. Достаточно небольших скриптов и связки трёх инструментов:

Массовое внедрение AI в работу менеджмента и экспертов формирует пузырь, который удивительно точно повторяет механику ипотечного кризиса 2008 года. Парадокс в том, что формируется он на самом видном месте. Эксперты, инвесторы, акционеры — все пристально смотрят в документацию компании (или института). Но качество документа не гарантируют качества экспертной информации, которая должна была отражаться конечным артефактом. Документ может быть "токсичным": логично выглядеть, но содержать ошибки, противоречия и «галлюцинации» AI.

“Документы не должны противоречить друг другу” как отдельного требования нет, но оно кажется очевидным из ISO 9001, ITIL и BPM.

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

Управление сервисными аккаунтами, API-ключами, OAuth-сертификатами проблема не новая. Однако, с приходом вездесущих ИИ-агентов появился свежий термин Non-Human Identity (NHI). Почему же вдруг NHI захватил конференции и слайды инвесторов?

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

Управление сервисными аккаунтами, API-ключами, OAuth-сертификатами проблема не новая. Однако, с приходом вездесущих ИИ-агентов появился свежий термин Non-Human Identity (NHI). Почему же вдруг NHI захватил конференции и слайды инвесторов?

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

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

Meshtastic позволяет обмениваться сообщениями через LoRa mesh-сеть даже без доступа к интернету. Но можно ли связать такую сеть с обычной электронной почтой?

Как получать и отправлять email там, где нет интернета и мобильной связи? Я сделал Python-шлюз для Meshtastic, который позволяет передавать письма через LoRa mesh-сеть и также писать ответ в сеть, который потом отправится как обычная почта.

Скрипт проверяет почтовый ящик через IMAP, разбивает письма на небольшие фрагменты и отправляет их через Meshtastic-ноду в сеть. В обратную сторону всё работает похожим образом: сообщение из mesh-сети можно отправить в определённом формате, после чего шлюз превратит его в обычное email-письмо и отправит получателю.

В статье я расскажу, как устроен этот шлюз, как решалась проблема ограниченного размера LoRa-пакетов, как реализована фрагментация сообщений и как подключаться к Meshtastic-ноде через USB или Bluetooth, автоматически находя её текущий адрес.

Итак, я решил довести до реально работающего проекта превосходный эмулятор синтезатора Roland JV880. Это рэковый модуль (без клавиатурный), сделанный на базе синтезатора JV80. Соответственно он поддерживает все карты расширения этого синтезатора и почти все MIDI команды.

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

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

Рынок CRM-систем в России плотно занят: Битрикс24, amoCRM, Мегаплан и другие. Но к сожалению, бесплатных и открытых мало или возможно нет вовсе.

Open-source дает полный контроль над кодом, self-hosted развёртывание и возможность кастомизировать каждый компонент. Сэкономленные деньги с лицензии ПО можно потратить на дополнительную кастомизацию под себя или другие цели кампании.

Я создал FARA CRM — open-source CRM, построенную на современном стеке, запускающуюся одной командой из Docker.

Стек: Python 3.12+ · React 18.2.0 · FastAPI · Docker · PostgreSQL

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

Первое случилось в самолёте. Мне было нечем заняться, и я решил посмотреть фантастический фильм «Она» (Her, 2013). Я человек впечатлительный, и если в истории есть драма, то легко начинаю сопереживать героям. Фильм рассказывает об одиноком мужчине, который устанавливает ИИ‑операционную систему, начинает с ней общаться и постепенно влюбляется в неё. Спойлерить не буду - фильм действительно стоит посмотреть.

Второе событие - это хайп вокруг OpenClaw. Я как раз вернулся домой, занялся своей обычной работой и в свободное время решил изучить, что это такое. К тому моменту вокруг проекта уже было много шума, и он успел набрать около 300 тысяч звёзд на GitHub.

Меня это действительно впечатлило. Ощущение было почти как в фильме про Железного человека: ты запускаешь ИИ, и он, как Джарвис, выполняет задачи и отвечает тебе почти как живой собеседник. Но довольно быстро стало понятно, что у такого подхода есть две серьёзные сложности.

Первая - нужно хотя бы в общих чертах понять, как внутри устроен OpenClaw: что такое ноды, каналы, связи между компонентами и прочие технические сущности.

Вторая - всё настраивается через пошаговый текстовый визард в терминале. Такой подход скорее рассчитан на технически подготовленного пользователя или ИИ‑специалиста, а не на обычного человека.

Неудивительно, что сегодня многие компании либо предлагают уже преднастроенный OpenClaw у себя в облаке, либо продают услуги по его установке и настройке под конкретные задачи.