Путь от простых хижин к роскошным особнякам, украшенным фресками и колоннами, в Pharaoh — это не просто вопрос архитектуры и разные текстуры. Это отражение заботы игрока о своём виртуальном городе, его нуждах, вере и безопасности. Каждое жилище в городе это FSM, реагирующая на условия вокруг: достаток еды, доступ к воде, религиозные обряды, культурные радости и много чего еще.

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

В этой статье попробую рассказать, как устроена эволюция домов, какие требования стоят за каждым уровнем жилья и как это было реализовано в оригинальной игре. Если вы вдруг пропустили встречу нашего жреческого круга... простите, предыдущие статьи про восстановление исходников этого старого ситибилдера, — обязательно найдите время, чтобы взглянуть на пару интересных моментов (Добро пожаловать в Древний…, ecs, dynvtbl, логические потоки и Фараоне, Как построить мастабу, Как рисуется карта в Фараоне, Новый дом для Фараона)

Все скриншоты в статье сделаны уже на рендере проекта, исходники на github

Как же меня бесят статьи в духе “Как всего за 139 рублей в месяц развернуть свой сайт-визитку на vps”. Какие 139 рублей за сайт-визитку, совсем уже стыд потеряли?!

В этой статье я вам пошагово расскажу и покажу как бесплатно разместить и вести ваш личный сайт(блог, cv, wiki). Вам даже отдельный домен не нужен (всё будет “из коробки”), хотя в последнем шагом мы и его прикрутим. От вас нужны будут базовые знания git и просто уметь работать с markdown.

Однажды я устал расшифровывать аудио пачкой инструментов в духе «Балерино-Капучино и Бобрито-Бандито» и решил собрать свой пайплайн.

В статье расскажу, как я подключил ИИ к обработке голосовых записей буквально за вечер. Мне нужно было загружать запись голоса в нейросетку и на выходе получать выжимку с итогами встречи — саммари/фоллоу‑апами/«минутками». Я хотел от софта безопасности данных, локального запуска и минимума вложений (в идеале 0 затрат). Я системный аналитик, поэтому не был готов писать приложение целиком.

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

Итак, вы наконец-то выкатили в мир свой стартап или микросервис. Поздравляю — это не просто шаг, это рывок. А дальше начинается самый интересный этап: выстраивание доверия. Потому что, как бы ни был хорош ваш продукт, первый пользователь, первый партнер и первый инвестор пойдут не на лендинг, а в Google или Яндекс.

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

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

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

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

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

Мы — команда студентов из ИТМО, которая прошла путь от хакатонов до продуктовой разработки. На собственном опыте расскажем, как выстроили инфраструктуру, способную масштабироваться, переживать сбои и не стоить, как полкоманды в найме.

Когда вы только начинаете делать стартап, инфраструктура кажется чем-то второстепенным. Важнее MVP, фичи, дизайн, пичдек. Но в какой-то момент всё внезапно перестаёт помещаться на одном сервере, руками деплоить становится больно, SSL не обновляется, а продакшн падает из-за перегрузки или забытого docker-compose up.

Kubernetes? Слишком сложно, долго и дорого. Монолит? Неудобно масштабировать. Мы искали третий путь — и нашли его.

Сегодня разберёмся, как сделать видеозвонки — ту самую фичу, без которой сложно представить современное общение в 2025 году, на примере реализации мессенджера.

Для этого мы познакомимся с WebRTC — технологией, которая позволяет приложениям устанавливать прямое соединение друг с другом для обмена аудио, видео и другими данными. Это мощный, но местами капризный инструмент, который требует понимания архитектуры, сигналинга и сетевых нюансов вроде NAT и ICE.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

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

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

Несколько недель назад я написал о настройке Git help.autocorrect и поведал странную историю о том, как её значение стали задавать в децисекундах.  

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

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

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

На прошлой неделе это случилось снова. Я был на совещании по анализу архитектуры, и коллега-архитектор начал ещё одну оживлённую дискуссию о микросервисах. Спустя считанные минуты взгляд присутствующих остекленел, и мы погрузились в абсурдное обсуждение того, что должно быть средством для достижения цели, но превратилось в саму цель. В тот самый момент я осознал: с меня хватит. Я наконец-то поклялся больше не общаться с архитекторами о микросервисах. Почему? Да потому, что такие обсуждения обычно не приводят ни к чему продуктивному.

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

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

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

Если вы только начинаете осваивать профессию, эти игры помогут вам понять преимущества и недостатки различных подходов на более простых аналогиях, а позже перенести этот опыт в реальную разработку. Например, необходимость масштабируемости, удобства хорошо настроенного CI/CD, или компромиссы, которые приходится принимать при использовании микросервисной архитектуры.

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

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

Это статья о том, как обустроить рабочее место под разный бюджет. Кроме разделения на бюджет и комфорт, поделил приёмы и вещи по степени важности. Например, кресло — это вершина комфорта, а камера с телесуфлёром, чтобы глаза смотрели в объектив, — это скорее блажь (которую я на себе протестировал). Но об этом я тоже расскажу и покажу наглядно — фото приложил.

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

Привет, Хабр! Инструмент, который генерирует производительный и безопасный код для работы с базой данных — миф или реальность? В этой статье обсудим, что такое sqlc, откуда он появился и какие идеи в него заложены. Разберём его возможности и ограничения, а также кейсы, когда он подходит лучше всего.

Привет! Меня зовут Павел Лукьянов, я заместитель CTO в AGIMA. На одной из прошлых работ мы с ребятами попробовали внедрить так называемую чистую архитектуру на монолитном проекте. И это был интригующий опыт. Во-первых, мы начали намного рациональнее подходить к оценке задач. Во-вторых, заметно сократили time-to-market. А в-третьих, сильно разозлили наших аналитиков. Считаю, такими впечатляющими результатами стоит делиться.