Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

Интервью-ретроспектива с ведущим программистом видео-игры Craftomation 101 о использовании Lua как основного языка в проекте на 60,000 строчек кода.

Дорогие друзья, всем привет! Сегодня мы общаемся с ребятами из студии «Играющие Кошки» — обычно в представлении не нуждаются, но если не в курсе, не беда, кратенько обрисуем. Команда состоит из бывших выходцев студии MiST land, которая запомнилась такими хитами как «Код доступа: РАЙ» или «Альфа: Антитеррор». После распада конторы и основания своей, разработчики взялись за свой первый проект — экшен rpg с видом от третьего лица «Три Богатыря». Следом — серия аркадных игр про кота Парфентия, а также вполне достойные стратегии в реальном времени «Сирия: Русская Буря» и «Передний Край», нашедшие своих поклонников.

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

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

Делимся опытом работы с автотестами в ОК: от подходов к постановке задач до схемы настройки окружения статического анализатора кода.

Материал подготовлен по мотивам доклада руководителя команды автоматизации тестирования ОК Эмилии Куцаревой и младшего инженера по автоматизации тестирования соцсети Евгения Буровникова на ИТ-конференции «Стачка».

Привет! Меня зовут Иван, я бэкенд-разработчик в KTS.

Сегодня расскажу, как в FastAPI эффективно работать с фоновыми задачами и настроить их мониторинг в Prometheus.

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

В статье опишу 5 вариантов: встроенный в FastAPI Background Tasks и 4 библиотеки — ARQ, SAQ, FastStream, адаптированный к асинхронному коду Celery.

В конце расскажу, как мониторить фоновые задачи.

Привет, Habr! Я frontend-разработчик в Альфа-Банк. В статье я хотел бы поделиться опытом внедрения мобильной версии web приложения «Альфа-Бизнес» в нашу архитектуру. А точнее — как без массовых доработок 100 фронтовых сервисов мы заставили работать mobile web версию с новой навигацией.

Возможно, у вас была мысль запустить собственную услугу Infrastructure as a Service (IaaS) либо разместить свои проекты на Kubernetes, но не платить за managed-услуги, или ваш проект — это и есть self-managed Kubernetes. У full-stack-разработчика и предпринимателя Нейта Бакареффа эти желания сошлись воедино.

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

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

Это выглядит совершенно базовым знанием (а так и есть), при этом знать и иметь навык совсем не одно и то же. Когда вы сидите перед респондентом и у вас несколько секунд, чтобы сформулировать вопрос, легко ли вам выбрать именно открытый вопрос? Я знаю за собой такую черту — я быстро сбиваюсь на закрытые вопросы, если я устала, волнуюсь или что-то отвлекло. Это потому, что навык открытых вопросов даже за много лет применения еще не стал совсем базовым в моей голове. В ИТ очень долго было принято задавать закрытые вопросы, чтобы быстрее подтвердить ожидаемое решение и заказчик «не придумал лишнего». Это приемлемо, если вам нужно подтвердить уже обсужденные договоренности, но совсем не годится для понимания контекста задачи и потребностей заинтересованных сторон.

Привет, Хабр! Это мой первый пост и рассказывает он о попытке нашего небольшого коллектива сделать свою игру, начатую в рамках дипломного проекта. О том, как шла разработка и почему в итоге не получилось — постараюсь рассказать в этой серии постов.

Мы в API отказались от большого количества unit-тестов в пользу большого количества интеграционных/системных, чтобы тестировать меньшим количеством кода большее количество функций, а также наблюдать за взаимодействием разных частей системы.

На самом деле мы просто решили писать тесты не на отдельные классы/методы, а на интерфейс api, которым пользуются клиенты - на сервисы этого API. Тестируя их, мы убиваем двух зайцев: проверяем логику работы сервисов api + форматирование результата.

А такое тестирование сопряжено с несколькими проблемами.

Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:

• какие проверки можно объединить?

• какие и вовсе выкинуть?

Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...