Ответы пользователя по тегу PHP
  • Каким должен быть правильный контроллер?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    Отвечу с позиции опыта на больших и средних проектах:

    Как говорят другие ответчики - D3lphi и Александр Шаповал , контроллер должен содержать минимум логики, и нет "единого правильного способа" его реализовать.

    Однако, исходя из своей практики, для обеспечения таких качеств проекта как сопровождаемость, тестируемость и изменяемость, я поступаю следующим образом:

    Контроллер, каким бы он не был и как бы не организовывался - содержит только обработку входных данных (валидация и преобразование) и преобразование выходных данных в нужный формат

    Логика и оркестрация которая в 80% случаев и является предметом спора о том как стоить контроллер (речь всех этих вызовах сервисов, управления потоками данных между ними, последовательности действий и пр), находятся в отдельном классе согласно паттерну Unit of Work - что позволяет легко покрыть все что связано с логикой вменяемыми юниттестами без танцев с бубном.

    Т.е. структура в итоге такая:

    {view} <--> {controller} <---> {unit_of_work} -->>> {{{..lots of services...}}}

    по сути класс семейства UnitOfWork - это полный сценарий обработки входных и выходных данных , с оркестрацией потоков данных и порядком действий, возможно какой то мелкой вспомогательной логикой, эдакий фронтенд над сервисами, заточенный под каждое конкретное действие извне (сам паттерн предполагает что класс создается на каждый отдельных случай и почти один в один описывает UseCase логику как она пришла от бизнеса (заказчика/аналитиков/моей головы/etc).

    Сами классы семейства UnitOfWork (имеется ввиду в одном приложении) могут иметь собственные иерархии наследования и композии - в угоду бизнес логики и дабы не дублировать код - главный критерий - это полная независимость бизнес и сервис слоев от контроллера. - что и является на мой взгляд "каноничным" вариантом реализации композии M и C в MVC.

    У меня, как у человека который не пишет фронты в принципе (имею ввиду сам UX/UI), но постоянно занимается сервисами, рестом, библиотеками - этот подход выработался по одной просто причине:
    взаимодействие с командой, я предоставляю "библиотеку"(не в классическом понятии этого слова) полностью абстрагированную от любых фронтов, оттестированную, полностью функциональную - а люди пишут к ней шаблонные обвязки где только валидация данных и рендер нужного формата под HTTP/Sockets/AMQP/etc типа всяких там CRUD/REST или RPC
    Ответ написан
  • Как сделать автоматический деплой PHP приложения?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    есть еще хороший инструмент magephp.com

    в отличии от Deployer работает более стабильно (сравнивал с версией 2 - сейчас если не ошибаюсь есть версия 3 - её не смотрел.)
    и в отличии от упомянутого Rocketeer - гораздо более продуманная и простая архитектура - писать кастомные процессы развертывания под него в разы проще чем под Rocketeer.
    Ответ написан
  • На что можно заменить \r\n\ в php или как выявить символ переноса каретки в linux?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    в PHP существует константа PHP_EOL - строковое значение перевода каретки под ту платформу на который работает код.

    Ответ написан
  • При запуске одного теста в PHPUnit инициализуется ли только его dataProvider или все?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    теоритически не должны, так как провайдеры мапятся к тесту аннотациями и внутри phpUnit происходит примерно следующее:

    1) загружается класс теста
    2) он реверсится, находятся все методы тестов
    а вот дальше возможны два варианта развития событий:
    а)
    3) начинается цикл по тестам,
    4) запуская каждый тест, сначала ревёрсятся его аннотации и вызываются дата-провайдеры
    5) запускается сам тест и ему передаются результаты работы провайдеров
    б)
    3) реверсятся все аннотации всех тестов
    4) выполняются все дата провайдеры
    5) запускаются тесты.

    Собственно, пардон за наглость, но проще проверить экспериментально. или почитать код фреймворка. заодно нам расскажешь. =)
    Ответ написан
  • Как сказать по-русски слово yield???

    Deroy
    @Deroy
    Senior Developer, Software Architect
    ну по смыслу - генерирует, отдает.
    чисто речевой перевод - много раз обсуждая как программист с программистом, используем прямой англицизм, т.е. "йилдит".

    примеры из повседневной речи:
    <..> и генератор будет йилдить до тех пор пока <..>
    <...> каждый раз йилдит новый джоб <...>
    для разговорной речи этого более чем достаточно.

    более литературно и по русски:
    <...> он будет отдавать значения с шагом в 10 единиц <..>
    <..> должен выдавать срез заданного размера <...>

    т.е. полностью аналога вроде как нет, но за счет окружающего контекста смысл придается тот же.
    Ответ написан
  • Как лучше выкладывать релизы при работе по модели git flow?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    за интерфейс не скажу... наверно подойдет любой гит-менеджер который рисует сеть коммитов в виде древа/графа

    а вот насчет релизов и проблем с пониманием что откуда взялось - что бы было меньше коммитов и история была понятней - можете попробовать использовать --squash при мердже фичи в dev - тогда у вас будет по одному коммиту на каждую законченную фичу.
    Ответ написан
  • Web-разработка. Уровень погружения в язык программирования: PHP vs JavaScript. Где "глубже"?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    Многое несомненно зависит от того как позиционируется PHP бэкенд в составе проекта,
    однако в целом если говорить про разработку приложений на PHP как такового (без зоопарка вокруг)
    список инструментов примерно следующий (представлены самые популярные)

    Стандарты - по хорошему надо прочитать и понять всё что издает php-fig в сфере юзерленд кода,
    самые важные - PSR 0-4

    Вспомогательные (обязательные) технологии - YAML, XML, CSV, JSON;
    Библиотеки "все-в-одном" - на бэкенде не водятся (да здравствует linux-way);
    Фремворки общего назначения, скелеты приложений - Yii (1,2), Symphony2, ZendFramework2;
    CMS-фреймфорки - Drupal, ... Wordpress? ищите под задачу;
    Модульность, Зависимости - Composer и все что с ним связано, PEAR/PECL (потихоньку отмирает);
    Сборка - Phing (хотя я собираю php-проект gulp'ом - у него API приятнее);
    Тестирование - PHPUnit, Behat, CodeCeption;
    Деплой(Развертывание релизов) - Mage (aka Magallanes), Deployer
    Помощники - Vargant, Docker (тестирование и разработка в готовых окружениях)

    Здесь я не упоминал того что нужно знать о самом языке и его компонентах.

    теперь поговорим о зоопарке..

    технологии и зоопарк специфичный только для PHP:

    Сервера приложений - php-fpm, apache-mod-php;
    Кэш и быстродействие - APC (APCu для PHP >= 5.5)
    дебаг - ZendDebug, XDebug, XHProf

    Далее то что не отличается от одного серверного языка к другому.
    это часть ответа безгранично велика на самом деле =)

    Сервера и прокси - Nginx, Apache, Varnish, etc.
    Кэши и NoSQL - Memcached, Redis, Mongo, etc.
    СУБД - MySQL, PostreSQL, etc..
    Поисковые индексы - ElasticSearch, Sphinx
    Очереди и межпроцессовое взаимодействие - RabbitMQ, ZeroMQ, linux-sockets, posix-treads
    Протоколы взаимодействия (4 уровень OSI) - HTTP(во всех его подробностях! просто MUST HAVE), POP, SMTP, IMAP, REPL.
    Траспортные Протоколы (3 уровнь OSI) - TCP, UDP
    Библиотеки уровня системы - cURL (абсолютный MUST HAVE - большинство взаимодействия поверх HTTP строится на этой библиотеке в абсолютном большинстве серверных скриптовых языков)
    Ответ написан