PHP *

«О нет!», воскликнет читатель, утомлённый разными мини-микро-слим-фреймворками и QueryBuilder-ами и будет прав.

Нет ничего скучнее, чем очередной фреймворк на PHP. Разве что «принципиально новая» CMS или новый дейтинг.



Так зачем же я с упорством, достойным лучшего применения, шагаю по неудобным подводным камням и выставляю на потеху публике суд товарищей своё творение? Заранее зная, что гнев критиков, как мощное цунами обрушится на этот пост и похоронит его на самом днище Хабра?

Не знаю. Как не знал в своё время Колумб, зачем он отплывает от уютных берегов Испании. Надеялся ли он найти путь в Индию? Конечно да. Но не знал точно — доплывёт ли?

Видимо и у программистов на PHP, к которым я вот уже 13 лет себя причисляю, есть такая же внутренняя потребность — выставлять свой код и зажмуривать глаза, ожидая реакции коллег.

Что вас ждет под катом?

• Открытый исходный код, лицензия LGPL
• Код, полностью совместимый с PHP 7.0-7.2
• 100% покрытие юнит-тестами
• Библиотеки, проверенные временем в реальных проектах (и только проклятая прокрастинация мешала мне опубликовать их ранее!)

Ну и, разумеется, история изобретения очередного велосипеда на костыльном приводе фреймворка*!

* вообще говоря это пока еще не фреймворк, а просто набор библиотек, фреймворком он станет чуть позже

17 июня в Москве пройдет DevConf 2017 — большая конференция для веб-разработчиков. Каждый год собирается более тысячи участников, чтобы рассказать и узнать обо всем самом новом в мире программирования для веб.

Будет большая тусовка, доклады будут читать опытные специалисты по Go, MySQL, PostgreSQL, PHP, Javascript и мобильным платформам.

Вы встречались с ошибками, которые возникают время от времени в продакшне, но никак не воспроизводятся локально? Бывает, изучаешь такой баг и вдруг понимаешь, что он проявляется только при одновременном параллельном выполнении скриптов. Изучив код, понимаешь как это исправить, чтобы такого больше не повторялось. Но на такое исправление хорошо бы написать тест…

В статье я расскажу о своем подходе к тестированию таких ситуаций. А также приведу несколько наглядных (и наверное даже классических) примеров багов, которые удобно протестировать с помощью этого подхода. Все примеры багов живые — то, что встречается в работе.

Забегая вперед сразу скажу, что в конце статьи будет ссылка на github, куда я выложил готовое решение, позволяющее тестировать параллельные консольные процессы легко и просто.

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

У админа может и не быть доступа к разрешению пользователя и в пределах одной роли пользователи могут иметь разный доступ к разрешениям

Как организовать сущности Role,Permission,Rule

Роли (role): типовые роли supper_admin,admin,customer (сотрудник, менеджер),user (авторизированный пользователь),guest (не авторизированный пользователь). Роль supper_admin наследует от всех ролей разрешения благодаря этому supper_admin имеет доступ ко всем permission не зависимо от их наличия в конкретной роли но требуется пропуск во всех правилах;

Разрешения (permission): роль является прямым родителем разрешения, без наследования (кроме роли supper_admin).Другими словами, одно и тоже разрешение будет назначаться каждой нужной роли.
Правила (Rule): правила для ролей и для разрешений наследуются от BaseRole в котором присутствует проверка общих правил.

Этим летом, 16 Июня 2017, в Москве пройдёт конференция веб-разработчиков, посвящённая PHP фреймворку Yii.

Докладчики расскажут о том, как правильно работать с фреймворком, представим лучшие практики, и приведем практические примеры оптимизации приложений на основе Yii в условиях высоких нагрузок.

Всем доброго времени суток! Меня зовут Константин, в Badoo я работаю в команде Features Team. Скорее всего, вы уже знаете, что наш бэкенд написан на PHP и обслуживает более трёх сотен миллионов пользователей. Так что я не мог упустить шанс перевести эту статью core-разработчика PHP Никиты Попова. Уверен, она будет полезна разработчикам всех уровней, но новичкам может показаться сложноватой. Приятного (и полезного) чтения!



