поэтому угрозы остаться без x86 нет, а вот Power вырубят запросто. и будет ситуация сисменс #2
Ну вот когда гром грянет тогда и будем креститься.
А прямо сейчас есть возможность эксплуатировать в разы более эффективный RISC.
Какая разница сейчас переводить на x86 приложения или когда гипотетические RISC закроют санкциями?
И что случиться? По кнопке отключат процессоры уже проданные?
Переезд нервы потрепит конечно. Но если сегодня можно эксплуатировать лучшее решение то зачем вы бежите впереди паровоза и предлагаете отказаться от RISC уже сейчас, до санкций? В чем тайный смысл?
У graphql в принципе все по набору фич очень похоже на OpenAPI. Но разница в том, что если программно был описан объект Х, для него уже готова документация, входные параметры типа Х будут валидироваться на полное соответсвие (что немаловажно для языков без строгой типизации).
Все равно не понял.
В OpenAPI вы можете (да так часто и делают для удобства разработчиков фронтенда) задействовать веб-сервер, который распарзит описание API и отдаст его в не очень красиво оформленной страничке.
И даст поиграться с API даже безо всякого curl, то есть прямо с этой страницы.
Моя мечта начать использовать graphql, который тоже REST, но не RESTAPI. С моей точки зрения graphql имеет уникальные перимущества которе не может дать на сегодняшний день ни одна другая система.
GraphQL хорош когда вы сами не знаете что хотите.
Вы просто получаете универсальный язык запросов.
Проблема на 80% является средствием использования разных кривых инструментов.
Так уж сложилось, что программистами в этом мире являются и еще другие люди, кроме вас, идеального программиста.
Вместо того, чтобы хаять других, авторы Докера просто решили проблему. Программа не выпускается за пределы контейнера.
А хаять других не помогает — ведь постоянно новые программисты появляются.
Просто скоро мы придем к тому, что появятся обертки над Докером, у которого со временем свои приколы вылезут и с версиями и с еще чем-то там. А первопричина проблем так и останется.
Ну а вы что предлагаете?
Расстреливать за «кривую программу»?
Кто кривизну будет определять?
Не боитесь, что в каких то условиях и ваша программа будет менее прямой, чем у большинства?
С моей точки зрения graphql имеет уникальные перимущества которе не может дать на сегодняшний день ни одна другая система. Программный код и документация связаны и никогда не могут рассогласоваться
Поясните.
По мне так это уже давно норма.
И не вижу чтобы конкретна эта технология тут чем то особенным выделялась.
Чем больше разбираюсь с Docker тем сильнее начинает казаться, что это просто костыль такой являющийся следствием:
1. Крайне плохой совместимости диструтивов между собой
2. Стремлением бездумно писать софт таская с собой десятки либ разных версий. И очень часто из-за того, чтобы из огромной либы вызывать лишь один метод.
В итоге приложение-уродец без докера ну никак не заработает.
Нормально спроектированному софту никакие докеры не нужны.
DLL Hell или как там оно называется в Unix — существовал за много десятилетий до Докера.
Докер просто предлагает кардинальный способ решения проблемы и предоставляет для этого универсальный инструмент.
Ну во первых проблема не столько в различных дистрибутивах, а в в их различные поколения. Типичная проблема: в одном приложении библиотека aaa.so требуется версии 1.31 и не выше, а другом приложении так же aaa.so, но не ниже 1.33. И эта проблема возникает на одном и том же дистрибутиве запросто.
Вот вторых вы не можете написать все ПО всего мира. Типичный серверный проект (а Докер прежде всего для серверов решение) — скорее всего будет использовать кучу не написанного Вами лично ПО. Помимо вашего собственного.
С Докером мы просто получаем то, что могли бы получить если бы программисты писали код строго по правилам — то есть получаем софт, который смотрит в мир жестко определенным портом и пишет на диск в жестко определенное место. И никому не мешает. Все остальное — сочетать этот софт друг с другом — это уже задача админа.
Собственно в современных средствах написани программ также предпринято попытки создавать программы без Докера и без проблемы с зависимостями. Например Go/golang представляет из себя единственный бинарный файл, который может запускаться на любой системе (разумеется бинарный файл должен соответствовать классу системы 32/64 бита, Linux, FreeBSD, Windows, MacOSX). На конкретный дистрибутив операционной системе Go плевать.
Докер же пытается решить эту проблему более глобально — для любого ПО. Независимо от того, сколько дополнительных файлов нужно этому ПО для работы. Строго говоря, подход Докера соответствует подходу заказчиков — наплевать что там внутри, пусть программисты извращаются как хотят, если им так удобнее, если так лучше для дела. Но это должно работать.
Мне кажется немного запутанно получилось со Swagger и OpenAPI. По всей видимости имелась ввиду сама спецификация Swagger Specification, которая сейчас действительно называется OpenAPI Specification
Наверное, автор слишком уж "в теме" и не отдает себе отчет, что для новичков в этом вопросе не очевидно:
Изначально это был Swagger
но уже 2 года как переименован в OpenAPI.
Тем не менее осталось куча упоминаний о старом названии (например, в названии инструментов, например, существуют и сайт Swagger и сайт OpenAPIs)
Ну вот когда гром грянет тогда и будем креститься.
А прямо сейчас есть возможность эксплуатировать в разы более эффективный RISC.
Какая разница сейчас переводить на x86 приложения или когда гипотетические RISC закроют санкциями?
И что случиться? По кнопке отключат процессоры уже проданные?
Переезд нервы потрепит конечно. Но если сегодня можно эксплуатировать лучшее решение то зачем вы бежите впереди паровоза и предлагаете отказаться от RISC уже сейчас, до санкций? В чем тайный смысл?
6 сервисов?
Всегда считал что это называется сервисы.
А микросервисы — это помельче подробить надо и побольше из сделать. Штук 20 в данной задаче.
Вот тогда их и можно будет назвать микросервисами.
В Нидерландах они дорогие не из за качества только а из за законов. Что можно все
Начальству, уверяю тебя, пофиг, пока ты приносишь прибыль.
Другое дело что не каждый за 8 часов и зарплату окупит свою
Почему 8?
Потому что сто или сколо там лет назад рабочие выбили себе это как стандартное рабочее время?
Все равно не понял.
В OpenAPI вы можете (да так часто и делают для удобства разработчиков фронтенда) задействовать веб-сервер, который распарзит описание API и отдаст его в не очень красиво оформленной страничке.
И даст поиграться с API даже безо всякого curl, то есть прямо с этой страницы.
GraphQL хорош когда вы сами не знаете что хотите.
Вы просто получаете универсальный язык запросов.
Где его только нет.
В том же OpenAPI/Swagger, Python, Go — да где угодно.
Так уж сложилось, что программистами в этом мире являются и еще другие люди, кроме вас, идеального программиста.
Вместо того, чтобы хаять других, авторы Докера просто решили проблему. Программа не выпускается за пределы контейнера.
А хаять других не помогает — ведь постоянно новые программисты появляются.
Ну а вы что предлагаете?
Расстреливать за «кривую программу»?
Кто кривизну будет определять?
Не боитесь, что в каких то условиях и ваша программа будет менее прямой, чем у большинства?
Поясните.
По мне так это уже давно норма.
И не вижу чтобы конкретна эта технология тут чем то особенным выделялась.
Более того: это могут быть разные языки программирования
DLL Hell или как там оно называется в Unix — существовал за много десятилетий до Докера.
Докер просто предлагает кардинальный способ решения проблемы и предоставляет для этого универсальный инструмент.
Ну во первых проблема не столько в различных дистрибутивах, а в в их различные поколения. Типичная проблема: в одном приложении библиотека aaa.so требуется версии 1.31 и не выше, а другом приложении так же aaa.so, но не ниже 1.33. И эта проблема возникает на одном и том же дистрибутиве запросто.
Вот вторых вы не можете написать все ПО всего мира. Типичный серверный проект (а Докер прежде всего для серверов решение) — скорее всего будет использовать кучу не написанного Вами лично ПО. Помимо вашего собственного.
С Докером мы просто получаем то, что могли бы получить если бы программисты писали код строго по правилам — то есть получаем софт, который смотрит в мир жестко определенным портом и пишет на диск в жестко определенное место. И никому не мешает. Все остальное — сочетать этот софт друг с другом — это уже задача админа.
Собственно в современных средствах написани программ также предпринято попытки создавать программы без Докера и без проблемы с зависимостями. Например Go/golang представляет из себя единственный бинарный файл, который может запускаться на любой системе (разумеется бинарный файл должен соответствовать классу системы 32/64 бита, Linux, FreeBSD, Windows, MacOSX). На конкретный дистрибутив операционной системе Go плевать.
Докер же пытается решить эту проблему более глобально — для любого ПО. Независимо от того, сколько дополнительных файлов нужно этому ПО для работы. Строго говоря, подход Докера соответствует подходу заказчиков — наплевать что там внутри, пусть программисты извращаются как хотят, если им так удобнее, если так лучше для дела. Но это должно работать.
Наверное, автор слишком уж "в теме" и не отдает себе отчет, что для новичков в этом вопросе не очевидно:
Изначально это был Swagger
но уже 2 года как переименован в OpenAPI.
Тем не менее осталось куча упоминаний о старом названии (например, в названии инструментов, например, существуют и сайт Swagger и сайт OpenAPIs)