Там вопрос не в установлении личности, а в наборе подтвержденных клиентских данных. СНИЛС, ИНН (подтвержденной в ФНС), паспорт тот же (с проверкой что он не числится в БД недействительных паспортов МВД) и т.п. Считается что на ГУ данные подтверждены.
И да, можно сделать это через веб интерфейс. Но девочке проще сказать "установите приложение", чем объяснять как это сделать через веб на мелком экране телефона. Или говорить клиенту - вон там у нас комп для клиентов, идите в вебе подвяжите аккаунт ГУ, потом снова подойдете.
Так что тут требования регулятора, помноженные на человеческий фактор конкретной девочки (а операторы в ККО - это низшая ступень "пищевой цепочки" в банке, в т.ч. и по оплате).
Как оно устроено в банках можете мне не рассказывать. Я в этом 8 лет уже варюсь. На уровне центральных серверов (ядро АБС).
Да, есть "нормативка" когда что-то должно быть сделано к строго определенной дате. Но в целом корректность и оптимальность кода важнее малого ТТМ. И дефект промсреды - это уже "инцидент".
Время на тесты тут кратно превышает время на разработку. И тесты многоступенчатые - компоненты, бизнес, нагрузка, интеграция, техтест на прелайве...
Фортран - специализированный язык для разного рода расчетов и численных методов. И для этого там есть все необходимое. И там, кстати, есть много библиотек где реализованы разного рода алгоритмы и численные методы.
И никому в голову не придет писать фронт на фортране. Потому что он не для этого.
Бизнес может потерять крупных клиентов просто от того, что там есть баги. Особенно, если крупный клиент в результате бага потеряет крупные деньги.
А если область регулируемая (скажем, банк) и в результате бага банк начнет пропускать платежи которые не должен пропускать или не предоставит какую-то обязательную отчетность (или предоставит, но неверную), то тут уже последуют санкции. Вплоть до лишения лицензии.
Бывают ситуации, когда решение задачи не ограничивается просто получением некоего Б на выходе, если на вход пришло некое А, но и выполнение этой задачи в рамках заданного временного окна. Т.е. "не дольше чем ...". Т.е. если вы обрабатываете какой-то большой объем данных, пусть и правильно, но за несколько часов (ну данных же много...), то задачу вы не решили. Нужно чтобы эти данные были обработаны не более чем за час. Как - это уже ваша проблема, вам за это платят. Сидите и думайте.
Бывают задачи "на оптимизацию". Когда оно есть и работает, но количество данных увеличилось и оно перестало укладываться в заданное временное окно. Нужно сделать то же самое, но быстрее...
А часто при этом еще и ограничение на использование ресурсов процессора и памяти. Потому что это сервер на нем еще много чего в то же время работает.
Так что ваша программ решает задачу только при условии правильного результата вкупе с оптимальностью алгоритмов.
А это как раз пример того, что случается если принципы писания приложений для постинга в сеть котиков переносят на серьезные вещи где подходы "херек-херак и в продакшн, главное быстрее всех, баги сами вылезут, потом поправим" чреваты реальными катастрофами и жертвами.
В том же банке, если вы выпустите в прод код, который "случайно" отправит 10 лямов VIP клиента бог знает куда (или просто внезапно обнулит его счет) - у вас будут очень большие проблемы (с большим количеством вполне себе реальных нулей)... И с клиентом и с регулятором.
Если ваш банковский софт как-то проработает год, но в НГ (период пиковых нагрузок) встанет колом - вы будете иметь очень большие проблемы (как репутационные, так и с регулятором, опять же).
Если у вас какая-то система управления, скажем, АЭС, то кривой софт может подарить миру еще один Чернобыль или Фукусиму...
А всякие инет-лабазы торгующие зарядниками для телефонов - там да. Пофиг. Ну обломится клиент с покупкой да и фиг с ним казалось бы...
В рунете вообще очень любят чуть что аппелировать к мифическому "70-летнему пенсионеру из Костромы в пенсией 12тр". Вот сколько было родителей (и тетешек-дядюшек) - ни у кого "12тр" не было. Не сотни тысяч, но на жизнь хватало всем. И не скажу чтобы ежиков без соли кушали.
К слову сказать, жена уже оформила пенсию. чуть менее 60тр получилось. Всю жизнь занималась (ну и сейчас еще работает "вполсвиста") переводами (научная и техническая тематика, в т.ч. патенты - т.е. еще немного юридическое в области патентного права и интеллектуальной собственности), вопросами интеллектуальной собственности и иногда контролем качества (есть сертификат аудитора по качеству). Т.е. просто работала, не чиновничела и не начальничела особо.
Имена длиной до 255 символом это не есть великое достижение и врядли на самом деле используется. А когда используется то это что-нибудь составное из даты, времени и еще каких-нибудь атрибутов которые на самом деле могли бы быть реализованны иначе, но увы иначе не предусмотренно.
В АСке имя объекта, а там все есть объект - и файл (хотя *FILE это просто один из типов объектов) и библиотека (аналог папки в винде) вообще ограничено 10-ю символами. Но у каждого объекта есть свойство TEXT - 50 символов произвольного текста куда можно писать все что угодно (и оно редактируемое).
Ну вот мне АСка тоже очень нравится. И возможностями своими и тем, что она предоставляет разработчику и своей логической и идеологической целостностью и понятностью (сначала непривычно все, начиная от файловой системы которая там вообще не похожа на вин/линукс и концепцией "все есть объект", потом, когда чуть вникнешь в основы, дальше уже все просто и логично ложится одно на другое без зазоров).
И обратно в тот зоопарк вин/линукс я уже точно не хочу (и, надеюсь, не придется уже). Именно в плане разработки.
Делов том, что есть определенный инструмент. И к нему привык - куча паттернов, которые делаются просто на автомате. И вот когда с новой версией все паттерны ломаются т.к. там весь интерфейс перепахали, это сильно снижает производительность на то время когда привыкнешь к новым. То, что раньше делал не задумываясь, теперь думаешь - "а как, черт возьми, это сделать в новой версии?". А когда привыкаешь к новому, тут опять обновление и начинай все сначала...
Все определяется потребностями бизнеса. Где бизнесу надо хоть криво-сыро, но скорее выкинуть на рынок с минимальными затратами - там будет кривое-сырое, но раньше всех. И сеньоров там будет мало - вс будут делать более дешевые джуны и мидлы.
А где для бизнеса важно чтобы оно работало максимально эффективно и цена ошибки в коде выражается крупными финансовыми и репутационными потерями - там все будет совсем иначе.
Реалии жизни в условиях "одноразового потребления" в том, что первого намного больше чем второго. И массовая прибыль делается на первом. А второе уходит в разного рода нишевые сегменты. В результате работать в областях из второго пункта воспринимается как "фу-у, нерелевантный опыт..."
Насколько высоко от дивана должен оторвать свою жопу 70 летний пенсионер из Костромы с пенсией $100 в месяц, чтобы получить возможность эмигрировать, скажем, в Канаду?
Вот тут не надо передергивать. В 70 лет, понятно, делать уже что-то поздно.
Но. В 52(!!!) года я лично резко оторвал опу от дивана. Не до уровня "эмигрировать в Канаду", но поменял работу (хотя далось это тяжеловато). И резко поднял уровень своего благосостояния.
Знаю немало людей в своем окружении, кто сделал это в 30-35 лет. В т.ч. и тех, что уде имеет или ВНЖ или гражданство в европе.
Так что возможность таки есть. Но думать про это надо не в 70 лет, это совершенно точно.
Я не слышал, чтобы кто-то из разработчиков плакал: "Вот какая пичалька! Я хочу сделать то-то и то-то, в z/OS я бы сделал это одной левой, а в Windows или Linux не могу! Ааааааа!!!"
А много вы знаете разработчиков, кто серьезно бы МФ, а потом вернулся бы на Вин/Линукс? Для решения схожих задач...
Я с МФ не работал, работаю с middliware от IBM - IBM i (AS/400). И могу сказать, что в АСке возможностей для разработчика намного больше (и под вин и под линукс работал долго до АСки).
К примеру, достаточно активно используем системные очереди для организации разного рода конвейеров для распараллеливания обработки больших объемов данных. Ни в винде ни в линуксе ничего близко похожего нет.
Есть "очереди сообщений" куда я из программы могу откидывать какие-то трейсы и видеть что там происходит в реальном времени. Опять - в мире вин и линукс такого нет.
Также нет ведущихся системой для каждого задания joblog. Где видно все, что в этом задании происходило. Включая ошибки, исключения и т.п. - если программа упала, то там будет видно почему упала и где именно упала.
Нет системных журналов где журналируются все изменения объектов. На уровне системы. Автоматом. У нас на них работают т.н. "журнальные мониторы" которые отслеживают и анализируют изменения и выполняют необходимые действия.
И такого очень много. И, подозреваю, что на МФ тоже много подобных вещей.
Да, аппаратные терминалы ушли в прошлое. Для IBM i на смену аппаратным 5250 пришли эмуляторы. В т.ч. и гуевые.
Сама IBM дает бесплатный пакет IBM i Access Client Solutions.
Там кроме самого эмулятора 5250 еще очень много всякого полезного - работа со спульниками, работа с IFS ("интегрированная файловая система" - INIX-like подраздел ФС), работа с бд, включая интерактивный SQL который еще и планы запросов рисовать умеет с диагностикой и рекомендациями оптимизатора - очень полезный инструмент для разработчика) и средства администрирования...
Там вопрос не в установлении личности, а в наборе подтвержденных клиентских данных. СНИЛС, ИНН (подтвержденной в ФНС), паспорт тот же (с проверкой что он не числится в БД недействительных паспортов МВД) и т.п. Считается что на ГУ данные подтверждены.
И да, можно сделать это через веб интерфейс. Но девочке проще сказать "установите приложение", чем объяснять как это сделать через веб на мелком экране телефона. Или говорить клиенту - вон там у нас комп для клиентов, идите в вебе подвяжите аккаунт ГУ, потом снова подойдете.
Так что тут требования регулятора, помноженные на человеческий фактор конкретной девочки (а операторы в ККО - это низшая ступень "пищевой цепочки" в банке, в т.ч. и по оплате).
Думаю, что цена реализации нефункциональных требований на разных платформах может сильно отличаться...
Может это не в банке дело, а в требованиях регулятора, которые банк не может нарушать?
Как оно устроено в банках можете мне не рассказывать. Я в этом 8 лет уже варюсь. На уровне центральных серверов (ядро АБС).
Да, есть "нормативка" когда что-то должно быть сделано к строго определенной дате. Но в целом корректность и оптимальность кода важнее малого ТТМ. И дефект промсреды - это уже "инцидент".
Время на тесты тут кратно превышает время на разработку. И тесты многоступенчатые - компоненты, бизнес, нагрузка, интеграция, техтест на прелайве...
Фортран - специализированный язык для разного рода расчетов и численных методов. И для этого там есть все необходимое. И там, кстати, есть много библиотек где реализованы разного рода алгоритмы и численные методы.
И никому в голову не придет писать фронт на фортране. Потому что он не для этого.
Бизнес может потерять крупных клиентов просто от того, что там есть баги. Особенно, если крупный клиент в результате бага потеряет крупные деньги.
А если область регулируемая (скажем, банк) и в результате бага банк начнет пропускать платежи которые не должен пропускать или не предоставит какую-то обязательную отчетность (или предоставит, но неверную), то тут уже последуют санкции. Вплоть до лишения лицензии.
Бывают ситуации, когда решение задачи не ограничивается просто получением некоего Б на выходе, если на вход пришло некое А, но и выполнение этой задачи в рамках заданного временного окна. Т.е. "не дольше чем ...". Т.е. если вы обрабатываете какой-то большой объем данных, пусть и правильно, но за несколько часов (ну данных же много...), то задачу вы не решили. Нужно чтобы эти данные были обработаны не более чем за час. Как - это уже ваша проблема, вам за это платят. Сидите и думайте.
Бывают задачи "на оптимизацию". Когда оно есть и работает, но количество данных увеличилось и оно перестало укладываться в заданное временное окно. Нужно сделать то же самое, но быстрее...
А часто при этом еще и ограничение на использование ресурсов процессора и памяти. Потому что это сервер на нем еще много чего в то же время работает.
Так что ваша программ решает задачу только при условии правильного результата вкупе с оптимальностью алгоритмов.
А это как раз пример того, что случается если принципы писания приложений для постинга в сеть котиков переносят на серьезные вещи где подходы "херек-херак и в продакшн, главное быстрее всех, баги сами вылезут, потом поправим" чреваты реальными катастрофами и жертвами.
Если вниматель читать ответы, то станет понятно что не было
Вы мыслите в рамках вин/линукс. И заперты в этих рамках.
Если что, я не в москве и даже не в питере. Равно как и мой круг общения.
Ну и олигархов в родне нет. Обычные научные сотрудники (в системе РАН) и преподаватели ВУЗов.
Не везде.
В том же банке, если вы выпустите в прод код, который "случайно" отправит 10 лямов VIP клиента бог знает куда (или просто внезапно обнулит его счет) - у вас будут очень большие проблемы (с большим количеством вполне себе реальных нулей)... И с клиентом и с регулятором.
Если ваш банковский софт как-то проработает год, но в НГ (период пиковых нагрузок) встанет колом - вы будете иметь очень большие проблемы (как репутационные, так и с регулятором, опять же).
Если у вас какая-то система управления, скажем, АЭС, то кривой софт может подарить миру еще один Чернобыль или Фукусиму...
А всякие инет-лабазы торгующие зарядниками для телефонов - там да. Пофиг. Ну обломится клиент с покупкой да и фиг с ним казалось бы...
В рунете вообще очень любят чуть что аппелировать к мифическому "70-летнему пенсионеру из Костромы в пенсией 12тр". Вот сколько было родителей (и тетешек-дядюшек) - ни у кого "12тр" не было. Не сотни тысяч, но на жизнь хватало всем. И не скажу чтобы ежиков без соли кушали.
К слову сказать, жена уже оформила пенсию. чуть менее 60тр получилось. Всю жизнь занималась (ну и сейчас еще работает "вполсвиста") переводами (научная и техническая тематика, в т.ч. патенты - т.е. еще немного юридическое в области патентного права и интеллектуальной собственности), вопросами интеллектуальной собственности и иногда контролем качества (есть сертификат аудитора по качеству). Т.е. просто работала, не чиновничела и не начальничела особо.
В АСке имя объекта, а там все есть объект - и файл (хотя *FILE это просто один из типов объектов) и библиотека (аналог папки в винде) вообще ограничено 10-ю символами. Но у каждого объекта есть свойство TEXT - 50 символов произвольного текста куда можно писать все что угодно (и оно редактируемое).
Ну вот мне АСка тоже очень нравится. И возможностями своими и тем, что она предоставляет разработчику и своей логической и идеологической целостностью и понятностью (сначала непривычно все, начиная от файловой системы которая там вообще не похожа на вин/линукс и концепцией "все есть объект", потом, когда чуть вникнешь в основы, дальше уже все просто и логично ложится одно на другое без зазоров).
И обратно в тот зоопарк вин/линукс я уже точно не хочу (и, надеюсь, не придется уже). Именно в плане разработки.
Дело не в хобби и не в том что сложно.
Делов том, что есть определенный инструмент. И к нему привык - куча паттернов, которые делаются просто на автомате. И вот когда с новой версией все паттерны ломаются т.к. там весь интерфейс перепахали, это сильно снижает производительность на то время когда привыкнешь к новым. То, что раньше делал не задумываясь, теперь думаешь - "а как, черт возьми, это сделать в новой версии?". А когда привыкаешь к новому, тут опять обновление и начинай все сначала...
Все определяется потребностями бизнеса. Где бизнесу надо хоть криво-сыро, но скорее выкинуть на рынок с минимальными затратами - там будет кривое-сырое, но раньше всех. И сеньоров там будет мало - вс будут делать более дешевые джуны и мидлы.
А где для бизнеса важно чтобы оно работало максимально эффективно и цена ошибки в коде выражается крупными финансовыми и репутационными потерями - там все будет совсем иначе.
Реалии жизни в условиях "одноразового потребления" в том, что первого намного больше чем второго. И массовая прибыль делается на первом. А второе уходит в разного рода нишевые сегменты. В результате работать в областях из второго пункта воспринимается как "фу-у, нерелевантный опыт..."
Профессионал не тот, кто умеет писать хороший код, а тот, кто не умеет писать плохой.
Вот тут не надо передергивать. В 70 лет, понятно, делать уже что-то поздно.
Но. В 52(!!!) года я лично резко оторвал опу от дивана. Не до уровня "эмигрировать в Канаду", но поменял работу (хотя далось это тяжеловато). И резко поднял уровень своего благосостояния.
Знаю немало людей в своем окружении, кто сделал это в 30-35 лет. В т.ч. и тех, что уде имеет или ВНЖ или гражданство в европе.
Так что возможность таки есть. Но думать про это надо не в 70 лет, это совершенно точно.
А много вы знаете разработчиков, кто серьезно бы МФ, а потом вернулся бы на Вин/Линукс? Для решения схожих задач...
Я с МФ не работал, работаю с middliware от IBM - IBM i (AS/400). И могу сказать, что в АСке возможностей для разработчика намного больше (и под вин и под линукс работал долго до АСки).
К примеру, достаточно активно используем системные очереди для организации разного рода конвейеров для распараллеливания обработки больших объемов данных. Ни в винде ни в линуксе ничего близко похожего нет.
Есть "очереди сообщений" куда я из программы могу откидывать какие-то трейсы и видеть что там происходит в реальном времени. Опять - в мире вин и линукс такого нет.
Также нет ведущихся системой для каждого задания joblog. Где видно все, что в этом задании происходило. Включая ошибки, исключения и т.п. - если программа упала, то там будет видно почему упала и где именно упала.
Нет системных журналов где журналируются все изменения объектов. На уровне системы. Автоматом. У нас на них работают т.н. "журнальные мониторы" которые отслеживают и анализируют изменения и выполняют необходимые действия.
И такого очень много. И, подозреваю, что на МФ тоже много подобных вещей.
Да, аппаратные терминалы ушли в прошлое. Для IBM i на смену аппаратным 5250 пришли эмуляторы. В т.ч. и гуевые.
Сама IBM дает бесплатный пакет IBM i Access Client Solutions.
Там кроме самого эмулятора 5250 еще очень много всякого полезного - работа со спульниками, работа с IFS ("интегрированная файловая система" - INIX-like подраздел ФС), работа с бд, включая интерактивный SQL который еще и планы запросов рисовать умеет с диагностикой и рекомендациями оптимизатора - очень полезный инструмент для разработчика) и средства администрирования...