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

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



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

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

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

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

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

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

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

Качество кода не только в том, как он работает, но и в том как выглядит. То, что единый в рамках кампании 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 + Новые концепции разработки приложений.

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

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

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

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

Давно не делали опрос о популярности php-фреймворков. Это, конечно, не волшебный мир JavaScript, где всё меняется каждые полгода-год, но всё-таки и в php тоже постоянно идут изменения.

Выпускаются новые версии, что-то устаревает, что-то входит в моду и т.д. Один фреймворк более «компонентный» и лучше следует принципам SOLID, другой удобен для быстрого старта, третий имеет хорошее комьюнити.

Итак, опрос для тех, кто использует php в своей практике.

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

Production на удалённой VDS, Ubuntu 16, со всем необходимым окружением. Главные репозитории в GitLab — бесплатном аналоге GitHub. Каждый разработчик удаленно трудится над проектами на своих локальных машинах, работая с клоном репозитория и проверяя все доработки на встроенном в symfony веб-сервере.

Однажды в команду на фронт привлекли человека, который работал на windows, который понятия не имел о развёртке рабочего окружения. Только в этот момент мы осознали, что в до этого в команде на windows никто не работает. Только в этот момент встала актуальная задача «Как малой кровью и с минимумом знаний можно развернуть среду для разработки проектов symfony на винде».

Нужно было написать краткий мануал для разработчиков, которые сидят на windows. В итоге решили, что мануал должен быть в виде статьи на Хабре.

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

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

Можно ли с этим бороться? — легко! Борются ли с этим? — не встречал. Значит, пора начать.

Привет, Хабр!) Тем, кто пока не имеет представления, советую почитать предыдущую статью А если кратко, то речь пойдет об окружении для локальной веб разработки, которое полностью настроено и готово для запуска большинства фреймворков и cms. Запускайте Symfony, Laravel, Yii2, и другие фреймворки легко! По принципу клонировал -> запустил. Забудьте про постоянные настройки веб сервера и рабочего окружения. Все что вам нужно уже есть в Stacker

Основные лозунги проекта

Их много — он один!
Все просто, не нужно миграций!
Быстро развернул и начал работать!
Хватит настраивать! Пиши код!
Держи зоопарк под Docker, пусть хостовая машина остается чистой!

Вы наверняка думаете, что писать на php — это просто. И «hello, world» выглядит примерно так так:

<?php
echo 'Hello, world!';

Конечно, чего еще ожидать от языка с низким порогом входа. Ну да, именно так и было раньше. Много лет назад. Но теперь, в 2017 году никто так уже не делает. Давайте рассмотрим, почему, и попробуем построить наше более реалистичное hello-world приложение по шагам, а их, скажу сразу, получилось не мало.

Сразу, коротко и по делу о том, какие типы фильтров вы сможете использовать из коробки с уже созданной кастомизацией:

BooleanFilterType
CheckboxFilterType
ChoiceFilterType
CollectionAdapterFilterType
DateFilterType
DateRangeFilterType
DateTimeFilterType
DateTimeRangeFilterType
DocumentFilterType
EmbeddedFilterTypeInterface
EntityFilterType
NumberFilterType
NumberRangeFilterType
SharedableFilterType
TextFilterType

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

В предыдущей статье я писал о загрузке файлов в GridFS. Там мы создали MongoDB документ со свойством $file, аннотированным как @MongoDB\File. Так как ORM сущности я использую чаще, чем ODM документы, я искал простой способ получить доступ к документу из сущности.

Прямую связь между сущностью и документом установить нельзя, и я подумал, что не плохо было бы сделать собственный тип поля. С помощью определения собственного типа поля мы сможем контролировать способ хранения ссылки на документ и в то же время возвращать эту ссылку с помощью вызова свойства сущности.

Компонент Symfony 2 Config предназначен для работы с конфигурационными файлами и предоставляет следующие возможности:

