Приветствую всех в новом сообществе, где я буду делиться ходом разработки!
Сегодня говорим о том где вообще записываются диалоги игры.
Если вы достаточно информированный фанат, то знаете что Дискач делали с помощью ARTICY, что у них были такие большие деревья диалогов, что программа буквально крашилась.
Вскрытие показало, что я немного отстал от жизни, и язык программирования «Кровожадный краборжав» уже вполне себе пригоден для написания простеньких хелоуворлдов…
Ладно. В кои-то веки обойдусь без ёрничанья. Официально заявляю: я написал свою первую библиотеку на расте и мне понравилось. Раст — несомненно местами красивый и приятный для работы язык. Написание кода укладывается в зелёный диапазон плотности wtf/sec, а инструментарий заслуживает всяческих похвал (кроме кросс-публикации документации на https://docs.rs/, которая в 2025 году занимает час — хоть донаты шли, её-богу).
Итак, я написал библиотеку, которая позволит эрлангистам проще вкатываться в раст. Акторная модель притворяется краденой из эрланга, с примитивами GenServer и GenStatem, с деревьями супервизоров, с боксированными сообщениями, мэйлбоксами, и привычной терминологией. Библиотека названа joerl, светлой памяти Джо Армстронга, с которым мне посчастливилось быть знакомым, и который сильнейшим образом повлиял на менталитет разработчика во мне.
Рассказывать про такие игры как Broken Arrow достаточно тяжело, потому что автор рискует попасть в одну из ловушек. Можно уйти в сухие цифры, терминологию и рассуждения о балансе. Это будет интересно любителям жанра, но для обывателя или новичков — это всё будет звучать как «эльфийский язык». Если же расписать всё «на пальцах», то текст будет не интересен игрокам.
В этой статье я попытаюсь достичь золотой середины. Мы начнем с базового объяснения понятия «варгейм», после перейдем к более подробному обсуждению механик и закончим разговорами о балансе. Приятного чтения.
Не секрет, что каждый из нас, так или иначе, стремится достичь определённой победы в своих начинаниях, которую и называет успехом, причём, для каждого, это будет нечто своё, где, тем не менее, всё равно можно выделить некоторые общие составляющие для достижения этой точки.
Далее, будет мой взгляд на этот вопрос. Постараюсь без занудства и максимально просто (даже картинку поставил чёрно-белую, чтобы ничего не отвлекало от мыслей). :-)
В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny, чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос.
Казалось бы — живи и радуйся. Но я заметил странную вещь: снаружи тихо, а сервер все равно греется. Я заглянул внутрь контейнера и понял: проблема не во входящих пакетах. Проблема в архитектуре самого приложения.
Парадокс: я могу спроектировать архитектуру, которая выдержит падение дата-центра. Я могу дебажить race condition в многопоточном приложении. Но когда мне нужно позвонить в страховую или выбрать отель для отпуска, я впадаю в ступор.
Мой личный бэклог забит задачами типа «разобраться с налогами» и «начать бегать», которые висят там с 2019 года. Я переношу их из спринта в спринт, испытывая фоновое чувство вины.
В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг), только не в репозитории, а в нейросети.
И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.
SIMA 2 — это не просто обновление прошлой версии. Это качественно новый агент от Google DeepMind, который демонстрирует, как крупные языковые модели могут научиться не только рассуждать о мире, но и активно действовать в нем. Цель - создать агента, который понимает сложные инструкции на естественном языке и выполняет их в динамичных 3D-мирах, имитируя действия человека. В качестве платформы для обучения и тестирования используются коммерческие игры (например, No Man's Sky, Valheim) и специализированные исследовательские симуляторы.
Кто угодно может пнуть мёртвого льва. Мёртвый лев не рыкнет на наглеца. Мёртвый лев не откусит ему ногу «по самое не хочу», хотя стоило бы. Лев мёртв, и теперь его может пнуть каждый ишак, что конечно же не показывает превосходство ишака над львом. Эта статья будет полна негодования и ненависти. Кровь ещё закончила кипеть от негодования. Но, разумеется, помимо эмоций будут и сухие объективные факты, немножко исследования и расстановка точек над i. В интернете кто-то не прав... опять...
Существует целый ряд инструментов, технологий и вообще вещей, которым по какой-то непонятной вселенской несправедливости не повезло: нашлась масса непонятных людей, которые по какой-то необъяснимой причине начали распускать про эти инструменты/технологии/вещи разные небылицы, идиотские фейки, слухи и прочий порочащий репутацию «компромат». Можно не переживать, если речь идёт о технологии, которая находится «на пике» — у неё будет большое community и правда восторжествует. Совсем другое дело, когда речь идёт о чём-то, что далеко не на пике, чья минута славы в прошлом (возможно даже давно в прошлом) — здесь мёртвый «лев» не может дать сдачи, и что самое обидное, что в какой-то степени «лев» сейчас мёртв отчасти и потому, что ещё при его жизни началось необоснованное распространение всяких бредовых поверий и мифов про него. И сегодня речь пойдёт об одном из таких случаев.
В октябре 2022 года The Open Group официально выпустил Open Agile Architecture™ (O-AA) — новую версию стандарта, призванного соединить мир «классической» корпоративной архитектуры с реалиями Agile, DevOps и цифровой трансформации. Первая версия документа была опубликована Open Group еще в 2020 году.
Если вы корпоративный архитектор, архитектор решения, бизнес- или системный аналитик, и до сих пор считали, что Agile — это «про разработчиков», а архитектура это «про рисунки и бумажки», эта статья для вас. Задача этой статьи — дать краткое содержание стандарта Open Agile Architecture, чтобы вы могли сами решить, нужно ли его вам изучить подробнее или нет.
Привет. Меня зовут Евгений, и я продуктовый менеджер направления отчетности и визуализации данных в компании «Форсайт».
Хотя корпоративная «Форсайт. Аналитической платформа» (далее просто Платформа) имеет в своем арсенале большое число различного инструментария, на мой взгляд, именно инструменты отчетности фактически являются ключевым блоком и «лицом» Платформы и BI-приложений, реализованных на ее основе. Ведь это первое, c чем сталкивается конечный пользователь и на что обращает внимание при работе: наличие необходимых функций, удобство построения пользовательского интерфейса, скорость работы — все это пользователи часто записывают именно на счет компонентов отчетности.
Хочу поделиться с вами нашей «вендорской» историей от том, как развивался инструментарий отчетности в составе нашей Платформы, какие интересные компоненты появились у нас относительно недавно, и над чем новым «Форсайт» работает прямо сейчас. Итак, начинаем!
Вчера я уже писал о завершении трейдингового турнира Alpha Arena Season 1.5, где ИИ-модели торговали токенизированными акциями Tesla, Nvidia, Google и Amazon на реальные деньги. Из восьми участников в плюсе осталась только "секретная модель", чей портфель вырос на 12,11% — теперь стали известны подробности о ней.
В рамках «CNews FORUM 2025: Информационные технологии завтра» состоялась традиционная церемония вручения премии CNews Awards 2025, на которой платформа для создания отказоустойчивых сред VMmanager была признана как: «Серверная виртуализация: продукт года».
Последние 2 года я выстраивал и непрерывно улучшал собственную систему планирования в Obsidian. За это время я обнаружил кое-что важное, что решил разделить с сообществом.
И вот что я заметил: почти все, кто пытается выстроить систему управления, начинают с одного и того же вопроса — «Какой инструмент мне взять?» Notion? Jira? Obsidian? Linear? Асана?
Тут я всегда отвечаю одно: выбор инструмента — это последний вопрос, а не первый.
Последние пару лет я активно работаю с автоматизацией и AI‑агентами. Проекты разные — от чат‑ботов для Telegram до сложных RAG‑систем с векторными базами. И знаете, что меня всегда бесило? Каждый раз при развертывании нового проекта уходило несколько часов, а то и целый день на настройку окружения.
Сначала настраиваешь Docker Compose для n8n, потом прикручиваешь Postgres, потом вспоминаешь про Redis (потому что без него n8n в queue mode не заведешь), потом Supabase для векторов, потом Qdrant, потому что Supabase для векторов медленноват... А еще же HTTPS нужно настроить, Caddy или Nginx сконфигурировать, сертификаты получить. И так каждый раз.
После очередного развертывания я подумал: «Хватит, надо это автоматизировать раз и навсегда». Так родился n8n‑install — репозиторий, который превращает чистый Ubuntu VPS в полноценный AI‑стек одной командой.
История удаленного управления серверами — это история борьбы с расстоянием. С момента появления первых дорогостоящих мейнфреймов, работавших, дай бог, на перфокартах, инженеров стал волновать вопрос — как контролировать критически важное оборудование, не находясь рядом с ним 24/7? Ответом стала череда технологических решений: от примитивных терминалов на выделенных линиях до сложных сетевых архитектур и, наконец, интеллектуальных встроенных контроллеров. В этой статье рассмотрим ключевые этапы этого пути — от проприетарных систем 1970-х (IBM SNA) через трансформацию 1990-х к рождению универсального стандарта IPMI. Мы постараемся как можно интереснее рассказать об ИТ-ландшафте, заложившем основу для современных инструментов управления серверами. Где-то пройдемся по верхам, где-то остановимся чуть подробнее.
Работать в агентстве или на стороне клиента? Джентльменский разбор
Есть вечная история: сидит спец в агентстве, получает по лицу от клиента на созвоне и думает — хватит? Перейду-ка я на сторону клиента, сидеть буду спокойно, задачи ставить, за них спрашивать и если что покричать смогу. Кто мне что сделает? Власть. Рай.
Базово существует существовал карьерный трек по учебнику: вырастаешь до сеньера или хеда > переходишь в инхаус > «кайфуешь».
Тем не менее, романтизировать такой подход — базовая ошибка агентской жизни. Откуда взяться пониманию того, что трафик — лишь малая часть воронки? В агентстве более широкий взгляд на маркетинг и иные функции появляется не у всех. Ему просто неоткуда взяться: зачастую не с кем и не на чем его развивать.
Отсюда и рождается конфликт двух миров: некомпетентный клиент в глазах агентства и подрядчик, который видит перед глазами только рекламный кабинет.
Распишу кратко свое имхо, какие есть плюсы и минусы с обеих стороны.
📌 Клиентские плюсы
1. Шире картинка
Смотришь на продукт по новому: офлайн, онлайн, бренд, пиар — перечислять можно долго. Сплит не делится на перформанс и медийку, грубо говоря. Даже если ты не отвечаешь за все, то все равно будешь вникать во все аспекты.
2. Погружение в один продукт
Нет десяти ниш одновременно. Куда глубже вникаешь в нюансы, за счёт чего решения в рамках бизнеса и его специфики принимаются куда корректнее. Не будет ощущения, что ты «по верхам».
3. Прямое влияние на деньги
Один трафик не всегда влияет напрямую на бизнес-результаты, следовательно, твой импакт на рост прямо пропорционален твоим решениям, изменениям в сплиту и работе по всей воронке.
4. Стратегический взгляд
Оптимизировать кампашки в Директе — одно, смотреть на продукт со всех сторон — требует больших навыков.
📌 Клиентские минусы
1. Агентство — твои руки, но не твои люди
Уметь выстроить отношения, коммуникацию, мотивировать и понимать, на что можно давить, а на что нет — достаточно сложно.
2. Узкая ниша = более сложный переход
Работал три года в условном мобайл-екоме? Рынок может решить, что больше тебе и не надо ничего видеть другого.
3. Бюрократия
Сменить подрядчика, внести изменения на лендинге? Если ещё и корпорат — будет непросто.
4. Монотонность
Один продукт может быстро надоесть, а в агентство для более красочной картинки могут не взять. Темп другой. Где-то стереотип, а где-то правда.
5. Кросс-функциональные войны
Маркетинг, продукт, закупки, CRM — не всегда одна команда. Каждый хочет оторвать свой кусок, особенно в период кризиса.
📌 Агентские плюсы
1. Быстрый рост
Темп высокий, задач много — бери инициативу и расти.
2. Насмотренность
Тендеры, разные бизнес-модели, разные клиенты. В целом это может сформировать тот самый более широкий взгляд, но смотря где работать.
3. Многозадачность
Сроки вчера, пять брифов одновременно — сейчас особенно нужны люди, которые умеют в жнеца и грецa.
4. Отвечать за один трафик проще
Отчасти это плюс, поскольку твоя задача — чтобы договоренности и коммиты на КПИ с клиентом были выполнены. Если всем win-win, то будь здоров.
📌 Агентские минусы
1. Риск застрять в одной функции
Достаточно легко много лет запускать один канал, а потом осознать, что рынок уже не тот.
2. Ограниченный доступ к продукту
О чём уже проговорили — не так часто клиенты пускают агентства к себе внутрь.
3. Сложнее перейти на клиента
Особенно сейчас, когда работодатель не готов рисковать. А тот же стереотип про агентских, которые мыслят поведенческими метриками, — всё так и осталось.
4. Высокий темп
Более быстрое выгорание. Не всем подходят клиенты, защиты, тендеры, хотя, считаю, сейчас это плюс. Всё очень динамично и быстро, нужно быть готовым.
5. Рынок не так «уважает»
Есть вайб на рынке, что агентство — про продажи того, что не нужно. Клиент более презентабелен, скажем так, в новом костюме. Это вопрос отношения.
Романтизировать ни один путь не стоит. И агентство, и клиент — две разные реальности с разными правилами.В идеале — попробовать и то и то. А дальше будет понятнее, на чём можно остановиться.
Один ответ вряд ли кто-то даст.
«А если мы просто возьмём больше разработчиков, уложимся к концу месяца?»
Если больше людей будет участвовать в разработке, значит, все задачи можно будет распараллелить. Тогда срок разработки сожмется пропорционально количеству дополнительно привлеченных специалистов – что-то такое обычно строится в голове у тех, кто не знаком с реальным процессом разработки цифрового продукта. В статье – о том, как происходит на самом деле, и как победить ограничения.
Сегмент инфраструктурного программного обеспечения в России переживает качественный сдвиг от “бумажного” импортозамещения к комплексным проектам на отечественном стеке. Российские операционные системы и службы каталогов становятся основой корпоративной цифровой инфраструктуры компаний и определяют уровень безопасности, управляемости и независимости бизнеса.
Эксперты РЕД СОФТ и К2Тех проанализировали, как меняется рынок базовых инфраструктурных сервисов и какие тренды будут определять его развитие в ближайшие два года.
Ресурсы: YouTube | Анонс | Документация
Далее коротко о том, что нам подарили на ближайшие два года Unity в этот раз...
Минцифры РФ приняло решение постепенно отказываться от подтверждения входа на портал «Госуслуги» через СМС из‑за растущих случаев мошенничества.
Кейс: «Жива Технологии» арендует в облаке виртуальные машины с GPU для приложения с AI 🤖💬
👨💻 Что за компания
«Жива Технологии» — разработчик приложения JIVA, ассистента с AI, который помогает вести здоровый образ жизни. В приложении можно составить план, чтобы достичь поставленной цели: рассчитать норму воды, построить график тренировок или поправить технику упражнений.
А еще искусственный интеллект рассчитывает по фото питательность блюда: вес порции, количество калорий, белков, жиров, углеводов, микро- и макро-нутриентов. В результате такого анализа AI-помощник в JIVA советует, что можно заменить или добавить, чтобы прием пищи стал полезнее.
🕵️ Какая была задача
Искусственный интеллект внутри JIVA — это AI-модели для распознавания нутриентов по фото, встроенный AI-ассистент на базе LLM и каскад моделей по детекции и распознаванию физических упражнений. Все модели разработчик собрал на open source.
Клиенту были нужны видеокарты с GPU для инференса и обучения этих моделей. Закупать свои графические процессоры оказалось невыгодно, и он решил арендовать их в облаке. «Жива Технологии» хотел использовать виртуалки с GPU и другие облачные сервисы, чтобы мониторить работу моделей и управлять ресурсами в одном месте.
📈 Результат
Клиент использовал набор сервисов Cloud.ru, чтобы развернуть в облаке бэкенд приложения, тестовую и продовую среду и сами модели:
Развернул бэкенд и модель для подбора упражнений на пяти ВМ платформы Cloud.ru Advanced. Там же подключил сервисы для мониторинга, логирования и работы с базами данных.
Для LLM выбрал две платформы: Cloud.ru Evolution для тестовой среды и дообучения и Cloud.ru Advanced для продовой среды и инференса моделей.
Тестовую среду развернул на виртуальных машинах Evolution Compute c GPU с гарантированной долей vCPU 30% 8vCPU 16GB RAM. Для тестирования взял одну GPU-карту A100 — она позволяет экспериментировать при обучении и тестировании LLM.
Чтобы собирать данные для дообучения и хранить бенчмарки, выбрал объектное хранилище Evolution Object Storage.
Для продовой среды выбрал виртуалки с такими параметрами: 20 vCPU 117 GB RAM 1 × A100 NVIDIA 80 GB.
🚀 Что дальше
В планах «Жива Технологии» — ускорить распознавание нутриентов по фото с 8–9 до 2–3 секунд, не арендуя при этом дополнительные GPU. У Cloud.ru есть сервисы, которые помогают в инференсе моделей, их дообучении и не только. Например, для запуска и развертывания ML-моделей предложили клиенту протестировать сервис Evolution ML Inference.