CJON устраняет кавычки, скобки и пробелы, тем самым экономя от 30% до 50% символов;
YAML делает тоже самое, при этом оставаясь читаемым для человека.
Не уверен, что CJON способен сравниться по читаемости с JSON или YAML даже близко. Давайте попробуем рассмотреть реальные prod-like примеры, а не "на кошках".
Ну а если готовы жертвовать читаемостью в угоду размера и скорости серилизации, то не вижу причин не использовать бинарные форматы вроде protobuf или avro
Из любого правила есть исключения и любое решение это взвешивание и поиск компромиссов. В первую очередь мы стремимся к тому чтобы код было легко читать и как этого достигнуть можно сказать только в каждой конкретной ситуации.
То, о чем я говорю работает в общем случае, но конечно не в 100% случаев.
Для сложной алгоритмики или убивания абстракций / использования низкоуровневых элементов языка ради оптимизации имеет смысл и верхнеуровнево описывать "что". Но только на более высоком уровне абстракции чем непосредственно код. Условно не "делаем X, проверяем Z, делаем Y", а решаем задачу A путём применения X и затем Y для результатов удовлетворяющих условию Z".
Часто хорошим маркером читаемости кода является ревью своего же кода на следующий день после написания
Я всегда всем объясняю так: если ты пишешь комментарий, который отвечает на вопрос "как?" Или "что?", то вместо этого перепиши код, чтобы было понятно что он делает без комментариев.
А вот вопросы "зачем?", "почему?" и "для чего?" это именно то что кодом никак не выразить и требуется раскрывать комментариями.
Код сам должен описывать то что он делает. Но намерения и цели код не опишет. Иногда критически важно понять почему конкретный код находится именно здесь и делает именно это.
Ещё хороший поинт - если тебе на ревью задают вопрос "почему ты сделал так" - писать комментарии вместо объяснения в тредах пулл-реквеста.
Ещё более важный вопрос "почему именно так, а не иначе?"
Насчёт MDC там не так все радужно, на самом деле. API ScopedValue подразумевает, что хранимое значение неизменяемо и может быть только переопределено во вложенных скоупах.
А MDC внутри содержит HashMap, соответственно там между сабтасками может быть неразбериха (если они пишут в MDC).
Я как-то экспериментировал и писал адаптеры для MDC и SpringSecurity для поддержки StructuredScope и ScopedValues (чтобы код оставался таким же простым как в примерах из JEP) и (не знаю как сейчас, может за год изменилось что) там все равно нужно было писать обёртку, чтобы каждая подзадача получила свою копию MDC, либо гарантировать что в подзадаче никогда не будет вызываться MDC.put, а только та его версия, что использует стек внутри.
Я бы отметил такой момент: лучше не использовать классы LocalDateTime в сущностях и DTO. То, как они сериализуются зависит от таймзоны сервера или настроек jdbc драйвера + позволяет без явного указания таймзоны получать дату, что чревато ошибками в приложениях которые работают в нескольких таймзонах (как правило, вы сперва думаете что ваше приложение маленькое и всё ок, а потом возникает необходимость поддержать пользователей из разных таймзон и вылезают разные неприятные ошибки).
Лучше всего использовать Instant или OffsetDateTime. Для передачи по REST и стерилизации использовать стандарт ISO-8068, а для хранения в БД тип TIMESTAMP WITH TIMEZONE, тогда драйвер тоже сам разберётся в как передавать дату и время и не будет ошибок.
А если нужно получить только дату или только время - явно конвертировать в целевую таймзону которая имеет значение с точки зрения бизнес-логики.
Блин, это конечно хорошо, но по заголовку я ожидал что, наконец-то, добавили возможность работы с асинхронным кодом/корутинами/webflux. А так получается if/else - наше всё
Хочется ответить: https://github.com/kelseyhightower/nocode
А если серьезно: не умеете использовать инструмент, не используйте. Половина описаных проблем касается не Ангуляра, а клиентской разработки в целом. И Ангуляр, при правильном подходе, вполне себе успешно их решает абсолютно прозрачным для разработчика способом.
Недавно настраивал у себя окружение для работы с Android и заметил интересную особенность (сейчас нет ноута под рукой, не могу назвать конкретные названия технологий и параметры): у меня на ноутбуке ASUS s46сb (intel core i7 U серии, кажется четвертого поколения) виртуализация, используемая эмуляторами Android конфликтует с виртуализацией, используемой докером. Если в биосе выставлены настройки для работы докера — стандартный эмулятор выдает ошибку с просьбой отключить данные настройки, а запуск Genymotion попросту приводит к BSOD. И, соответственно, если выставить настройки для работы эмуляторов — не стартует докер. К сожалению, не было необходимости использовать их вместе, так что с проблемой не разобрался.
Наконец-то статья о том, что кто-то выбрал Angular! Столько статей про React последнее время… Как любителю Angular становилось грустно, спасибо за статью!
YAML делает тоже самое, при этом оставаясь читаемым для человека.
Не уверен, что CJON способен сравниться по читаемости с JSON или YAML даже близко. Давайте попробуем рассмотреть реальные prod-like примеры, а не "на кошках".
Ну а если готовы жертвовать читаемостью в угоду размера и скорости серилизации, то не вижу причин не использовать бинарные форматы вроде protobuf или avro
Из любого правила есть исключения и любое решение это взвешивание и поиск компромиссов. В первую очередь мы стремимся к тому чтобы код было легко читать и как этого достигнуть можно сказать только в каждой конкретной ситуации.
То, о чем я говорю работает в общем случае, но конечно не в 100% случаев.
Для сложной алгоритмики или убивания абстракций / использования низкоуровневых элементов языка ради оптимизации имеет смысл и верхнеуровнево описывать "что". Но только на более высоком уровне абстракции чем непосредственно код. Условно не "делаем X, проверяем Z, делаем Y", а решаем задачу A путём применения X и затем Y для результатов удовлетворяющих условию Z".
Часто хорошим маркером читаемости кода является ревью своего же кода на следующий день после написания
Я всегда всем объясняю так: если ты пишешь комментарий, который отвечает на вопрос "как?" Или "что?", то вместо этого перепиши код, чтобы было понятно что он делает без комментариев.
А вот вопросы "зачем?", "почему?" и "для чего?" это именно то что кодом никак не выразить и требуется раскрывать комментариями.
Код сам должен описывать то что он делает. Но намерения и цели код не опишет. Иногда критически важно понять почему конкретный код находится именно здесь и делает именно это.
Ещё хороший поинт - если тебе на ревью задают вопрос "почему ты сделал так" - писать комментарии вместо объяснения в тредах пулл-реквеста.
Ещё более важный вопрос "почему именно так, а не иначе?"
Насчёт MDC там не так все радужно, на самом деле. API ScopedValue подразумевает, что хранимое значение неизменяемо и может быть только переопределено во вложенных скоупах.
А MDC внутри содержит HashMap, соответственно там между сабтасками может быть неразбериха (если они пишут в MDC).
Я как-то экспериментировал и писал адаптеры для MDC и SpringSecurity для поддержки StructuredScope и ScopedValues (чтобы код оставался таким же простым как в примерах из JEP) и (не знаю как сейчас, может за год изменилось что) там все равно нужно было писать обёртку, чтобы каждая подзадача получила свою копию MDC, либо гарантировать что в подзадаче никогда не будет вызываться MDC.put, а только та его версия, что использует стек внутри.
Да, спасибо, опечатался :)
Я бы отметил такой момент: лучше не использовать классы LocalDateTime в сущностях и DTO. То, как они сериализуются зависит от таймзоны сервера или настроек jdbc драйвера + позволяет без явного указания таймзоны получать дату, что чревато ошибками в приложениях которые работают в нескольких таймзонах (как правило, вы сперва думаете что ваше приложение маленькое и всё ок, а потом возникает необходимость поддержать пользователей из разных таймзон и вылезают разные неприятные ошибки).
Лучше всего использовать Instant или OffsetDateTime. Для передачи по REST и стерилизации использовать стандарт ISO-8068, а для хранения в БД тип TIMESTAMP WITH TIMEZONE, тогда драйвер тоже сам разберётся в как передавать дату и время и не будет ошибок.
А если нужно получить только дату или только время - явно конвертировать в целевую таймзону которая имеет значение с точки зрения бизнес-логики.
Блин, это конечно хорошо, но по заголовку я ожидал что, наконец-то, добавили возможность работы с асинхронным кодом/корутинами/webflux. А так получается if/else - наше всё
Хочется ответить: https://github.com/kelseyhightower/nocode
А если серьезно: не умеете использовать инструмент, не используйте. Половина описаных проблем касается не Ангуляра, а клиентской разработки в целом. И Ангуляр, при правильном подходе, вполне себе успешно их решает абсолютно прозрачным для разработчика способом.