Эти 2 строки ничем не отличаются в плане дублирования.
Заменой статическоего метода на сервис решается проблема зависимости от конкретной реализации (D в SOLID), нерасширяемости и нетестируемости статических методов.
"Свои данные" и данные "соседа" это самый простой частный случай. Профиль, посты, комменты - там где можно сказать чьи данные.
В реальности же доменная модель бывает гораздо сложнее, разные пользователи могут управлять одними и теми же данными.
Хорошо реализованная система ACL - это сложно и дорого.
Поэтому приемлимой альтернативой к "хакеры нашли проблему в авторизации и увидели больше чем положено инкрементируя id" является "хакеры нашли проблему в авторизации но ничего не увидели потому что не смогли подобрать UUID"
Явное изменение версии хороший вариант - просто и понятно.
Изменение каждого метода равноценно изменению всех классов с добавлением аннотаций по трудоемкости.
Чтобы люди не забывали инкрементить версию можно написать юнит тест который найдет все энтити у которых есть методы начинающиеся с add и проверить что они инкрементят версию - либо вызывав их , либо тупо посчитав что количество методов равно количеству инкрементов или количество инкрементов равно количеству @OneToMany аннотаций x 3.
При том, что ученые ищут что бы еще подействовало на ковид. И нашли, и опубликовали уже довольно много клинических исследований и мета-анализов.
Вот эта работа, например, PMID: 34127807:
Statistically significant improvements were seen for mortality, ventilation, hospitalization, cases, and viral clearance. 100% of the 17 Randomized Controlled Trials (RCTs) for early treatment and prophylaxis report positive effects, with an estimated improvement of 73% and 83% respectively (RR 0.27 [0.18–0.41] and 0.17 [0.05–0.61]), and 93% of all 28 RCTs. These studies are tabulated in Table 1. The probability that an ineffective treatment generated results as positive for the 55 studies to date is estimated to be 1 in 23 trillion (p = 0.000000000000043).
И механизмы действия против вирусов там описаны. (Они немного сложнее, конечно, чем такой простой и понятный механизм как "act by interfering").
Видел уже несколько раз баги:
В погоне за модой фукнкионального стиля люди начинают использовать
requireNonNullElse() или orElse()
и код который был в ветви else, которая раньше не выполнялась, теперь выполняется всегда, причем до основного if (который теперь стал filter или anyMatch).
Optional.ofNullable() тоже зло.
Люди пихают его везде, просто по привычке чтобы не парится с нуллами.
В итоге баги доходят до UI и живут пока юзеры не пожалуются что у них тут что-то пустое место вместо нужных им цифр.
Говорят есть страны где детский сад бесплатный, и музыкой и танцами там с детьми занимаются и т.д. И школа тоже бесплатная.
НО. Путь к этой школе пролегает через гаражи. И тогда становится понятно, что какой бы ни была зарплата по ППС у папы девочки Лизы, есть вещи которые он купить не в состоянии.
после создания volume, docker volume inspect покажет где файлы лежат, туда и записывайте все что надо контейнеру, а потом при создании/старте контейнера mount подмонтирует эту папку внутрь контейнера по указанному пути.
Более того, любое количественное ограничение по длине строки это полная ерунда.
Строчка должна выполнять одну логическую операцию. Если используются длинные имена переменных, то она может быть длинной, особенно если там вызывается метод класса с хорошим длинным названием и неудачно большим количеством параметров (больше трех).
Разбиенеие одного вызова получения чего-то откуда-то на несколько строк ухудшает читаемость.
Те, кому надо сконцентрироваться на этой конкретной строке — прокрутят и прочитают.
Но тогда получатся разные конфиги для prod и для dev, по моему это вообще не огонь, или альтернативного решения нет?
На проде вообще не будет docker-compose. Там будет окрестрация, так что конфиги все равно разные. Запекая файлы в образе мы гарантируем что все равно как этот контейнер запускается — он будет работать одинаково.
Фактически образ это исполняемый файл приложения. Исполняемый файл + переменные окружения = все что нужно для выполнения программы. Один из пунктов The Twelve-Factor App.
Программа должна работать без "volumes" в docker-compose (Их можно опционально добавлять при девепоменте, чтобы изменения в файлах хоста автоматически переносились в запущенный контейнер и не надо было билдить и запускать новый image каждый раз когда надо увидеть внесенные в код изменнения)
Далее надо использовать Rancher или Kubernetes чтобы это все дело оркестрировать на проде.
$user = $createUser($request->all());
Эти 2 строки ничем не отличаются в плане дублирования.
Заменой статическоего метода на сервис решается проблема зависимости от конкретной реализации (D в SOLID), нерасширяемости и нетестируемости статических методов.
"Свои данные" и данные "соседа" это самый простой частный случай. Профиль, посты, комменты - там где можно сказать чьи данные.
В реальности же доменная модель бывает гораздо сложнее, разные пользователи могут управлять одними и теми же данными.
Хорошо реализованная система ACL - это сложно и дорого.
Поэтому приемлимой альтернативой к "хакеры нашли проблему в авторизации и увидели больше чем положено инкрементируя id" является "хакеры нашли проблему в авторизации но ничего не увидели потому что не смогли подобрать UUID"
Да все равно, мне больше нравится UUID.toString() - более human readable когда в базе и логах смотришь .
Тут проблема безопасности, так как не только вам нетрудно догадаться.
Используйте UUID как идентификатор.
@IdString id;Кроме этого, использование последовательностей не посзволяет создавать сущности сразу в валидном состоянии.
Явное изменение версии хороший вариант - просто и понятно.
Изменение каждого метода равноценно изменению всех классов с добавлением аннотаций по трудоемкости.
Чтобы люди не забывали инкрементить версию можно написать юнит тест который найдет все энтити у которых есть методы начинающиеся с add и проверить что они инкрементят версию - либо вызывав их , либо тупо посчитав что количество методов равно количеству инкрементов или количество инкрементов равно количеству @OneToMany аннотаций x 3.
При том, что ученые ищут что бы еще подействовало на ковид. И нашли, и опубликовали уже довольно много клинических исследований и мета-анализов.
Вот эта работа, например, PMID: 34127807:
Statistically significant improvements were seen for mortality, ventilation, hospitalization, cases, and viral clearance. 100% of the 17 Randomized Controlled Trials (RCTs) for early treatment and prophylaxis report positive effects, with an estimated improvement of 73% and 83% respectively (RR 0.27 [0.18–0.41] and 0.17 [0.05–0.61]), and 93% of all 28 RCTs. These studies are tabulated in Table 1. The probability that an ineffective treatment generated results as positive for the 55 studies to date is estimated to be 1 in 23 trillion (p = 0.000000000000043).
И механизмы действия против вирусов там описаны. (Они немного сложнее, конечно, чем такой простой и понятный механизм как "act by interfering").
Когда Хабр забанит эту леди за дезинформацию?
Этот "дегельминтизатор для крупного рогатого скота" Нобелевскую премию между прочим получил в 2015 году и не из-за того что он так хорош для скота.
"nobel prize medicine 2015"
В погоне за модой фукнкионального стиля люди начинают использовать
requireNonNullElse() или orElse()
и код который был в ветви else, которая раньше не выполнялась, теперь выполняется всегда, причем до основного if (который теперь стал filter или anyMatch).
Optional.ofNullable() тоже зло.
Люди пихают его везде, просто по привычке чтобы не парится с нуллами.
В итоге баги доходят до UI и живут пока юзеры не пожалуются что у них тут что-то пустое место вместо нужных им цифр.
Нет.
НО. Путь к этой школе пролегает через гаражи. И тогда становится понятно, что какой бы ни была зарплата по ППС у папы девочки Лизы, есть вещи которые он купить не в состоянии.
Строчка должна выполнять одну логическую операцию. Если используются длинные имена переменных, то она может быть длинной, особенно если там вызывается метод класса с хорошим длинным названием и неудачно большим количеством параметров (больше трех).
Разбиенеие одного вызова получения чего-то откуда-то на несколько строк ухудшает читаемость.
Те, кому надо сконцентрироваться на этой конкретной строке — прокрутят и прочитают.
На проде вообще не будет docker-compose. Там будет окрестрация, так что конфиги все равно разные. Запекая файлы в образе мы гарантируем что все равно как этот контейнер запускается — он будет работать одинаково.
Фактически образ это исполняемый файл приложения. Исполняемый файл + переменные окружения = все что нужно для выполнения программы. Один из пунктов The Twelve-Factor App.
Для прода нужно чтобы не было статических ссылок на другие контейнеры в конфиг файлах nginx.conf и т.д.
Значение хоста и порта в инструкциях типа SetHandler "proxy:fcgi://php:9000" должны приходить из ENV: SetHandler "${PHP_UPSTREAM}"
Конфиги и все файлы из src должны "запекаться" в image при помощи ADD/COPY инструкций Dockerfile.
Процесс надо разделить на 2 этапа. Сначала билдим все images, потом в docker-compose.yml ссылаемся на эти собранные image.
Программа должна работать без "volumes" в docker-compose (Их можно опционально добавлять при девепоменте, чтобы изменения в файлах хоста автоматически переносились в запущенный контейнер и не надо было билдить и запускать новый image каждый раз когда надо увидеть внесенные в код изменнения)
Далее надо использовать Rancher или Kubernetes чтобы это все дело оркестрировать на проде.