Продукт местами хороший, чего нельзя сказать обо всей линейке sdk от smart engines. В ряде задач можно применить, но потом возникает задача лицензирования в которой smart engines является тем ещё самодуром с запросами в стиле "мы продаем только если вы окажетесь от софта конкурента (а ничего Карл что вы конкурента и его юз кейс не покрываете? нет, нас это ничуть не смущает, ну и что что у вас бизнес встанет). В общем всем кто общался с smart engines понятно что это чисто политический продукт с нулевой конкурентоспособностью на мировом рынке. И к сожалению не из-за технологий, а лишь из-за семейного имперского мышления собственников
читаю вот такое и понимаю что если в мире задача компьютерного зрения и мобильных АРМов это для ускорения процессов, контроля работы сотрудников и т.п. то у нас - открытым текстом только для борьбы с невероятным взяточничеством где вот эти вот нелегальные мигранты коррумпируют голодных сотрудников РЦ. Местный так сказать колорит, cultural references!
Маразм из 20 века. Уже решено сто тысяч раз по спатиал данным, найдите продукт или апи которое это решает если совсем лень думать, не увеличивайте энтропию. Вам, как бизнесу, проще за такое платить, чем самому придумывать. Все равно очень плохо получается
Хорошо. в 2003м - 2005м в Зените в Ростове работал. У зенита розница была КомпьютерСити и своя сборка компов. Возможно вы у нас дилерами были, если закупали от нас. Но вообще - странно. Не очень сильный прогресс с 10 по 23й. Очень классическое ИТ, если позволите, но ничего больше. хорошо что вы смогли остаться как регионалы. Тот же ЮФО был почти без боя сдан москвичам и их рознице с 5го по 8й год. Эльдорадо, мвидео и тп
Спасибо, очень хороший материал. Отдельно добавлю что не за горами тот момент, когда в индустриальном окружении и в более лёгких индустриях, например дискретном производстве, будут всё большую роль играть мобильные приложения. Вот в них, по нашему опыту, необходимость вылизывать каждый мм дизайна исходя из оптимизационной задачи под окружение, пользователя, свет, необходимой скорости ввода, количества данных и т.п. стоит ещё более остро. И да, дизайнеры даже в самых продвинутых странах на эту тему ещё не очень активно работают.
З.Ы. а вы знаете что по статистике около 8% мужчин имеют отклонения в восприятии цвета (а-ля дальтонизм и тому подобные, менее известные) поэтому всеми любимый красный/жёлтый/зелёный это то, что не работает в условиях высокой интенсивности без пиктограмм? Особенно если нет регулярного медосмотра по зрению на цвета (а это 98% производства).
Как высказались в комментариях 2д сканер или умный измерительный инструмент будет гораздо более правильным решением.
Что касается голосового ввода, то очевидно, что вам надо искать edge SDK, а не Клауд. То есть, если отбросить всю остальную критику и принять ваш подход правильным то cloud - самый большой concern для всей архитектуры. Как максимум - локальный деплой, однако edge это самое правильное.
Вердикт - если заказчик с реально большим складом и серьезным потоком, будут плавающие баги и простои. Всему виной - слабая кроссплатформенная связка. Но это вы увидите только на больших объемах, для смб вполне подойдёт
Такое пишется в одно лицо за 1-2 месяца если в начале пути не знать флаттер, swift и немного дружить с гайдами. Говорю как человек написавший именно такое именно так и при этом в начале только слышал о флаттере. По итогу в продакшне - и flutter гно, и MLKit тоже)
Вы для начала проверьте их работу в реальных условиях с реальными этикетками, освещением, углами и тп, вопросы снимутся.
Большинство посетителей этого сайта считают что если нечто работает на их Iphone 10-14 с 1 штрих кодом в хорошо освещённом офисе, когда последние 8 часов юзернейм только умственно работал, а смартфон в ходе теста в руке не трясется от банальной усталости, постоянно теряя фокус, то вопрос выбора компонента для сканирования закрыт, можно в продакшн. Но есть один момент)))
Если долго работать с flutter и именно по вашей специфике т.е. работа с камерой и передача событий от native к flutter то можно заметить, что т.н. channels это глючное гно, которое может отваливаться и при этом событие распознавание шк на платформе не придет к флаттер аппу. Сколько об этом ни говорили Гуглу - воз и ныне там, а прошло уже пару лет. Но не спешите переписывать под реакт нейтив или, спаси Б-г под capacitor и иже с ними... Там будет проблематика с пропадающим camera preview т.к. не всегда нейтив красиво как на картинке встраивается в контейнер под него в приложении, страдает при этом дизайнер урезающий UI до убогого гна. Так как за пару лет прошло более 3 млрд. сканирований, со статистикой не поспорить - все кроссплатформенные платформы слабо работают с нативным железом.
Что касается MLKit то при небольшой дистанции и с 1 шк в кадре он норм, но на расстоянии более 30 см и наличии нескольких шк на экране легко тормозит и не понимает что есть что. Конечно лучше чем avfoundation/zxing но тоже шлак, годный лишь для сценариев с низкой нагрузкой до 100 сканирований в час. На поточных операциях типа склада спасает только коммерческий софт.
Ну и да, поточное сканирование это конечно новинка которой лет 7-8 уже как, а вот когда надо и пару разных шк и этикетку сразу распознать, а иногда и сразу у всех пачек лекарств в коробке все dataMatrix считать, тут и экономия в десятки раз по времени и выгоды. Только гугль такого не умеет.
Спасибо, вы - тот самый покупатель, которому и должен этот компонент считывания штрих-кодов служить верой и правдой. И если вы его используете и всё работает - значит разработчики всё сделали правильно. А если вы три раза попробовали и все три раза ничего не считалось - то компания потратила на разработку Х денег, а продуктом не воспользовались, конверсии нет, доверие упало. Если с happy path всё плюс-минус понятно, то вот как не сделать то, чем никто не сможет пользоваться (а у разрабов будет отговорка "у нас всё работает") и был основной посыл этой статьи. Но я постараюсь её доделать, добавить инфографики и других визуальных пояснений, которые лучше дадут понять методологию и почему это важно.
Вы правы почти во всём. Один нюанс - ТСД это устройство для сотрудника, клиентам его не дашь. И второе - ТСД достаточно дороги, если их стоимость это 50-70т.р. без аксессуаров (доп.батарея, док-станция, кабели и тп) то ТСО на год почти в 2 раза больше. Если заместить это хозяйство смартфоном сотрудника (личным) то экономия может быть кардинальной, если заместить корпоративным смартфоном - тоже достаточно существенной, в разы. Плюс смартфон даёт возможность работать в других корпоративных приложениях, что в случае с ТСД практически исключено.
Спасибо за замечание, действительно, статья нуждается в изменениях - идея была в том, чтобы рассказать о правильном подходе в выборе компоненты сканирования штрихкодов для моб.приложений.
Хоть задача и кажется типовой, выбор часто происходит при минимальном тестировании или тестировании happy path в достаточно понятном и отличном от реального окружении.
А надо смотреть на вопрос выбора компонента, как на решение из-за которого произойдет существенное уменьшение а) конверсии по клиентским процессам либо б) показателей по служебным процессам сотрудника.
Посему, в отличие от многих других понятных для разработчиков софта компонент, выбор компонента распознавания ш\к должен идти по достаточно требовательной методике, включающей в себя тестирование в реальном окружении на реальных, а не топовых смартфонах, с понятным набором KPI по самому процессу (сколько секунд на считывание, сколько - на весь процесс со считыванием)
Отдельно всё это актуально для компаний, которые хотят заменить ТСД на смартфоны и пытаются при этом перейти на что-то очень популярное, опенсорсное, но с кучей проблем при массовом (тысячи в сутки) распознавании штрих-кодов. Просто так zxing-ом ТСД не заменить, однако при должном наборе тест-кейсов и правильном подходе можно найти компоненты, пусть и коммерческие, которые снижают стоимость владения парком устройств даже не в разы, а на порядок. Об этом я тоже отдельно в следующих материалах изложу.
Продукт местами хороший, чего нельзя сказать обо всей линейке sdk от smart engines. В ряде задач можно применить, но потом возникает задача лицензирования в которой smart engines является тем ещё самодуром с запросами в стиле "мы продаем только если вы окажетесь от софта конкурента (а ничего Карл что вы конкурента и его юз кейс не покрываете? нет, нас это ничуть не смущает, ну и что что у вас бизнес встанет). В общем всем кто общался с smart engines понятно что это чисто политический продукт с нулевой конкурентоспособностью на мировом рынке. И к сожалению не из-за технологий, а лишь из-за семейного имперского мышления собственников
читаю вот такое и понимаю что если в мире задача компьютерного зрения и мобильных АРМов это для ускорения процессов, контроля работы сотрудников и т.п. то у нас - открытым текстом только для борьбы с невероятным взяточничеством где вот эти вот нелегальные мигранты коррумпируют голодных сотрудников РЦ. Местный так сказать колорит, cultural references!
Маразм из 20 века. Уже решено сто тысяч раз по спатиал данным, найдите продукт или апи которое это решает если совсем лень думать, не увеличивайте энтропию. Вам, как бизнесу, проще за такое платить, чем самому придумывать. Все равно очень плохо получается
Хорошо. в 2003м - 2005м в Зените в Ростове работал. У зенита розница была КомпьютерСити и своя сборка компов. Возможно вы у нас дилерами были, если закупали от нас. Но вообще - странно. Не очень сильный прогресс с 10 по 23й. Очень классическое ИТ, если позволите, но ничего больше. хорошо что вы смогли остаться как регионалы. Тот же ЮФО был почти без боя сдан москвичам и их рознице с 5го по 8й год. Эльдорадо, мвидео и тп
Хабр может удивляться, но реальность такова, что присловутый "индус" пишет код качественнее русского. Стоит дешевле и меньше кидает пальцев.
Увы, деньги испортили белых людей. У тех, кто не особо на них заморочен, получается и проще, и дешевле, и быстрее.
Спасибо, очень хороший материал. Отдельно добавлю что не за горами тот момент, когда в индустриальном окружении и в более лёгких индустриях, например дискретном производстве, будут всё большую роль играть мобильные приложения. Вот в них, по нашему опыту, необходимость вылизывать каждый мм дизайна исходя из оптимизационной задачи под окружение, пользователя, свет, необходимой скорости ввода, количества данных и т.п. стоит ещё более остро. И да, дизайнеры даже в самых продвинутых странах на эту тему ещё не очень активно работают.
З.Ы. а вы знаете что по статистике около 8% мужчин имеют отклонения в восприятии цвета (а-ля дальтонизм и тому подобные, менее известные) поэтому всеми любимый красный/жёлтый/зелёный это то, что не работает в условиях высокой интенсивности без пиктограмм? Особенно если нет регулярного медосмотра по зрению на цвета (а это 98% производства).
Как высказались в комментариях 2д сканер или умный измерительный инструмент будет гораздо более правильным решением.
Что касается голосового ввода, то очевидно, что вам надо искать edge SDK, а не Клауд. То есть, если отбросить всю остальную критику и принять ваш подход правильным то cloud - самый большой concern для всей архитектуры. Как максимум - локальный деплой, однако edge это самое правильное.
Вердикт - если заказчик с реально большим складом и серьезным потоком, будут плавающие баги и простои. Всему виной - слабая кроссплатформенная связка. Но это вы увидите только на больших объемах, для смб вполне подойдёт
Такое пишется в одно лицо за 1-2 месяца если в начале пути не знать флаттер, swift и немного дружить с гайдами. Говорю как человек написавший именно такое именно так и при этом в начале только слышал о флаттере. По итогу в продакшне - и flutter гно, и MLKit тоже)
Вы для начала проверьте их работу в реальных условиях с реальными этикетками, освещением, углами и тп, вопросы снимутся.
Большинство посетителей этого сайта считают что если нечто работает на их Iphone 10-14 с 1 штрих кодом в хорошо освещённом офисе, когда последние 8 часов юзернейм только умственно работал, а смартфон в ходе теста в руке не трясется от банальной усталости, постоянно теряя фокус, то вопрос выбора компонента для сканирования закрыт, можно в продакшн. Но есть один момент)))
Если долго работать с flutter и именно по вашей специфике т.е. работа с камерой и передача событий от native к flutter то можно заметить, что т.н. channels это глючное гно, которое может отваливаться и при этом событие распознавание шк на платформе не придет к флаттер аппу. Сколько об этом ни говорили Гуглу - воз и ныне там, а прошло уже пару лет. Но не спешите переписывать под реакт нейтив или, спаси Б-г под capacitor и иже с ними... Там будет проблематика с пропадающим camera preview т.к. не всегда нейтив красиво как на картинке встраивается в контейнер под него в приложении, страдает при этом дизайнер урезающий UI до убогого гна. Так как за пару лет прошло более 3 млрд. сканирований, со статистикой не поспорить - все кроссплатформенные платформы слабо работают с нативным железом.
Что касается MLKit то при небольшой дистанции и с 1 шк в кадре он норм, но на расстоянии более 30 см и наличии нескольких шк на экране легко тормозит и не понимает что есть что. Конечно лучше чем avfoundation/zxing но тоже шлак, годный лишь для сценариев с низкой нагрузкой до 100 сканирований в час. На поточных операциях типа склада спасает только коммерческий софт.
Ну и да, поточное сканирование это конечно новинка которой лет 7-8 уже как, а вот когда надо и пару разных шк и этикетку сразу распознать, а иногда и сразу у всех пачек лекарств в коробке все dataMatrix считать, тут и экономия в десятки раз по времени и выгоды. Только гугль такого не умеет.
Спасибо, вы - тот самый покупатель, которому и должен этот компонент считывания штрих-кодов служить верой и правдой. И если вы его используете и всё работает - значит разработчики всё сделали правильно. А если вы три раза попробовали и все три раза ничего не считалось - то компания потратила на разработку Х денег, а продуктом не воспользовались, конверсии нет, доверие упало. Если с happy path всё плюс-минус понятно, то вот как не сделать то, чем никто не сможет пользоваться (а у разрабов будет отговорка "у нас всё работает") и был основной посыл этой статьи. Но я постараюсь её доделать, добавить инфографики и других визуальных пояснений, которые лучше дадут понять методологию и почему это важно.
Вы правы почти во всём. Один нюанс - ТСД это устройство для сотрудника, клиентам его не дашь. И второе - ТСД достаточно дороги, если их стоимость это 50-70т.р. без аксессуаров (доп.батарея, док-станция, кабели и тп) то ТСО на год почти в 2 раза больше. Если заместить это хозяйство смартфоном сотрудника (личным) то экономия может быть кардинальной, если заместить корпоративным смартфоном - тоже достаточно существенной, в разы. Плюс смартфон даёт возможность работать в других корпоративных приложениях, что в случае с ТСД практически исключено.
Спасибо за замечание, действительно, статья нуждается в изменениях - идея была в том, чтобы рассказать о правильном подходе в выборе компоненты сканирования штрихкодов для моб.приложений.
Хоть задача и кажется типовой, выбор часто происходит при минимальном тестировании или тестировании happy path в достаточно понятном и отличном от реального окружении.
А надо смотреть на вопрос выбора компонента, как на решение из-за которого произойдет существенное уменьшение а) конверсии по клиентским процессам либо б) показателей по служебным процессам сотрудника.
Посему, в отличие от многих других понятных для разработчиков софта компонент, выбор компонента распознавания ш\к должен идти по достаточно требовательной методике, включающей в себя тестирование в реальном окружении на реальных, а не топовых смартфонах, с понятным набором KPI по самому процессу (сколько секунд на считывание, сколько - на весь процесс со считыванием)
Отдельно всё это актуально для компаний, которые хотят заменить ТСД на смартфоны и пытаются при этом перейти на что-то очень популярное, опенсорсное, но с кучей проблем при массовом (тысячи в сутки) распознавании штрих-кодов. Просто так zxing-ом ТСД не заменить, однако при должном наборе тест-кейсов и правильном подходе можно найти компоненты, пусть и коммерческие, которые снижают стоимость владения парком устройств даже не в разы, а на порядок. Об этом я тоже отдельно в следующих материалах изложу.