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

    @xfg
    Сделать бекенд и фронтенд контроллеры. Через бекенд контроллер можно менять все поля, через фронтенд контроллер не все. Пользователей и Администраторов сделать используя RBAC. Пользователи могут вызывать фронтенд контроллеры и не могут бекенд контроллеры.
    Ответ написан
    6 комментариев
  • ООП. хранить ли данные в объекте?

    @xfg
    Не оба.
    class Class {
      private $data;
    
      public function __construct($data) {
        $this->data = $data;
      }
      public function data() {
        return $this->data;
      }
    }

    Код для получения data живет за пределами класса. Чтобы понять, почему так, переименуйте Class например в Auto, а data например в color. В общем, суть в том, что у объекта должно быть состояние (свойства объекта) и может быть поведение (методы объекта), которые это состояние меняют. Это должно быть очевидно. Иногда бывают исключения. Очень редко. Почти всегда, можно сделать тру ООП.

    Сейчас у вас, к сожалению, процедурный код, обернутый в номенклатуру ООП :(
    Ответ написан
  • На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

    @xfg
    Любой фреймворк с инверсией зависимостей подойдет. На Symfony и Yii2 точно можно сделать. На русскоязычном форуме Yii по теме DDD очень много обсуждений. Но если не увидели единого согласия по DDD, то скорее всего не читали книгу Эванса или Вернона. Если так, то лучше начать с кого-нибудь из них.

    Многоуровневая архитектура рассказывает нам о слоях presentation, application, domain и infrastructure. С однонаправленным потоком данных. Нижестоящий слой, никогда не должен вызывать вышестоящий. Это значит, что к примеру можно выбросить presentation слой и не придется ничего изменять в оставшихся 3.

    Фактически выходит, что в любой момент можно выбросить фреймворк и заменить другим, так как это presentation layer в многоуровневой архитектуре. Можно даже сначала написать application/domain, проверить их юнит-тестами, а только потом уже задуматься о фреймворке. Application/domain слои никогда ни при каких обстоятельствах не должны вызывать методы фреймворка. Контроллеры фреймворка работают с доменной моделью, через вызовы методов application layer.

    Соответственно, при миграции на другой фреймворк, всё что потребуется, это переписать контроллеры (методы очень простые 1-5 строк) и реализации классов в infrastructure layer если вы завязывали их на фреймворк. Хотя лично я бы, не советовал этого делать. Лучше найти/написать отдельные библиотеки/компоненты под инфраструктурный слой, тем самым облегчив себе жизнь в будущем, когда фреймворк умрет или при очередном релизе мажорной версии.

    Symfony под DDD наилучший выбор, он компонентный, можно подтянуть только то, что нужно. С другой стороны Yii2, он монолитный и вы затяните Active Record и кучу всего еще, чем не будете пользоваться, но джуниор придет и обязательно понавызывает AR или чего-нибудь еще в application/domain слоях, чего вы явно не ожидаете. Поэтому в случае с Yii2 нужен будет тотальный контроль. :)

    Про Laravel не пишу ничего, так как не работал с ним. Но судя по беглому просмотру документации, никаких проблем сделать на нем DDD также нет.
    Ответ написан
    4 комментария
  • Как повысить уровень программирования?

    @xfg
    Если говорим об ООП подходе, то прочитать книгу по DDD от Вон Вернона. Фактически автор описывает, как строить многоуровневую архитектуру, чтобы разделить кашу из бизнес-логики, работы с хранилищем, приложением и представлением, на отдельные слои с однонаправленным потоком данных. Книга задает вектор движения и позволяет минимизировать собственные творческие шатания из стороны в сторону, которые приводят в итоге к спагетти коду.
    Ответ написан
    Комментировать
  • ORM в nodeJS, как это должно работать?

    @xfg
    Не совсем понятно, что хотите получить. Но можете посмотреть typeorm. Это единственная orm в node.js реализующая паттерн data mapper, все остальные реализуют паттерн active record. Но условия выборки всё равно придется писать.
    Ответ написан
    Комментировать
  • С чего начать рефакторинг?

    @xfg
    Без знаний архитектурных принципов делать рефакторинг бессмысленно. Это будет переливание из пустого в порожнее. Уже упомянули прочитать и добавить MVC если его нет. Для CRUD-приложения будет достаточно. Потом можно почитать про GRASP и SOLID. Потом про DDD, которое дает целостное представление об архитектуре. Всё в контексте объектно-ориентированной парадигмы. Для других парадигм ничего посоветовать не могу, не достаточно опыта.
    Ответ написан
    Комментировать
  • Как писать тесты?

    @xfg
    Существуют принципы проектирования позволяющие отделять бизнес-логику от хранения. Тесты будут лаконичные и наименее ломкие. Когда невозможно, мокают методы для работы с бд.

    В любом случае, юнит-тесты не должны быть завязаны на бд. Они должны быть быстрыми и простыми. В противном случае это будут уже более медленные и более ломкие интеграционные тесты.

    Оптимальный вариант писать юнит-тесты на бизнес-логику и функциональные тесты, но только на важный функционал, к примеру такой как оплата или регистрация на сайте, т.к. они очень медленные и самые ломкие, меняете верстку и у вас падают функциональные тесты. Интеграционные тесты, которые вы хотите писать сейчас, не писать вообще.

    Почему? Потому что ни какие тесты вам не дадут 100% гарантии, а вот устроить себе вечный ад из поддержки кучи хрупких тестов, которые десятками валятся от малейшего изменения - запросто. Выбираем золотую середину. Вариант выше, дает достаточную уверенность, что скорее всего всё работает как ожидается. Важный функционал тоже работает как ожидается.

    Если вы будете покрывать тестами всё, что только можно, я вам гарантирую, вы через месяц начнете выкатываться в продакшн с красными тестами.
    Ответ написан
    2 комментария
  • Как мыслить объектами?

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

    Поверьте, в одном сообщении невозможно описать как строить архитектуру приложения. Но понять основные принципы проектирования можно почитав книгу Vaughn Vernon - Implementing Domain-Driven Design. Но эти принципы популярны в энтерпрайз сегменте со сложной бизнес-логикой и большими бюджетами, в основном на языке Java (качественно, дорого, медленно). Типичные интернет-приложения в своей массе используют другой подход, там объекты это скорее контейнер для функций, объединенные по принципу "так решил разработчик", у тех кто знает о solid/grasp немного получше, у тех кто нет - немного похуже, но в целом это подход - бысто, дешево, менее качественно и в целом, не особо отличается от процедурного программирования.
    Ответ написан
    Комментировать
  • Как выполнять последовательно действия через определенный промежуток времени?

    @xfg
    Поискать таск менеджер с возможностью отложенной обработки задач. Например kue умеет отложенные задачи ставить в очередь https://github.com/Automattic/kue#delayed-jobs и затем написать обработчик этих задач, который будет что-то делать, например отправлять данные пользователю через сокет. Можно поискать альтернативы kue работающие напрямую с памятью, если не хотите раздувать стек технологий редисом. Но более-менее популярных альтернатив я не встречал.
    Ответ написан
    1 комментарий
  • Есть идея по защите от спама, но сработает ли?

    @xfg
    Для ботов общего назначения (спамят все сайты какие найдут), подойдет любая примитивная защита. Если бота пишут под конкретный сайт, ничего не поможет. Много раз уже обсуждалось, спам можно победить, только если злоумышленнику станет финансово невыгодно спамить ваш сайт. Если ему будет выгодно, он будет спамить, даже руками. Ничего его не остановит.

    Ваше решение обладает излишней сложностью для ботов общего назначения и в то же время не сильно затруднит работу программисту, который будет писать целевого бота под ваш сайт. Достаточно скрытого поля через css и на сервере убедиться, что оно осталось незаполненым. Поможет избежать спама от ботов общего назначения. С целевыми ботами и ручными спамерами борются кто как используя комплекс мер, регистрируют по номеру телефона, привлекают пользователей к борьбе со спамом, выдают капчу на подозрительную активность и прочее Можете проанализировать большие сайты, если интересно. Но если ваш сайт не является таким же интересным для спамеров, то и усложнять так всё не имеет смысла.
    Ответ написан
    3 комментария
  • В чем косяк (полиморфизм)?

    @xfg
    В программировании несколько различных видов полиморфизма. Вам следовало уточнить, о каком из них идет речь. Собеседующий с вами конечно же не совсем корректен, так как простейшая форма полиморфизма в вашем примере все же присутствует. Другое дело, что в php под полиморфизмом обычно понимают полиморфизм подтипов. Выглядит так
    interface UnitInterface {
      public function setHp();
    }
    class Warrior implements UnitInterface {
      public function setHp() {...}
    }
    class Medic implements UnitInterface {
      public function setHp() {...}
    }
    
    class MainProgram {
      private $unit;
    
      public function __construct(UnitInterface $unit) {
        $this->unit = $unit;
      }
      public function run() {
        return $this->unit->setHp();
      }
    }
    
    echo (new MainProgram(new Warrior())->run();

    Идея в том, что конструктор класса MainProgram ничего не знает о конкретных реализациях ваших юнитов. Он знает только о том, что они должны удовлетворять интерфейсу UnitInterface. В будущем если у вас хорошо спроектирован интерфейс, то вы сможете заменить одну реализацию юнита на другую, не изменяя код внутри MainProgram. Таким образом, вы соблюдаете принцип открытости/закрытости из SOLID, который говорит, что классы должны быть открыты для расширения, но закрыты для изменений.
    Ответ написан
    1 комментарий
  • Можно ли сделать псевдо-"движок" сайта на include?

    @xfg
    Ваше решение уже совсем из прошлого века. Возьмите https://www.slimframework.com/ и тут посмотрите как сделать layout stackoverflow.com/a/37163209/2868530

    Будет похоже на что-то современное.
    Ответ написан
    Комментировать
  • Как вы планировали своё учебное время?

    @xfg
    В любом длительном деле главное заинтересованность. Вам нужно начать делать любой интересный для вас проект. В процессе, когда вам требуется сделать то или иное для вашего проекта, вы гуглите, читаете, делаете и даже что-то запоминаете. Изначально по любому вопросу будет требоваться гугл, но очень скоро обнаружите, что уже изучили добрую половину API языка javascript, спроектировали и сверстали несколько UI экранов вашего проекта.

    Радуйтесь маленьким победам. Когда вы делаете интересный лично для вас проект, вы понимаете зачем вы сейчас читаете тот или иной материал. Вы практикуетесь, вы решаете реальные задачи. Я никак не планировал учебное время, я 15 лет назад захотел свой сайт, открыл блокнот, нашел в сети учебник по html читал и сразу делал свой сайт. Потом захотел бекенд и открыл php.net, далее возникло желание, чтобы код был не просто лапшой, а имел какую-то структуру так познакомился с различными фреймворками. Потом захотел, на свой код тесты и так познакомился с TDD/BDD. Далее захотел независимую от фреймворка бизнес-логику и так познакомился с DDD. Ну и так далее.

    Английский учил также. Сразу взял интересную мне статью и запоминал все важные незнакомые в ней слова. Иногда что-то о попадавшихся грамматических конструкциях читал если смысл предложения оставался не понятным зная все слова. Важно то, что я никогда не изучал всё сразу, только то, что нужно мне прямо сейчас, для решения моей задачи.

    Если задуматься, все наши предки делали примерно также. Сначала была задача, а только потом они искали решение этой задачи. Человек захотел подняться в небо и только потом, он искал решение. Не наоборот. И это был не боинг.
    Ответ написан
    Комментировать
  • Как перенести проект с Codeigniter на Yii2?

    @xfg
    Нужно писать бизнес-логику независимой от фреймворка. Обкладывая доменную модель интерфейсами со всех сторон. Тогда при переезде на любой другой фреймворк переписать придется только реализации этих интерфейсов, контроллеры фреймворка, которые должны состоять из 2-3 строк кода и вьюшки. Можете погуглить и посмотреть реализации DDD архитектур например.

    Но сейчас нет выбора, нужно пересматривать каждый кусок кода, который делает обращения к codeigniter. То есть по-сути заново написать проект. На Yii2 тоже 99% пишут зависимый от фреймворка код. Можно перед переездом почитать что-то по архитектуре и сделать БЛ максимально независимой от фреймворка. Чтобы в будущем здесь не появился очередной вопрос "Как перенести проект с Yii2 на Symfony?".

    Но не всегда это оправдано. Это не быстро и не для простых crud проектов. Поэтому возможно будет выгоднее с каждым переездом на новый фреймворк переписывать проект, если он относительно не сложный, чем пытаться выстроить архитектуру вокруг всего этого.
    Ответ написан
    Комментировать
  • Как вы относитесь к такому тестовому заданию?

    @xfg
    Ctrl + S в браузере. Результат отправить заказчику.
    Ответ написан
    1 комментарий
  • Как правильно протестировать такой класс?

    @xfg
    Тестировать нужно только публичные методы класса. Вообще лучше внедрить внешние сервисы которые отвечают за сохранение и выгрузку в конструктор этого класса, замокать работу с базой/выгрузку и написать чистый юнит-тест. Такие тесты будут быстрыми, короткими и легко поддерживаемыми. На самый важный функционал сайта потом можно будет написать несколько медленных функциональных тестов. И всё, этого вполне достаточно. Сейчас же вы хотите интеграционный тест написать. Уродливый, медленный, с кучей лишнего бойлерплейта. В этом очень мало смысла. Нужно писать юнит-тесты на свой код и только для важных фич типа оплаты или регистрации писать функциональные тесты. Интеграционные тесты не писать вообще. Помните, каждая лишняя написанная вами строка кода, требует вашей дальнейшей поддержки в будущем. Пишем тесты, которые дают наибольший результат при минимуме кода.
    Ответ написан
    Комментировать
  • Какой выбрать набор инструментов и порядок их изучения для веба?

    @xfg
    Изучай синтаксис JS если хочешь, но читай умные книжки по архитектуре. Культура кода в JS крайне низкая сейчас. А Node.js это просто платформа для выполнения javascript кода на сервере. Учить там нечего, открыл api, да сделал. Но сначала конечно нужно изучить синтаксис любого языка, который поддерживает ту парадигму, которая тебе интересна, иначе книги по архитектуре будут совсем непонятны. Сейчас доминирует ООП. Поэтому можешь брать любой который нравится JS, Python, PHP, Ruby. Без разницы, все они умеют ооп, в JS используют prototype-based, но это просто один из стилей объектно-ориентированного программирования, суть не меняется. Ну и в JS ооп немного коцаное, но есть языки компилирующиеся в JS призванные исправить это недоразумение, типа TypeScript.
    Ответ написан
    Комментировать
  • Какие есть ресурсы для изучения английского (читать/писать), в которых информация изложена максимально кратко, но полно?

    @xfg
    Не ясен уровень подписавшихся. Если околонулевой, то любой источник по группе времен simple в активном и пассивном залоге. Дальше почитать о технике запоминания слов с помощью воображения и сразу читать интересную вам информацию на английском и как встречается незнакомое слово важное для общего понимания, запоминать.

    Быть максимально адекватным, не брать с нулевой базой худ. лит., начать с простого, например с статей из https://simple.wikipedia.org, как будет получаться читать без постоянного заглядывания в словарь, то можно перейти к группам времен continuous и perfect и дальше пробовать читать всё и продолжать набирать слова. Не нужно сразу бежать и пытаться выучить все группы времен особенно какой-нибудь perfect continuous, когда эта группа используется в 3-5% случаев. Только потратите время и всё равно всё забудете. Лучше несколько раз прочитать группу simple, которая используется в 80% случаев, довести до автоматизма, а затем переключаться на менее популярные группы.
    Ответ написан
    3 комментария
  • Меньше стек технологий, больше шанс устроиться на удаленную работу?

    @xfg
    Есть вакансии в веб-студиях, где нужен человек, который уже готовую верстку поставит на wordpress/bitrix, установит нужные модули и редко (почти никогда) напишет свой модуль. В общем ставят задачу собрать сайт и отдать контент-менеджеру. В такой вакансии будет указан стек технологий, но по факту, всё что нужно знать, это куда воткнуть вывод данных в html и как загрузить своё поделие на сервер по ftp. Таких вакансий в PHP довольно много, можно устроиться с минимальным набором знаний.

    С другими языками сложнее, там нет конвеерных веб-студий делающих сайты на цмс за 1 день, как в PHP. Там как правило командой делают нетипичный проект некоторое время для решения бизнес-задач и к таким разработчикам требования значительно выше, знания алгоритмов, архитектуры, паттернов, системы контроля версий, фреймворков, TDD и т.п.
    Ответ написан
    2 комментария
  • Точно и подробно про защиту от инъекций в php, mysql?

    @xfg
    Подготовленные запросы.

    Старайся вообще читать по меньше хабр и побольше документации от разработчиков инструмента, которым пользуешься. Хабр и другие блог платформы это субъективное мнение автора. Не надежный источник информации.
    Ответ написан
    3 комментария