Да, спасибо! Гарантированная доставка так или иначе крутится вокруг ретраев. Поэтому Кафка, хороший, там где это уместно, инструмент - не про гарантированную доставку.
Я, на самом деле, на шине использую аналогичный Кафке алгоритм, только вместо офсета - ID обработанных сообщений (с привязкой к консьюмеру). Что позволяет, спокойно пропускать "проблемные" сообщения и возвращаться к ним позднее. Это не годится только для потоков данных где критична последовательность сообщений в рамках топика. На практике, такое бывает крайне редко. В этом случае, просто тормозим поток до ручного разбора инцидента.
Я как "шинник" могу сказать про ESB ПО следующее: суть шины в централизации. Вместо того чтобы размазывать интеграционный код ровным слоем по всем языкам и платформам, которые имеются в более-менее крупной компании, мы стремимся централизовать его. Понятно, для того чтобы извлекать стандартные плюсы централизации: гибкость к изменениям, шире возможности в оперировании (при расследованнии инцидентов в передаче данных), ниже стоимость, выше скорость разработки. Понятно, что на 100% этой цели достичь невозможно, все-равно останутся какие-то "хвосты" в каких-то системах. Но даже приближение дает огромное преимущество над ситуацией когда выгрузки-загрузки написаны непонятно кем, на чем и кто в лес, кто по дрова ("лоскутная интеграция").
Очевидно, что если кто-то использует "Кафка" и "гарантированная доставка" в одном предложении - он не совсем в теме. Кафка вообще не про гарантированную доставку. Представим, что мы выгружаем какие-то документы в 1С через Кафку. Что произойдет если при загрузке части документов случится конфликт блокировок (потому что база сильно нагружена в текущий момент). Ничего хорошего. Сообщения прочитаны, офсет сдвинут - до свидания. Что произойдет на шине:
залогируются сообщение в 1С и ответ 1С для анализа проблемы
полетят алерты отвественным сотрудникам
без вмешательства человека шина попытается доставить эти документы позднее (в соответствие с настроенной политикой: увеличивающиеся интервалы, до истечения времени жизни сообщения/кол-ва попыток и т.д.)
И это не требует ни строчки кода в 1С! Так как шина использует коннектор к OData 1С (всю интеграционную логику мы уже централизовали).
К тому же, современная ESB - это идеальная платформа для "корпоративного API": она уже имеет доступ ко всем данным всех систем нашего ИТ ландшафта, имеет кластеризацию "из коробки", широкие инструменты настройки и контроля доступа к данным, спецификации, документацию, API разворачивается "по нажатию одной кнопки" и т.д. Если, конечно, это "правильно приготовленная" ESB.
Вот то что этот паттерн недооценен и многие просто даже не думают о том чтобы решать вопросы интеграции приложений стратегически - это да...
В основном, трудности с высокоуровневыми обертками. Да. Мне так и не удалось вникнуть в эту тему с java биндингами к нативному коду iOS. Выглядит непонятно. Но проблема эта субъективная, конечно. Так-то, техническая возможность есть, согласен.
Ну… Нужно же как-то вносить в жизнь стабильность и распорядок. А то с этими играми я мог бы где-нибудь на пляже загорать все время, и скатиться в прокрастинацию окончательно :)
Спасибо :) На самом деле, с музыкой легко, сложно найти профи… А вот дальше я просто полагаюсь на его вкус и видение. Я вообще своих коллег не «прессую» чтобы они сделали четко как я себе представлял. Ни композитора, ни художника. Творческая свобода — наше все, я считаю!
Спасибо за хороший вопрос! Изначально, я спрятал значок карты в рюкзак, когда ее находим, он там появляется. Чтобы не загромождать UI. И вот на этот момент жаловались многие тестеры. Так как карта — это самая нужная вещь в игре, даже жизненно необходимая я бы сказал, переход в 2 клика: открыть рюкзак, открыть карту — никуда не годился. Поэтому было решено вытащить кнопку карты в быстрый доступ и увеличить скорость анимации перехода между текущим кадром и кадром «глав. герой смотрит на карту». Это единственное место в игре, где скорость смены кадров такая высокая.
С этой правкой связан забавный баг. У меня в коде есть 2 структуры, одна хранит всякие служебные поля объектов в рюкзаке, другая — отображение этих объектов, значки и т.п. И так как изначально я предполагал что количество предметов в рюкзаке всегда равно количеству отображаемых иконок, то я сделал их связь просто по индексу, вместо ключа, например. А после того как я вынес иконку карты в быстрый доступ, получилось что в рюкзаке она как бы есть, но иконки ее там нет! В результате, подбираем карту, а в инвентаре отваливается перетаскивание предметов и другие совершенно непонятные вещи начинают происходить. Я что только не передумал, пока до такой простой причины не докопался :)
Не особо… В App Store 200 копий продали, в Google Play — 10 тыс загрузок (там игра бесплатна). Сейчас договариваюсь о фичеринге в GP, может что-то и выгорит.
Да. На Java я довольно много писал всякого под Android. И мне нравится концепция LibGDX — какие-то базовые объекты мы вам даем, типа Stage, Actor, а дальше, все в ваших руках, делайте из них, что хотите! Нравится привычное наследование, префабы в Unity — это, все-таки, немного не то. Например, у меня есть «базовый кадр», который реализует только белую рамку, подстраивающуюся под соотношение сторон экрана и свое появление сверху, снизу, слева и справа. Дальше, я наследую от этого класса «базовый кадр с UI», где добавляются кнопки интерфейса «карта», «инвентарь», «выход». И попапы. От него наследуется «кадр комнаты», где помимо всего вышеперечисленного, появляются кнопки перехода в соседние комнаты, подсказки и т.д.
Отличное начинание! Я как раз недавно делал перевод своей «dev story», с привлечением англо-говорящего корректора даже, которая на Хабре собрала сотню плюсов и 57k просмотров, но совершенно «не зашла» ни на Медиум, ни на Реддите. Было бы круто иметь возможность сразу же разместить ее английский вариант здесь, на «Хэбре» :)
На определенный период, наверное (месяц). Тут в общем-то все субъективно, четкой цели по количеству установок, например, я не ставлю. Если я вижу, что игра «не зашла», надо останавливаться и фиксировать убытки.
Да, спасибо! Гарантированная доставка так или иначе крутится вокруг ретраев. Поэтому Кафка, хороший, там где это уместно, инструмент - не про гарантированную доставку.
Я, на самом деле, на шине использую аналогичный Кафке алгоритм, только вместо офсета - ID обработанных сообщений (с привязкой к консьюмеру). Что позволяет, спокойно пропускать "проблемные" сообщения и возвращаться к ним позднее. Это не годится только для потоков данных где критична последовательность сообщений в рамках топика. На практике, такое бывает крайне редко. В этом случае, просто тормозим поток до ручного разбора инцидента.
Я как "шинник" могу сказать про ESB ПО следующее: суть шины в централизации. Вместо того чтобы размазывать интеграционный код ровным слоем по всем языкам и платформам, которые имеются в более-менее крупной компании, мы стремимся централизовать его. Понятно, для того чтобы извлекать стандартные плюсы централизации: гибкость к изменениям, шире возможности в оперировании (при расследованнии инцидентов в передаче данных), ниже стоимость, выше скорость разработки. Понятно, что на 100% этой цели достичь невозможно, все-равно останутся какие-то "хвосты" в каких-то системах. Но даже приближение дает огромное преимущество над ситуацией когда выгрузки-загрузки написаны непонятно кем, на чем и кто в лес, кто по дрова ("лоскутная интеграция").
Очевидно, что если кто-то использует "Кафка" и "гарантированная доставка" в одном предложении - он не совсем в теме. Кафка вообще не про гарантированную доставку. Представим, что мы выгружаем какие-то документы в 1С через Кафку. Что произойдет если при загрузке части документов случится конфликт блокировок (потому что база сильно нагружена в текущий момент). Ничего хорошего. Сообщения прочитаны, офсет сдвинут - до свидания. Что произойдет на шине:
залогируются сообщение в 1С и ответ 1С для анализа проблемы
полетят алерты отвественным сотрудникам
без вмешательства человека шина попытается доставить эти документы позднее (в соответствие с настроенной политикой: увеличивающиеся интервалы, до истечения времени жизни сообщения/кол-ва попыток и т.д.)
И это не требует ни строчки кода в 1С! Так как шина использует коннектор к OData 1С (всю интеграционную логику мы уже централизовали).
К тому же, современная ESB - это идеальная платформа для "корпоративного API": она уже имеет доступ ко всем данным всех систем нашего ИТ ландшафта, имеет кластеризацию "из коробки", широкие инструменты настройки и контроля доступа к данным, спецификации, документацию, API разворачивается "по нажатию одной кнопки" и т.д. Если, конечно, это "правильно приготовленная" ESB.
Вот то что этот паттерн недооценен и многие просто даже не думают о том чтобы решать вопросы интеграции приложений стратегически - это да...
Тут дело в том, что Platform не доступно из веба и если его таким образом не "прикрыть", то это все в вебе просто упадет )
В основном, трудности с высокоуровневыми обертками. Да. Мне так и не удалось вникнуть в эту тему с java биндингами к нативному коду iOS. Выглядит непонятно. Но проблема эта субъективная, конечно. Так-то, техническая возможность есть, согласен.
Я как-то собирал под веб, вроде все работало, но это было давно...
С этой правкой связан забавный баг. У меня в коде есть 2 структуры, одна хранит всякие служебные поля объектов в рюкзаке, другая — отображение этих объектов, значки и т.п. И так как изначально я предполагал что количество предметов в рюкзаке всегда равно количеству отображаемых иконок, то я сделал их связь просто по индексу, вместо ключа, например. А после того как я вынес иконку карты в быстрый доступ, получилось что в рюкзаке она как бы есть, но иконки ее там нет! В результате, подбираем карту, а в инвентаре отваливается перетаскивание предметов и другие совершенно непонятные вещи начинают происходить. Я что только не передумал, пока до такой простой причины не докопался :)