Удачи, друзья, попутного вера. Я, как пользователь одной из систем онлайн мед карт, каждый раз открывая сайт для того чтобы посмотреть результаты анализов, всегда с нетерпением ожидаю, какой оригинальной дизайнерской находкой удивят авторы на этот раз. И вроде зашел ведь только по делу, посмотреть, нет ли каких аномалий в показателях крови, а зависаю на десятки минут, наслаждаясь замечательным квизом на тему «попробуй найди свои анализы на этом сайте сегодня». Зато какие креативные находки! Скучно было бы просто взять стандартный шаблон с предсказуемой навигацией, обычными шрифтами и полнейшей банальщиной! Так бы я просто в два клика взял свои анализы и ушел. Надо накретивить, чтобы посетитель зависал надолго. Тем более, выбора у него особо нету, если его поликлиника купила вашу систему. Так что, побольше авторских находок в дизайне сайте! Устраивайте конкурсы на тему кто оригинальнее. Тратьте деньги на организацию, составление программ, отчетов и презентаций о том, как замечательно вы выбираете дизайн. В конце концов, иначе, так ведь эти деньги могут пойти на зарплаты врачам! А что тогда делать отделу маркетинга?
Ну, короче, маркетологи взялись за дело — результат видим. Весьма посредственный, невыразительный дизайн, уровень «фриланз». Сэкономили нормально. Сколько ушло на зарплаты маркетологам, на все эти правильные слова, презентации и отчеты?
Сразу напомнило нетленное.
Ну и еще хочу добавить одну идею. Может Яндекс люди читают или еще кто…
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
Как пользователь, могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
Скажу больше, и многие джависты «хуже знают внутренее устройство, примитивы и шаблоны многопоточности»:-).
Вы путаете ситуацию «хуже знают» с вообще " без знания Java".
Скажем, у меня в BG С++. И я сразу хочу учить Kotlin. В результате, очень быстро все выражается в необходимость изучения Java библиотек и фреймворков и тонких особенностей их использования в Kotlin. При том что в обоих мирах постоянно происходят изменения и следить приходиться за обоими, чтобы быть на уровне. Это дополнительная нагрузка на программиста.
Принципиальным является тот факт, насколько в реальности Kotlin программист может обходиться без знания Java. Насколько я понимаю, в реальности, для энтерпрайз проекта на Kotlin будут нужны люди, которые хорошо знают и Java и Kotlin и особенности их совместного использования.
Из текста не совсем понятно, они вытащили java библиотеки HLLAPI из acs или hod. Я так понимаю, что из acs — там они должны быть, я думаю. А документацию читали из hod. Хоть бы описали процесс подробно, названия библиотек которые нужно брать… Пользы бы от статьи было больше.
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
Я вот наблюдаю следующую корреляцию: чем более некомпетентная в отношении IT компания, тем больше персональных данных они стремятся заполучить.
Думаю, только прямой запрет и высокие штрафы смогут заставить все эти сайты любящие коллекционировать сканы паспортов пользователей отказаться этой практики.
Надежность и стабильность современных систем c IBM i во многом является коммерческой рекламой IBM, а не реальным состоянием дел.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Ну, я уже как-то приводил здесь ссылку на книжку. Если есть интерес, то вот еще раз. Обращаю внимание, что книга во многом устарела, но об этом ниже.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.
Не могу согласиться. Потому что тогда бы все команды OS для всех объектов *FILE можно было бы применять друг к другу, а это не так. Создаются эти объекты разными командами, специфичными для конкретного класса. Например, для создания логического файла используется команда CRTLF, а для дисплейного — CRTDSPF. Если бы было по вашему, то существовала бы единая команда типа CRTFILE, которыой бы создавались все варианты объектов данного класса, и логические файл и физические и дисплейные.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
Там зависит какие операции. Если только отдавать контент, у вас хорошо все горизонтально масштабируется, актуальность не критична — то проблем нет.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
Я думаю, надо принципиально решать насчет продолжения использования 5250, а не пытаться искать заместители DDS. DDS отлично делает свое дело. Пример с результатами SQL запроса притянут искусственно. Пользователям никто не даст запускать непредсказуемые запросы. А тех-персоналу все эти «украшательства» не нужны.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
Так я же пояснил, что крэш может не быть связан с релизом непосредственно. Большинство ошибок релиза вылавливаются еще на этапе PIV.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
Не понимаю суть претензий, они из области этики?
Во-первых, компания вообще никому ничего не должна.
Во-вторых, часто, а в айти особенно, авторы продукта действительно реализуют свое хобби. Не уверен что здесь именно этот случай, но в приципе не вижу проблемы.
В-третьих, за счет бюджета (читай налогоплательщиков) существуют все военные и куча невоенных айти компаний.
Вы не поняли что вам сказали. Себестоимость зависит от объемов. Объемы — от спроса. Поэтому вначале компания может и очень часто будет работать в убыток, чтобы завоевать рынок. Когда возрастут объемы — снизится себестоимость и пойдет прибыль. Сколько на это понадобиться времени — зависит (нередко годы). Но вот чтобы прибыль пошла сразу — это скорее исключение чем правило.
Добавлю, что, конечно, все процессы схожие с описанными выше в компании были, все эскалировалось примерно как вы описали и т.д. Но смысл в том, что ты можешь хоть обписаться процессами и получить 100500 подписей под вашими документами, собрать десятки митингов с менеджерами, админами, разрабабами и т.д. Пока разработчик который знает эту программу не откроет ее в дебаггере на проде и не посмотрит что там в реальности происходит, ничего с места не сдвинется.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Хех, скажу более, такая ситуация совсем нередко встречается. Разрабам приходится встраивать в софт закладки, чтобы в случае чего на проде быстро и в комфортных условиях посмотреть ошибку. Классический случай, когда некая комбинация действий в клиенте открывает консоль.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
Ага. Да. В той истории, как раз оказалось, внезапно, что можно и из дома залогиниться в прод. И, да, работать через расшаренный терминал через цитрикс предлагали.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.
Сразу напомнило нетленное.
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
Вы путаете ситуацию «хуже знают» с вообще " без знания Java".
Скажем, у меня в BG С++. И я сразу хочу учить Kotlin. В результате, очень быстро все выражается в необходимость изучения Java библиотек и фреймворков и тонких особенностей их использования в Kotlin. При том что в обоих мирах постоянно происходят изменения и следить приходиться за обоими, чтобы быть на уровне. Это дополнительная нагрузка на программиста.
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
Думаю, только прямой запрет и высокие штрафы смогут заставить все эти сайты любящие коллекционировать сканы паспортов пользователей отказаться этой практики.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.
При этом, объекты наследуют ряд свойств от базового класса и есть команды применимые ко всем объектам наследующим от *FILE.
Файлы же в свою очередь наследуют от общего класса, и потому WRKOBJ работает не только с файлами но и другими объектами.
В банках же идет суровый OLTP и деньги. Там так просто на кластер не переведешь.
Конечно, это возможно все перевести на PG и т.п. и большинство шопов или уже перевели, или в процессе или задумываются. Но процесс не быстрый и дорогой.
Почему Альфа упорно держится за i… Была хорошая статья по теме, не могу сейчас найти. Там смысл в психологии менеджмента. Менеджерам спокойнее продолжать платить IBM ежегодно предсказуемую сумму (стоимость владения i относительно невелика), чем рисковать затевать миграцию где сразу нужны большие затраты и успех не гарантирован. В больших инертных организациях менеджмент крайне консервативен в данном вопросе. Пока какой-то внешний фактор явно не припрет (типа санкции), никто ответственность на себя брать не будет.
С точки зрения технической, конечно, открытые технологии и стандарты дают гораздо более высокий уровень гибкости и являются предпочтительными.
Из PRG уже давно можно и в HTTP и во что угодно. Не хочется самим делать — есть куча готовых решений на рынке. Самое известное — profoundlogic.
Хотя сама идея поиграться с возможностью напрямую писать в 5250 поток, конечно, интересная.
И в любом случае, разговор же здесь не про время, а про нахождение ошибки. Вот на проде идут крэши. На тесте они не воспроизводятся. Сложность системы такая, что можно очень долго гадать что там и как и реальный действенный способ понять что происходит — это дать доступ разрабам к проду. А откатить релиз который уже давно в проде — ну, попытайтесь получить разрешение ;-). Когда в релизе изменена методика финансового подсчета чего нибудь там по требованию законодательства и циферки уже 3 недели считаются по новой методе. Откатить бд системы в ядре банка на 3 недели тоже? Удачи ;-). Безумству храбрых поем мы песню, как сказал великий писатель.
Во-первых, компания вообще никому ничего не должна.
Во-вторых, часто, а в айти особенно, авторы продукта действительно реализуют свое хобби. Не уверен что здесь именно этот случай, но в приципе не вижу проблемы.
В-третьих, за счет бюджета (читай налогоплательщиков) существуют все военные и куча невоенных айти компаний.
Я не говорю, что это требуется в каждом случае. Если ошибка вопроизводится на деве по логам и дампам, ее конечно можно и будут исследовать там. Но бывает что не воспроизводится.
Более того, ошибка может быть никак не связана с последним релизом. Это может быть древний баг который просто ждал своего часа (наступления некоторой комбинации в данных и действиях пользователя и т.п.). Так что вы очень лихо это априори решили, что откат последнего релиза сразу восстановит систему. Далеко не всегда. Вы бесполезно потратите время на откат, который сам по себе уже может быть проблемой, например когда фичи нового релиза — это требования изменившегося законодательства. Кроме того, откат — не всегда быстрый процесс. Он может быть гораздо дольше чем исследовать проблему и быстро установить фикс.
Т.е. все эти драконовские меры на самом деле ведут к появлению очень мрачных вещей.
Конечно, именно о таком режиме работы по выявлению багов мечтают разработчики :-).
Ребята, зачем разрабу ваш расшаренный ssh терминал через два гейта, если мне нужно подтянуть дебаггер? Разработчику может быть некомфортно работать в терминале, где все настроено строго под выполнение рутинных админских задач по бакапу и т.д. и нет ничего, что разраб использует ежедневно и к чему привык.
По аналогии, я вот свою машину могу вести в любом состоянии с закрытыми глазами кажется. Все действия на автомате, руки сами все делают… Пришлось тут по случаю рулить чужой — я почувствовал себя новичком на площадке. Почему в принципе вы считаете, что админы настолько доверенные люди, что только им позволено, а разрабы могу исключительно через расшаренный экран под пристальным надзором комманды из админов с пальцем на красной кнопке, типа только мышь не туда скользнула — сразу рубим сеть :-).
Насчет вот этих всех авралов… Есть вообще-то трудовое законодательство. И 8-часовой рабочий день. И, потом, проблему можно было спокойно решить в рабочее время.
Потом, вот эти все фантазии, насчет давать внезапно доступ только по инциденту…
Человек в первый раз в жизни зайдет на тот энвайромент — а там все по-другому, чем на его дев машине. Нет привычных комманд, шорткатов, тулов и т.д.
Весь мой опыт говорит — без регулярного опыта работы на проде, сходу, ночью, куча времени будет потрачена на совершенно левые не относящиеся к проблеме вещи.