Под конец прошлого года компания Amazon выпустила (наконец-то!) C++ SDK для своей платформы AWS. Непонятно, почему так долго тянули — есть масса приложений, написанных на С++, из которых давно хотелось удобно пользоваться AWS. Не джавой же единой, в самом деле.

Всегда интересно посмотреть на что-то, написанное на С++ в наши дни с нуля, без груза обратной совместимости и странных архитектурных решений, присущих некоторым разработкам прошлого. Я не буду тут пересказывать документацию, но остановлюсь на ключевых моментах, определяющих всё поведение SDK.

Эта статья – о рисках смены руководства в больших компаниях и характерных явлениях при попытках игнорировать закон эффективного управления собственностью:

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Картинка для привлечения внимания читателей из поколений Y и Z:

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

---

Как именно в Netflix реализован код до этапа работы в облаке? Части этой истории мы рассказывали и прежде, но сейчас настало время добавить в неё больше деталей. В данном посте мы опишем инструменты и методы, позволившие нам пройти путь от исходного кода до развёрнутого сервиса, который позволяет наслаждаться фильмами и сериалами более чем 75 миллионам подписчиков со всего мира.



Схема выше – отсылка к предыдущему посту, представляющему Spinnaker, нашу глобальную непрерывную платформу передачи данных. Но до попадания в Spinnaker строке кода нужно пройти несколько этапов:

• Код должен быть написан и локально испытан плагинами Nebula;
• Изменения перемещаются в центральное хранилище git;
• Jenkins запускает Nebula, которая создаёт, тестирует и подготавливает приложения для облака;
• Билды «выпекаются» в Amazon Machine Image;
• Spinnaker способствует разблокировке и активизации измененного кода.

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

Организационная культура, облако и микросервисы

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

Культура Netflix расширяет возможности инженеров в плане использования любого, по их мнению, подходящего инструментария ради решения поставленных задач. По нашему опыту, для того, чтобы какое-либо решение получило всеобщее признание, оно должно быть аргументированным, полезным и уменьшать когнитивную нагрузку на большинство инженеров Netflix. Команды свободны в выборе пути решения задач, но за это расплачиваются дополнительной ответственностью по поддержке этих решений. Предложения центральных команд Netflix начинают считаться частью «проторенной дорожки» (paved road). Сейчас именно она находится в центре нашего внимания и поддерживается нашими специалистами.

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

Конечная цель любой балансировки игры – увеличение возврата игроков или времени партии. То есть играбельности механики:

• Не должно быть однозначной ультимативной стратегии победы, иначе игра потеряет вариативность и интерес.
• Игрок должен чувствовать, что от его действий и навыков зависит игра. Иначе получится Mass Effect, который, скорее, фильм, нежели RPG.
• Баланс должен быть «амортизированным», то есть прощать некоторые ошибки – иначе запоздалый на миллисекунду клик в Starcraft по первому рабочему из-за «эффекта бича» вызывал бы проигрыш через 4 часа идеальной партии. Наша настольная формула – 5-7 важных решений за игру, в двух можно ошибиться.
• У настолок есть ещё социальное условие: игроки не должны выпадать по ходу пьесы – интересно должно быть всем и до конца.

Теперь – методы.

Мы в «Латере» занимаемся созданием биллинга для операторов связи. В блоге на Хабре мы не только рассказываем об особенностях нашей системы и деталях ее разработки (например, обеспечении отказоустойчивости), но и публикуем материалы о работе с инфраструктурой в целом. Разработчик и системный архитектор Михаель Виттиг (Michael Wittig) написал в блоге Cloudonout интересный материал о наиболее распространенных ошибках при работе с сервисом AWS (Amazon Web Services). Мы представляем вашему вниманию основные тезисы этой заметки.

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

8 лет назад маленькая команда разработчиков, почти что бывшие студенты, решили сделать свою первую большую, как им тогда казалось, игру. Они выполняли все функции вперемешку. И гейм-дизайн, и программирование, и арт. Кто что умел. Получившаяся игра называлась «Возмездие». Это была браузерка. Она показала неплохие результаты: доходы с игры выросли от нескольких десятков до сотен тысяч рублей за первые месяцы. Для группы в несколько человек это уже какие-то деньги. В таком режиме игра просуществовала порядка года. А потом аудитория стала уменьшаться, доход начал падать. Разработчики подумали: «Наверное, мало контента». Игра была контентнозависимой, т.е. постоянно жила на обновлениях. Они поднажали, стали производить больше локаций, предметов, уровней, ремесленнических рецептов — всё, что делали раньше. Но пользователи все равно продолжали уходить. И было непонятно, почему это происходит. В итоге проект, просуществовав три года, закрылся — рано или поздно такой конец ждет все онлайн-игры.


^{Арт персонажа браузерной игры Возмездие}

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

Вопрос расчёта lifetime value (он же LTV, customer lifetime value, CLV) рано или поздно встаёт перед разработчиками мобильных (впрочем, и не только) приложений. Методов расчёта придумано множество, и по поводу того, как считать LTV, существует сколько людей, столько же и мнений. В данном материале я решил описать наиболее распространённые методы, обозначить их плюсы и минусы. Данные методы подходят прежде всего для описания f2p-модели.

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

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

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

