28 апреля 2014 в 00:29

Дайджест интересных новостей и материалов из мира 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 прошедших конференций




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




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




Быстрый поиск по всем дайджестам
Предыдущий выпуск
Автор: @pronskiy

Комментарии (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 недели

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

Самое читаемое Разработка