Помогите расшифровать ответ от приставов.

У меня есть в Братске полная тезка, как по ФИО, так и по дате рождения. На мою работу присылали письма, что я якобы должна оплатить долг, хотя там стоит не мой адрес прописки. Я написала на них жалобу и они прислали вот такой ответ. Но я не совсем понимаю, что здесь написано.

Уведомление с информацией по находящемуся на исполнении исполнительному производству в отношении физического и юридического лица

Уведомление с информацией по находящемуся на исполнении исполнительному производству в отношении физического и юридического лица

Ваше заявление от 15.10.2018 «Заявление о предоставлении информации о ходе исполнительного производства» рассмотрено. Сведения об исполнительном производстве 103354/18/38007-ИП предоставлены по состоянию на 24.10.2018:

Расчеты по ИП:

Операция: Начисление, дата проводки: 20.06.2018, сумма 14 284.86 р., тип назначения суммы: Основной долг.

Документы по ИП:

Постановление о возбуждении исполнительного производства (O_IP_RES_REOPEN, 25071580132171) от 20.06.2018 № 38007/18/577288. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ПФ (O_IP_RED_PF, 25071580139028) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос произвольный (O_IP_RED_ANY, 25071580139019) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ЗАГС (O_IP_RED_ZAGS, 25071580139030) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ГИБДД МВД России на получение сведений о зарегистрированных автомототранспортных средствах (МВ) (O_IP_RED_AUTO, 25071580148268) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ФМС (МВ) (O_IP_RED_GO_FMS, 25071580148274) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в банки (Рег. МВ) (O_IP_RED_BANK_REG, 25071580139021) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ПФР на получение сведения о заработной плате, иных выплатах и вознаграждениях застрахованного лица (МВ) (O_IP_RED_SALARY, 25071580148315) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в банк (МВ) (O_IP_RED_IP_BANKS, 25071580148277) от 20.06.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Постановление об обращении взыскания на заработную плату (O_IP_ACT_ZP, 25071585053576) от 13.07.2018 № 38007/18/729490. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Постановление о запрете на регистрационные действия в отношении транспортных средств (O_IP_ACT_BAN_GIBDD, 25071585877446) от 18.07.2018 № 38007/18/658701. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Запрос в ПФР на получение сведения о заработной плате, иных выплатах и вознаграждениях застрахованного лица (МВ) (O_IP_RED_SALARY, 25071594765548) от 18.09.2018. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Постановление об обращении взыскания на заработную плату (O_IP_ACT_ZP, 25071595996868) от 27.09.2018 № 38007/18/861478. СПИ: Татаринова Ирина Васильевна, ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580159668) № 6660650424. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580160698) от 20.06.2018 № 172130439224. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580176083) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580174618) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580171350) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580154346) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580158868) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580155383) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580150423) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580424633) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580159112) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580175625) от 20.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580180018) от 21.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580178354) от 21.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580334115) от 21.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580330240) от 22.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580415668) от 22.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580966425) от 23.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071580639608) от 25.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071581126245) от 27.06.2018. ID ИП 25071579853471.

Ответ из ведомства (MTV_EXTERNAL_RESPONSE, 25071584657317) от 12.07.2018. ID ИП 25071579853471.

PSR Стандарты


PSR — Чуть больше, чем стиль оформления кода.
Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.
Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…
Небольшая предыстория, которая вдохновила меня на написание этой статьи. За последние полгода мне пришлось провести множество собеседований на позицию Middle PHP-Developer.
Один из вопросов, который я задавал всем кандидатам, был:- «Знаете ли Вы, что такое PSR?»


Как оказалось, практически всем кандидатам была знакома эта аббревиатура. Однако пытаясь рассказать подробнее, почти все разработчики указывали в основном на то, что это стандарт оформления кода (code style). Только некоторые упоминали про PSR-4 автозагрузку (использует Composer) и PSR-3 Logger Interface (в сети очень много однородных статей про PSR-0-1-2-3-4).
Мне кажется это весьма странным, так как термин PSR существует достаточно давно (уже более 10 лет) и каждый год набирает все большую популярность. Поэтому, думаю, будет неплохо собрать все в кучу и сделать обзор PSR стандартов.

