Технический директор Croteam Ален Ладавач, участвовавший в разработке Serious Sam и Talos Principle, рассказывает, как ему удалось найти причину торможения графики даже на самых мощных машинах.

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

Т-т-тормоза

Вы с нетерпением ждали следующей части вашей любимой серии видеоигр для PC и она наконец вышла. На этот раз вы хотите насладиться ею во всей полноте, поэтому потратили деньги и время на тщательную подготовку. Вы заменили процессор, поставили сверхсовременную видеокарту, добавили ещё ОЗУ — чёрт возьми, даже купили RAID на SSD. Игра должна быть плавной с самой заставки.

Предзаказ наконец разблокирован и вы только что завершили установку. В нервном предвкушении вы впервые запускаете игру. Пока всё хорошо — она работает с частотой 60 кадров в секунду. Или, по крайней мере, так сообщает счётчик кадров тюнера GPU. Но что-то не так. Вы делаете мышью резкие, хаотичные движения. Стрейфитесь влево-вправо, и тут игра… начинает тормозить! Блин, да как такое возможно? Как она может тормозить при 60 кадрах в секунду?

Если такое с вами никогда не случалось, то это может показаться смешным. Но если вы их испытали, то, скорее всего, ненавидите тормоза всей душой. Тормоза в играх. Это не старый добрый «лаг». Не низкая частота кадров. Это просто «тормоза», происходящие при высоких частотах кадров на идеальных, супербыстрых машинах. Что это, откуда они взялись и как от них избавиться? Позвольте мне рассказать вам историю…

Привет! Сегодня я надеюсь показать вам немного магии. Моим хобби является придумывание всяких казалось бы невозможных штук на С++, что помогает мне в изучении всевозможных тонкостей языка ну или просто развлечься. Оператор in есть в нескольких языках, например Python, JS. Но в С++ его не завезли, но иногда хочется чтобы он был, так почему бы его не реализовать.

	std::unordered_map<std::string, std::string> some_map = 
	{
		{ "black", "white" },
		{ "cat", "dog" },
		{ "day", "night" }
	};

	if (auto res = "cat" in some_map)
	{
		res->second = "fish";
	}

Доброго времени суток, Хабр!

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

Когда люди обсуждают изменения в PHP7, самое распространенное что вы слышите — это значительно улучшенный движок, который может похвастаться более быстрой скоростью выполнения и значительно меньшим объемом памяти при сравнении обычных приложений PHP, таких как Drupal, WordPress и MediaWiki.

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

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

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

• Какие бывают электронные письма
• Кто участвует в процессе тестирования и контроля
• Почтовое сообщение и почтовый транспорт
• Интерфейс почтовой инфраструктуры и границы тестируемого приложения
• Определение тестируемых параметров
• Типичная структура генерирующего приложения
• Что и когда тестировать
  
  1. Инфраструктура доставки
  2. Генерирующее приложение
  3. Структурный и вёрсточный шаблоны письма
• Базовые требования при проверке инфраструктуры
• Требования к авторизации
• Проверка генерирующего приложения
  
  • Требования к почтовым адресам
  • Требования к заголовкам писем
  • Требования к структуре письма
  • Требования к URI
  • Требования к вёрстке письма
• Проведение сплит-тестов

Закрадывалась ли вам в голову идея переписать своё жирное энтерпрайзное приложение с нуля? Если с нуля, то это ж ого-го. Как минимум кода будет раза в два меньше, верно? Но ведь пройдёт пара лет, и оно тоже обрастёт, станет легаси… времени и денег на переписывание не так много, чтобы делать идеально.

Успокойтесь, начальство всё равно не даст ничего переписать. Остаётся рефакторить. На что лучше всего потратить свои невеликие ресурсы? Как именно рефакторить, где проводить чистки?

Название этой статьи — в том числе отсылка к книге Дяди Боба «Чистая Архитектура», а сделана она на основе замечательного доклада Victor Rentea (твиттер, сайт) на JPoint (под катом он начнёт говорить от первого лица, но пока дочитайте вводную). Чтения умных книжек эта статья не заменит, но для такого короткого описания изложено весьма хорошо.

Идея в том, что популярные в народе вещи вроде «Clean Architecture» действительно являются полезными. Сюрприз. Если нужно решить вполне конкретную задачу, простой изящный код не требует сверхусилий и оверинжиниринга. Чистая архитектура говорит, что нужно защищать свою доменную модель от внешних эффектов, и подсказывает, как именно это можно сделать. Эволюционный подход к наращиванию объема микросервисов. Тесты, которые делают рефакторинг менее страшным. Вы ведь уже знаете всё это? Или знаете, но боитесь даже подумать об этом, ведь это же ужас что тогда делать придётся?

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

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

Вопрос только в том, какой музыкальный жанр выбрать.

На таких площадках, как Reddit, Hacker News и Хабр обсуждению этого вопроса посвящен не один тред. Мы решили проанализировать мнения разработчиков и отобрать наиболее интересные.

В июне 2018 г. в России был опубликован перевод последнего издания книги Рэфа Костера “Разработка игр и теория развлечений” (A Theory of Fun for Game Design).

Рэф Костер — один из наиболее известных и авторитетных теоретиков геймдизайна, обладатель титула “Легенда онлайн-игр” (2012). Хотя первое издание книги Костера о разработке игр было выпущено более 10 лет назад, его работа об этиологии любви человека к играм и о том, зачем нам нужны игры и какими они должны быть в современных условиях, до сих пор актуальна.
Под катом — тезисный пересказ русскоязычного издания книги.

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

Ни о чем не напоминает? Примерно так звучит пара из шестнадцати тысяч записей из звуковой библиотеки BBC. Это – новая часть проекта RemArc, созданного чтобы пробуждать воспоминания.

Аннотация

Обработка данных в реальном времени ровно один раз (exactly-once) — задача крайне нетривиальная и требующая серьезного и вдумчивого подхода на всей цепочке вычислений. Некоторые даже считают, что такая задача невыполнима. В реальности хочется иметь подход, обеспечивающий отказоустойчивую обработку вообще без каких-либо задержек и использование различных хранилищ данных, что выдвигает новые еще более жесткие требования, предъявляемые к системе: concurrent exactly-once и гетерогенность персистентного слоя. На сегодняшний день такое требование не поддерживает ни одна из существующих систем.

Предложенный подход последовательно раскроет секретные ингредиенты и необходимые понятия, позволяющие относительно просто реализовать гетерогенную обработку concurrent exactly-once буквально из двух компонент.

Введение

Разработчик распределенных систем проходит несколько стадий:

Стадия 1: Алгоритмы. Здесь происходит изучение основных алгоритмов, структур данных, подходов к программированию типа ООП и т.д. Код исключительно однопоточный. Начальная фаза вхождения в профессию. Тем не менее, достаточно непростая и может длиться годами.

Стадия 2: Многопоточность. Далее возникают вопросы извлечения максимальной эффективности из железа, возникает многопоточность, асинхронность, гонки, дебагинг, strace, бессонные ночи… Многие застревают на этом этапе и даже начинают с какого-то момента ловить ничем не объяснимый кайф. Но лишь единицы доходят до понимания архитектуры виртуальной памяти и моделей памяти, lock-free/wait-free алгоритмах, различных асинхронных моделях. И почти никто и никогда — верификации многопоточного кода.

Стадия 3: Распределенность. Тут такой треш творится, что ни в сказке сказать, ни пером описать.