Задать вопрос

ksimmi

Комментарии

  • Как правильно спроектировать формат передачи рассадки и планировки зала для виджета бронирования мест?

    @ksimmi Автор вопроса
    Владимир Коротенко,
    1 Это настолько нечастая операция, что я не хочу делать интерфейс редактирования. Хочу захардкодить просто все концертные площадки, со всеми вариантами рассадки, если она вариативна. Пользователь админки просто будет выбирать под конкретное мероприятие рвссадку и все. Когда появтяся партнеры, то мы также будем хардкодить все их варианты рассадки, предварительно согласовав.

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

    3 Это не срочно.

    Владимир, спасибо ваш совет очень близок к тому, что мне нужно.
    Написано

  • Как правильно спроектировать формат передачи рассадки и планировки зала для виджета бронирования мест?

    @ksimmi Автор вопроса
    но не так уж и важно

    Владимир Коротенко, Это как дизайнер решит :)
    Написано

  • Как правильно спроектировать формат передачи рассадки и планировки зала для виджета бронирования мест?

    @ksimmi Автор вопроса
    SVG поддерживается браузером нативно

    Я про SkiaSharp интересовался. Хочется либо технологию, которая будет работать на всех трех платформах: iOs, Android, браузер. Либо, сделать решение для браузера и обернуть в WebView.

    Это как атрибут вынесенный выше, "цвет штанов" можно дифференцировать тарифными планами.

    Я имел в виду буквально другое отображение, а не просто "другой цвет". Например, есть обычное место, которое отображается в один ряд и их 15 в ряду, а есть вип-место, которых всего 6 в длину ряда, и каждое по ширине в 2 ряда. Обычное место - кресло, вип-место - диван со столом.

    Есть концертная площадка в виде кафе/ресторана, куда приезжают музыкальные группы, а публика ужинает под их выступление. Там есть Столики на 2-х, 4-х, 6-х. Где-то стулья, где-то кресла.

    Спасибо за советы, если SkiaSharp можно использовать в брауере как mvp, то это то что нужно.
    Написано

  • Как правильно спроектировать формат передачи рассадки и планировки зала для виджета бронирования мест?

    @ksimmi Автор вопроса
    Я впервые слышу про SkiaCharp, нагуглил только SkiaSharp, видимо это оно, но опять-таки не знаком с технологией. Мне сейчас главное понимать, какие данные будут ходить по сети между мобилкой и беком. Из вашего оттвета я делаю вывод, что это будет:
    1 Одно svg-изображение c эскизом зала;
    2 По одному svg-изображению на каждый тип места. Под типом я имею в виду вариатовность самих мест, например вип-кресло, обысное кресло.
    3 Атрибуты мест (JSON?)?
    3.1 Координаты места относительно эскиза зала;
    3.2 Занято/свободно или "выбрано текущим пользователем";
    3.3 Цена места;
    3.4 Прочие атрибуты.

    Только как быть с браузером? SkiaCharp это чисто мобильная технология или в браузере тоже можно отрисовать?
    Написано

  • Как правильно интегрировать платежные сервисы с разными бизнес-правилами на id-транзакций?

    @ksimmi Автор вопроса
    ksimmi, Изначально были INT, они так бы и остались, потому что переделывать дорого, опасно и вообще ЛЕНЬ. Потом прилетело требование от безопасников по результатам пентеста - передалали. Остальные, описанные плюсы выявили в процессе эксплуатации.
    Написано

  • Как правильно интегрировать платежные сервисы с разными бизнес-правилами на id-транзакций?

    @ksimmi Автор вопроса
    Независимые это значит совпадение идентификаторов одной и той же транзакции в разных сервисах не помешает их работе.

    Независимые!

    ...почему именно UUID?... ...единственный бонус - гарантированно уникальные...

    Гарантированно уникальные - это не маленький такой бонус:
    1 Проще расследовать инциденты, искать в логах какое-либо число такое себе удовольствие!
    2 Проще формировать отчетность. Отчетностью занимаются другие люди, которые при заполнении DWH и витрин в скриптах постоянно путали между собой целочисленные идентификаторы, которые то и дело пресекаются случайным образом в разных сущностях; Т.е. ребята скриптом собирали все данные из почти 40 БД в одну БД (DWH), чтобы потом расчитать и заполнить витрины (DATAMARTS). Пока использовали INT, постоянно саппортили их, а с UUID, они к нам даже не обращались, если связь не построилась - значит не стой колонкой сопоставляешь!
    3 есть требование от безапасников скрыть количество пользователей/транзакций, а также сделать максимально трудной предугадываение идентификаторов для новых сущностей. Вы не представляете сколько фрод-атак происходит! Также этот аргумент был первым от команды, у которой мы заказывали Пентест.
    4 Идентификатор сущности может быть получен до фактической ее записи в БД.
    Написано

  • Как правильно интегрировать платежные сервисы с разными бизнес-правилами на id-транзакций?

    @ksimmi Автор вопроса
    Сервисы взаимно независимые?

    Если я правильно понял вопрос, то да - независимые и их сильно больше чем я описал.

    В общем есть сервис transactions с которого и начинается процесс. Этот сервис генерит UUID (назовем его внутренним id-транзакции), а также по типу транзакции определяет какие "ведомые" сервисы-шлюзы будут учавстниками транзанкции. Тут старались воплотить оркестрируемый паттерн SAGA. Этот единый UUID рассылается в "оркестирируемые" сервисы, а дальше уже варианты. В те API, что принимают UUID мы отсылаем тот же самый UUID. Там где UUID не принимают мы думали использовать AUTOINCREMENT INT, но я решил поискать best practices и не найдя их задал вопрос тут.

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

    Спасибо за ваш ответ.
    Написано