Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (4)

Наибольший вклад в теги

Все теги (20)

Лучшие ответы пользователя

Все ответы (18)
  • На что можно заменить \r\n\ в php или как выявить символ переноса каретки в linux?

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

    Ответ написан
  • Как сказать по-русски слово yield???

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

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

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

    т.е. полностью аналога вроде как нет, но за счет окружающего контекста смысл придается тот же.
    Ответ написан
  • 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 строится на этой библиотеке в абсолютном большинстве серверных скриптовых языков)
    Ответ написан
  • Каким должен быть правильный контроллер?

    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
    Ответ написан
  • Как произвести валидацию модели до сохранения при использовании паттерна Repository?

    Deroy
    @Deroy
    Senior Developer, Software Architect
    при использовании паттерна репозиторий вам стоит перестать думать о модели которая путешествует через систему, как о месте где должна случаться валидация входных данных. Такой подход получил распространение благодаря RAD-framework'ам (Yii и ему подобные) - упрощенка цель которой - быстрая скорость разработки.

    Если смотреть на архитектуру с точки зрения "чистоты", то:

    Модель которая путешествует через всю систему должна содержать в себе только доменную логику, или не содержать ее вовсе (т.е. по факту являться Value-object'ом).

    Валидация входных данных описывается отдельной моделью - моделью реквеста - и содержит в себе логику валидации/маппинга/и пр.

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

    Последнее вы уже сделали = репозиторий как раз оно.

    Так что ваше предположение - верно.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (1)