Сорри за агрессивный тон с моей стороны, просто сильно тригерюсь на суждения "часто/редко", особенно когда это вижу в книгах :)
На самом деле действительно задач в которых требуется чисто crud действительно часто больше чем сложных, особенно в заказной разработке, но ключевой момент именно в том что задачи определяют подход в не из частота) и т.к. мало кто это понимает - хочется чтобы в статьях мы отражали именно это.
Насчёт использования DI - тут важно понимать, что под DI я понимаю именно "получение зависимости извне", а не использование фреймворков. Это банально упрощает структуру приложения т.к. мы оперируем готовыми объектами + упрощает замену реализаций, внедрение промежуточной логики в виде адаптеров там где это необходимо и т.п.
Т.е. банально, при последующих изменениях и расширении функциональности требует менять меньше кода или вообще не менять зависимые компоненты.
Откуда берутся все эти утверждения "чаще всего данные отдаются сразу клиенту", "обычно DI не нужен" и т.п.
Запомните раз и навсегда. Нет никаких "чаще всего" и "обычно". Есть разные задачи решаемые системами. Где-то задачи простые и там действительно данные сразу отдаются клиенту и проверяются интеграционными тестами (кстати польза от DI не только для тестов).
А есть задачи сложные (именно сложные с точки зрения бизнес-процессов и предметной области) и там без грамотного моделирования логики, юнит тестов и т.п. код за месяц превращается в неподдерживаемое <censored>, которое ломается от малейшей правки.
И выбирать подходы следует именно из анализа вашей предметной области и тех задач, которые система в ней решает, а не из "чаще/реже/ у нас так принято/на прошлом проекте делали".
А есть тут пользователи jellyfin? Пробовали транскодить 4к источник в худшее качество при удаленном доступе? Если да, то на каком железе? Я так понял что без нормальной видеокарты транскодить 4к вообще не вариант
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 становилось грустно, спасибо за статью!
Сорри за агрессивный тон с моей стороны, просто сильно тригерюсь на суждения "часто/редко", особенно когда это вижу в книгах :)
На самом деле действительно задач в которых требуется чисто crud действительно часто больше чем сложных, особенно в заказной разработке, но ключевой момент именно в том что задачи определяют подход в не из частота) и т.к. мало кто это понимает - хочется чтобы в статьях мы отражали именно это.
Насчёт использования DI - тут важно понимать, что под DI я понимаю именно "получение зависимости извне", а не использование фреймворков. Это банально упрощает структуру приложения т.к. мы оперируем готовыми объектами + упрощает замену реализаций, внедрение промежуточной логики в виде адаптеров там где это необходимо и т.п.
Т.е. банально, при последующих изменениях и расширении функциональности требует менять меньше кода или вообще не менять зависимые компоненты.
Откуда берутся все эти утверждения "чаще всего данные отдаются сразу клиенту", "обычно DI не нужен" и т.п.
Запомните раз и навсегда. Нет никаких "чаще всего" и "обычно". Есть разные задачи решаемые системами. Где-то задачи простые и там действительно данные сразу отдаются клиенту и проверяются интеграционными тестами (кстати польза от DI не только для тестов).
А есть задачи сложные (именно сложные с точки зрения бизнес-процессов и предметной области) и там без грамотного моделирования логики, юнит тестов и т.п. код за месяц превращается в неподдерживаемое <censored>, которое ломается от малейшей правки.
И выбирать подходы следует именно из анализа вашей предметной области и тех задач, которые система в ней решает, а не из "чаще/реже/ у нас так принято/на прошлом проекте делали".
А железки остальные какие в таком сетапе? Хочется что то не сильно громоздкое и энергозатратное
У меня просто роль медиа сервера выполняет синолоджи или rpi и пока обхожусь тем что локально plex стримит без транскодинга.
Но вот удаленный доступ для 4к сломался.
С 1080 отлично rpi справлялась правда с глубиной цвета до 8 бит
А есть тут пользователи jellyfin? Пробовали транскодить 4к источник в худшее качество при удаленном доступе? Если да, то на каком железе? Я так понял что без нормальной видеокарты транскодить 4к вообще не вариант
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
А если серьезно: не умеете использовать инструмент, не используйте. Половина описаных проблем касается не Ангуляра, а клиентской разработки в целом. И Ангуляр, при правильном подходе, вполне себе успешно их решает абсолютно прозрачным для разработчика способом.