Дайджест интересных новостей и материалов из мира PHP № 40 (14 апреля — 27 апреля 2014)



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

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


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


    • Behat 3.0.0 — После 2 лет работы наконец-то стала доступна третья версия популярного BDD-инструмента для PHP. Подробнее в видеопрезентации от автора video.
    • Авторы PHPUnit анонсировали конец поддержки PEAR — Некогда популярный репозиторий расширений и пакетов для PHP PEAR уверенно движется к концу своего существования. Канал pear.phpunit.de существовал с 2006 года, но будет закрыт не позднее 31 декабря этого года, а релизы PHPUnit 3.7.35 и PHPUnit 4.0.17 станут последними доступными через такой способ установки. Кроме того, Фабьен подтвердил, что PEAR пакеты Symfony также перестанут публиковаться в скором времени.
    • habr Yii 2.0 beta — Подробный обзор бета-версии долгожданного фреймворка Yii 2.0. Также смотрите подборку тем ru, которые следует изучить при переходе на Yii 2.
    • habr WordPress 3.9 “Smith” — Релиз содержит в основном косметические изменения и улучшения.
    • ru DevConf 2014 — 14 июня в Москве пройдет конференция для веб-разработчиков DevConf. Среди подтвержденных в PHP-секции доклады от SamDark по Yii 2.0 ru, а также от одного из core разработчиков Laravel – Shawn McCool.


    PHP


    • RFC: Return Type Declarations — Предложение по реализации type-hinting для возвращаемых значений уже упоминалось в дайджесте, была добавлена реализация, так что есть все шансы увидеть это в действии в скором времени.


    Инструменты


    • Monolog — Самая популярная PHP-библиотека для логирования.
    • Open source инструменты от компании Box — Известный сервис хранения данных Box выложил в общий доступ ряд своих внутренних инструментов среди которых и PHP-решения.
    • Gaufrette — Библиотека, предоставляющая абстрактный слой для работы с файловой системой. Позволяет прозрачно взаимодействовать как с локальным хранилищем, так и с удаленными. Ранее упоминалось похожее решение – библиотека Flysystem.
    • Obfuscalp — Инструмент позволяет находить и удалять подозрительный / вредоносный код в PHP скриптах.
    • sabre/http — Библиотека для удобной работы с HTTP запросами и ответами.
    • ZFDeploy — Инструмент для развертывания ZF2-приложений.
    • Structr — Определение, валидация и обработка структур данных на PHP. Взгляните на пример, чтобы оценить эту интересную идею.
    • Database Backup Manager — Библиотека позволяет делать резервные копии баз данных и сохранять их в S3, Dropbox, FTP, SFTP и другие хранилища.
    • PINQ — Аналог LINQ для PHP. Хотя подобных реализаций достаточно много, даже была на Хабре.
    • Pattern Lab — Генератор статических сайтов.
    • js-search — Поисковый движок для статических сайтов.
    • Rollout PHP — Порт популярного инструмента из Ruby-мира Rollout.
    • Ardent — Альтернативная реализация коллекций для PHP.
    • Cartographer — Sitemap-генератор.
    • Bldr — Система сборки / запуска задач для PHP.
    • Thelia — E-commerce решение на базе Symfony 2.


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




    Материалы c прошедших конференций




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




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




    Быстрый поиск по всем дайджестам
    Предыдущий выпуск
    Zfort Group 238,95
    Компания
    Поделиться публикацией
    Комментарии 27
    • +1
      Как всегда, спасибо! PHP Virgin прикольные видео.
      • +2
        Любимый дайджест
        • +3
          Слон гулял с гофером :)
          image
          • 0
            Ребята, а кто использует BDD в реальной жизни? Есть примеры?
            • +3
              Преимущественно BDD-тренеры :)
              А из примеров, то можете взглянуть в этот проект — github.com/Sylius/Sylius
              Разрабатывается по всем законам BDD
              • +2
                Я видел, только пользы с этого? Все равно на каждое правило нужно написать кусок кода, который это правило будет тестировать. Те. это лишь усугубление TDD, которое в чрезмерных количествах может быть злом само по себе
            • 0
              >> Реализация мультиязычности — Советы и рекомендации по реализации поддержки мультизычности в PHP-приложении.

              Прямо-таки советы, как это НЕ надо делать
              • 0
                Возможно, знаете другие источники, где были-бы советы как ПРАВИЛЬНО делать? Если да — поделитесь, пожалуйста.
                • –3
                  По переводам моделей правильно сделано в Propel. На каждую переводимую таблицу создается своя таблица переводов. Тогда полный перевод любой строчки вытягивается одним простым джойном. То. что рекомендуется в статье (а именно так сделано в Doctrine) — образец гавноархитектуры. Если вам надо вытянуть 10 полей одной модели, надо делать либо 10 джойнов таблицы переводов, либо 10 отдельных запросов. Только поэтому мне в свое время пришлось сменить Doctrine на Propel.

                  По статическим переводам. Переводы должны храниться в БД, а не файлах. Потому что, когда заказчик попросит поменять запятую в одном слове, вы скажите «Вот вам админка, там сами можете свои переводы править».
                  • 0
                    Потому что, когда заказчик попросит поменять запятую в одном слове, вы скажите «Вот вам админка, там сами можете свои переводы править».

                    С такой логикой шаблоны тоже должны быть редактируемы из админки, а то вдруг заказчику захочется список на табличку поменять?
                    • 0
                      Перегибать-то не надо. Какая проблема хранить 2-5 словные переводы в БД по сравнению с файлами?
                    • +2
                      Переводы должны храниться в БД, а не файлах.

                      Категорическое нет. Для переводов (локализации) и интернационализации придумали миллион подходов. Самый простой для понимаия — локали и gettext, который ложится в память и практически не влияет на скорость генерации локализованной страницы.
                      Запомните одно простое правило — интерфейс != данные. Смешивать их даже на уровне системы хранения попросту чревато. Или у вас никогда не отваливалась БД? А так — показали холодные данные из кеша (пусть и немного прокисшие) даже при отсутствии живого соединения с базой, но в переведённом интерфейсе.

                      Хотя, для сайтишек на 3 калеки в час — сойдёт. Если больше — надо думать не столько о наполнении, сколько о живучести и задавать себе преинтереснейшие вопросы: а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально? И вот тогда наружу проступают эти изначальные архитектурные просчёты.
                      • 0
                        А то, что переводы из БД можно точно так же кэшировать хоть в каком кэше, вы видимо не додумались?
                        • 0
                          >> а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально

                          Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.

                          >> Хотя, для сайтишек на 3 калеки в час — сойдёт

                          Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».
                          • 0
                            Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.

                            Айяйяй. Я не уверен в этом. Даже джойн джойну рознь и может утопить СУБД. В данном случае — это попросту растрата ценного ресурса.

                            Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».

                            Сколько экспрессии! Каков драматизм!
                            Ответ см. выше. Кроме абстракного 3+ посетителя — цифр приведено не было :) Как я смогу вам объяснить, что да. в некоторых условиях квадратные колёса поедут вполне комфортно, но для этого придётся готовить покрытие.
                          • 0
                            А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.
                            Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
                            Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.

                            Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
                            • 0
                              >> А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.

                              Кэш у вас есть в любом проекте, БД тоже. Вам не кажется, что этот ваш gettext как раз-таки и есть еще одна «внешняя зависимость»?

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

                              А я о чем по-вашему говорю. Переводы надо в БД хранить именно потому что можно организовать нормальную систему правки переводов, хоть с версионностью, хоть с преферансом. Узнать, какие строки непереведены (вечный pain in ass при хранении в файлах) тут одним запросом.
                              • 0
                                Все описанные проблемы по случайному стечению обстоятельств решены в gettext. Программа PO-edit. Она есть практически стандарт у переводчиков и не вызывает отторжения если я им даю английский файл (творческие люди, что с них взять :)). РО-edit прекрасно показывает непереведённые строки, строки с приблизительным переводом, умеет работать со множественными числами и т.д.

                                Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
                                Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
                                Ngettext — множественные числа напрямую встроенные в модуль.
                                Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.

                                На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.

                                Засим дискуссию считаю законченной, спасибо за внимание.
                                • 0
                                  >> Программа PO-edit

                                  Т.е. нам надо установить десктопную программу, чтобы управлять контентом сайта. Торжество идей web 3.0. Создатели Chrome OS плачут горькими слезами.

                                  >> Если какие- то менюшки, ..., разметка хранятся в БД

                                  Менюшки и разметку я не предлагал хранить в БД

                                  >> Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом…

                                  Каким образом вы так лихо определяете, где контент, а где интерфейс? В CMS шаблон — контент или интерфейс?
                                  Тогда говоря вашей же терминологией, с того самого момента, как отдельный человек (переводчик) начинает сам заниматься редактированием переводов, то переводы становятся КОНТЕНТОМ, а не интерфейсом. Чем отличается переводчик от контент-менеджера? Вы контент-менеджеру для своих сайтов тоже предлагаете править данные в PHPMyAdmin? Нет, вы делаете нормальную админку с нормальным CRUDом. А почему переводчик (или заказчик) должен изучать какой-то POEdit или yaml или еще бог весть какие там форматы, в которых хранятся переводы?

                                  >> Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран

                                  Я уже 2 раза писал и напишу в 3 раз, что мы кэшируем переводы и никакой разницы не будет.
                              • 0
                                Погуглил я этот gettext. Так и не понял в чем его фишка. Мало того, что надо устанавливать дополнительное расширение на php, так он еще геморный в управлении. Короче какой-то архаичный никому не нужный костыль, типа Pear. Вот, что, например, пишут здесь же на хабрахабре habrahabr.ru/post/108096/#comment_3419163. Заметьте, MySQL + memcached.
                                • 0
                                  Кстати, 80% результатов первой страницы гугла по запросу «php localization» толкуют таки о gettext.
                    • +2
                      А я всегда первым делом смотрю (и больше всего жду) на новую фотку PHP-слона, а уже потом на сам дайджест :)
                      • +6
                        В сеть просочился исходный код популярного ресурса 4chan

                        extract($_POST);
                        extract($_GET);
                        extract($_COOKIE);
                        

                        Это все объясняет.
                        • 0
                          А события моделей еще где-то есть? Вроде удобная штука
                          • +2
                            Секция DevConf::PHP расширилась
                            http://devconf.ru/offers/php

                            — Архитектура AVITO.ru
                            — Codeception — тестируем с человеческим лицом (автор Codeception)
                            — Асинхронный PHP — миф? Реальность!
                            • 0
                              Мне показалось что Structr очень похож на symfony2/config дерево, кто то пользовался им? в чем преимущество?
                              • +1
                                Верю в существование дайджеста за 4 недели

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое