Я привык платить картой и плачу ей, потому что удобно. У меня телефон в чехле на поясе, кошелек в сумке. Достать карту и платить ей быстрее, чем делать оплату по телефону с NFC. Оплату с NFC осуществляю только когда уже телефон в руке для предъявления скидочной/накопительной карты. Тут уж все удобства очевидны, тем более не надо вводить пин при большой сумме.
Теперь про оплату по QR. Банковское приложение позволяет делать оплату по NFC без ввода пароля на приложение, ориентируясь на разблокировку телефона. Это удобно, логично. Но почему для оплаты по QR мне надо вводить код приложения? Это вообще не удобно и не логично. Ну и ожидание прогрузки всего и вся до момента готовности открыть сканер кода - вообще боль.
Да, я очень хочу лайт версию банковского приложения, в котором только история (оповещения), оплата по коду и переводы. Мгновенная загрузка, отсуствие блокировок (при условии наличия на телефоне защиты и разблокированного состояния), намного реже обновления, минимум всплывающей мишуры.
Я беру для примера большие проекты тянущиеся на десятки лет с развитием и поддержкой. Считаем срок их жизни с нуля и до сейчас считаем людей работающих над ним (примерно человекочасы), весь код на сейчас считаем отлаженным с допустимой погрешностью. Так вот, выхлоп из разработчика в день 50-100 строк отлаженного кода. Механически я его могу выложить в компьютер за полчаса-час. Все остальное время на работе тоже программирование, тоже работа с кодом. Только можно научиться это делать в голове, в идеале в фоне. Да, перед дедлайном или при аврале можно выдавать работающий код тысячами строк в день (мгновенные проблемы он закроет). Это и выглядит как "фигачинг за компом" не поднимая головы весь день. Но когда он станет продуктовым кодом, он все равно выйдет на 50-100 строк в день.
Предложу фантастический вариант. По току катушки можно определить нагрузку создаваемую сопротивлением стрелки (груза) на подъем или на опускание. Удаленно это вряд-ли получится сделать из-за большой погрешности вносимой длинной линией. Но в качестве задачки "на слабо" рядом размещенным контроллером можно попробовать. Если же реализовывать обратную связь для длинной линии, то вешать датчик нуля на каждую стрелку (магнит+геркон) и им докидывать сопротивление на линию. Его величина не должна сильно влиять на мощность привода, но должна быть однозначно считываема удаленно (независимые нули по каждой стрелке с разными величинами сопротивления). Или одинаковыми, но закрытыми разнонаправленными диодами.
Да, только на весе классических стрелок такое не сделать, нужно будет на приводе часовой делать смещающий противовес для состояния свободного свисания на 2.5 минутных деления до или после 6. Время синхронизации, соответственно, будет либо на полшестого либо на полседьмого.
Есть идея установки в ноль. Шаговые импульсы идут на одном напряжении. При подаче более высокого напряжения срабатывает отключение шаговых обмоток и включатеся "втягивающее реле" расцепителя стрелок. Обе падают на "полшестого". Таким образом спроектировав механизм с "электронным сцеплением" можно два раза в сутки выставлять показания "по нулям". К сожалению, без вмешательства в механику не представляю как это сделать.
Вообще ни слова о технических подробностях - средствах считывания кодов и радиометок. Самое интересное для данного ресурса.
Если заложить стоимость такой инфраструктуры для покрытия территории в пределах города, а потом разделить ее на самокатчиков и включить в сбор при регистрации...
Упор был на "автоматически" и "без дополнительных ухищрений". Произвольная группа абонентов в произвольном месте. Телефоны с плохой связью используют всех до кого дотянутся как ретрансляторов.
Жду патентования функции ретрансляции, когда устройство с устойчивой связью будет автоматически обеспечивать голосовую связь и передачу сообщений другим устройствам.
Есть в этом плюсы - без дополнительных ухищрений где-нибудь в глухомани закидываем на елку один телефон с тем оператором, который там самый устойчивый, а все спокойно ходим внизу и болтаем по своим трубкам вообще ничего не донастраивая (в идеале - по разным операторам). В совсем идеальном случае на елке может быть любой оператор, роуминг применяется к оконечному абоненту.
Напрягает то, что наличие у человека смартфона (ну и мобильного номера) становится обязательным (де факто) для приобретения услуги или товара. Не знаю насколько это законно.
И билеты конечно же были анонимные? Замечал, что продажа там билетов слабо защищена, но там требуется ввод паспортных данных. Так что это сработает только если хочешь лишить человека денег и купить на несуществующего человека. В остальных случаях следы остаются (пусть даже на третье лиуо, но оно все равно становится вовлечено в махинацию).
Есть у меня несколько заправочных топливных приложений. Одно генерирует при открытии динамический код, время жизни которого ограничено. Второе показывает статический баркод, который стоковым читателем расшифровывается как "НОМЕРКАРТЫ=ХХХХХ". Мне кажется что второе пятизначное число не слишком сложное. Может быть и в первом приложении тоже для опытного человека скрыт примитивный алгоритм навроде того, что описан в статье, но второе выглядит совсем по-детски. Сам разбираться не хочу и не сильно умею, но интуитивно стараюсь тратить баллы с заправок, чтобы у ребенка не отобрали кулек накопленных конфет.
В прокат надо поставить небольшую почасовую аренду и оплату за расход заряда. Тогда любители носиться и гонять вдвоем сразу осознают преимущества спокойной одиночной езды.
Бегло посмотрел ссылку, написание латиницей не заметил. По нашим законам транслитерация автоматически попадает под защиту зарегистрированной торговой марки?
Кстати, вижу зарегистрированное слово "стартер". Постоянно вижу в меню кафешек страничку "стартеры". Если так можно, значит можно в меню и страничку "додстеры"? А если нельзя, значит рейд по точкам общепита?
С сырками наверное будут разные позиции, ибо это по честному коду (молочка).
На классических товарах если они пробиваются подряд - объединяются. Если между ними проскочил другой товар, множество рвется на следующую группу и потом туда идет объединение. Такое я наблюдал (не в Магните). Но не вижу причин не объединять товары, если программист может. Другое дело, если начинают работать скидочные программы (типа 3как2, или по скидке максимум 10 в один чек).
Вопрос в том как сортировать товары в чеке. Никаких идей кроме как в порядке пробивания нет. И тут разрыв группы при попадании иного товара выглядит логичным.
Часть покупателей после первого негативного опыта к КСО никогда не подойдут снова. Необходимы независимые проверки новых и обучившихся покупателей. ЧТо усложняет исслодование, но улучшает результат. По-хорошему и на первой покупке не должно быть затыков. Просто чуть медленнее.
Это делается не так. Тестовые кассы вообще отвязанные отмозгов КСО и от банковского терминала (режим эмуляции), подключется обычный комп (если это ускорит процесс адаптации US), запускается толпа покупателей с их обычным набором в корзинках. Рядом сидит человек смотрит за процессом, все пишется на камеры. Точки торможения засекаются, исправляются. Запускается новая партия покупателей. Покупатели используются всегда новые (снизить эффект обучения).
Финальная проверка уже с полностью прошитыми аппаратами и настоящими терминалами.
Важно же замерять не только общую скорость. Важно отловить тормозящие моменты. Ведь кто-то просто медленно сканирует, а кто-то сканирует быстро, а не может разобраться в интерфейсе.
Я привык платить картой и плачу ей, потому что удобно. У меня телефон в чехле на поясе, кошелек в сумке. Достать карту и платить ей быстрее, чем делать оплату по телефону с NFC. Оплату с NFC осуществляю только когда уже телефон в руке для предъявления скидочной/накопительной карты. Тут уж все удобства очевидны, тем более не надо вводить пин при большой сумме.
Теперь про оплату по QR. Банковское приложение позволяет делать оплату по NFC без ввода пароля на приложение, ориентируясь на разблокировку телефона. Это удобно, логично. Но почему для оплаты по QR мне надо вводить код приложения? Это вообще не удобно и не логично. Ну и ожидание прогрузки всего и вся до момента готовности открыть сканер кода - вообще боль.
Да, я очень хочу лайт версию банковского приложения, в котором только история (оповещения), оплата по коду и переводы. Мгновенная загрузка, отсуствие блокировок (при условии наличия на телефоне защиты и разблокированного состояния), намного реже обновления, минимум всплывающей мишуры.
Я беру для примера большие проекты тянущиеся на десятки лет с развитием и поддержкой. Считаем срок их жизни с нуля и до сейчас считаем людей работающих над ним (примерно человекочасы), весь код на сейчас считаем отлаженным с допустимой погрешностью. Так вот, выхлоп из разработчика в день 50-100 строк отлаженного кода. Механически я его могу выложить в компьютер за полчаса-час. Все остальное время на работе тоже программирование, тоже работа с кодом. Только можно научиться это делать в голове, в идеале в фоне. Да, перед дедлайном или при аврале можно выдавать работающий код тысячами строк в день (мгновенные проблемы он закроет). Это и выглядит как "фигачинг за компом" не поднимая головы весь день. Но когда он станет продуктовым кодом, он все равно выйдет на 50-100 строк в день.
Предложу фантастический вариант. По току катушки можно определить нагрузку создаваемую сопротивлением стрелки (груза) на подъем или на опускание. Удаленно это вряд-ли получится сделать из-за большой погрешности вносимой длинной линией. Но в качестве задачки "на слабо" рядом размещенным контроллером можно попробовать.
Если же реализовывать обратную связь для длинной линии, то вешать датчик нуля на каждую стрелку (магнит+геркон) и им докидывать сопротивление на линию. Его величина не должна сильно влиять на мощность привода, но должна быть однозначно считываема удаленно (независимые нули по каждой стрелке с разными величинами сопротивления). Или одинаковыми, но закрытыми разнонаправленными диодами.
Да, только на весе классических стрелок такое не сделать, нужно будет на приводе часовой делать смещающий противовес для состояния свободного свисания на 2.5 минутных деления до или после 6. Время синхронизации, соответственно, будет либо на полшестого либо на полседьмого.
Есть идея установки в ноль. Шаговые импульсы идут на одном напряжении. При подаче более высокого напряжения срабатывает отключение шаговых обмоток и включатеся "втягивающее реле" расцепителя стрелок. Обе падают на "полшестого". Таким образом спроектировав механизм с "электронным сцеплением" можно два раза в сутки выставлять показания "по нулям". К сожалению, без вмешательства в механику не представляю как это сделать.
Для простого протокола появятся простые глушилки. Метка установлена, но в автомате не считывается.
Вообще ни слова о технических подробностях - средствах считывания кодов и радиометок. Самое интересное для данного ресурса.
Если заложить стоимость такой инфраструктуры для покрытия территории в пределах города, а потом разделить ее на самокатчиков и включить в сбор при регистрации...
Боюсь, что "батарейка вам не принадлежит, вы ее арендуете".
//Грустная шутка.
Упор был на "автоматически" и "без дополнительных ухищрений". Произвольная группа абонентов в произвольном месте. Телефоны с плохой связью используют всех до кого дотянутся как ретрансляторов.
Жду патентования функции ретрансляции, когда устройство с устойчивой связью будет автоматически обеспечивать голосовую связь и передачу сообщений другим устройствам.
Есть в этом плюсы - без дополнительных ухищрений где-нибудь в глухомани закидываем на елку один телефон с тем оператором, который там самый устойчивый, а все спокойно ходим внизу и болтаем по своим трубкам вообще ничего не донастраивая (в идеале - по разным операторам). В совсем идеальном случае на елке может быть любой оператор, роуминг применяется к оконечному абоненту.
На почте, если у меня сел телефон или нет связи, я могу удостоверить личность установленным законом способом.
В случае же с билетами по приложению альтернатив нет.
Напрягает то, что наличие у человека смартфона (ну и мобильного номера) становится обязательным (де факто) для приобретения услуги или товара. Не знаю насколько это законно.
И билеты конечно же были анонимные? Замечал, что продажа там билетов слабо защищена, но там требуется ввод паспортных данных. Так что это сработает только если хочешь лишить человека денег и купить на несуществующего человека. В остальных случаях следы остаются (пусть даже на третье лиуо, но оно все равно становится вовлечено в махинацию).
Есть у меня несколько заправочных топливных приложений. Одно генерирует при открытии динамический код, время жизни которого ограничено. Второе показывает статический баркод, который стоковым читателем расшифровывается как "НОМЕРКАРТЫ=ХХХХХ". Мне кажется что второе пятизначное число не слишком сложное. Может быть и в первом приложении тоже для опытного человека скрыт примитивный алгоритм навроде того, что описан в статье, но второе выглядит совсем по-детски. Сам разбираться не хочу и не сильно умею, но интуитивно стараюсь тратить баллы с заправок, чтобы у ребенка не отобрали кулек накопленных конфет.
В прокат надо поставить небольшую почасовую аренду и оплату за расход заряда. Тогда любители носиться и гонять вдвоем сразу осознают преимущества спокойной одиночной езды.
Бегло посмотрел ссылку, написание латиницей не заметил. По нашим законам транслитерация автоматически попадает под защиту зарегистрированной торговой марки?
Кстати, вижу зарегистрированное слово "стартер". Постоянно вижу в меню кафешек страничку "стартеры". Если так можно, значит можно в меню и страничку "додстеры"? А если нельзя, значит рейд по точкам общепита?
Под кодом таймер (убывающий прогресс плюс цифры) и большая надпись с нарисованной ладошкой "коснитесь чтобы продлить".
С сырками наверное будут разные позиции, ибо это по честному коду (молочка).
На классических товарах если они пробиваются подряд - объединяются. Если между ними проскочил другой товар, множество рвется на следующую группу и потом туда идет объединение. Такое я наблюдал (не в Магните).
Но не вижу причин не объединять товары, если программист может. Другое дело, если начинают работать скидочные программы (типа 3как2, или по скидке максимум 10 в один чек).
Вопрос в том как сортировать товары в чеке. Никаких идей кроме как в порядке пробивания нет. И тут разрыв группы при попадании иного товара выглядит логичным.
Часть покупателей после первого негативного опыта к КСО никогда не подойдут снова.
Необходимы независимые проверки новых и обучившихся покупателей. ЧТо усложняет исслодование, но улучшает результат. По-хорошему и на первой покупке не должно быть затыков. Просто чуть медленнее.
Это делается не так. Тестовые кассы вообще отвязанные отмозгов КСО и от банковского терминала (режим эмуляции), подключется обычный комп (если это ускорит процесс адаптации US), запускается толпа покупателей с их обычным набором в корзинках. Рядом сидит человек смотрит за процессом, все пишется на камеры. Точки торможения засекаются, исправляются. Запускается новая партия покупателей. Покупатели используются всегда новые (снизить эффект обучения).
Финальная проверка уже с полностью прошитыми аппаратами и настоящими терминалами.
Важно же замерять не только общую скорость. Важно отловить тормозящие моменты. Ведь кто-то просто медленно сканирует, а кто-то сканирует быстро, а не может разобраться в интерфейсе.