Совершенно верно, докер большинство используют как систему развертывания, чтобы избежать сложностей с установкой и конфигурацией зависимостей. Одна команда — и тебе поднимается весь готовый эластик без лишней головной боли. В случае некоторых сторонних продуктов и зависимостей это имеет смысл. Но тем не менее для развертывания есть свои тулзы: Chef, Puppet, Terraform, Ansible — докер больше по части виртуализации, которая в большинстве случаев не нужна. На одной хостовой тачке можно поднять кучу процессов — заворачивать каждый в свой контейнер вовсе не обязательно. Многие утверждают, что докер позволяет избежать ада с зависимостями и библиотеками, но во-первых, ОС имеет свой репозиторий и уже как правило предоставляет свежую версию необходимой зависимости, а во-вторых тут есть скрытая угроза в безопасности — контроль над версиями ложится на самих разрабов, которые очень не спешат апдейтить зависимости, пока не случаются проблемы. А контейнер на продакшне сильно затрудняет сторонний security-audit.
У нас в докере поднимается "неубиваемый" кластер из Postgresql, ничего страшного в этом нет. Естественно data-volume-ы замеплены на файловую систему. Тоже compose+swarm. Плюс отдельный контейнер/машина под Elastic. Сервисы деплоятся без контейнеров прямо на тачки при помощи git.
Да, конкретно по томкэту мануалы уже попахивают. Хотя для общего развития полезно ознакомиться с легаси веб стеком джавы (контексты, сервлеты, фильтры, etc). В мире Java сейчас в основном форсят Spring Boot, который (внезапно!) пускает тот же томкэт в embedded-режиме, но никак на него не завязан. На хабре каждая вторая статья в джавовском хабе — это как написать очередной Hello World на спринге с кучей плюшек.
И да, когда контейнеры и кубернетис — это на 90% хайп, ибо сегодня, планируя архитектуру, никто уже не задумывается о необходимости данных тулзов применительно к решаемой задаче. Архитектура большинства систем не настолько сложна, чтобы был необходим промежуточный слой виртуализации и оркестрации сервисов. Контенеризация зачастую излишня: как правило вы выделяете весь виртуальный сервер под конкретный процесс/систему — зачем еще одна операционка внутри другой? Большинство задач оркестрации и сервис дискавери решается средствами самой операционки (либо тупо конфигурационным файлом). Для деплоя и управления обычно хватает ssh. Чуть сложнее инфраструктура или сценарий — есть Ansible. А бездумно пихать микросервисы, k8s и весь девопс в каждый проект, тем самым усложняя себе и другим жизнь, и получая себе на задницу массы новых впечатлений — лишь увеличивает градус неадеквата. Думаю, об этом и была данная статья.
Томкэт по сути это тот же сервер приложений, только урезанный до веба, и который разделяет все его идеи: запускается отдельно от приложения, ресурсы конфигурирются также отдельно, а само приложение пакуется и деплоится на сервак. К сожалению в экосистеме Java томкэт долгое время это был фактически единственным вебсервером, благодаря чему люди стали использовать альтернативные технологии. Однако ситуация уже давным давно поменялась: есть embedded-сервера (https://www.eclipse.org/jetty/), куча хеви и лайтовых фреймворков для веб разработки с минимальным порогом вхождения (https://javalin.io/).
В идеале задумка провайдеров была задвинуть клиенту за монету свой сервер, на который тот бы смог деплоить свои приложения, и они бы там работали, а провайдер собирал бы за лицензию и поддержку. Но концепт быстро устарел: вместо одного сервера с кучей приложений уже одному приложению требовалось несколько серверов для работы. К тому же люди быстро поняли, что концепция деплоить что-то куда-то стала излишней, а все то, что предлагал сервер приложений либо нафиг не нужно, либо неплохо решалось с помощью сторонних библиотек. И расцвел век фреймворков типа спринга. Но империя нанесла ответный удар ввиде контейнеров и кубернетиса. И теперь хомячкам снова требуется все паковать и куда-то деплоить, чтобы оно там работало. А чтобы это не выглядело совсем по-идиотски, клиента убедили самому раздробить свое приложение по частям, а уже платформа возьмет на себя задачу собрать все снова воедино. И все это безобразие назвали хайповым словом "микросервисы".
Весь k8s задуман и продвигается с целью пропаганды в массы cloud-решений. И чтобы клиент даже не задумывался о необходимости данной тулзы для своего проекта. Это как в свое время сервер приложений — некоторые люди реально не представляли как java приложение с вебом может работать вне сервера приложений. Теперь точно также не представляют как деплоить без кубернетиса.
Виной всему существующая бизнес модель, которая не изменилась с 19XX-бородатых годов: мы продаем вам платформу, а вы пишите под нее свой бизнес. Обязательным условием продаваемости был vendor-lock — подсадить клиента на свое решение, чтобы миграция на конкурирующее потребовала значительных расходов. Сначала это были дорогущие мейнфреймы. Затем появились ПК, и расцвел рынок проприетарных настольных и серверных ОС. Затем появились кросс-платформенные технологии, и потребовалась концепция — сервера приложений, которая и по сей день отживает свое в энтерпрайзе. Затем появились фреймворки, научившиеся локально стартовать встроенный вебсервер, и потребовалась новая концепция продаваемой платформы — облако, которая включает в себя хостинг и управление инфраструктурой. Облака активно форсились 10-12 лет назад. Затем развитие виртуализации опять сделало приложения независимыми от поставщика услуг, и провайдеры резко начали форсить концепт микросервисов, DevOps-а и serverless архитектуры, под которыми удобнее продавать API к своим сервисам (PaaS, AaaS). В итоге предпринимаются все рекламные усилия, чтобы никогда не дать приложению развернутся на локальной тачке со всеми своими зависимостями, а сделать некий компот из ненужных сервисов, завязанный на API платформы и продаваемые бизнес-решения.
Не совсем так. На супертурнирах гроссмейстеры используют домашние заготовки. Каждая такая заготовка — десятки часов, проведенных за анализом с компьютером. Так что это своего рода технический допинг. 15-20 лет назад была популярна тема игры человека с компьютером, даже были чемпионаты по Advanced Chess, где каждому игроку предоставлялся компьютер для анализа. И проблема даже не в том, что человек не может поймать компьютера и выиграть партию, а в том, что партий в турнире много, а заготовок с анализом мало, и они очень дорогие. А железка не приемлет договорной ничьи и бьется за каждую партию по-максимуму. Поэтому гроссмейстеры быстро потеряли интерес к таким турнирам — они тупо не оправдываются экономически.
Что же касается компьютеров, то несмотря на постоянно увеличивающуюся мощность, сильное преимущество им это не дает. Во-первых, для увеличения глубины перебора необходим экспоненциальный рост, а во-вторых, современные мощности растут в основном за счет распределенности вычислений, однако шахматная задача очень плохо паралелится. И в-третьих, программы не способны к хорошей оценке позиции и позиционной игре. Делается это намеренно, в угоду глубины перебора.
А смысл шило на мыло? Тот же самый бокс, только на другой технологии виртуализации. В сигивине все приложения пускаются нативно под виндой, поэтому оно легче и быстрее.
Намучился в WSL2 с сеткой и VPN-ами. Дело в том, что я работаю удаленно с разными клиентами, у каждого свой VPN-клиент под винду. Из под WSL пускаю ssh с тунелями. Поначалу все работает, но в какой-то неопределенный момент винда перестает видеть тунели ssh, или наоборот, из WSL не видно машины клиентов.
Первая проблема, в том, что WSL поднимает свой виртуальный интерфейс на динамическом IP, и с сеткой, которая может конфликтовать с VPN-ом. Благо вроде есть способ это настроить. Другая проблема в том, что при отключении VPN клиента иногда че-то происходит с роутингом между этими интерфейсами, и связь межу виндой и WSL обрывается — каждый становится сам по себе. Третья проблема DNS провайдер от VPN не прописывается в WSL. На форумах нет никакой конкретной инфы. Короче, ну ее нахрен — вернулся в Cygwin.
Потому что многие технологии, особенно основанные на AOP требуют, чтобы класс был открытым. Так работает большинство фреймворков и многие библиотеки для тестинга и мокирования. В Котлине последовали советам Фаулера и сделали все классы по дефолту final. Однако это очень сильно помешало тулзам из экосистемы Java. Пришлось придумывать костыли типа allopen.
Поощрение подхода «композиция вместо наследования»
Очень немногие ЯП реально поощряют данный подход. Если в языке нет extension methods или delegates, то любая композиция связана с кучей boilerplate-кода ввиде декораторов и самописных делегатов.
WT плохо приспособлен для multi-window. Хочу в разных окнах пускать Far, WLS, CMD, SSH и различные консольные программы и скрипты, просто щелкнув по значку.
При этом:
В таскбаре есть разные шорткаты для разных консольных программ. Однако при этом все открытые WT-окна группируются в один единственный значок терминала.
Хочу разные цвета для разных консольных программ. Однако из коммандной строки нельзя задать цветовую схему. А создавать на каждый скрипт/программу свой профайл слишком муторно (особенно возиться с гуидами). В идеале хочется, чтобы из коммандной строки можно было бы переопределять любые свойства профайла.
Если профайл hidden, то при запуске из коммандной строки он почему-то не находится, что странно, иначе зачем вообще он нужен.
Как я понял, добавили режим без вкладок, которого не хватало. При этом неплохо бы все же по желанию оставить заголовок, т.е. там часто пишут имя машины, текущую path и другую полезную инфу.
Долгий запуск по сравнению с cmd.exe.
Для консольных приложений Windows (как например Far) не работает мышка.
Иногда бывает относительно абстрактный маппинг, иногда бывают языки со слабой типизацией.
В таком случае семантика интерпретации задается самой программой. Универсальный парсер готовит дерево, не вдаваясь в типы каждого поля, и использует только string. А уже сама программа интерпретирует string-поле в зависимости от того, что она там ожидает.
И после таких утверждений, что нет разницы, true или «true» люди с фамилией Null или номерным знаком NULL начинают испытывать проблемы.
Могу предположить какие дикие батхерты испытывает чел с фамилией Null в цифровом веке :) Однако, если у вас поле "фамилия", так вы и должны интерпретировать ее как string и никак иначе. Особо умные парсеры типа Yaml пытаются оказать медвежью услугу и конвертнуть литерал в наиболее подходящий по их мнению тип. Отсюда и возникают проблемы с null, true и бедной Норвегией. С умными всегда тяжело — никогда не знаешь что от них ожидать :)
Можно придумать такой пример (стырил из nginx):
Это заведомо плохой дизайн, навеяный как раз полутипизированным парсером. Если мы зададимся вопросом, "какой тип будет у данного поля?", то он будет синтетическим: BooleanOrString, что достаточно нетривиально как со стороны юзера, так и со стороны кода. В данном случае гораздо проще и понятнее использовать два связанных поля с enumerated и string типами соответственно:
proxy_redirect: none|auto|host
proxy_redirect_host: url
Важно. Мне это в JSON тоже очень не нравится. Раньше была идея писать /Date(timestamp)/ — но тоже костыль и не прижилось.
Ну вот о чем и речь. В общем случае парсер не знает в какой тип замэпить значение поля, поэтому необходимо предоставлять ему метаданные о структуре документа и типах отдельно от самого документа. Так работают, например, Java-библиотеки типа Jackson и MOXy, которые мепят Json-документ в объекты Java. Поскольку вся информация о типах и структуре записана в классах, парсер знает в какой тип должно мэпится каждое поле. В этом сценарии нативные типы Json абсолютно рудиментарны: зная, что тип поля boolean, парсер одинаково хорошо распарсит значение и true и "true". С таким же успехом эти библиотеки парсят XML и вообще любой формат, где нет никаких boolean ни number.
Отличие true от «true» — это очень важно. Также как и отличия «0042» от 0042.
А отличие Date от строки не очень важно?
тем, что это соглашение для строки.
Т.е. формат json date не соглашение для строки? Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
А я считаю, что вполне могут быть
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить. Задолбаетесь для каждого придумывать собственные кавычки :)
Не путайте разметку документа с его семантикой — это разные вещи. Семантика, т.е. способ интерпретации контента, задает парсер и доменная модель. Поэтому "стандартные" соглашения — это те, которые приняты в данной доменной модели, и на которые настроен парсер. В XML семантика может задаваться схемой, плюс есть технологии, которые из схемы могут генерить доменную модель (JAXB, XMLBeans, etc.). А вот JSON (а потом и его преемник Yaml) — выходец из JavaScript (по сути изначально это был кусок кода на JS), свои слабые типы JS встроили в саму разметку, породив при этом больше боли, чем выгоды: отличие true от "true", 42 от "42" и т.д.
Чаще всего minOccurs=0 и отсутствие тэга интерпретируется как null. Для структур с фиксированным набором полей: nillable=true/xsi:nil="true". Такая же проблема двойственности есть и в Json: не указать тэг или поставить null?
xs:boolean чем не подходит?
maxOccurs='unbounded', для простых типов xs:list.
date, time, dateTime и еще набор на все случаи жизни со стандартизированным форматом
в самой разметке нет и не должно никаких отличий или запахов (flavours), отвечающих за интерпретацию контента (см. выше). В schema же есть широкий набор числовых и кастомных типов.
Ну и бонусом вопрос, в XML правильно игнорировать или ведущие пробелы или нет?
Да. Таким образом убирается зависимость от форматирования документа. Если необходимы пробелы, есть способ сделать через CDATA.
Я могу ошибаться, но без диска в случае, если упадет ELK, все трейсы за период простоя будут потеряны, тогда как в дисковом варианте Filebeat корректно сможет их залить после восстановления работы.
У меня тоже с хибернейтом не сложилось. Известны случаи, где он генерит семантически неправильный SQL, иногда делает странные сторонние вещи, когда его не просят, причем в зависимости от движка базы, до последнего времени криво поддерживал EntityGraph, и после перехода на ByteBuddy стал неимоверно долго стартовать. Поэтому я уже привык использовать EclipseLink.
Совершенно верно, докер большинство используют как систему развертывания, чтобы избежать сложностей с установкой и конфигурацией зависимостей. Одна команда — и тебе поднимается весь готовый эластик без лишней головной боли. В случае некоторых сторонних продуктов и зависимостей это имеет смысл. Но тем не менее для развертывания есть свои тулзы: Chef, Puppet, Terraform, Ansible — докер больше по части виртуализации, которая в большинстве случаев не нужна. На одной хостовой тачке можно поднять кучу процессов — заворачивать каждый в свой контейнер вовсе не обязательно. Многие утверждают, что докер позволяет избежать ада с зависимостями и библиотеками, но во-первых, ОС имеет свой репозиторий и уже как правило предоставляет свежую версию необходимой зависимости, а во-вторых тут есть скрытая угроза в безопасности — контроль над версиями ложится на самих разрабов, которые очень не спешат апдейтить зависимости, пока не случаются проблемы. А контейнер на продакшне сильно затрудняет сторонний security-audit.
У нас в докере поднимается "неубиваемый" кластер из Postgresql, ничего страшного в этом нет. Естественно data-volume-ы замеплены на файловую систему. Тоже compose+swarm. Плюс отдельный контейнер/машина под Elastic. Сервисы деплоятся без контейнеров прямо на тачки при помощи git.
Да, конкретно по томкэту мануалы уже попахивают. Хотя для общего развития полезно ознакомиться с легаси веб стеком джавы (контексты, сервлеты, фильтры, etc). В мире Java сейчас в основном форсят Spring Boot, который (внезапно!) пускает тот же томкэт в embedded-режиме, но никак на него не завязан. На хабре каждая вторая статья в джавовском хабе — это как написать очередной Hello World на спринге с кучей плюшек.
И да, когда контейнеры и кубернетис — это на 90% хайп, ибо сегодня, планируя архитектуру, никто уже не задумывается о необходимости данных тулзов применительно к решаемой задаче. Архитектура большинства систем не настолько сложна, чтобы был необходим промежуточный слой виртуализации и оркестрации сервисов. Контенеризация зачастую излишня: как правило вы выделяете весь виртуальный сервер под конкретный процесс/систему — зачем еще одна операционка внутри другой? Большинство задач оркестрации и сервис дискавери решается средствами самой операционки (либо тупо конфигурационным файлом). Для деплоя и управления обычно хватает ssh. Чуть сложнее инфраструктура или сценарий — есть Ansible. А бездумно пихать микросервисы, k8s и весь девопс в каждый проект, тем самым усложняя себе и другим жизнь, и получая себе на задницу массы новых впечатлений — лишь увеличивает градус неадеквата. Думаю, об этом и была данная статья.
Томкэт по сути это тот же сервер приложений, только урезанный до веба, и который разделяет все его идеи: запускается отдельно от приложения, ресурсы конфигурирются также отдельно, а само приложение пакуется и деплоится на сервак. К сожалению в экосистеме Java томкэт долгое время это был фактически единственным вебсервером, благодаря чему люди стали использовать альтернативные технологии. Однако ситуация уже давным давно поменялась: есть embedded-сервера (https://www.eclipse.org/jetty/), куча хеви и лайтовых фреймворков для веб разработки с минимальным порогом вхождения (https://javalin.io/).
В идеале задумка провайдеров была задвинуть клиенту за монету свой сервер, на который тот бы смог деплоить свои приложения, и они бы там работали, а провайдер собирал бы за лицензию и поддержку. Но концепт быстро устарел: вместо одного сервера с кучей приложений уже одному приложению требовалось несколько серверов для работы. К тому же люди быстро поняли, что концепция деплоить что-то куда-то стала излишней, а все то, что предлагал сервер приложений либо нафиг не нужно, либо неплохо решалось с помощью сторонних библиотек. И расцвел век фреймворков типа спринга. Но империя нанесла ответный удар ввиде контейнеров и кубернетиса. И теперь хомячкам снова требуется все паковать и куда-то деплоить, чтобы оно там работало. А чтобы это не выглядело совсем по-идиотски, клиента убедили самому раздробить свое приложение по частям, а уже платформа возьмет на себя задачу собрать все снова воедино. И все это безобразие назвали хайповым словом "микросервисы".
Весь k8s задуман и продвигается с целью пропаганды в массы cloud-решений. И чтобы клиент даже не задумывался о необходимости данной тулзы для своего проекта. Это как в свое время сервер приложений — некоторые люди реально не представляли как java приложение с вебом может работать вне сервера приложений. Теперь точно также не представляют как деплоить без кубернетиса.
Виной всему существующая бизнес модель, которая не изменилась с 19XX-бородатых годов: мы продаем вам платформу, а вы пишите под нее свой бизнес. Обязательным условием продаваемости был vendor-lock — подсадить клиента на свое решение, чтобы миграция на конкурирующее потребовала значительных расходов. Сначала это были дорогущие мейнфреймы. Затем появились ПК, и расцвел рынок проприетарных настольных и серверных ОС. Затем появились кросс-платформенные технологии, и потребовалась концепция — сервера приложений, которая и по сей день отживает свое в энтерпрайзе. Затем появились фреймворки, научившиеся локально стартовать встроенный вебсервер, и потребовалась новая концепция продаваемой платформы — облако, которая включает в себя хостинг и управление инфраструктурой. Облака активно форсились 10-12 лет назад. Затем развитие виртуализации опять сделало приложения независимыми от поставщика услуг, и провайдеры резко начали форсить концепт микросервисов, DevOps-а и serverless архитектуры, под которыми удобнее продавать API к своим сервисам (PaaS, AaaS). В итоге предпринимаются все рекламные усилия, чтобы никогда не дать приложению развернутся на локальной тачке со всеми своими зависимостями, а сделать некий компот из ненужных сервисов, завязанный на API платформы и продаваемые бизнес-решения.
Не совсем так. На супертурнирах гроссмейстеры используют домашние заготовки. Каждая такая заготовка — десятки часов, проведенных за анализом с компьютером. Так что это своего рода технический допинг. 15-20 лет назад была популярна тема игры человека с компьютером, даже были чемпионаты по Advanced Chess, где каждому игроку предоставлялся компьютер для анализа. И проблема даже не в том, что человек не может поймать компьютера и выиграть партию, а в том, что партий в турнире много, а заготовок с анализом мало, и они очень дорогие. А железка не приемлет договорной ничьи и бьется за каждую партию по-максимуму. Поэтому гроссмейстеры быстро потеряли интерес к таким турнирам — они тупо не оправдываются экономически.
Что же касается компьютеров, то несмотря на постоянно увеличивающуюся мощность, сильное преимущество им это не дает. Во-первых, для увеличения глубины перебора необходим экспоненциальный рост, а во-вторых, современные мощности растут в основном за счет распределенности вычислений, однако шахматная задача очень плохо паралелится. И в-третьих, программы не способны к хорошей оценке позиции и позиционной игре. Делается это намеренно, в угоду глубины перебора.
Отнюдь. Старый тяжелый legacy движок, абсолютно недружественный к пользователю, рассчитанный на постоянное присутствие DBA в системе.
А смысл шило на мыло? Тот же самый бокс, только на другой технологии виртуализации. В сигивине все приложения пускаются нативно под виндой, поэтому оно легче и быстрее.
Намучился в WSL2 с сеткой и VPN-ами. Дело в том, что я работаю удаленно с разными клиентами, у каждого свой VPN-клиент под винду. Из под WSL пускаю ssh с тунелями. Поначалу все работает, но в какой-то неопределенный момент винда перестает видеть тунели ssh, или наоборот, из WSL не видно машины клиентов.
Первая проблема, в том, что WSL поднимает свой виртуальный интерфейс на динамическом IP, и с сеткой, которая может конфликтовать с VPN-ом. Благо вроде есть способ это настроить. Другая проблема в том, что при отключении VPN клиента иногда че-то происходит с роутингом между этими интерфейсами, и связь межу виндой и WSL обрывается — каждый становится сам по себе. Третья проблема DNS провайдер от VPN не прописывается в WSL. На форумах нет никакой конкретной инфы. Короче, ну ее нахрен — вернулся в Cygwin.
Потому что многие технологии, особенно основанные на AOP требуют, чтобы класс был открытым. Так работает большинство фреймворков и многие библиотеки для тестинга и мокирования. В Котлине последовали советам Фаулера и сделали все классы по дефолту final. Однако это очень сильно помешало тулзам из экосистемы Java. Пришлось придумывать костыли типа allopen.
Очень немногие ЯП реально поощряют данный подход. Если в языке нет extension methods или delegates, то любая композиция связана с кучей boilerplate-кода ввиде декораторов и самописных делегатов.
Зашел по хабу "Google Web Toolkit". Судя по аналогичным статьям в том же хабе, далеко не все осознают, что означало это название: https://es.wikipedia.org/wiki/Google_Web_Toolkit
WT плохо приспособлен для multi-window. Хочу в разных окнах пускать Far, WLS, CMD, SSH и различные консольные программы и скрипты, просто щелкнув по значку.
При этом:
В таком случае семантика интерпретации задается самой программой. Универсальный парсер готовит дерево, не вдаваясь в типы каждого поля, и использует только string. А уже сама программа интерпретирует string-поле в зависимости от того, что она там ожидает.
Могу предположить какие дикие батхерты испытывает чел с фамилией Null в цифровом веке :) Однако, если у вас поле "фамилия", так вы и должны интерпретировать ее как string и никак иначе. Особо умные парсеры типа Yaml пытаются оказать медвежью услугу и конвертнуть литерал в наиболее подходящий по их мнению тип. Отсюда и возникают проблемы с null, true и бедной Норвегией. С умными всегда тяжело — никогда не знаешь что от них ожидать :)
Это заведомо плохой дизайн, навеяный как раз полутипизированным парсером. Если мы зададимся вопросом, "какой тип будет у данного поля?", то он будет синтетическим: BooleanOrString, что достаточно нетривиально как со стороны юзера, так и со стороны кода. В данном случае гораздо проще и понятнее использовать два связанных поля с enumerated и string типами соответственно:
proxy_redirect: none|auto|host
proxy_redirect_host: url
Ну вот о чем и речь. В общем случае парсер не знает в какой тип замэпить значение поля, поэтому необходимо предоставлять ему метаданные о структуре документа и типах отдельно от самого документа. Так работают, например, Java-библиотеки типа Jackson и MOXy, которые мепят Json-документ в объекты Java. Поскольку вся информация о типах и структуре записана в классах, парсер знает в какой тип должно мэпится каждое поле. В этом сценарии нативные типы Json абсолютно рудиментарны: зная, что тип поля boolean, парсер одинаково хорошо распарсит значение и true и "true". С таким же успехом эти библиотеки парсят XML и вообще любой формат, где нет никаких boolean ни number.
А отличие Date от строки не очень важно?
Т.е. формат json date не соглашение для строки? Вообще сериализация и десериализация подразумевает сохранение значений в текстовой или бинарной форме. Любое примитивное значение так или иначе мепится в строку.
То, что вам в JS оставили boolean и еще пару примитивных типов, и на базе которых склепали JSON, совсем не значит, что в нормальных ЯП нет других примитивных (и кастомных) типов, которые тоже надо как-то мэппить. Задолбаетесь для каждого придумывать собственные кавычки :)
Не путайте разметку документа с его семантикой — это разные вещи. Семантика, т.е. способ интерпретации контента, задает парсер и доменная модель. Поэтому "стандартные" соглашения — это те, которые приняты в данной доменной модели, и на которые настроен парсер. В XML семантика может задаваться схемой, плюс есть технологии, которые из схемы могут генерить доменную модель (JAXB, XMLBeans, etc.). А вот JSON (а потом и его преемник Yaml) — выходец из JavaScript (по сути изначально это был кусок кода на JS), свои слабые типы JS встроили в саму разметку, породив при этом больше боли, чем выгоды: отличие true от "true", 42 от "42" и т.д.
Да. Таким образом убирается зависимость от форматирования документа. Если необходимы пробелы, есть способ сделать через CDATA.
Дедушка XML: "Шли бы вы оба к себе в песочницу, детки!"
Нельзя писать коментарии, так что как конфигурация Json сразу отпадает. Это тупо формат сериализации данных.
Объясните дедушке, старый добрый Factory уже вышел из моды или недостаточно технологично?
Я могу ошибаться, но без диска в случае, если упадет ELK, все трейсы за период простоя будут потеряны, тогда как в дисковом варианте Filebeat корректно сможет их залить после восстановления работы.
У меня тоже с хибернейтом не сложилось. Известны случаи, где он генерит семантически неправильный SQL, иногда делает странные сторонние вещи, когда его не просят, причем в зависимости от движка базы, до последнего времени криво поддерживал EntityGraph, и после перехода на ByteBuddy стал неимоверно долго стартовать. Поэтому я уже привык использовать EclipseLink.