Pull to refresh
4
0
Влад Солнцев @Quber

Тимлид

Send message

Привет! Спасибо за статью! Рассматривали ли вы вариант делать микросервисы на одной базе аля своём фреймворке , который под капотом умеет слать все общие между микросервисами метрики? Если да, то почему такой вариант не подошёл? Тогда в графане достаточно было просто сделать один раз общий дашборд на котором сделать переключатель по микросервисам. У нас так сделано и не надо ничего изобретать 🤔 все микросервисы конечно при таком подходе должны использовать общие методы логирования, воркеров, консьюмеров, контроллеры веб сервера и тд

У меня даже с премиумом не работает режим «картинка в картинке» в приложениях ютуб на айфоне и айпаде. Чтобы воспользоваться этой функцией нужно обязательно открывать ютуб через браузер.

> И да, я считаю, что в енамах значение по умолчанию всегда должно быть неопределённым.
Неопределенным или неизвестным? Это разные вещи. Оба варианта могут быть присущи полю типа enum.

Не нашел инфу о поддержке DOH в браузере TOR… можете что то прояснить?

Вопросы для разработчика ничего общего не имеют с оценкой уровня кандидата.
Ребята вы молодцы. Одна маленькая просьба. Учитывайте что есть те, кто слушает подкаст на скорости x1.5. У вас речь бывает не равномерная по скорости. Что-то говорите быстро, что-то медленно. Например, когда читаете «могли бы обсудить, не обсудили», делаете это очень быстро и на x1.5 некоторые слова «проглатываются». Старайтесь прослушивать подкаст перед публикацией на повышенных скоростях. Спасибо!
> А просто не использовать поле не по назначению.
Если вы считаете, что поле sex может содержать значения только «мужской» и «женский», а всё остальное это «не по назначению», то вы ошибаетесь. Если взять стандарт ISO 5218 то поле sex может иметь не 2, а 4 значения.
Понял. Спасибо.
Понял. Спасибо.
Да, вы правы. Я ошибся.

В таком случае исключения не будет, если вы это хотели сказать своим комментарием.

Я к тому что DO и VO это же разные по смыслу вещи, разве нет?

Вы можете называть это как угодно. Сути не меняет.

Ну допустим. А если нас появится пол «унисекс», когда персонаж может иметь мужской и женский пол, например, для того чтобы в sims 4 можно было одевать разную одежду. И это может быть «другое» как у автора статьи на скриншоте. И тогда мы опять приходим к тем проблемам, которые обозначил автор статьи.
Устраивает. Но optional мы сможем применить только один раз по отношению к полю. А значений у нас может быть много: не определен, не известен, не применим и т.д. И это разные по смыслу и назначению вещи.
Возможно вы правы. Не претендую на истину. Но тогда наш объект приобретает две роли, валидация и хранение значения.

И есть еще вопрос, не связанный напрямую с темой. Судя по пространству имен и PSR-4 вы храните Domain object и Value object в одной директории. Насколько это оправдано?
> «Не определен» это не пол.

Это не пол, но значение вполне может храниться в поле sex.

> Если есть такое поле, значит есть и другие поля, которые «не определены»

Абсолютно не значит. Других полей может не быть, которые не определены. Если у вашего объекта всего два поля «имя» и «пол». Имя известно, пол не определен. Допустим вы добавите отдельное поле, например, булево отражающее определен пол или не определен, тогда вы можете столкнуться с ситуацией когда ваш объект будет иметь пол «мужской» и тип «пол не определен».
Предположим, что функция hasSex отвечает у нас за применимо или не применимо понятие «пол». А сам пол мы отобразим в базе как нулевое поле. Через какое то время у нас появляется новое понятие, пол «не известен». Итого у нас есть «пол не применим», «пол не определен», «пол не известен», «другой». Нулевое значение у нас уже занято. Функция hasSex задействована. Каким образом вы будете решать появление нового значения «не известен»? Разумеется разделять эти понятия не имеет смысла, так как у нас объект не может иметь одновременно и «мужской пол» и статус «не определен» или «женский пол» и статус «пол не применим».

Я просто хочу вам сказать, что вы можете ошибаться, когда думаете что знаете точное количество значений, на примере поля sex. В процессе разработки, например компьютерной игры, могут появляться новые значения, которые на этапе планирования не заложили. А соответственно тогда и начнутся те самые проблемы, которые описал автор в своей статье.
Мне кажется у вас нарушен принцип единственной ответственности, когда вы в value object начинаете проверять валидность данных, через функцию assert. Проверку на валидность данных лучше выносить в отдельный слой.
> Если пол не применим к объекту, следует отделить объекты, к которым пол применим, для других enum просто не потребуется.

Интересно каким образом вы отделите объекты к которым пол не применим, если они хранятся в одной таблице и имеют одинаковые свойства с теми у которых пол применим? Создадите отдельную таблицу или класс под них?

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Backend Developer, Fullstack Developer
Lead
PHP
Golang
PostgreSQL
Git
SQL
OOP
Database
Docker
High-loaded systems