Внимание! В рецепте с отбеливателем обнаружилась опасность коррозии металла! Не рекомендуется в стандартном применении!

Обзор экспериментов год спустя:
DIY порошок для посудомойки: как не растворить посуду и не повторить моих ошибок. Год экспериментов

В прошлой публикации мы создавали дешевый порошок для посудомойки из желудей и спичек кальцинированной соды и стирального порошка. В этой я расскажу о том, как можно его улучшить с помощью кислородного отбеливателя и где можно купить компоненты для более продвинутой версии. Будем делать упор на эффективности мойки, но даже при этом цена не выйдет за 100 рублей/килограмм. А еще будет рецепт ополаскивателя с себестоимостью в районе 1 рубля за литр. Как справедливо заметил amarao, занятие не для всех и многим проще использовать готовые таблетки. Но в подобных экспериментах с бытовой химией есть что-то от детства, первых опытов по смешиванию соды с уксусом и газировки с мятными конфетами. Так что ощутимая экономия здесь все-таки вторична. Будем развлекаться) Если кому-то лень читать весь текст — в конце поста будут подробные рецепты с рекомендациями.

Серия игр Grand Theft Auto прошла долгий путь с момента своего первого релиза в 1997 году. Примерно 2 года назад Rockstar выпустила GTA V. Просто невероятный успех: за 24 часа игру купило 11 миллионов пользователей, побито 7 мировых рекордов подряд. Опробовав новинку на PS3, я был весьма впечатлен как общей картинкой, так и, собственно, техническими характеристиками игры.

Ничто так не портит впечатление от процесса, как экран загрузки, но в GTA V вы можете играть часами, преодолевая бескрайние сотни километров без перебоев. Учитывая передачу солидного потока информации и свойства PS3 (256 Mb оперативной памяти и видеокарта на 256 Mb), я и вовсе удивился, как меня не выбросило из игры на 20-ой минуте. Вот где чудеса техники.

В этой статье я расскажу о проведенном анализе кадра в версии для ПК в среде DirectX 11, которая съедает пару гигов как оперативки, так и графического процессора. Несмотря на то, что мой обзор идет со ссылкой на ПК, я уверен, что большинство пунктов применимо к PS4 и в определенной степени к PS3.

Анализ кадра

Итак, рассмотрим следующий кадр: Майкл на фоне любимого Rapid GT, на заднем плане прекрасный Лос-Сантос.



Осторожно! Трафик!

Если Вы не следите за оставшимся свободным местом в корневом разделе — то Вас могут ожидать неприятные новости. В случае переполнения данного раздела, важные для Вашего проекта сервисы перестанут работать. Согласитесь, неработающий MySQL или web server скажется на проекте не лучшим образом.

Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

Не так давно я участвовал в проекте написания прошивки для некоторого устройства. В процессе работы возник вопрос, а как, собственно, взаимодействовать с «большим братом» (управляющим компьютером)? Поскольку в качестве «большого брата» закладывались совершенно разные устройства (различные смартфоны, планшеты, ноутбуки с различными ОС и прочее), планировалось использовать web-приложение, что диктовало использование JSON для обмена сообщениями.

В итоге получилась легкая и быстрая библиотека сериализации/десериализации JSON. Основные фичи данной библиотеки:

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

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

class Test : public Serializable
{
public:
	int SomeInt = 666;
	float SomeFloat = 42.2; 
	string SomeString = "Hello My Little Pony";
private:
	serialize(SomeInt);
	serialize(SomeFloat);
	serialize(SomeString);
};

Такое мне вполне подходило, и я уже представлял себе решение.

С появлением многоядерных процессоров возникла необходимость в создании игрового движка на основе параллельной архитектуры. Использование всех процессоров системы — как графического (ГП), так и центрального (ЦП) — открывает гораздо больше возможностей по сравнению с однопоточным движком на базе только ГП. Например, используя больше ядер ЦП, можно улучшить визуальные эффекты, увеличив количество физических объектов, используемых в игре, а также добиться более реалистичного поведения персонажей за счет реализации продвинутого искусственного интеллекта (ИИ).
Рассмотрим особенности реализации многопоточной архитектуры игрового движка.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

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

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

Сравнительно недавно, geektimes [1] опубликовал статью «Про сахара…». Помните, как говорил Штирлиц в фильме «17 мгновений весны»: «Запоминается то, что сказано в самом конце…». В этой статье (в конце главы «про фруктозу») написано: «Если есть, сколько надо … продукты с фруктозой вреда не принесут».

Аналогичными и даже более радикальными заявлениями (как правило, «безымянных авторов») буквально «забиты» социальные сети «про здоровый образ жизни». Появление новой «информации» о пользе соков, смузи, меда и сухофруктов резко «накручивает» счетчики «лайков» под публикациями. Люди, вновь и вновь, спешат «поделиться» тем, во что хочется верить самим. У многих слово «здоровье» вызывает ассоциации с фруктами, образами людей, бегущих трусцой и бутылками «ключевой» воды… Беда в том, что такая «информация» очень часто почерпнута из «мусорной» (не защищенной авторским правом) части сети Интернета и отражает лишь личное мнение неспециалиста или даже является плодом трудов «контент-мэйкера». Нужно отметить, что и статья в geektimes написана специалистом-химиком, а не медиком или биологом. А это – существенно. Не зря же существует профессиональная специализация?

Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.