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

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

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

Если вы собрались плотно погрузиться в тему Doman Driven Design (DDD), о том как его применять, как использовать, для чего он нужен, и как с ним связаны Command and Query Responsibility Segregation (CQRS), Event Sourcing и другие термины из мира DDD то можно воспользоваться планом обучения, который последовательно погрузит вас в эти темы и поможет сориентироваться. Часть информации на русском, часть на английском языке, так как русскоязычных аналогов я не смог найти.

Я работаю геймдизайнером в EPAM. Часто моя задача состоит в том, чтобы пользователь приложения вовлекался и не «выгорал», т.е. не терял интерес к продукту. Для этого существуют разные механики, такие как непрекращающиеся цели, ступенчатая кривая сложности, обещание красивого результата на пути из точки «A» в точку «Z».

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

О них я и хотел рассказать в этой статье.

Кратко о теории

typedef int (^MyBlock)(int);

int multiplier = 7;
MyBlock myBlock = ^(int num) {
 return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

int multiplier = 7;
int (^myBlock)(int) = ^(int num) {
  return num * multiplier;
};

* This source code was highlighted with Source Code Highlighter.

myBlock( 3 )

* This source code was highlighted with Source Code Highlighter.

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

• соберем приложение и запустим на симуляторе
• соберем ipa и запустим на реальном девайсе
• соберем ipa для выкладки на маркет
• немного подэбажим ошибки сборки

О торговле