• Как разграничивать права доступа в API?

    @xfg
    site.tld/api/v1/backend/users/1
    site.tld/api/v1/frontend/users/1

    Где дублирование? Что здесь нарушает рест?
  • ООП. хранить ли данные в объекте?

    @xfg
    Нужно видеть реальную задачу. Не понятно, что вы хотите сделать. В любом случае, данные в объекте храниться не должны, для данных есть хранилища (база/файл/удаленный сервис и т.д.). Из данных собирают объект или вложенную иерархию объектов (агрегат). Скорее всего, то что вы хотите хранить в $this->data можно разложить на дочерние объекты, которые будут жить внутри класса Class.

    Напишите какую вы задачу решаете.
  • Как разграничивать права доступа в API?

    @xfg
    Нет. REST не устанавливает никаких требований к контроллерам. Он предъявляет требования к формату запроса/ответа, но не накладывает никаких ограничений на возвращаемые данные из контроллера. Что конкретно по вашему в этом подходе противоречит рест?
  • На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

    @xfg
    Лучше скачайте/купите Implementing domain-driven design, вот эту красную книжечку https://vaughnvernon.co/?page_id=168 Это практика, не теория. Когда я изучал тему, прочитал изначально, только раздел про Entity вдохновился и пошел делать эти сущности. Затем возник вопрос, а как сделать доменный объект из нескольких Entity и пошел читать про Aggregate. Затем, как это всё сохранить и прочитал про Repository. В итоге, со временем по кускам прочитал почти всю книгу. Любую тех. литературу нужно так читать:

    1. Делаем проект
    2. Возникает вопрос
    3. Ищем решение в книге
    4. Возвращаемся в пункт 1

    Статьи я читал как дополнение, просто гуглил, куча разных блогов/сайтов/stackowerflow и прочего. Но это все разрознено по какому-то конкретному небольшому вопросу, а так чтобы ввиде цикла статей о проектировании доменной модели и многоуровневой архитекруты не встречал.
    Но если хотите, то https://lostechies.com/jimmybogard/category/domain...
    Но лучше пишите приложение, ищите решение в книге и гуглите, в большинстве случаев гугл вас все равно будет отправлять на какие-то конкретные статьи из этого блога, там много по теме DDD. Это продуктивнее и быстрее, чем выискивать какие-то конкретные статьи.

    Также посмотрите тестовое приложения на DDD https://github.com/citerus/dddsample-core/tree/mas... и примерно поймете, как нужно организовывать код, что куда складывать. Пример на Java, но зная PHP можно примерно понять, что там и как.

    В любом случае, вы будете делать и переделывать сделанное, так как ваши знания будут постепенно расширяться. Сразу круто не получается ни у кого. Даже сейчас, если вы не знаете ничего, всё равно пишите код. Вам нужно создать ваш первый доменный объект? Отлично, откройте упомянутую выше книгу и прочитайте раздел про Entity. И сделайте её. Для этого не нужно читать всю книгу.
  • На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

    @xfg
    olijen: Отказываться не обязательно. Но и использовать смысла мало. Репозиторий всё равно должен возвращать доменный объект, а не AR модель, так на кой черт она вам нужна? Из данных создать AR модель, затем из AR модели создать доменный объект? Смысла ноль, лишнее потребление ресурсов, излишняя зависимость инфраструктуры от фреймворка. Захотите откатиться с этого фреймворка - будете переписывать все репозитории, оно вам надо? Сделайте своё небольшое решение, которое будет напрямую заполнять доменный объект данными из базы и раскладывать доменный объект в данные для сохранения в базу. Если вам не принципиально хранить данные в реляционном виде в куче плоских таблиц, то не очень сложно написать реализацию для хранения их как иерархических структур в виде JSON объектов. Вон Вернон пишет как это делать в PostgreSQL. В MySQL естественно плюс/минус тоже самое. Если принципиально, то попробуйте прикруть, хотя бы Doctrine, так как свой костыль будет написать уже довольно сложно, а собирать/разбирать доменные объекты руками, это долго. Но я бы не терял на всё это время, когда можно сделать гораздо удобнее, чем подход из 70ых годов прошлого века.
  • Как начать тестирование сайта?

    @xfg
    Да, медленные и ломкие. Можно их писать только на критические юзер-кейсы, типа регистрации или оплаты на сайте. Остальное покрывать юнит-тестами.
  • Мелкие задачи по сайтам на фрилансе, как делать правки у клиента?

    @xfg
    vism: нужно выгрузить только схему бд без данных и файлы сайта. Ну это для проектов, которые деплоятся руками по фтп.
  • Как писать тесты?

    @xfg
    Оптимус Пьян: мок-объект - это фальшивый объект, который имитирует поведение реального объекта. Мокать методы, это значит, создать мок-объект с нужным набором методов для теста, методам можно сказать, чтобы они возвращали заранее заготовленные значения и прочее.

    Например, у вас есть метод объекта, на который вы хотите написать тест. Но этот метод внутри себя вызывает метод другого объекта например для работы с базой данных. Тогда вы перед тестом можете создать мок-объект имитирующий объект для работы с базой данных, указать, какие значения должны возвращаться из методов мок-объекта и прочие настройки. Теперь ваш метод, на который вы пишите тест будет внутри себя вызывать мок объект вместо реального объекта для работы с базой данных. Что вы получили? Вы получили возможность проверить тестируемый метод без необходимости реального обращения к базе данных.

    Подробнее тут https://en.wikipedia.org/wiki/Mock_object если с англ проблемы, то есть тут https://ru.wikipedia.org/wiki/Mock-объект но очень скудно.

    Как этим всем пользоваться в phpunit здесь https://phpunit.de/manual/current/en/test-doubles.html
  • Как писать тесты?

    @xfg
    Оптимус Пьян: вы когда хотите написать код метода, понимаете что он должен делать и какая у него должна быть сигнатура? Просто представьте, что этот метод уже есть, вы знаете какие агрументы он должен принимать и что возвращать. Теперь просто вызовите этот несуществующий метод в тесте, сравните результат работы с ожидаемым. Тест естественно не пройдет. Теперь подумайте какими внутренностями нашпиговать метод, чтобы тест проходил.
  • В чем косяк (полиморфизм)?

    @xfg
    MaxKorz: это уже ваше предположение, что метод будет одинаков. Моя задача показать, что такое полиморфизм подтипов на примере автора. Поэтому конкретная реализация классов не имеет никакого значения.

    Полиморфизм = многообразный. Это значит, что вы не должны делать N правок. Каждая конкретная реализация интерфейса должна иметь своё собственное отличное от других поведение. Именно это я пытался донести. Если поведение всегда одинаково, то очевидно, что полиморфизм не нужен вообще. Собственно это нужно понимать, т.к. вопрос о полиморфизме, а не об архитектуре приложения.


    я бы сделал так sandbox.onlinephpfunctions.com/code/3385d3ecb1d405...

    Нет никакого смысла иметь абстрактный класс, без абстрактных методов.
  • Переход проекта с jQuery на Angular 1 или Angular 2 или React?

    @xfg
    Alex: очень оптимистично. Если все было бы из коробки, не было бы тысяч пакетов расширяющих функционал ангуляра. Помоему очевидно.
  • Переход проекта с jQuery на Angular 1 или Angular 2 или React?

    @xfg
    Alex: чтобы максимально быстро начать писать фичи проекта, а не инфраструктурный код, поверх которого эти фичи будут работать.
  • Переход проекта с jQuery на Angular 1 или Angular 2 или React?

    @xfg
    Ничего не стоит дать совет использовать Angular 2. Это же проблемы автора, когда он не сможет найти готовых решений под него.
  • Что делать что бы не писать запросы в коде?

    @xfg
    Оптимус Пьян: основная задача ORM это конвертировать данные из базы в объекты и наборот объекты в данные. Нужно, для того, чтобы работать с объектами, а не возиться с сырыми данными.
  • Какие есть ресурсы для изучения английского (читать/писать), в которых информация изложена максимально кратко, но полно?

    @xfg
    vjjvr: нужно просто помнить как они образуются, чтобы в тексте различать где субъект выполняет действие над объектом, а где объект претерпевает действие.

    Человек построил здание - активный залог.
    Здание построенно человеком - пассивный залог.

    Запомнить, что в группе simple пассивный залог образуется как to be + past participle. И всё, больше ничего не нужно. Это просто очень сильно поможет новичку понимать предложения на английском. Потому что иначе бывает, что вроде все слова знаешь, но суть не понятна. Со временем форма пассивного залога примелькается и мозг даже начнет воспринимать предложения в пассивном залоге из других групп такие как to be + being + past participle в группе continuous и to have + been + past participle группе perfect, хотя человек их мог даже специально вообще не изучать, просто интуиция подскажет.
  • Как лучше создать поиск для сайта используя MySql + ElasticSearch?

    @xfg
    Что будет, если в результате сбоя данные в mysql изменятся, а в ES нет? Например упало приложение до апдейта ES, но после mysql. Со временем, будет расхождение в данных.

    Я бы лучше сделал синхронизацию по крону. Можно просто добавить поле updated_at и при каждом insert/update писать туда таймштамп. Скрипт раз в N времени приходит, забирает новые данные и раскладывает в ES. Можно также посмотреть готовые решения https://www.elastic.co/guide/en/logstash/master/pl...

    Поиск будет отдавать немного устаревшие данные, но возможно это не критично и менеджерам можно объяснить, что мы тоже тут не боги.
  • Есть ли обучение по созданию push уведомлений?

    @xfg
    Дмитрий Королёв: ну я в курсе, что разные. Хотел лишь выяснить, по поводу внешнего вида. Спасибо.
  • Точно и подробно про защиту от инъекций в php, mysql?

    @xfg
    Косяки бывают, но это ошибка, когда документация расходится с кодом. Соответственно , когда кто-то сделает репорт, то разработчики выпустят фикс, который исправляет документацию или код.

    Но со статьями иначе, по мимо ошибок, там может быть личное заблуждение автора или в вашем случае - предпочтение, т.е. в отличие от документации статья имеет место субъективному мнению. Поэтому и не надежный источник.