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

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

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

Давайте представим некоторый проект на 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 + Новые концепции разработки приложений.
Читать дальше →