По идее про «API» должны знать все разработчики. Переводится как программный интерфейс приложения, но поскольку для нас наибольший интерес представляет Интернет, то речь пойдёт о Web API. Под ним обычно понимают некие http-запросы между клиентом и сервером. То есть всегда есть тот, кто отправляет запрос и есть тот, кто его обрабатывает и возвращает результат.

Простой пример. Вася — верстальщик, который делает сайт и знает только HTML и JavaScript. На сайте есть страница, которая выводит список пользователей. Чтобы его отобразить, нужно вначале откуда-то получить данные.

Петя, наоборот, ничего не знает о JS и верстке, но неплохо разбирается в PHP и базах данных. То есть Петя делает так, чтобы можно было сформировать данные о юзерах, а Вася сможет их получить через простой Ajax-запрос к серверу. Петя даёт Васе URL-адрес такого запроса, http-метод и список возможных параметров. Вася указывает их в fetch() или XMLHttpRequest() и получает готовые JSON-данные, которые прекрасно работают с его js-скриптами.

Вот этот механизм, когда программа предоставляет интерфейс для управления и называется API.

Читать ➝

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

Пользоваться таким кодом очень сложно, поскольку приходится заключать каждую функцию/метод в блок try/catch, хотя было бы достаточно, если функция вернёт обычный false.

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

Для новичков, которые не имеют опыта полноценного программирования (например на Pascal/Delphi) исключения — это вообще тёмный лес... Попробуем разобраться.

Генератор мне потребовался для создания документации для новой версии Berry CSS. Но перед этим я хочу сделать небольшой анонс. Я о нём уже писал в своём телеграмм-канале, продублирую и здесь.

Я решил расширить возможности Berry и сделать из него полноценный css-фреймворк на основе утилитарных классов. Основная задача - повторить Bootstrap по возможностям, за исключением сложных js-компонентов. Отличие Berry в том, что утилитарными классами можно выполнить вёрстку практически любого блока, то есть это универсальный подход. Но, чтобы показать его преимущество, нужна полноценная документация. Поэтому Berry 3 (будущая версия) выйдет только после того, как я напишу всю документацию.

Структурно Berry будет состоять из нескольких модулей. Первый — утилитарные классы, это примерно то, что сейчас и есть. Второй модуль — типографика. Это примерно то, что входит в комплект UniCSS. Третий модуль — цвета. Я сильно их переиграл, чтобы можно было работать не только с индивидуальными цветами, но и целыми группами. Например, если шаблон использует только красные оттенки, то достаточно указать только эту группу. И последнее — будет несколько js-компонентов на чистом javascript без каких-либо зависимостей. Меня, честно говоря, уже задолбало учитывать версии jQuery, и прочих библиотек. Такие компоненты состоят из css, scss и js-файлов + readme и всё. Подключай как хочешь.

Читать ➝

Это достаточно «классическая» задача в PHP — приём и отправка обычной формы. Давным-давно, ещё во времена PHP 4, в книгах приводился пример того как это делать. Это всегда был один php-файл, где размещался и обработчик формы, и html-код вывода формы, и вывод ошибок. Понятно, что на заре рождения PHP, говорить о каком-то разделении кода или даже о культуре программирования не приходится. Но, недавно я случайно наткнулся на книгу о PHP 7 2018 года выпуска, где рассказывается об основах языка, классах, есть даже глава о PostgreSQL и даже описано несколько ООП-шаблонов проектирования.

Я с удивлением обнаружил, что до сих пор приводится код из PHP 4, как будто бы последних 20 лет развития PHP-программирования и не было. Сами посмотрите: это я сохранил скриншот. То есть вместо того, чтобы учить студентов нормальным практикам, до сих пор предлагается код 20-летней давности.

Чтобы продолжить, давайте определимся что именно неверно в таком подходе.

Читать ➝

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

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

Читать ➝

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

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

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

Читать ➝