Exiting: error loading config file: config file ("filebeat.yml") can only be writable by the owner but the permissions are "-rwxrwxrwx" (to fix the permissions use: 'chmod go-w /usr/share/filebeat/filebeat.yml')
Как первоначальное описание идея хорошая, но комментарии имеют свойство устаревать, или хуже, когда комментарий поменяли, а логику нет. Конечно это может отлавливатся на ревью, но все ошибаются.
Так же такой подход может спровоцировать длинные методы. Из-за комментариев сложно будет уследить за длинной самого метода и пропорций код/комментарии.
Это действительно полезно на этапе проектирования, но потом должно уходить в документацию (конфлюенс/javadoc)
Добавил в начало статьи пару местных статей. Сам не писал, потому что теории по graphql много, в гугле и тут. Статью писаль исключительно с практической целью.
Плюсы и минусы не сильно зависят от реализации, так же находятся на уровне теории.
Graphql преподносится как альтернатива REST. Один из плюсов, почему хотели использовать его, возможно выбирать нужную информацию (забирать не все поля DTO). Тогда для сайта можно одно, для мобилки другое (например размер изображений). Для этого не требуется писать новый контроллер (сервлет), достаточно просто изменить запрос на фронте.
При запуске в винды
ошибка:
Exiting: error loading config file: config file ("filebeat.yml") can only be writable by the owner but the permissions are "-rwxrwxrwx" (to fix the permissions use: 'chmod go-w /usr/share/filebeat/filebeat.yml')
лечится
https://discuss.elastic.co/t/volume-mapped-filebeat-yml-permissions-from-docker-on-windows-host/91893
добавлением строки
command: filebeat -e -strict.perms=false
в docker-compose.yml для компонента beats
beats:
image: elastic/filebeat:7.16.2
command: filebeat -e -strict.perms=false
volumes:
- ./configs/filebeat/config.yml:/usr/share/filebeat/filebeat.yml:ro
- ./host_metrics_app/:/host_metrics_app/:ro
networks:
- elk
depends_on:
- elasticsearch
Мы используем котли, потому что котлин, котлин, котлин, он такой как котлин)
Как первоначальное описание идея хорошая, но комментарии имеют свойство устаревать, или хуже, когда комментарий поменяли, а логику нет. Конечно это может отлавливатся на ревью, но все ошибаются.
Так же такой подход может спровоцировать длинные методы. Из-за комментариев сложно будет уследить за длинной самого метода и пропорций код/комментарии.
Это действительно полезно на этапе проектирования, но потом должно уходить в документацию (конфлюенс/javadoc)
Статья называется "будущее..." а в самой статье история. Не надо так
Плюсы и минусы не сильно зависят от реализации, так же находятся на уровне теории.
Graphql преподносится как альтернатива REST. Один из плюсов, почему хотели использовать его, возможно выбирать нужную информацию (забирать не все поля DTO). Тогда для сайта можно одно, для мобилки другое (например размер изображений). Для этого не требуется писать новый контроллер (сервлет), достаточно просто изменить запрос на фронте.