В статье представлен обзор виртуальной машины Zend для PHP 7. Это не исчерпывающее описание, но я постараюсь охватить большинство важных частей, а также некоторые детали.

Описание сделано на основе PHP версии 7.2 (в настоящее время находится в разработке), но почти всё справедливо и для PHP 7.0/7.1. Однако отличия от виртуальных машин серии PHP 5.x являются значительными, и с ними я, как правило, не проводил параллели.

Команда PHP фреймворка Yii выпустила релиз версии 1.1.18. Скачать архив можно с тут.

Ветка 1.1 уже достигла EOL. Дополнительные исправления, если будут, то по части безопасности и совместимости с PHP 7.

Релиз 1.1.18 позволяет обновить PHP на сервере со старым Yii 1.1 до поддерживаемой командой PHP. Yii 1.1.18 совместим с PHP 7.1. Патчи безопасности для этой версии PHP будут выпускаться до 1 декабря 2019.

В этой статье мы рассмотрим результаты нескольких бенчмарков, начиная с PHP 5 и вплоть до экспериментальной JIT-ветки (сейчас в разработке). На момент написания не было известно, появится ли до PHP 8 ещё какая-то основная версия, например PHP 7.2. Но логично предположить, что возможности экспериментальной ветки как минимум будут включены в PHP 8.

Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.

«Но Саймон! Почему?!", вы, вероятно, прокричите увидев этот текст на экране. И вот почему:

Перспективы трудоустройства

PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.

Иначе просто невозможно добиться успеха.

Приведем немного научных™ фактов, чтобы доказать эти утверждения:

$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;

Шукюров Заур, разработчик @KinomanBot и @GaidarForum_bot, написал руководство по созданию простого чат-бота на PHP.

24 июня 2015 года разработчики Telegram открыли платформу для создания ботов (программ, которые выполняют определенные действия по заданному алгоритму).

За полтора года работы платформы набралось много интересных чат-ботов, решающих множество проблем и позволяющих с пользой провести время в мессенджере.

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

В программной инженерии шаблон проектирования приложений — это многократно применяемое решение регулярно возникающей проблемы в рамках определённого контекста архитектуры приложения. Шаблон — это не законченное архитектурное решение, которое можно напрямую преобразовать в исходный или машинный код. Это описание подхода к решению проблемы, который можно применять в разных ситуациях.

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

Качество кода не только в том, как он работает, но и в том как выглядит. То, что единый в рамках кампании code style — это очень важная вещь — в наши дни убеждать уже никого не нужно. Код должен быть не только написан, но и оформлен. В плане оформления PHP кода, утилита php-cs-fixer давно уже стала стандартом. Использовать ее довольно просто, есть куча правил и можно удобно забиндить ее запуск на какую-нибудь комбинацию клавиш в шторме или на pre-commit hook в гите. Все это легко гуглится и подробно разбирается в сотнях статей. А мы сегодня поговорим о другом. Хотя в php-cs-fixer есть большое количество разных фиксеров, но что, если нам понадобится такой, которого там нет? Как написать собственный фиксер?

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

При выполнении очередного госзаказа наша команда столкнулась с проблемой интеграции сайта с ЕСИА. Инструкции по решению этой задачи в сети нет, кроме информации в официальных документах МинКомСвязи (примерно 300 страниц в трех регламентах). Также есть компании, которые оказывают платные услуги по интеграции ЕСИА. Мы реализовали, описали процесс интеграции и решили поделиться с сообществом habrahabr.

Отмечаем 5-летний юбилей ThinkPHP вместе на четырнадцатой встрече нашего комьюнити! Пять лет интересных встреч, насыщенных докладов, оживленных кофе-брейков и уютных пятничных вечеров — и ThinkPHP #14 продолжает эту традицию. Вас ждут крутые спикеры, актуальные темы мира PHP, вкусные кофе-брейки и многое другое.

