Дайджест интересных новостей и материалов из мира PHP № 51 (26 октября – 16 ноября 2014)



    Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

    Приятного чтения!


    Новости и релизы


    • habr О Symfony 3.0
    • Релизы PHP: 5.4.35, 5.5.19 и 5.6.3 — Обновления актуальных веток, включающие исправление уязвимости в fileinfo.
    • Facebook открыл код системы мониторинга osquery — Инструмент позволяет отслеживать состояние операционной системы выполняя SQL-запросы к виртуальной базе данных. Доступна оболочка на PHP.
    • Hack Transpiler — Также Facebook анонсировал релиз инструмента h2tp, который позволяет транслировать Hack-код обратно в традиционный PHP.
    • График поддерживаемых версий PHP — Новая страница PHP.net с наглядным изображением периодов поддержки существующих версий интерпретатора.
    • Symfony Marketplace — Каталог сервисов и продуктов связанных с Symfony и экосистемой.


    PHP


    • RFC: Return Type Declarations — Vote Cancelled — Голосование по столь ожидаемому предложению аннулировано поскольку был найден баг, исправить который в текущей реализации невозможно. Подробнее о баге тут.
    • RFC: Additional Usage for the Splat Operator — Предлагается использовать splat оператор для реализации array_merge:
      $arr1 = ['d' => 4, 'e' => 5, 'f' => 6]; $arr2 = ['a' => 1, 'b' => 2, 'c' => 3, ...$arr1];.
    • RFC: Filtered unserialize() — Предложение расширить функцию unserialize(), для предотвращения проблем безопасности. Подробнее в посте автора.
    • RFC: Standardized PHP Http Interface — Предлагается добавить в ядро интерфейсы HttpMessageReceive и HttpMessageSend, а также классы HttpRequest и HttpResponse для работы с HTTP запросами.
    • RFC: Default constructors — Предлагается реализовать концепцию конструкторов по умолчанию.


    Инструменты


    • PackageTrack — Загружаем composer.json и трекаем по RSS обновления пакетов.
    • PHP Secure Configuration Checker — Проверка конфигурации PHP на возможные проблемы безопасности.
    • PHP dotenv — Автоматическая загрузка переменных окружения из файла .env. Клон рубишного dotenv.
    • Peridot — Событийно-ориентированный BDD фреймворк тестирования.
    • Period — Объект-значение для работы с диапазонами дат. Подробнее об использовании тут и мотивации — тут.
    • Process — Библиотека предоставляет улучшенный API для работы с процессами на unix-подобных системах.
    • oauth2-server — На 100% совместимый со спецификацией сервер OAuth 2.0 на PHP.
    • hook — Open-source Back-end as a Service на PHP.
    • phly/http — Реализация предложенного PSR HTTP message interfaces и node-подобный http-сервер.
    • Money — Объект-значение для работы с денежными данными.
    • Medusa — Неизменяемые постоянные коллекции для PHP.
    • Hippo — Проверка кода на соответствие стандартам.
    • Morphos — Библиотека для склонения имен собственных русского языка.
    • PHP CS Fixer — Инструмент для автоматического исправления стиля кода добрался до стабильного релиза.
    • Sismo — Сервер непрерывного тестирования на PHP.
    • Pipes — Обертка над SPL итераторами, представляющая текучий интерфейс.
    • Yona CMS — Реализована на Phalcon.
    • Blueberry — Язык программирования, который транслируется в PHP. Автора вдохновляли Ruby, Coffeescript и Python. Не забываем о Gutscript.
    • php-amqplib — Реализация протокола AMQP на PHP.
    • Docker PHP — Клиент Docker на PHP.


    Материалы для обучения




    Аудио и видеоматериалы




    Занимательное




    Быстрый поиск по всем дайджестам
    Предыдущий выпуск
    Zfort Group
    112.41
    Company
    Share post

    Comments 44

      +4
      Спасибо, на редкость много интересных ссылок!
        +2
        ну default конструкторы сразу реджектнут, ибо:
        it is highly improbably somebody's code relies on being unable to call parent::__construct.

        весьма наивно. Более того, автор приводит в RFC ссылку на реализацию дефолтных конструкторов в c# и в Java, при том что ничего общего с предложенным там нет. В том же c# если у класса нет подходящего конструктора вызывается пустой дефолтный конструктор. А автор RFC предлагает дергать все конструкторы по цепочке наследования.

        «стандартизированные интерфейсы» для Http так же думаю реджектнут и хорошо. Зачем вообще это включать в PHP, тот же PSR-6 еще в драфте и не собирается оттуда выходить. Так зачем очередной велосипед да еще и на уровне ядра…

        С фильтрацией при unserialize так же не все так красиво. Хотя из этих трех эта RFC хоть выглядит полезной.
          +2
          > ну default конструкторы сразу реджектнут, ибо:
          И это хреново, сейчас всегда надо проверять проверять чтобы у родителя был этот метод (из-за этого я всегда добавляю пустые конструкторы во все создаваемые классы).

          > А автор RFC предлагает дергать все конструкторы по цепочке наследования.
          Что-то никак не могу припомнить ни одного случая когда было нужно сознательно разорвать цепочку вызова конструкторов, а вы?
            0
            Что-то я погорячился. Внимательно изучив RFC всетаки речь именно о конструкторах по умолчанию. Меня видимо смустила как раз таки эта фраза из BC changes (там говорится все же о том что «крайне маловероятно что чей-то код работает за счет того что нельзя вызывать конструктор у родителя, если его нет»). Если все так то у этой RFC неплохие шансы и действительно не вижу ничего плохого в оной. С остальными мнение не поменял.

            Что до разрыва вызова цепочки конструкторов — самый распространенный пример — прокси классы для ленивой инициализации сервисов, реализация сущностей доктрины и т.д. У них у всех отключен конструктор родителя. Сам я разрывал цепочку вызова конструкторов для случаев когда автор базовых классов делал в оных что-то сверхестественное, например к файловой системе обращался или в базу лез.
              +1
              >> Что-то никак не могу припомнить ни одного случая когда было нужно сознательно разорвать цепочку вызова конструкторов, а вы?

              Когда в конструкторы понатыкают тяжелых операций
                0
                А если это необходимо для правильной инициализации объекта?
                  +1
                  Этим может и должна заниматься ваша реализация IoC.
                    0
                    Настолько безапелляционно?
                      0
                      Типичный конструктор выглядит примерно вот так:

                      function __construct($a, $b, $c)
                      {
                      // Сначала присваиваем переданные переменные свойствам класса
                      $this->a = $a;
                      $this->b = $b;
                      $this->c = $c;

                      // Делаем еще какие-то операции

                      }

                      Почему бы не вынести все что там дальше делается в отдельный метод init или connect. Кому надо, тот сам вызовет его дополнительно руками. Зато ваш класс можно использовать для ленивой инициализации.

                      Да, теперь класс инициализируется двумя строчками вместо одной. Но если есть IoC, вы легко рефакторите весь код.
                        0
                        > Почему бы не вынести все что там дальше делается в отдельный метод init или connect
                        Какой в этом смысл если класс физически не может работать без этих данных? Хотя если вам нравится постоянно держать в голове необходимость вызова init сразу после создания экземпляра (= вызова конструктора) — пожалуйста.
                          0
                          Для того что бы не держать в голове можно это на уровне класса делать — по первому требованию дергать init который будет проверять не инициализировал ли он сам себя ранее. Или IoC просить. Но согласитесь, обращаться в I/O в конструкторе это дичь. Допускаю что в некоторых случаях это оправдано но в большинстве случаев лучше так не делать.
                            0
                            > Для того что бы не держать в голове можно

                            Собственно, я вообще вел к тому что случаи бывают разные и просто так взять и сказать «должна» нельзя (везде есть свои недостатки/достоинства, поэтому все больше зависит от личных предпочтений и принятых соглашений)

                            > Допускаю что в некоторых случаях это оправдано но в большинстве случаев лучше так не делать.

                            Соглашусь с тем что надо по месту смотреть, где это будет говнокодом, а где-то вполне уместно.
              +1
              Насколько я понял — просто parent::__construct() не будет выкидывать ошибку, если сам метод не определён в родительском классе, вот и всё. Так что RFC имеет все шансы пройти.
              +4
              Встречаем Laravel 5 Elixir — В следующей версии Laravel в качестве билд-инструмента предлагается использовать Elixir — надстройку на Gulp, который в свою очередь реализован на JavaScript и требует node.js.


              Зачем? Ну зачем нам js еще и в php.
              Неужели PHP на столько ущербен, что нельзя написать нормальный билд-инструмент на нем. Я прям возмущен этим решением…
                –1
                штуки типа autoprefixer, uglifyjs и т.д. вы тоже на PHP будете портировать? Я вот phing на gulp заменил на своих проектах и счастлив. Можно распаралелить сборку настолько насколько это возможно и при этом это не ущербно выглядит. Каждому свое словом.
                  0
                  Во первых: перечисленные вами штуки это из мира JS, и больше востребованы там или для front-end.
                  Во вторых: они уже портированы

                  1) autoprefixer-php
                  2) makesites/uglifyjs-php, smallhadroncollider/uglify-php

                  В третьих: я php программист, я пишу на php, а не на js, и я не люблю js в принципе.

                  Почему меня обязывают использовать js инструменты в php фреймворке? Именно этим я и возмущен. Минус Laravel-у.
                    0
                    Вас не обязывают. Вам рекомендуют. Более того вот эта штука как раз таки и была создана что бы вы могли пользоваться чудным миром фронтэнд-штуковин и не писать кучу JS кода.

                    Что до приведенных вами ссылок:
                    — autoprefixer-php — внезапно требует nodejs, по сути это просто обертка над proc_open.
                    — makesites/uglifyjs-php — тут интереснее, node.js нам уже не нужен что бы работать но сделано это за счет того что node.js установлен на серере у этого самого makesites и просто обрабатывает http запросы формируемые этой либой. Идея занятная но мы таким образом делаем себя зависимыми от его сервиса который может попросту в один прекрасный день перстать быть доступным.
                    — smallhadroncollider/uglify-php — работает на exec, то есть еще хуже ситуация чем с autoprefixer.

                    Отдельная же реализация требует огромного вложения сил при довольно сомнительном профите. Проще поставить один пакет в систему.

                    Я не знаю почему у вас так много ненависти в отношении JS или node.js. Меня вот совсем не напрягает, это капля в море по сравнению с тем зверинцем технологий которые я ипользую в повседневной работе. Благо есть ansible и vagrant что бы все это разруливать.
                      0
                      Если кому интересно, на одной из конференций был доклад Optimising Your Front End Workflow With Symfony, Twig, Bower and Gulp. К сожалению видео я больше не могу найти, остались только слайды и пример структуры проекта, если у кого-то имеется ссылка было бы неплохо поделиться.
                        0
                        Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.
                        — С просторов интернета

                          +1
                          *Точнее с просторов сообщества habrahabr во вконтактике
                    0
                    Плюсую. Именно по этому написал пакет, который умеет собирать ассеты без каких либо внешних зависимостей: github.com/SerafimArts/Asset (ридми: github.com/SerafimArts/Asset/wiki/%5BRU%5D-README)

                    Вполне себе уже работает в продакшене, единственное но — пока минимизация не реализована.
                      0
                      А Assetic не рассматривали? В целом… я не понимаю зачем нужно переписывать что-то что работает и хорошо, при этом делать реализацию заведомо медленнее и тратить время на поддержку оной. Мы ведь боремся за секунды времени сборки проекта.
                        0
                        И да, как вы решаете вопрос с внедрением всего этого добра в шаблоны, есть ли разделение на окружения, планируются ли сорсмэпы?
                          0
                          1) Это же тупо функции\методы, о какой конкретно поддержке вы говорите? о_0

                          2) Есть файл конфигов, где можно настроить всё, что пожелается (я очень надеюсь): github.com/SerafimArts/Asset/blob/master/src/config/config.php

                          3) На счёт сорсмапов — план разработки пока следующий: github.com/SerafimArts/Asset/wiki/TODO но я уже смотрел спецификацию в надежде быстренько запилить, как можно заметить — быстренько не получилось — надо вникать.
                          0
                          Он слишком тяжеловесен, имхо. И не думаю, что медленнее. т.к. в продакшн-режиме просто происходит проверка существования кеша и всё, без проверок изменений файлов и прочего. В дев-режиме же каждый файл кешируется отдельно, что избавляет от дополнительных телодвижений.
                            0
                            Нет ну дело вы большое делаете, просто у меня сомнения по поводу оправданности подобного велосипедостроения (медленно, баги, никто не пользуется и вы через пол года год забьете). Если честно я даже завидую — у меня например нет столько свободного времени.
                              0
                              Я пробовал уже существующие решения, включая вот это: github.com/CodeSleeve/asset-pipeline казалось бы намного надёжнее (звёздочек аж почти 500, и 50 форков), но по факту — багов там одним местом жуй, а предложенное Тейлором (эликсир) — просто не воспринимаю как что-то вменяемое — тупо костыль.

                              Учитывая то, что моё решение используется на работе вместо компилей из мира nodejs — времени хватает. А на счёт полугода:
                              Initial commit. 6 Aug 2013
                              и 400 установок с пакагиста. Тут уж не отвертеться ;)
                                0
                                Медленно, всегда будет отставать от актуальной реализации, куча времени убиваемая на поддержку решения вместо решения реальных проблем коих в PHP комьюнити хватает. Но это мое личное мнение, мне просто это не понятно.

                                p.s. 400 устновок с пакагиста это мало. У вас небыло такого что вы поставили что-то, покрутили и выкинули?
                                  0
                                  Ну это всё понятно. Только актуальной реализации не существует из принципа.

                                  А чего такого не хватает php сообществу, без влезания в дебри сишного кода? Всё что в голову приходит — переписывание стандартной библиотеки под ОО вид =)
                                    0
                                    SPL и так состоит из ОО штук. Если вы про работу со скалярами как с объектами — не вижу в этом смысла. С тем синтаксисом который используется в PHP для доступа к методам/свойствам уж лучше как функции использовать.
                                      0
                                      В таком случае чем же я ещё могу помочь php-сообществу, без влезания в сишный код? =)
                          0
                          А почему только Laravel? :(
                            0
                            Вначале был отдельный пакет, но потом, вместе с рефакторингом всего и вся — прицепились пакеты кеширования и конфигов от лары, так что для того, что бы вытащить всё это из под его крыла — надо как минимум запилить фоллбеки для всех illuminate/* пакетов: github.com/SerafimArts/Asset/blob/master/composer.json#L12
                              0
                              Ну и плюс смысл был в том, чтобы реализовать что-то аналогичное рельсовому ассет пайплаину (манифесты получились покруче, имхо), только для себя.

                              Просто пакет поставить, добавить провайдер и пользуйся на здоровье, прямо из коробки любой транслятор, который вызывается одной строкой без всякого геморроя в настройках и сборки всего этого, всё автоматом.
                                0
                                да, схожесть с asset pipeline я уловил )
                                но тем не менее, РНР сообщество движется к унификации экосистемы, и было б круто, если б ваш пакет можно было использовать во всех популярных фреймворках. А я бы попробовал написать к нему таски для Robo Task Runner
                                  0
                                  Попробую как-нибудь на досуге сделать адаптеры для существующих готовых решений.
                                    0
                                    Да, я вот Zend2 использую, хочется чтобы пакеты ставились на любой фреймворк, как например kriswallsmith/assetic.
                                    Да тяжелый, да может есть не все ф-ии, которые нужны, но я могу поставить его на любой фреймворк. Это большой плюс.
                              0
                              А я вот такую штуку для себя написал в качестве эксперимента. (https://github.com/Freezko/smart-assets) Правда только для laravel 4.
                              Основан на github.com/CodeSleeve/asset-pipeline
                              Отличие в том что в шаблоне сразу пишем ссылку на скрипт который нам необходимо преобразовать, но через дополнительный route.
                              <script type="text/javascript" src="/pipeline/folder/file.coffee"></script>
                              — в данном случае /pipeline указывает на то что файл необходимо конвертировать.
                              Минификация и конкатенация в один файл тоже есть.
                              Но в продакшене не использую пока. Нашли багу в sass-php. Он не может bourbon адекватно преобразовать. Падает с ошибками. (Например ошибка о том что else-if не может быть после else, а у бурбона встречается внутри такая проблема. Grunt при этом не ругается)
                                0
                                Кодеслив и так при вызове функции создаёт роут и конвертит всё налету. Как раз именно такой, какой у вас в примере, так что берёте и заменяете обратно на CodeSleeve — будет тоже самое. ( github.com/CodeSleeve/asset-pipeline/blob/master/src/routes.php )

                                Плюс заходим сюда и смотрим версию scss: github.com/Freezko/smart-assets/blob/master/composer.json она 0.0.9, а актуальная 0.1.1. Как бы всё становится на свои места ;)

                                Плюс версией от CodeSleeve по факту невозможно пользоваться, просто потому, что он компилит каждый scss файл отдельно, как следствие — переменные и миксины из одного файла не будут доступны в другом. Я даже не говорю про объединение, минификацию и генерацию *.gz алиаса.

                                Яж не просто так решил не брать готовое, а полностью написать своё с нуля, ибо у CodeSleeve слишком много проблем в подходе, исправить которые слишком сложно.
                                  0
                                  З.Ы. Например результат у моего пакета в продакшене будет вот такой: docs.rudev.org/assets/19abeee936b7dbfb854723b218fd48f9-layout.scss.css для вот этих стилей: github.com/Developers-RuDev/Docs/tree/master/app/assets/stylesheets и вот таким подключением github.com/Developers-RuDev/Docs/blob/master/app/views/layouts/master.blade.php
                                    0
                                    По поводу scss. Я взял composer.json от codesleeve. Каюсь не посмотрел актуальные версии пакетов.
                                    А вот по поводу routes у codesleeve не согласен. Я даже поэкспериментировал. Он в этот route не попадает если написать путь к файлу — /assets/folder/file.coffee. Во всяком случае преобразования файла не происходит. Как я понимаю codesleeve написали аналог рубишного asset-pipeline. А это совсем не то что написал я.
                                      0
                                      Хм, не знал что не будет работать если прописать прямой путь. В таком случае беру свои слова обратно на счёт бессмысленности.

                                      В любом случае это не отменяет остальных проблем.
                            +2
                            Спасибо Вам за еще одну интересную подборку!
                              +1
                              Как и всегда — огромное спасибо!
                              Самому постоянно все отслеживать ну просто не реально, а тут все по полочкам и в тему!

                              Only users with full accounts can post comments. Log in, please.