Весь 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.
Если глобально, то в дизайне IO-стримов в Java. А конкретно этом случае виноват Logback. В Java нигде не говорится, что циклические ссылки невозможны или некорректны. Она не дает создать только прямую ссылку на само исключение через ex.addSuppressed(ex), а транзитивные возможны. К тому же остальные логгеры отрабатывают корректно.
Apache VFS в случае, если рвалась сессия SFTP, кешировал это исключение и кидал его на все последующие вызовы write(), что впринципе корректно. Но поскольку в close() Apache VFS еще производил запись (типа установить атрибуты удаленного файла), то в случае ошибки блок try-with-resources добавлял к suppressed то же самое закешированное исключение, что вызывало цикличность. Как-то так.
P.S. Вот Apache VFS реально плохо задизайнена. Там дофига подводных камней, один из которых — привязка ресурсов к ThreadLocal. То есть если вы открываете ресурс в одном треде, пишите или закрываете в другом, то у вас происходит утечка памяти, которая в нашем случае стабильно приводила к OutOfMemoryError.
Потому что данный тип исключения с циклической ссылкой генерировался библиотекой Apache VFS в очень специфическом случае — когда upload файла фейлился на OutputStream.close(). В остальных случаях, когда соединение рвалось на OutputStream.write(), в т.ч. и на интеграционных тестах, все отрабатывало без проблем. В то время у клиента по ночам возникали проблемы с инфраструктурой, и данный баг время от времени редко, но вылезал.
Весь 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.
Если глобально, то в дизайне IO-стримов в Java. А конкретно этом случае виноват Logback. В Java нигде не говорится, что циклические ссылки невозможны или некорректны. Она не дает создать только прямую ссылку на само исключение через ex.addSuppressed(ex), а транзитивные возможны. К тому же остальные логгеры отрабатывают корректно.
Apache VFS в случае, если рвалась сессия SFTP, кешировал это исключение и кидал его на все последующие вызовы write(), что впринципе корректно. Но поскольку в close() Apache VFS еще производил запись (типа установить атрибуты удаленного файла), то в случае ошибки блок try-with-resources добавлял к suppressed то же самое закешированное исключение, что вызывало цикличность. Как-то так.
P.S. Вот Apache VFS реально плохо задизайнена. Там дофига подводных камней, один из которых — привязка ресурсов к ThreadLocal. То есть если вы открываете ресурс в одном треде, пишите или закрываете в другом, то у вас происходит утечка памяти, которая в нашем случае стабильно приводила к OutOfMemoryError.
Потому что данный тип исключения с циклической ссылкой генерировался библиотекой Apache VFS в очень специфическом случае — когда upload файла фейлился на OutputStream.close(). В остальных случаях, когда соединение рвалось на OutputStream.write(), в т.ч. и на интеграционных тестах, все отрабатывало без проблем. В то время у клиента по ночам возникали проблемы с инфраструктурой, и данный баг время от времени редко, но вылезал.
Классику даже не упоминаем :)