Давайте представим некоторый проект на GitHub, куда мы хотим оформить Pull Request. Здесь нас будет интересовать только тот огромный жизненный цикл нашего пулл реквеста, который он фактически может пройти с момента рождения до самого момента его принятия и мержа в основной код проекта.



Итак, если порассуждаем, то пулл реквест может иметь следующие варицации над состояниями, которые я специально усложнил, если не знать о WorkFlow и смотреть на подобное тз:

1. Открыт
2. Находится в проверке в Travis CI, причем может попасть туда после того как были сделаны какие-то исправления или любые изменения, связанные с нашим Pull Request, ведь проверить-то надо все, не так ли?
3. Ждет Review только после того как была сделана проверка в Travis CI
3.1. Требует обновлений кода после того как была сделана проверка в Travis CI
4. Требует изменения после Review
5. Принят после Review
6. Смержен после Review
7. Отклонен после Review
8. Закрыт после того, как был отклонен после Review
9. Открыт заново после того как был закрыт, после того как был отклонен, после того как было проведено Review
10. Изменения после того как был помечен «Требует изменений», после того как было проведено Review, при этом после этого он снова должен попасть в Travis CI (пункт 2), а от Review снова может с ним случиться только те состояния, которые мы описали выше

Symfony 4.0 выйдет в релиз в конце ноября 2017 года. Следующие несколько недель будут опубликовываться статьи о новых идеях и основных изменениях в Symfony 4.

Symfony 3.0 был скучным и являлся более лаконичной версией Symfony 2.8:
Symfony 3.0 = Symfony 2.8 — Deprecated Features.

Но что же будет представлять из себя Symfony 4.0 в отличии предыдущих версий:
Symfony 4.0 = Symfony 3.4 — Deprecated Features + Новые концепции разработки приложений.

Или вот еще один вариант развития событий:
Symfony 4.0 = Symfony 3.0 + All features added in 3.x — Deprecated Features + Новые концепции разработки приложений.

На некоторой стадии развития веб-проекта возникает одна из следующих ситуаций:

• backend перестаёт помещаться на одном сервере и требуется хранилище сессий, общее для всех backend-серверов
• по различным причинам перестаёт устраивать скорость работы встроенных файловых сессий

Традиционно в таких случаях для хранения пользовательских сессий начинают использовать Redis, Memcached или какое-то другое внешнее хранилище. Как следствие возникает бремя эксплуатации базы данных, которая при этом не должна быть единой точкой отказа или бутылочным горлышком в системе.

Однако, есть альтернатива этому подходу. Возможно безопасно и надёжно хранить данные сессии в браузерной куке у самого пользователя, если заверить данные сессии криптографической подписью. Если вдобавок к этому данные ещё и зашифровать, то тогда содержимое сессии не будет доступно пользователю. Главное достоинство этого способа хранения в том, что он не требует централизованной базы данных для сессий со всеми вытекающими из этого плюсами в виде надёжности, скорости и масштабирования.

Абсолютно невозможно отрицать, что развитие естественных паттернов в интерфейсах дало фантастический толчок к развитию всей ИТ-индустрии в целом. И речь не только и не столько о голосовых интерфейсах, сколько о повсеместном внедрении жестов, гигантском сдвиге в парадигме мобильных платформ и, конечно, существенных работах в области UI и UX в целом. В то время как индустрия стремится стать все более дружелюбной для все более широких масс людей, обычная и, в определенной степени, рутинная разработка превращается в бесконечные попытки объять необъятное. Если раньше нас в основном заботили уровни абстракции языков и фреймворков, то сейчас перед нами стоят куда более глобальные вопросы. Как найти баланс между сложным и функциональным интерфейсом? Стоит ли начинать новый проект с микросервисов? На эти вопросы я не могу ответить, зато я могу рассказать вам об инструментах, которые уже сейчас существенно облегчают и удешевляют освоение и применение новых технологий и подходов к разработке.