PHP-FIG и PSR

PHP-FIG (PHP Framework Interop Group) — организованная в 2009 году группа разработчиков, основная идея которой находить способы совместной работы, выделяя общие концепции в разработке проектов на PHP.
Проще говоря, ребята стараются выделить что-то общее между различными проектами на разных фреймворках и сформировать некие стандарты (рекомендации) для дальнейшего периспользования.
Участники PHP-FIG
ReactPHP, Composer, Laminas Project (переименованный Zend Framework), Yii framework, CakePHP, Slim, Joomla, Magento, Drupal, phpBB, phpDocumentor и другие.
PSR (PHP Standards Recommendations) — описывает общие концепции, которые уже были проверены и отработаны. Вероятно при создании PSR, группа PHP-FIG вдохновлялась Java Community Process, а первый стандарт был принят в 2010 году.
Список PSR стандартов расширяется новыми, а сами стандарты делятся на категории:
Автозагрузка, Интерфейсы, HTTP и Стиль кодирования,
каждому из которых присваивается определенный статус:
Принят, Устаревший, Черновик и Заброшенный.
Далее мы рассмотрим принятые PSR стандарты по категориям:

Автозагрузка


Разработчики, которые «недолго» работают с PHP, вероятно не знакомы с проблемами импорта классов, ведь есть пространства имен, а сейчас вообще трудно представить проект без менеджера зависимостей Composer, которой решает все вопросы с автозагрузкой классов.
Однако так было не всегда, пространства имен появились только в PHP 5.3 (это был 2009 год), а первый релиз Composer состоялся в марте 2012 года. Но вот сам PHP существует гораздо дольше, как Personal Home Page с 1995 года и как Hypertext Preprocessor с 1998 года, однако только PHP 5 включает «полноценную объектную модель», релиз которого был в июле 2004 года. Бородатым разработчикам того времени приходилось как-то сражаться со всеми возникшими проблемами при импорте классов.
Не самый плохой пример импорта классов на PHP 14-ти летней давности:
Пример кода class MyLib { private $CI; public function __construct() { $this->CI = &get_instance(); $this->CI->load->library(‘encrypt’); $this->CI->load->library(‘session’); $this->CI->load->library(‘url’); $this->CI->load->helper(»); $this->CI->load->helper(‘cookie’); $this->CI->load->helper(’email’); } … }
(Напишите в комментариях, если узнали где использовался данный подход).

  • PSR-0 — Autoloading Standard Устарел
    После релиза пространства имен в 2009 году, в 2010 году был опубликован первый стандарт, который стал революцией в решении проблем автозагрузки классов и стал первым шагом на пути объединения фреймворков — наличие общей структуры директорий.
    Пример реализации
  • PSR-4 — Autoloading Standard
    Прогресс не стоит на месте и в конце 2013 года PHP-FIG публикуют новый стандарт автозагрузки классов. Он может использоваться в дополнение к PSR-0, а также любой другой спецификации автозагрузки. Стандарт также описывает, где размещать файлы, которые будут автоматически загружаться в соответствии со спецификацией. Данный стандарт решает некоторые проблемы/ограничения PSR-0 и используется по умолчанию в Composer.
    Пример реализации

Сейчас, сложно встретить разработчика, который бы смог рассказать о тонкостях работы автозагрузки в PHP, в основном все ссылаются на работу с Composer, не задумываясь как все устроено под капотом.
В дополнение, оставлю ссылку на статью, которая подробно описывает работу с пространством имен, решенные проблемы и PSR-4.

Интерфейсы


