https://youtu.be/zVNrqo9XGOs?t=11m58s

11:58

там часть про то что нужно продумывать наперед а потом про то что не нужно этого делать и YAGNI)

ну бля

как вам сказать

если домен меняется пару раз в месяц

all the data from the single endpoint

not breaking changes

закрыл

> если домен меняется пару раз в месяц это как?

ну он про правила "вот этот процесс вот такой", а потом "уупс, не такой"

ну он про правила "вот этот процесс вот такой", а потом "уупс, не такой"

нууу..... тут есть нюансы

но это не проблема

должна быть

это проблема которой не избежать

т.е. не проблема)

поэтому мы к ней готовы

ну не особо

ну в абстракте

только начинаем приспосабливаться)

как при это endpoints не меняются

я не знаю

у нас дикая проблема с неймингом)

у фэйсбука домен не меняется

причем всего)

начиная от самих продуктов

да

их тоже меняют пару раз в месяц

заканчивая какими-то простыми терминами

их тоже меняют пару раз в месяц

просто видение не оч было

ну да

если домен не сильно разработан и эксперты сами не такие уже эксперты как хотелось бы

то туго

ну да

не ну да)

немного офтопа из мира js: в v8 добавили модули

воу воу

круто)

насколько бредовой выглядит идея сделать все модели immutable?

а сеттеры заменить на что-то вроде withProperty('new value'): self

А смысл?

Модель же не value object, имеет состояние.

насколько бредовой выглядит идея сделать все модели immutable?

ты предлагаешь при изменении одно property копировать весь аггрегат?

иммутабельность ради иммутабельности?

да уже в @oop_ru обсудили)

не ну да)

да мы косячим там как можем, короче

насколько бредовой выглядит идея сделать все модели immutable?

и что будут делать withProperty?

насколько бредовой выглядит идея сделать все модели immutable?

давай подругому. Сеттеры не нужны. Нужны операции, действия над сущностью. Можешь выделить списочки оных?

например возьмем старую добрую сущность юзера

class User { private $id; private $email; private $password; private $name; }

у него будут методы: - __construct(UserBuilder $builder - authenticate(string $password, PasswordEncoder $encoder) - changePassword(string $oldpassword, string $newPassword, PasswordEncoder $encoder) - updateProfile(string $name)

ничоси.

кто какую документную БД использует? особо интересует как ведет себя couchbase с шардированием.

couchbase нормально шардируется

@fes0r а зачем в сущность UserBuilder передавать?

@fes0r а зачем в сущность UserBuilder передавать?

потому что помимо name всегда надо что-то еще потом передавать а >3 аргументов в метод (конструктор) не красиво

И все геттеры будут «проксями» для билдера?

И все геттеры будут «проксями» для билдера?

нет геттеров нет проблем)

Типа getAvatar.

билдер используется только на момент создания сущности, не более

билдер = фабрика по сути

ты наполняешь ее стэйтом, просишь сбилдить юзера

С сеттерами, геттерами, где-то видел такой подход.

С сеттерами, геттерами, где-то видел такой подход.

этот паттерн так и называется - Builder

можно еще у билдера просто делать проперти публичными

и тогда это будет что-то типа DTO

ERROR: S client not available

DTO + фабрика

фишка билдера, что ему можно почастям закинуть данные, которые сущность требовала бы все сразу

а не получится так, что сущность будет в неконсистентном состоянии?

чего билдим? и так ли он нужен, этот билдер в данном случае?

а не получится так, что сущность будет в неконсистентном состоянии?

либо в конструкторе либо в методе build билдера должны проверяться инварианты

если инварианты/прекондишены не соблюдаются - плюемся исключениями

чего билдим? и так ли он нужен, этот билдер в данном случае?

нужен

билдеры не нужны когда у тебя value object-ы простенькие

когда больше 3-х аргументов никогда не нужно будет передавать

StorytellerCZ: If you are starting new project you shouldn't use HybridAuth.

вашу мать, а что нужно использовать для новых проектов что осуществлять эту долбанную гибридную авторизацию?

Умные человеки

как определить code coverage в пхп?

какие инструменты есть

какие инструменты есть

phpunit?

phpunit

там можно степень покрытия смотреть как то?

там можно степень покрытия смотреть как то?

угу

а как?

он вроде в процессе выполнения тестов это считает

и пишет в лог куда то?

нельзя просто так взять и с воздуха это определить

хз, не ковырял этот модуль, но он там есть и делает магию в процессе

при чем юзает какую-то интересную стандартную пыховскую штуку внутри, о которой я узнал только ковыряя его

запускаешь тесты с флагом --coverage-html dir, как то так, там разные есть флаги, xml,html,console

phpunit вроде умеет lcov

и может html, text, json репорты сам из него строить или можно юзать другие тулзы

их много, phpstorm умеет в lcov

у кого-нибудь была protected ломка?

если хочется извращений, то можно вручную что-ниубдь сделать https://xdebug.org/docs/code_coverage :)

у кого-нибудь была protected ломка?

что?))

когда хочется немного понаследовать