• Поддержка древовидной структуры конфигурации
• Абстракция составных частей конфигурации, из которых производится ее загрузка (ресурсы, загрузчики ресурсов и т.д.)
• Поддержка произвольного количества составных частей конфигурации и некоторых правил по сборке и объединению
• Кеширование прочитанной конфигурации и автоматическая ее пересборка при изменении одного из исходных файлов
• Валидация конфигурации по различным правилам и подробная информация об ошибках парсинга

Официальная документация по этому компоненту содержит подробную информацию по его использованию. А мы давайте посмотрим на то, как устроен этот компонент внутри.

Сегодня хочу предложить вашему вниманию частный случай для решения «неудобств», связанных с периодичным запуском процессов в том случае, если предыдущий еще не завершился. Иначе говоря — блокировка запущенных процессов в symfony/console. Но все было бы слишком банально, если бы не необходимость блокировки среди группы серверов, а не на отдельно взятом.

Дано: Один и тот же процесс, который запускается на N серверов.
Задача: Сделать так, чтобы в единицу времени был запущен только один.

По слухам, сегодня должен состояться релиз 7.1. Поэтому хотелось бы немного оглянуться назад и посмотреть, а как же php вырос из набора костылей и подпорок в полноценный язык для веба. Прямо по шагам, т.е. по версиям. А в конце хотелось бы немного поразжигать поразмыслить о роли php в современной экосистеме.

Давайте мысленно вернемся во времена php4, когда получили своё развитие wordpress, bitrix и миллионы других CMS и домашних страничек.

При разработке приложений часто приходится сталкиваться с необходимостью просмотра вывода exception stack trace (в логах или при debug-инге). Хотелось бы иметь возможность автоматически попадать в необходимое место кода, прямо кликом по строке в выводе stack trace в браузере или в терминале.

Если вы являетесь пользователем одного из последних продуктов компании JetBrains (в частности PhpStorm), вы можете использовать для этих целей внутреннее REST API (для навигации из браузера) и command line launcher (для навигации в терминале).

Навигация в браузере

Частичное описание методов REST API IDE от JetBrains можно посмотреть здесь:

» http://develar.org/idea-rest-api/

Одним из методов этого API является возможность открыть файл проекта и переместиться на произвольную позицию в этом файле внутри самой IDE.

Вводная

Устали от LAMPов, MAMPов, ручной настройки, конфликтов? Хотите получить полностью настроенное и готовое к работе окружение для web разработки с Nginx, DB(Mysql, Pgsql, Redis), PHP7 на борту и с настроенным xDebug и все это за 5 минут? Stacker идет на помощь!

GridFS — это спецификация MongoDB для хранения больших файлов. В этой статье я расскажу как можно легко загружать файлы в GridFS, а затем извлекать их из базы данных и отображать в браузере.

Проблема

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

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

• иметь возможность получить список значений перечислениях
• интеграция с Doctrine для использования перечисления в качестве типа поля
• интеграция с Form для использования перечислений как поле в форме для выбора нужного элемента
• интеграция с Twig для перевода значений перечисления

На хабре есть много статей, как сделать хорошо. Есть много статей, как делать не стоит.
Но что, если у вас есть проект, который работает, приносит бизнесу деньги, но из программистов, что-то в нем понять, не способен почти никто. Каждое изменение делается на страх и риск сыграть в русскую рулетку.

Хорошо, когда у вас есть годик или два для подготовки нового проекта с нуля (был у меня и такой опыт). Но если владелец не готов вкладываться в то, что вы будете что-то делать параллельно с нуля, пока старый движок во всю загибается. Попытки даже заговорить, о том, чтобы написать все по новой, встречают моментальный отказ. Но можно попробовать маленькими шажками, делать новый движок, который постепенно бы начал забирать на себя всю большую и большую роль в работе проекта. Собственно об опыте осуществить такую замену, я бы и хотел вам рассказать.