PHP развивается, набирает все большую популярность, а его инфраструктура пополняется огромным количеством различных инструментов.
Появляются проблемы с изучением и переиспользованием однотипного функционала, а менеджер зависимостей может затянуть целую кучу несвязанных однотипных зависимостей. (тут JavaScript разработчик улыбнется).
Поэтому принято решение стандартизировать некоторые общие концепции:

  • PSR-3: Logger Interface
    Основная цель данного интерфейса – простым и универсальным способом стандартизировать реализацию логирования. К данному интерфейсу прилагается спецификация, которая описывает в каких случаях какой из методов рекомендуется использовать.
    LoggerInterface interface LoggerInterface { public function emergency($message, array $context = array()); public function alert($message, array $context = array()); public function critical($message, array $context = array()); public function error($message, array $context = array()); public function warning($message, array $context = array()); public function notice($message, array $context = array()); public function info($message, array $context = array()); public function debug($message, array $context = array()); public function log($level, $message, array $context = array()); }
    Если Ваш проект нуждается в расширенном функционале, МОЖНО расширять данный интерфейс, но СЛЕДУЕТ сохранять совместимость с описанными в данном стандарте правилами. Это позволит сторонним библиотекам, применяемых при разработке приложения, использовать централизованную систему логирования.
    На сегодняшний день нет необходимости самостоятельно реализовывать данный интерфейс (разве что в целях обучения), так-как существует отличное решение Monolog для реализации логирования, которое используется во многих проектах.
  • PSR-6: Caching Interface
    Кэширование широко используется для повышения производительности любого проекта.
    Кэширование так-же является одной из наиболее распространенных функций многих CMS, фреймворков и библиотек.
    Это привело к ситуации, когда многие библиотеки реализуют свои собственные системы кэширования с различными уровнями функциональности. Эти различия заставляют разработчиков изучать несколько систем, которые могут предоставлять или не предоставлять необходимую им функциональность. Кроме того, разработчики кеширующих библиотек сами сталкиваются с выбором между поддержкой только ограниченного числа платформ или созданием большого количества классов адаптеров.
    Чтобы решить эти проблемы был принят общий стандарт для библиотек реализующих кэширование, он включает в себя несколько интерфейсов:
    CacheItemInterface и CacheItemPoolInterface interface CacheItemInterface { public function getKey(); public function get(); public function isHit(); public function set($value); public function expiresAt($expiration); public function expiresAfter($time); }
    interface CacheItemPoolInterface { public function getItem($key); public function getItems(array $keys = array()); public function hasItem($key); public function clear(); public function deleteItem($key); public function deleteItems(array $keys); public function save(CacheItemInterface $item); public function saveDeferred(CacheItemInterface $item); public function commit(); }
    Наверное самая годная реализация PSR-6 это Symfony Cache. А вот одна из самых старых реализаций — это Laminas Cache (бывший Zend).
  • PSR-11: Container Interface
    Основная цель стандартизировать, как фреймворки и библиотеки будут использовать (DIC) контейнер для доступа к объектам и параметрам. Для этого был описан ContainerInterface.
    ContainerInterface interface ContainerInterface { public function get($id); public function has($id); }
    Спецификация PSR-11 не описывает то, как необходимо регистрировать зависимости в проекте, однако дает четкую рекомендацию как делать не нужно:
    Пользователи НЕ ДОЛЖНЫ передавать контейнер в объект, чтобы объект мог получить свои собственные зависимости. Это означает, что контейнер используется в качестве Service Locator, который обычно не рекомендуется использовать.
    Отсюда, возникает простой вопрос: «Как это вообще работает»?
    На самом деле все просто, на помощь приходит паттер Factory, который возьмет на себя задачу создания объекта. А вот сам класс фабрики уже может принимать ContainerInterface и передавать в создаваемый объект необходимые зависимости.
    Пример кода ConfigProvider
    , ‘factories’ => , ];
    MyHandlerFactory
    class MyHandlerFactory { public function __invoke(ContainerInterface $container) : RequestHandlerInterface { $dep = $container->get(MyDepInterface::class); return new MyHandler($dep); } }
    MyHandler
    class MyHandler { private $dep; public function __construct(MyDepInterface $dep) { $this->dep = $dep; } public function __invoke(ServerRequestInterface $request): RequestHandlerInterface { // } }
    Данный подход использует middleware framework Mezzio (это бывший Zend Expressive), что позволяет соблюдать принципы SOLID и получить дополнительную гибкость при создании объектов.
  • PSR-13: Hypermedia Links
    Не самый популярный стандарт, который предоставляет несколько интерфейсов, чтобы унифицировать общий формат hypermedia ссылок.
    LinkInterface, EvolvableLinkInterface и LinkProviderInterface EvolvableLinkProviderInterface LinkInterface
    interface LinkInterface { public function getHref(); public function isTemplated(); public function getRels(); public function getAttributes(); }
    EvolvableLinkInterface
    interface EvolvableLinkInterface extends LinkInterface { public function withHref($href); public function withRel($rel); public function withoutRel($rel); public function withAttribute($attribute, $value); public function withoutAttribute($attribute); }
    LinkProviderInterface
    interface LinkProviderInterface { public function getLinks(); public function getLinksByRel($rel); }
    EvolvableLinkProviderInterface
    interface EvolvableLinkProviderInterface extends LinkProviderInterface { public function withLink(LinkInterface $link); public function withoutLink(LinkInterface $link); }
    В качестве примера, можно рассмотреть использование hypermedia ссылок в контексте HTML и в различных форматах API. При этом, если контекст использования ссылок в HTML понятен, то с API поможет разобраться статья «Hypermedia — то без чего Ваше API не совсем REST».
    Примеров использования данного стандарта не много: и Html Model.
  • PSR-14: Event Dispatcher
    Целью этого PSR является создание общего механизма для диспетчеризации событий, чтобы библиотеки и компоненты могли свободно использоваться в различных приложениях и средах. Для этого предоставляется несколько интерфейсов:
    EventDispatcherInterface, ListenerProviderInterface и StoppableEventInterface EventDispatcherInterface
    interface EventDispatcherInterface { public function dispatch(object $event); }
    ListenerProviderInterface
    interface ListenerProviderInterface { public function getListenersForEvent(object $event) : iterable; }
    StoppableEventInterface
    interface StoppableEventInterface { public function isPropagationStopped() : bool; }
    Диспетчеризация событий — это распространенный и хорошо протестированный механизм, позволяющий разработчикам легко и последовательно расширять логику приложения. Детально данный стандарт хорошо описывает статья «PSR-14 — главное событие в PHP».
    Чтобы попробовать в действии, предлагаю взглянуть на реализацию Symfony Event Dispatcher, YiiSoft Event Dispatcher и другие.
  • PSR-16: Simple Cache
    Обратите внимание на PSR-6, это действительно «мощная» спецификация для реализации системы кеширования, однако в большинстве проектов такая реализация может оказаться избыточной.
    Поэтому был принят PSR-16. Этот более простой подход направлен на создание стандартизированного оптимизированного интерфейса для общих случаев.
    CacheInterface interface CacheInterface { public function get($key, $default = null); public function set($key, $value, $ttl = null); public function delete($key); public function clear(); public function getMultiple($keys, $default = null); public function setMultiple($values, $ttl = null); public function deleteMultiple($keys); public function has($key); }
    В списке реализаций все тот-же Symfony Cache и Laminas Cache (бывший Zend).

HTTP


Если речь идет о WEB-приложении, то не важно на сколько сложная в нем бизнес-логика, по факту оно делает всего 2 вещи — принимает Request и отдает Response. Это значит, что так или иначе, приходится реализовывать эти объекты у себя в проекте.
Пожалуй, одной из самых сложных задач, которая нередко возникает является переиспользование кода между различными проектами. Если хорошо абстрагированные участки бизнес логики, некоторые компоненты и модули перенести возможно (с минимальными затратами), то с переносом более высокого уровня фреймворков (например контроллеров) возникают сложности.
Группа PHP-FIG пытается исправить данную проблему и предоставляет стандарты абстракции над HTTP.

  • PSR-7: HTTP Message Interfaces
    Цель данного стандарта, предоставить общий набор интерфейсов для фреймворков, чтобы последние могли использовать одинаковые абстракции над Request и Response объектами. Это позволит разработчикам писать переиспользуемый, независимый от фреймворка код. Спецификация данного стандарта достаточно объемна:
    MessageInterface, RequestInterface, ServerRequestInterface, ResponseInterface, StreamInterface, UriInterface и UploadedFileInterface MessageInterface
    interface MessageInterface { public function getProtocolVersion(); public function withProtocolVersion($version); public function getHeaders(); public function hasHeader($name); public function getHeader($name); public function getHeaderLine($name); public function withHeader($name, $value); public function withAddedHeader($name, $value); public function withoutHeader($name); public function getBody(); public function withBody(StreamInterface $body); }
    RequestInterface
    interface RequestInterface extends MessageInterface { public function getRequestTarget(); public function withRequestTarget($requestTarget); public function getMethod(); public function withMethod($method); public function getUri(); public function withUri(UriInterface $uri, $preserveHost = false); }
    ServerRequestInterface
    interface ServerRequestInterface extends RequestInterface { public function getServerParams(); public function getCookieParams(); public function withCookieParams(array $cookies); public function getQueryParams(); public function withQueryParams(array $query); public function getUploadedFiles(); public function withUploadedFiles(array $uploadedFiles); public function getParsedBody(); public function withParsedBody($data); public function getAttributes(); public function getAttribute($name, $default = null); public function withAttribute($name, $value); public function withoutAttribute($name); }
    ResponseInterface
    interface ResponseInterface extends MessageInterface { public function getStatusCode(); public function withStatus($code, $reasonPhrase = »); public function getReasonPhrase(); }
    StreamInterface
    interface StreamInterface { public function __toString(); public function close(); public function detach(); public function getSize(); public function tell(); public function eof(); public function isSeekable(); public function seek($offset, $whence = SEEK_SET); public function rewind(); public function isWritable(); public function write($string); public function isReadable(); public function read($length); public function getContents(); public function getMetadata($key = null); }
    UriInterface
    interface UriInterface { public function getScheme(); public function getAuthority(); public function getUserInfo(); public function getHost(); public function getPort(); public function getPath(); public function getQuery(); public function getFragment(); public function withScheme($scheme); public function withUserInfo($user, $password = null); public function withHost($host); public function withPort($port); public function withPath($path); public function withQuery($query); public function withFragment($fragment); public function __toString(); }
    UploadedFileInterface
    interface UploadedFileInterface { public function getStream(); public function moveTo($targetPath); public function getSize(); public function getError(); public function getClientFilename(); public function getClientMediaType(); }
    А более детальное описание с примерами можно разобрать в статье «PSR-7 в примерах».
    Laminas Diactoros (бывший Zend Diactoros) — является отличной реализацией PSR-7. И при этом в экосистеме PHP популярны симфони компоненты, среди которых Symfony HTTP-Foundation. Данный компонент не реализовал поддержку PSR-7, но предоставил мост, который ранее работал через Zend Diactoros, но сейчас использует другую имплементацию psr-7.
  • PSR-15: HTTP Handlers
    Спецификация данного стандарта описывает интерфейсы для обработчиков HTTP-запросов
    и компонентов промежуточного программного обеспечения HTTP-сервера.
    RequestHandlerInterface и MiddlewareInterface RequestHandlerInterface
    interface RequestHandlerInterface { public function handle(ServerRequestInterface $request): ResponseInterface; }
    MiddlewareInterface
    interface MiddlewareInterface { public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface; }
    Если не вдаваться во все тонкости, то по сути это возможность писать некие абстрактные контроллеры для последующего переиспользования между различными проектами.
    Middleware framework Mezzio (бывший Zend Expressie) отлично демонстрирует примеры реализации PSR-15.
  • PSR-17: HTTP Factories
    PSR-17 описывает общий стандарт для фабрик, которые создают HTTP-объекты, совместимые с PSR-7.
    PSR-7 не содержит рекомендации о том, как создавать HTTP-объекты. Это может приводить к трудностям при необходимости их создания внутри компонентов, которые не привязаны к конкретной реализации PSR-7.
    Интерфейсы, описанные в этой спецификации, описывают методы, с помощью которых можно создавать PSR-7 объекты.
    RequestFactoryInterface, ResponseFactoryInterface, ServerRequestFactoryInterface, StreamFactoryInterface, UploadedFileFactoryInterface и UriFactoryInterface RequestFactoryInterface
    interface RequestFactoryInterface { public function createRequest(string $method, $uri): RequestInterface; }
    ResponseFactoryInterface
    interface ResponseFactoryInterface { public function createResponse(int $code = 200, string $reasonPhrase = »): ResponseInterface; }
    ServerRequestFactoryInterface
    interface ServerRequestFactoryInterface { public function createServerRequest(string $method, $uri, array $serverParams = ): ServerRequestInterface; }
    StreamFactoryInterface
    interface StreamFactoryInterface { public function createStream(string $content = »): StreamInterface; public function createStreamFromFile(string $filename, string $mode = ‘r’): StreamInterface; public function createStreamFromResource($resource): StreamInterface; }
    UploadedFileFactoryInterface
    interface UploadedFileFactoryInterface { public function createUploadedFile( StreamInterface $stream, int $size = null, int $error = \UPLOAD_ERR_OK, string $clientFilename = null, string $clientMediaType = null ): UploadedFileInterface; }
    UriFactoryInterface
    interface UriFactoryInterface { public function createUri(string $uri = ») : UriInterface; }
    Посмотреть пример использования PSR-17 можно в простой реализации PSR-7.
  • PSR-18: HTTP Client
    PSR-18 описывает общие интерфейсы для отправки PSR-7 HTTP-запросов и получения HTTP-ответов.
    ClientInterface, RequestExceptionInterface и NetworkExceptionInterface ClientInterface
    interface ClientInterface { public function sendRequest(RequestInterface $request): ResponseInterface; }
    RequestExceptionInterface
    interface RequestExceptionInterface extends ClientExceptionInterface { public function getRequest(): RequestInterface; }
    NetworkExceptionInterface
    interface NetworkExceptionInterface extends ClientExceptionInterface { public function getRequest(): RequestInterface; }
    Это может сделать библиотеки более пригодными для повторного использования, так как уменьшает количество зависимостей и снижает вероятность конфликтов версий.
    Также в спецификации указано, что HTTP-клиенты могут быть заменены согласно принципу подстановки Лисков. Это означает, что все клиенты ДОЛЖНЫ вести себя одинаково при отправке запроса.
    Пример реализации PSR-18 можно увидеть в библиотеке Symfony HTTP-client.

Предложенная абстракция над HTTP — это весьма серьезная заявка на попытку реализовывать действительно переиспользуемые и не зависящие от конкретных библиотек и фреймворков полноценные решения.
На практике, конечно все на много сложнее и есть свои нюансы и подводные камни, однако PHP-FIG делает значительный шаг вперед в этом направлении.

Стиль кодирования


До появления стандартов стиля кодирования, каждый из разработчиков оформлял свой код по-разному: одни писали CLASSNAME, другие ClassName, а третьи Class_Name, вечный спор относительно табов и пробелов, а еще StudlyCaps vs сamelCase vs snake_case и так далее.
Цель следующих PSR стандартов уменьшить когнитивное искажение при чтении кода от разных авторов.

  • PSR-1: Basic Coding Standard
  • PSR-2 — Coding Style Guide Устарел
  • PSR-12: Extended Coding Style Guide

Описанные выше спецификации достаточно объемные, поэтому мы рассмотрим только базовые из PSR-1:

  • Использование только тэгов <?php и <?=
  • Только UTF-8 без BOM для php кода
  • Не стоит мешать разный функционал в одном файле (1 файл = 1 класс)
  • Пространство имен и классы должны следовать
  • Классы объявляются в `StudlyCase`
  • Константы объявляются в ТАКОМ_ВИДЕ
  • Методы объявляются в `camelCase`

На самом деле, нет смысла помнить про кажный пункт о переносе скобки, пробеле, табе и т.п., так как существует различный функционал, который позволяет автоматически проверить и отформатировать кодовую базу по стандарту PSR-2/PSR-12:

  • Ручной режим: можно использовать reformat code в phpStorm.
  • Более продвинутый вариант: использовать какой-нибуть кодснифер, например PHP CS Fixer (часто используется в CI, чтобы не принимать коммиты с неотформатированным кодом).

Автоматическое форматирование обычно выглядит так:

А для достижения максимального профита можно расширить стандарты стиля кодирования руководством по написанию чистого кода.

Преимущества использования PSR

Сама аббревиатура PSR вышла за рамки простых рекомендаций относительно стиля кодирования. А группа PHP-FIG предлагает стандарты, которые предоставляют действительно мощную абстракцию для решения базовых проблем с переиспользованием различных инструментов и позволяет сделать код более независимым от конкретных реализаций и фреймворков (на практике все куда сложнее, но фундамент уже заложен).
Для демонстрации хорошей абстракции рассмотрим установку middleware framework Mezzio:

Стандартизация в виде интерфейсов предоставляет возможность выбора любой имплементированной реализации. Также можно существенно облегчить написание документации ссылаясь на хорошо описанные PSR спецификации.

И в заключение

PSR — это действительно годные стандарты, которые созданы для того, чтобы решать проблемы переиспользования кода и облегчить совместную разработку. Однако использование PSR остается рекомендацией, поэтому Вы можете использовать как отдельные стандарты, так и не использовать их вообще.
Лично я рекомендую использовать и делиться своим опытом с сообществом PHP.
Спасибо, что дочитали до конца!

Расшифруйте ответ пристава

Добрый вечер, направили заявление приставам слейдующего содержания

Заявление об исправлении допущенных в постановлении судебного пристава-исполнителя описок или явных арифметических ошибок № 3362201

Снять неправильно наложенное ограничение с транспортного средства

Обращение направлено заявителем в рамках исполнительного производства №977552/19/77041-ИП, по которому заявитель является иным лицом.

Прошу исправить допущенные в постановлении судебного пристава-исполнителя ошибки.

Я, Темников Александр Андреевич 18 апреля 2019

года купил транспортное средство мазда мпв 2002 года, гос номер с520ун55, по приезду домой проверил по вину машину, оказалось что на нее 15 апреля 2019 года наложено ограничение на регистрационные действия. По номеру исполнительного производства проверил, что арест наложен на человека, который 6 лет уже машиной не владеет. Сейчас я не могу поставить машину на учет из за ошибки судебного пристава Рыбакова Вячеслава Валерьевича. Прошу снять ограничение с данного транспортного средства. Все сканы документов прилагаю

Ответ прошу направить по адресу: FSSPRUS.RU 12042503792.

Получили слейдующий ответ:

Уведомление о ходе исполнительного производства

Ваше заявление от 25.04.2019 «Заявление о предоставлении информации о ходе исполнительного производства» рассмотрено. Сведения об исполнительном производстве 977552/19/77041-ИП предоставлены по состоянию на 26.04.2019:

Расчеты по ИП:

Операция: Начисление, дата проводки: 06.04.2019, сумма 19 662.05 р., тип назначения суммы: Основной долг.

Документы по ИП:

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443909994) № 7025162082. ID ИП 45411443438863.

Постановление о возбуждении исполнительного производства (O_IP_RES_REOPEN, 45411443791489) от 06.04.2019 № 77041/19/502958. ID ИП 45411443438863.

Запрос в банк (МВВ) (O_IP_REQ_IP_BANKS, 45411443795105) от 06.04.2019 № б/н. ID ИП 45411443438863.

Запрос в ФНС к ЕГРЮЛ/ЕГРИП (МВВ) (O_IP_REQ_FNS_MVV, 45411443795106) от 06.04.2019 № б/н. ID ИП 45411443438863.

Запрос в ПФР о СНИЛС (МВВ) (O_IP_REQ_PFR_MVV, 45411443795108) от 06.04.2019 № б/н. ID ИП 45411443438863.

Запрос в ГИБДД МВД России на получения сведений о зарегистрированных автомототранспортных средствах (МВВ) (O_IP_REQ_AUTO, 45411443795109) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822611) от 06.04.2019 № 981461/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822661) от 06.04.2019 № 981471/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822907) от 06.04.2019 № 981491/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822806) от 06.04.2019 № 981482/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822575) от 06.04.2019 № 981453/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822671) от 06.04.2019 № 981473/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822629) от 06.04.2019 № 981465/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822842) от 06.04.2019 № 981485/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822956) от 06.04.2019 № 981495/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822591) от 06.04.2019 № 981457/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822597) от 06.04.2019 № 981458/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822758) от 06.04.2019 № 981478/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822768) от 06.04.2019 № 981479/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443822882) от 06.04.2019 № 981489/19/77041. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443814280) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443815363) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443817485) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443819698) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443820205) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443821184) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443823238) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443827566) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443828340) от 06.04.2019 № б/н. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443829481) от 07.04.2019 № 981498/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443836290) от 07.04.2019 № 981512/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443829505) от 07.04.2019 № 981503/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443829516) от 07.04.2019 № 981505/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443836311) от 07.04.2019 № 981516/19/77041. ID ИП 45411443438863.

