Думаю, что каждый php-программист знаком с сессиями и может даже работал с ними. Сессии — это стандартный механизм PHP и применяется наверное во всех CMS или фреймворках в том или ином виде. Так же написаны сотни (если не больше) php-библиотек, которые предлагают множество функций для упрощения кода.

В целом же работа с сессиями очень простая и если говорить с практической точки зрения, то есть очень мало задач, которые стоят перед программистом. Первая — это добавление и получение данных в сессию, и вторая — организация flash-сессий для создания «мигающих сообщений». Очень часто это так и называется «flash message». Простой пример: после обновления данных, нужно вывести сообщение для пользователя только один раз.

Читать дальше...

REST — это концепция для взаимодействия компонентов основанный на протоколе HTTP. Не хочу останавливаться на скучной теории (вики в помощь), а дам простое объяснение применительно к сайтам.

В Сети обмен происходит по протоколу HTTP: запрос - ответ. Для того, чтобы передать какие-то данные, их нужно как-то идентифицировать, то есть указать их «признак», «действие» или что-то подобное. И поэтому раньше данные требовалось оформить в виде какого-то сложного формата, обычно это XML или Json.

Так вот, REST говорит что этого делать не нужно. Данные передаём как есть, только у HTTP-запроса указывается метод (параметр) для этих данных. Обычно мы оперируем GET и POST, поскольку они работают «из коробки» в HTML и их поддерживает любой браузер. Но на самом деле, метод у HTTP может быть абсолютно любым. Есть некие общепринятые: PUT, DELETE, OPTIONS, PATCH, но это совсем не стандарт.

Читать дальше...

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

Данный подход делает php-разработки сложными и запутанными. PHP — такой язык программирования, который позволяет решать задачи просто и понятно. Во многих случаях не нужна лишняя обвеска и дополнительный уровень абстракции, которая только запутывает код. Работа с HTTP по какой-то мистической причине, часто обвешивается тонной абстракций, хотя всё крутится вокруг простых вещей.

Читать дальше...

Фактически любой php-проект содержит какой-то роутинг. Без роутинга могут обходиться наверное только единичные страницы, где используется индексный файл index.php (например — лендинг), а также прямое обращение к php-файлу на сервере (сайт/contact.php и т.п.). Также встречаются разработки (обычно старые), где роутинг вынесен в .htaccess, в котором явно прописывается соответствие входящего URL какому-то php-файлу на сервере.

Но на сегодняшний день фактически стандартом стал подход, когда в .htaccess задаются простые правила, по которым все входящие запросы передаются во фронт-контролер (обычно это index.php). После этого загружается «ядро», может быть происходит какая-то инициализация, и дальше управление передаётся в роутер. Роутер на основе заданных правил подключает нужные файлы и, например, запускает на выполнение соответствующие функции/методы. Если бы мы рассматривали минимальное php-приложение (по современным подходам), то оно бы состояло только из фронт-контролера и роутера. Всё остальное — это обвеска на роутер. Именно так устроены современные php-фреймворки.

Читать дальше...

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

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

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

Существует два основных подхода к организации кэша: в файле и в памяти.

Читать дальше...

PHP Standards Recommendations — это набор рекомендаций для разработчиков на PHP. Отношение к PSR разное: от полного неприятия, то фанатичной преданности. Сам по себе PSR появился как копирование Java Community Process (ага, опять Java!). Основное назначение PSR в том, чтобы предоставить PHP-разработчикам некие общие концепции, которые уже были проверены и отработаны.

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

Читать дальше...

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

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

От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.