Не будет стоить дешевле и тем более не на несколько порядков.
Наоборот, будет дороже и больнее. Стек RPG-DB2/400-OS/400 работает как часики, и писать бизнес логику в нем одно удовольствие. Вот переписывание на java займет действительно на порядки больше и времени и денег.
Поддержка as400 будет требовать меньше людей чем поддержка аналогичной функциональности на java.
Задумайтесь, ведь никто не запрещает писать на java для as400. Там есть отличная, оптимизированная JVM. Только не пишут особенно бизнес логику. А все потому, что на RPG проще и быстрее.
Насчет того, почему в банках (и не только банках) до сих пор стоят «динозавры», я объяснил в другом комментарии.
Голубые гиганты не перестанут получать прибыль на «зеленых экранах» еще долго. Хотя, экраны уже давно могут быть не зелеными, а какими угодно.
Такое чувство, что в Альфе вообще не осталось никого, кто профессионально работает на as400. Пришла какая-то комманда пионеров-хипстеров и начала «креативить».
На самом деле изобретали велосипед. В pcom есть библиотека, в которой с древних времен нв VB отлично пишутся любые экранные скрипты. Не нравится VB — можно через обертку на питоне, например. Не нравится вин — есть бесплатная опенсоурсная реализация tn5250, где опять же имеется API.
Если не нравиться jt400, есть отличная опенсоурсная альтернатива (опять же от IBM).
Вообще, лет 20 назад, мне предлагали работать в альфе как раз в команде as400. Но платили что-то не очень, так что не срослось. Интересно, там ведь еще остались люди, пишущие на RPG и все вот это вот? Или все уже на пенсии?
ASN.1 — годный протокол. Пакует более эффективно чем имеющиеся альтернативы (например протобуф). А все потому, что позволяет более детально описывать типы и соответственно более эффективно их паковать.
Но проблема с отсутствием надежного бесплатного компилятора. Платных компиляторов индустриального уровня всего два. И они не дешевые. И проблема с их использованием даже не в том, чтобы купить в вашей организации. Проблема, что если задействовать протокол, то все партнеры должны будут тоже купить. Потому что «в ручную» писать разбор — это дорого и больно. И поэтому — протобуф.
Меня, как программиста, такая постановка вопроса, когда нужно выдать сроки и подпись поставить, давно не смущает. Если менеджер туп, то что поделать. Я вбиваю такой срок, на котором мне будет спокойно — хорошее такое резервирование, многократное ;-). А если появится свободное время, его всегда можно с пользой и интересно потратить на вылизывание кода. Качество результата от этого только повышается.
Если начальник свой человек и понимает, что программирование — не укладка кирпичей, а скорее, бурение, то да, при доверительных отношениях все делается очень быстро и эффективно. Но это только в случае, если есть доверительные отношение и я могу рассчитывать на понимание именно как специалиста. Потому что дело здесь даже не в прикрытии жопы, а в том, что есть разница между «затянул по дурости или неопытности» и «наткнулся на реальную проблему, потратил время, но решил». Если начальник не в состоянии оценить разницу, мне работать с ним доверительно будет трудно.
Если вам нравится мапить мышкой, то в Мule есть графический мапер. Гораздо удобнее и легче. Кроме того, язык DW мощнее гораздо.
Прелесть Мulе в том, что все реализовано с одной стороны гораздо проще, а с другой, по-человечески удобнее и есть выбор. Хочешь мапь в GUI, хочешь — пиши код. Это только один пример.
До боли знакомые картинки. Пользовался последний раз лет 10 назад. Ничего не изменилось в интерфейсе :-). С тех пор перешли на Mule и забыли об этом ужасе. Надеюсь навсегда.
Я все же не совсем понимаю, зачем нужен этот наворот в случае такси? В случае кассы — понятно. Там может прийти несколько платежей и не ясно, так действительно хотели или это дубль. Ну так для этих случаев финансисты с древних времен используют всякие дополнительные идентификаторы транзакций, задолго до того как появился REST.
А вот случае такси, как такое возможно? Что мешает сделать уникальный ключ в таблице по клиенту, from, to, и доверься надежности БД? Если insert прошел — ок. Если нет — ошибка -дубликат. Про мульти заказ не понятно тоже. Если подразумевается заказ на разные адреса, это это просто два разных заказа. Если по одному маршруту — так это просто атрибут типа автомобиля в одном заказе (типа сколько человек надо перевезти). Можно чтобы мини бас приехал и всех забрал, а можно чтобы одна или несколько машин. Клиенту это параллельно. Ему важно сколько человек должны уехать.
«Да, для всех, кто пользуется мессенджерами не вошедшими в этот список»
И какой же процент таких пользователей мессенжеров? Он исчезающе мал.
Я не думаю, что роскомнадзор, или кто там в РФ этим заведует, заботят маргиналы пользующиеся чем-то таким. Так что можете спать спокойно.
Мда, читаешь и радуешься за ВТБ. Особенно порадовало вот это «допустим, продуктовое подразделение хочет немедленно разместить информацию о новом продукте. Присылает по почте запрос контент-менеджеру: «коллеги, нам нужно разместить вот эту статью»».
Надо видимо завершить кейс, «а контент менеджер по почте и отвечает...». Завязалась неспешная переписка между менеджерами в уютном банковском офисе…
Все таки я не понял про «уходит один из столпов». Большинство популярных мессенджеров и так требует подтверждения номера мобильного при регистрации. Так что закон ничего не меняет практически. Напомнило классику:
Маленький принц оглянулся — нельзя ли где-нибудь сесть, но
великолепная горностаевая мантия покрывала всю планету. Пришлось стоять,
а он так устал… и вдруг он зевнул.
— Этикет не разрешает зевать в присутствии монарха, — сказал
король. — Я запрещаю тебе зевать.
— Я нечаянно, — ответил Маленький принц, очень смущенный. — Я долго
был в пути и совсем не спал…
— Ну, тогда я повелеваю тебе зевать, — сказал король. — Многие
годы я не видел, чтобы кто-нибудь зевал. Мне это даже любопытно. Итак,
зевай! Таков мой приказ.
— Но я робею… я больше не могу… — вымолвил Маленький принц и
весь покраснел.
— Гм, гм… Тогда… Тогда я повелеваю тебе то зевать, то…
Король запутался и, кажется, даже немного рассердился.
Ведь для короля самое важное — чтобы ему повиновались
беспрекословно. Непокорства он бы не потерпел. Это был абсолютный
монарх. Но он был очень добр, а потому отдавал только разумные
приказания.
«Если я повелю своему генералу обернуться морской чайкой, — говаривал он, — и если генерал не выполнит приказа, это будет не его
вина, а моя».
— Можно мне сесть? — робко спросил Маленький принц.
— Повелеваю: сядь! — отвечал король и величественно подобрал
одну полу своей горностаевой мантии.
Но Маленький принц недоумевал. Планетка такая крохотная. Чем же
правит этот король?
— Ваше величество, — начал он, — могу ли я вас спросить…
— Повелеваю: спрашивай! — поспешно сказал король.
— Ваше величество… чем вы правите?
— Всем, — просто ответил король.
Вот кто так пишет? Кто такой «пользователь МВД» в заголовке «На «Вконтакте» подали в суд за выдачу личных данных пользователя МВД».
Или как понять вот это выражение: "… запрос белгородской полиции данных"? В Белгороде есть какая-то «полиция данных»?
Если проблемы с падежами, ну, пишите на английском. Там падежей нет.
Ну а вообще, приоритет универсальности спецификации API далеко не всегда оправдан.
На самом деле, автор исходит из посылки, что изменение API — это сильно больнее сложности.
На практике, я часто вижу примеры, когда перебарщивают с универсальностью, порождая сложность. А потом оказывается, что эта универсальность не так уж и нужна. Зато сколько времени потрачено на вылизывание всяких гипотетических кейсов от тестеров, когда шлются дикие комбинации параметров, которые ломают логику, и тестеры радостно кричат «Ага!». Когда запрос четко валидируется на на уровне схемы и мапится в статику, это делает API сильно проще и надежнее. А добавить поле в ответ — ну, отрефакторим. Если нормально налажена работа в команде и бэкенд не пребывает в состоянии холодной войны с фронтендом, то никакой драмы. Ну и версионирование никто не отменял.
Ну, все равно получается избыточность. Если для include, то понятно. Но если не указывать тип, можно предположить что поля для того же объекта, что и запрос. Т.е. мне лично такой синтаксис кажется избыточным. Я бы сделал что-то типа:
GET /articles?fields=title&include=authors&fields[author]=id,name
Наоборот, будет дороже и больнее. Стек RPG-DB2/400-OS/400 работает как часики, и писать бизнес логику в нем одно удовольствие. Вот переписывание на java займет действительно на порядки больше и времени и денег.
Поддержка as400 будет требовать меньше людей чем поддержка аналогичной функциональности на java.
Задумайтесь, ведь никто не запрещает писать на java для as400. Там есть отличная, оптимизированная JVM. Только не пишут особенно бизнес логику. А все потому, что на RPG проще и быстрее.
Голубые гиганты не перестанут получать прибыль на «зеленых экранах» еще долго. Хотя, экраны уже давно могут быть не зелеными, а какими угодно.
На самом деле изобретали велосипед. В pcom есть библиотека, в которой с древних времен нв VB отлично пишутся любые экранные скрипты. Не нравится VB — можно через обертку на питоне, например. Не нравится вин — есть бесплатная опенсоурсная реализация tn5250, где опять же имеется API.
Если не нравиться jt400, есть отличная опенсоурсная альтернатива (опять же от IBM).
Вообще, лет 20 назад, мне предлагали работать в альфе как раз в команде as400. Но платили что-то не очень, так что не срослось. Интересно, там ведь еще остались люди, пишущие на RPG и все вот это вот? Или все уже на пенсии?
Но проблема с отсутствием надежного бесплатного компилятора. Платных компиляторов индустриального уровня всего два. И они не дешевые. И проблема с их использованием даже не в том, чтобы купить в вашей организации. Проблема, что если задействовать протокол, то все партнеры должны будут тоже купить. Потому что «в ручную» писать разбор — это дорого и больно. И поэтому — протобуф.
Если начальник свой человек и понимает, что программирование — не укладка кирпичей, а скорее, бурение, то да, при доверительных отношениях все делается очень быстро и эффективно. Но это только в случае, если есть доверительные отношение и я могу рассчитывать на понимание именно как специалиста. Потому что дело здесь даже не в прикрытии жопы, а в том, что есть разница между «затянул по дурости или неопытности» и «наткнулся на реальную проблему, потратил время, но решил». Если начальник не в состоянии оценить разницу, мне работать с ним доверительно будет трудно.
Прелесть Мulе в том, что все реализовано с одной стороны гораздо проще, а с другой, по-человечески удобнее и есть выбор. Хочешь мапь в GUI, хочешь — пиши код. Это только один пример.
А вот случае такси, как такое возможно? Что мешает сделать уникальный ключ в таблице по клиенту, from, to, и доверься надежности БД? Если insert прошел — ок. Если нет — ошибка -дубликат. Про мульти заказ не понятно тоже. Если подразумевается заказ на разные адреса, это это просто два разных заказа. Если по одному маршруту — так это просто атрибут типа автомобиля в одном заказе (типа сколько человек надо перевезти). Можно чтобы мини бас приехал и всех забрал, а можно чтобы одна или несколько машин. Клиенту это параллельно. Ему важно сколько человек должны уехать.
И какой же процент таких пользователей мессенжеров? Он исчезающе мал.
Я не думаю, что роскомнадзор, или кто там в РФ этим заведует, заботят маргиналы пользующиеся чем-то таким. Так что можете спать спокойно.
Надо видимо завершить кейс, «а контент менеджер по почте и отвечает...». Завязалась неспешная переписка между менеджерами в уютном банковском офисе…
Или как понять вот это выражение: "… запрос белгородской полиции данных"? В Белгороде есть какая-то «полиция данных»?
Если проблемы с падежами, ну, пишите на английском. Там падежей нет.
На самом деле, автор исходит из посылки, что изменение API — это сильно больнее сложности.
На практике, я часто вижу примеры, когда перебарщивают с универсальностью, порождая сложность. А потом оказывается, что эта универсальность не так уж и нужна. Зато сколько времени потрачено на вылизывание всяких гипотетических кейсов от тестеров, когда шлются дикие комбинации параметров, которые ломают логику, и тестеры радостно кричат «Ага!». Когда запрос четко валидируется на на уровне схемы и мапится в статику, это делает API сильно проще и надежнее. А добавить поле в ответ — ну, отрефакторим. Если нормально налажена работа в команде и бэкенд не пребывает в состоянии холодной войны с фронтендом, то никакой драмы. Ну и версионирование никто не отменял.
GET /articles?fields=title&include=authors&fields[author]=id,name