Запрос к оператору связи (МВВ) (O_IP_REQ_MOBILE, 45411443887045) от 08.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443901146) от 08.04.2019 № 7024959184. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443877488) от 08.04.2019 № 172578201866. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443939921) от 08.04.2019 № 985051/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443900206) от 08.04.2019 № 984637/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443899476) от 08.04.2019 № 984628/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411443921064) от 08.04.2019 № 984963/19/77041. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443884771) от 08.04.2019 № б/н. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411443904790) от 08.04.2019 № б/н. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411444029474) от 09.04.2019 № 986068/19/77041. ID ИП 45411443438863.

Ответ из ведомства (MVV_EXTERNAL_RESPONSE, 45411444102846) от 09.04.2019 № б/н. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411444318502) от 11.04.2019 № 988934/19/77041. ID ИП 45411443438863.

Постановление о запрете на регистрационные действия в отношении транспортных средств (O_IP_ACT_BAN_GIBDD, 45411444627869) от 15.04.2019 № 77041/19/610508. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411445160524) от 19.04.2019 № 1005325/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411445482299) от 22.04.2019 № 1011107/19/77041. ID ИП 45411443438863.

Ответ на запрос информации о должнике или его имуществе (I_ANSWER, 45411445680476) от 23.04.2019 № 1011942/19/77041. ID ИП 45411443438863.

Заявление о предоставлении информации по находящимся на исполнении исполнительным производствам в отношении физического и юридического лица (I_IPSIDE_OSP_COURSEIP_REQ, 45411446001515) от 26.04.2019 № 1013622/19/77041. ID ИП 45411443438863.

Судебный пристав-исполнитель (Код: 11-3-4-105)

Подпись верна

ФИО владельца сертификата: Валиахметова Ольга Павловна

Должность владельца сертификата: Зам. начальника отдела – заместитель старшего судебного пристава

Выдан УЦ: Федеральная служба судебных приставов

Рубрики: Статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *