Чем делиться, простите? Арендные платежи за Байконур — копейки. Даже если РФ будет отдавать всю свою прибыль от коммерческих пусков, то даже тогда цена вопроса — несколько квартир в Астане.
Собственно, была надежда, что автор раскроет что именно не подошло в готовых решениях и что они делают такого, что не может коробочный софт. В статье об этом ни слова, вполне обычный функционал.
Но, вообще, молодцы конечно. Мир безумцами движется.
Так и не ответили на вопрос зачем писать свое ПО с нуля и обрекать себя на вечные косты по поддержке и регулярной ресертификации если это всё можно было пиксель-в-пиксель сделать на готовом, коробочном софте?
Есть целый ряд сторонних решений типа CR2, KAL, и решений у самих банкоматных вендоров типа NCR Connections т.п. которые позволяют делать все описанное в статье быстро, просто, безгеморройно.
Не обязательно было делать связку Python-Node. Можно было прямо в ноде всё сделать.
И даже сделать так, чтобы работало всё на клиенте чтобы javascript-приложение можно было обернуть в cordova и запускать на мобильном. Более того, на клиенте можно и WebGL использовать, но…, да, молчу-молчу.
Есть целый ряд рабочих библиотек под JS
https://github.com/harthur-org/brain.js
https://github.com/karpathy/convnetjs
Видел банк с 2000+ банкоматами, который внутрь каждого банкомата поставил по еще одному компу с USB-камерой, своей сетью и защищенным питанием. И это не потому что они дураки, а потому что так вышло дешевле, чем покупать софт у винкора.
Бывает ставят софт, который берёт событие с XFS-слоя и таким образом синхронизирует видео с транзакцией.
А бывает так, что видеонаблюдение является частью клиентского приложения и для управления, журналирования, хранения видео используется та же инфраструктура что и для транзакций.
Да, в этом беда. Нет ещё единого протокола и, мне кажется, ещё лет десять не будет.
Ну тот же CR2 свой проприетарный протокол открыл, но это ещё не стандарт.
Просто браузер много не даст. Печать на чеке останется проблемой, скажем, в числе многого.
Отдали браузером управление — значит еще один хост должен дублировать функционал АТМ-контроллера: транзакции, реконсиляция, аутентификация, журналирование, все эти прелести.
Специализированный софт (CR2, к примеру) имеет свой АТМ-контроллер, свой АТМ-клиент и общаются они по своему протоколу. Никаких NDC и прочего архаизма. В легаси-схеме устарел сам подход, когда банкомат был тупым терминалом.
Основные банкоматные вендоры идут дорогой замены и хоста и клиента, эмуляцией (и заменой) ISO, NDC. Есть даже инсталляции кое-где, но лет пять готовых продуктов еще не будет.
Радует, что все вендоры идут в одну сторону, но беда в том, что, как обычно, каждый вендор идёт чуть-чуть своей дорогой.
Смотря что называть «левым» софтом.
Практика показывает, что софт компаний специализирующися на банкоматном софте внезапно оказывается лучше дефолтного софта поставляемого вместе с железом.
Особенно это становится явно, когда в банке большая сеть, особенно, когда используются устройства нескольких вендоров.
А если в банке несколько хостов, то дефолтный софт банкоматных вендоров уже совсем не подходит.
Водораздел идёт по XFS: вендор банкомата отвечает за работу устройства и работу драйверов до слоя XFS. Выше XFS — ответственность поставщика банкоматного софта.
Это позволяет забыть о NDC/DDC, стэйтах-шмейтах и прочих ограничений эпохи королевы Виктории.
Нет, не слетаете.
Сейлзы производителей банкоматов часто стращают банки потерей гарантии на всё устройство если банк отказывается от софта, но на самом деле это не так, поставщики банкоматов продолжают обеспечивать гарантию на железо.
1) Не надо ориентироваться на РФ. Мир большой.
2) если сделаете отсечку всех звонков от агентов недвижимости, то апп будет бесценным в Дубай
3) если сделаете автоматический поиск в базе World Checkи и прочим (как это делает tonbeller по городским линиям) чтобы показывать мошенников и прочих неблагонадежных лиц, то апп станет бесценным в лондонском Сити
4) и так далее, идите по нишам, их много.
На EMV-микросхему карты на этапе загрузки приложения заливается так называемый CVM-лист (CVM – Cardholder Verification Method). Также его можно менять в во время транзакции специальным эмитентским скриптом, направляемым с процессингового центра
А, всё-таки, нельзя ли рассказать подробнее про это?
Собственно, была надежда, что автор раскроет что именно не подошло в готовых решениях и что они делают такого, что не может коробочный софт. В статье об этом ни слова, вполне обычный функционал.
Но, вообще, молодцы конечно. Мир безумцами движется.
Так и не ответили на вопрос зачем писать свое ПО с нуля и обрекать себя на вечные косты по поддержке и регулярной ресертификации если это всё можно было пиксель-в-пиксель сделать на готовом, коробочном софте?
Есть целый ряд сторонних решений типа CR2, KAL, и решений у самих банкоматных вендоров типа NCR Connections т.п. которые позволяют делать все описанное в статье быстро, просто, безгеморройно.
И даже сделать так, чтобы работало всё на клиенте чтобы javascript-приложение можно было обернуть в cordova и запускать на мобильном. Более того, на клиенте можно и WebGL использовать, но…, да, молчу-молчу.
Есть целый ряд рабочих библиотек под JS
https://github.com/harthur-org/brain.js
https://github.com/karpathy/convnetjs
критика JWT
Видел банк с 2000+ банкоматами, который внутрь каждого банкомата поставил по еще одному компу с USB-камерой, своей сетью и защищенным питанием. И это не потому что они дураки, а потому что так вышло дешевле, чем покупать софт у винкора.
Бывает ставят софт, который берёт событие с XFS-слоя и таким образом синхронизирует видео с транзакцией.
А бывает так, что видеонаблюдение является частью клиентского приложения и для управления, журналирования, хранения видео используется та же инфраструктура что и для транзакций.
Ну тот же CR2 свой проприетарный протокол открыл, но это ещё не стандарт.
Отдали браузером управление — значит еще один хост должен дублировать функционал АТМ-контроллера: транзакции, реконсиляция, аутентификация, журналирование, все эти прелести.
Специализированный софт (CR2, к примеру) имеет свой АТМ-контроллер, свой АТМ-клиент и общаются они по своему протоколу. Никаких NDC и прочего архаизма. В легаси-схеме устарел сам подход, когда банкомат был тупым терминалом.
Основные банкоматные вендоры идут дорогой замены и хоста и клиента, эмуляцией (и заменой) ISO, NDC. Есть даже инсталляции кое-где, но лет пять готовых продуктов еще не будет.
Радует, что все вендоры идут в одну сторону, но беда в том, что, как обычно, каждый вендор идёт чуть-чуть своей дорогой.
Практика показывает, что софт компаний специализирующися на банкоматном софте внезапно оказывается лучше дефолтного софта поставляемого вместе с железом.
Особенно это становится явно, когда в банке большая сеть, особенно, когда используются устройства нескольких вендоров.
А если в банке несколько хостов, то дефолтный софт банкоматных вендоров уже совсем не подходит.
Это позволяет забыть о NDC/DDC, стэйтах-шмейтах и прочих ограничений эпохи королевы Виктории.
Сейлзы производителей банкоматов часто стращают банки потерей гарантии на всё устройство если банк отказывается от софта, но на самом деле это не так, поставщики банкоматов продолжают обеспечивать гарантию на железо.
2) если сделаете отсечку всех звонков от агентов недвижимости, то апп будет бесценным в Дубай
3) если сделаете автоматический поиск в базе World Checkи и прочим (как это делает tonbeller по городским линиям) чтобы показывать мошенников и прочих неблагонадежных лиц, то апп станет бесценным в лондонском Сити
4) и так далее, идите по нишам, их много.
А, всё-таки, нельзя ли рассказать подробнее про это?