Спасибо, что поделились своей историей :) Команда разработки в «Перекрёстке» действительно небольшая по меркам рынка — в ней около 10 человек. Несмотря на это, нам удалось добиться высокой скорости работы приложения — над аналогичными продуктами зачастую работают десятки человек.
Про технологии, которые использовали, с удовольствием расскажем в следующем материале, спасибо за идею.
Экспресс-доставка «Перекрёстка» доставляет товары из ближайшего к дому магазина.
А вы точно про сайт экспресс-доставки «Перекрёстка»?) По нашим мониторингам мы не видим, что у пользователей возникают какие-либо проблемы с загрузкой. Если всё же да, то дайте, пожалуйста, информацию, какие именно страницы долго грузятся — мы детально посмотрим, в чем может быть проблема.
Нам известно о проблеме с X5 ID, спасибо, что обратили внимание на это. Сервис интегрирован только в начале сентября, и мы продолжаем работать над его качеством. Типовые ошибки встречаются, но мы стараемся оперативно их устранять.
Куда развиваться всегда есть, но мы были бы признательны, если бы вы подробнее рассказали о проблеме, с которой столкнулись. По нашим данным, техподдержка всегда оперативно реагирует на вопросы покупателей, а в случае ошибки со стороны магазина — всегда дарит промокод. Клиенты остаются довольны.
При выборе на КСО биометрической оплаты начинает работать ПО Сбер (модуль распознавания VisionLabs из экосистемы Сбер). Передача данных осуществляется через пинпад Сбер. ПО Х5 в процессах обработки и передачи биометрических данных не участвует.
Проверяли и на близнецах, и не накрашенных, и с маской и т.д. - система все определяет верно. Даже различает близнецов. Скоро ждем сюжет на Первом канале на эту тему - они всеми возможными способами проверяли)
Включение камеры осуществляет при выборе биометрической оплаты в разделе выбора способа оплаты. Все остальное время камера выключена. Согласие на использование биометрической оплаты дается оператору биометрических данных (в данном случае Сбер).
Данная структура позволяет работать в концепции Dataset->Dataset, но при этом позволяет и общаться с базами напрямую и не плодить функции загрузки таблиц. Также, при загрузке таблицы из базы, она ещё проверит колонки-типы таблицы на соответствие описанию. Что придаёт чуточку больше стабильности.
Помимо разделения расчётов и выгрузок, архитектура нацелена на разбиение самих расчётов на логические шаги небольшого размера с понятным описанием входов и выходов. То есть при попытке понять, что происходит на определённом шаге алгоритма, не нужно прослеживать все предшествующие операции, чтобы разобраться в структурах таблиц, используемых в расчётах, достаточно посмотреть описание.
Ну и наконец, автоматическая сборка документации в понятном виде также являлась важным моментом для нашего проекта. Представленная архитектура позволяет собирать такую документацию достаточно легко.
Опять же оговорюсь, что цель статьи не пропаганда "наилучшего" подхода, а просто демонстрация рабочего и, как нам показалось, удобного.
P.S. по вопросу больших данных спорить не буду, понятие настолько же определённое, насколько размытое)
1) Безусловно, в случае если команда незрелая и в команде нет специалиста, отвечающего за организацию и внедрение процесса тестирования, эти задачи также ложатся на плечи SDET’а. Разумеется, эти задачи имеют первостепенную важность. Но, как правило, отправлять SDET’а в совсем незрелую команду неразумно (можно сжечь специалиста дотла).
2) “Удачные” случаи – это статистические выбросы, их нужно исключать из общей выборки. Уровень стресса зависит от характера выполняемых задач. У SDET’а, в большинстве своем, задачи не имеют жестких дедлайнов и не приводят к блокирующим и критичным ошибкам в промышленной среде, отсюда меньше стресса.
Мы используем react-navigation - эта самая популярная библиотека + она на 100% закрывает все наши потребности в плане навигации по приложению. Можно было бы поэкспериментировать с react-native-navigation, но при разработки MVP даже не вставал вопрос о выборе библиотеке навигации. Для различных вариацией BottomSheets мы использовали три разных библиотеки react-native-scroll-bottom-sheet, reanimated-bottom-sheet, reanimated-bottom-sheet. У каждой библиотеки имеются свои возможности и ограничения - функционала очень много и не везде удалось использовать одну и ту же библиотеку. Возможно, в будущем, при рефакторинге, нам удасться сократить число библиотек для работы с BottomSheet в проекте.Идея с переносом асинхронной логике в хуки сама по себе интересная. Нам не нравится, что redux-saga обязывает результат запроса сначала положить в глобальное состояние приложения, а только потом как-то реагировать в компоненте/скрине. Иногда (довольно часто) нужно просто async/await функцию вызвать прямо из компонента. Мы использовали в проекте redux-saga по причине того, что этот подход достаточно давно известен и хорошо себя зарекомендовал. Однако, в последнее время, мы присматриваемся к переносу части логики связанной с чатами на MobX, чтобы уменьшить количество бойлерплейта и снизить сложность кода бизнес логики. За лето мы написали на MobX веб версию чатов и подумали, что будет хорошей идеей унифицировать эту часть логики для всех платформ, чтобы не писать ее дважды
Ответим так) Мы в любом случае большую часть своей жизни проводим на рабочем месте и для многих людей с развитыми социальными функциями (не для всех конечно) важно ощущать себя частью команды, делиться мнениями и общаться с коллегами. В приложении негативом сотрудники тоже очень активно, кстати, делятся. В "Перчатке" можно предложить какое-то нововведение напрямую топ-менеджеру, и если оно эффективное и экономически обоснованное, оно будет реализовано, есть такие кейсы.
В компаниях с развитой корпоративной культурой всегда активные блоги, иногда даже два — анонимный и открытый — а называются они по-разному (Перчатка, Этушка или как-то ещё).
у нас есть решение электронных ценников, которое исключает возможность человеческого фактора ошибки, но пока что оно пилотируется и работает не во всех магазинах сетей.
Если бы можно было сделать элемент в чате фиксированной высоты, то мы бы использовали предложенный вами метод. Однако, к чатам это не применимо как бы дизайнер не старался - все элементы всегда будут иметь разные размеры в зависимости от длины текста. Так же, нужно учитывать, что существуют еще такие уникальные по длине элементы как голосовые сообщения, изображения и вложения.
Есть машина, как непрерывный ресурс и есть водитель, как ограниченный во времени ресурс. За каждой машиной закреплен экипаж водителей, из-за необходимости производить пересменку согласно графика сменности водителей, без потерь в эффективности транспорта, предлагается схема «выручай рейса». Вместо ожидания сменщика, водитель помогает ему, выручив своего сменщика путем заблаговременной загрузки машины товаром для рейса своего сменщика. Каждое ТС передается из рук в руки между 2-мя водителями и по предложенной нами схеме, водитель, который завершает смену, передает сменщику уже загруженную машину. «Выручай рейсы» не применяются при экспедировании, только с собственным транспортом. Таким образом, каждый водитель полностью утилизирует свою смену «полезным» временем, что положительно отражается на его вознаграждении.
Идея с QR кодом имеет место быть, но необходимо учитывать, что автомобиль проходит проверку перед и после рейса на АТП, часть АТП отдалена от РЦ. В этом случае печать двух комплектов является дополнительным расходом бумаги. Передача груза и автомобиля «из рук в руки» необходима для разграничения ответственности водителей, т.к. водители - штатные сотрудники.
Спасибо за идею, в следующей статье с удовольствием расскажем про технологии, которые использовали и добавим метрики и скрины
Приложение «Пятёрочки» — это отдельный продукт, мы не имеем к нему отношения.
Спасибо, что поделились своей историей :) Команда разработки в «Перекрёстке» действительно небольшая по меркам рынка — в ней около 10 человек. Несмотря на это, нам удалось добиться высокой скорости работы приложения — над аналогичными продуктами зачастую работают десятки человек.
Про технологии, которые использовали, с удовольствием расскажем в следующем материале, спасибо за идею.
Экспресс-доставка «Перекрёстка» доставляет товары из ближайшего к дому магазина.
А вы точно про сайт экспресс-доставки «Перекрёстка»?) По нашим мониторингам мы не видим, что у пользователей возникают какие-либо проблемы с загрузкой. Если всё же да, то дайте, пожалуйста, информацию, какие именно страницы долго грузятся — мы детально посмотрим, в чем может быть проблема.
Нам известно о проблеме с X5 ID, спасибо, что обратили внимание на это. Сервис интегрирован только в начале сентября, и мы продолжаем работать над его качеством. Типовые ошибки встречаются, но мы стараемся оперативно их устранять.
Куда развиваться всегда есть, но мы были бы признательны, если бы вы подробнее рассказали о проблеме, с которой столкнулись. По нашим данным, техподдержка всегда оперативно реагирует на вопросы покупателей, а в случае ошибки со стороны магазина — всегда дарит промокод. Клиенты остаются довольны.
При выборе на КСО биометрической оплаты начинает работать ПО Сбер (модуль распознавания VisionLabs из экосистемы Сбер). Передача данных осуществляется через пинпад Сбер. ПО Х5 в процессах обработки и передачи биометрических данных не участвует.
Проверяли и на близнецах, и не накрашенных, и с маской и т.д. - система все определяет верно. Даже различает близнецов. Скоро ждем сюжет на Первом канале на эту тему - они всеми возможными способами проверяли)
А откуда возник QR-код? При осуществлении платежа никакого сканирования QR-кода не нужно - просто посмотреть в камеру.
Включение камеры осуществляет при выборе биометрической оплаты в разделе выбора способа оплаты. Все остальное время камера выключена. Согласие на использование биометрической оплаты дается оператору биометрических данных (в данном случае Сбер).
Спасибо за развёрнутый комментарий!
Данная структура позволяет работать в концепции Dataset->Dataset, но при этом позволяет и общаться с базами напрямую и не плодить функции загрузки таблиц. Также, при загрузке таблицы из базы, она ещё проверит колонки-типы таблицы на соответствие описанию. Что придаёт чуточку больше стабильности.
Помимо разделения расчётов и выгрузок, архитектура нацелена на разбиение самих расчётов на логические шаги небольшого размера с понятным описанием входов и выходов. То есть при попытке понять, что происходит на определённом шаге алгоритма, не нужно прослеживать все предшествующие операции, чтобы разобраться в структурах таблиц, используемых в расчётах, достаточно посмотреть описание.
Ну и наконец, автоматическая сборка документации в понятном виде также являлась важным моментом для нашего проекта. Представленная архитектура позволяет собирать такую документацию достаточно легко.
Опять же оговорюсь, что цель статьи не пропаганда "наилучшего" подхода, а просто демонстрация рабочего и, как нам показалось, удобного.
P.S. по вопросу больших данных спорить не буду, понятие настолько же определённое, насколько размытое)
1) Безусловно, в случае если команда незрелая и в команде нет специалиста, отвечающего за организацию и внедрение процесса тестирования, эти задачи также ложатся на плечи SDET’а. Разумеется, эти задачи имеют первостепенную важность. Но, как правило, отправлять SDET’а в совсем незрелую команду неразумно (можно сжечь специалиста дотла).
2) “Удачные” случаи – это статистические выбросы, их нужно исключать из общей выборки. Уровень стресса зависит от характера выполняемых задач. У SDET’а, в большинстве своем, задачи не имеют жестких дедлайнов и не приводят к блокирующим и критичным ошибкам в промышленной среде, отсюда меньше стресса.
это не специально, сейчас разберемся
Мы используем react-navigation - эта самая популярная библиотека + она на 100% закрывает все наши потребности в плане навигации по приложению. Можно было бы поэкспериментировать с react-native-navigation, но при разработки MVP даже не вставал вопрос о выборе библиотеке навигации. Для различных вариацией BottomSheets мы использовали три разных библиотеки react-native-scroll-bottom-sheet, reanimated-bottom-sheet, reanimated-bottom-sheet. У каждой библиотеки имеются свои возможности и ограничения - функционала очень много и не везде удалось использовать одну и ту же библиотеку. Возможно, в будущем, при рефакторинге, нам удасться сократить число библиотек для работы с BottomSheet в проекте.Идея с переносом асинхронной логике в хуки сама по себе интересная. Нам не нравится, что redux-saga обязывает результат запроса сначала положить в глобальное состояние приложения, а только потом как-то реагировать в компоненте/скрине. Иногда (довольно часто) нужно просто async/await функцию вызвать прямо из компонента. Мы использовали в проекте redux-saga по причине того, что этот подход достаточно давно известен и хорошо себя зарекомендовал. Однако, в последнее время, мы присматриваемся к переносу части логики связанной с чатами на MobX, чтобы уменьшить количество бойлерплейта и снизить сложность кода бизнес логики. За лето мы написали на MobX веб версию чатов и подумали, что будет хорошей идеей унифицировать эту часть логики для всех платформ, чтобы не писать ее дважды
Спасибо большое за позитивный отклик! нам и самим очень нравится)
по поводу возможности использования вне магазинов — передадим команде, обсудим.
а на кассах самообслуживания или экспресс-сканом (прямо в телефоне) вы пробовали оплачивать? это очень удобно
Здравствуйте!
Ответим так) Мы в любом случае большую часть своей жизни проводим на рабочем месте и для многих людей с развитыми социальными функциями (не для всех конечно) важно ощущать себя частью команды, делиться мнениями и общаться с коллегами. В приложении негативом сотрудники тоже очень активно, кстати, делятся. В "Перчатке" можно предложить какое-то нововведение напрямую топ-менеджеру, и если оно эффективное и экономически обоснованное, оно будет реализовано, есть такие кейсы.
В компаниях с развитой корпоративной культурой всегда активные блоги, иногда даже два — анонимный и открытый — а называются они по-разному (Перчатка, Этушка или как-то ещё).
добрый день!
у нас есть решение электронных ценников, которое исключает возможность человеческого фактора ошибки, но пока что оно пилотируется и работает не во всех магазинах сетей.
Если бы можно было сделать элемент в чате фиксированной высоты, то мы бы использовали предложенный вами метод. Однако, к чатам это не применимо как бы дизайнер не старался - все элементы всегда будут иметь разные размеры в зависимости от длины текста. Так же, нужно учитывать, что существуют еще такие уникальные по длине элементы как голосовые сообщения, изображения и вложения.
добрый день!
Есть машина, как непрерывный ресурс и есть водитель, как ограниченный во времени ресурс. За каждой машиной закреплен экипаж водителей, из-за необходимости производить пересменку согласно графика сменности водителей, без потерь в эффективности транспорта, предлагается схема «выручай рейса». Вместо ожидания сменщика, водитель помогает ему, выручив своего сменщика путем заблаговременной загрузки машины товаром для рейса своего сменщика. Каждое ТС передается из рук в руки между 2-мя водителями и по предложенной нами схеме, водитель, который завершает смену, передает сменщику уже загруженную машину. «Выручай рейсы» не применяются при экспедировании, только с собственным транспортом. Таким образом, каждый водитель полностью утилизирует свою смену «полезным» временем, что положительно отражается на его вознаграждении.
Идея с QR кодом имеет место быть, но необходимо учитывать, что автомобиль проходит проверку перед и после рейса на АТП, часть АТП отдалена от РЦ. В этом случае печать двух комплектов является дополнительным расходом бумаги. Передача груза и автомобиля «из рук в руки» необходима для разграничения ответственности водителей, т.к. водители - штатные сотрудники.