Введение в Drupal 10 для разработчиков

Статья является переводом с английского, перевод может являться не точным, в процессе изучения Drupal будет редактироваться и дополняться.

Drupal — это система управления содержимым (content management system, CMS, система управления контентом). Несмотря на то, что Drupal полезен «из коробки», он разработан с учетом потребностей разработчиков.

«Из коробки» Drupal традиционно имеет все стандартные функции CMS:

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

Однако, начиная с 8 версии Drupal улучшил и представил некоторые более мощные возможности. Например, расширенная многоязычная поддержка, модерация контента, построение макетов, REST API и многие другие функции теперь доступны «из коробки».

Обратная совместимость

В Drupal 8 появилось такое понятие как обратная совместимость (backward compatibility, BC).  Drupal 10 это Drupal версии 9.5 c удаленным устаревшим кодом. Мажорные версии позволяют удалять весь устаревший код и оповещают разработчиков программного обеспечения  совместимы ли текущие модули со всеми новыми API и что они отказываются от старых. Так и произошло при переходе с Drupal 8 на Drupal 9.

Начиная Drupal 8 авторы начали полагаться на фреймворки с открытым исходным кодом и Drupal стал зависеть от их жизненных циклов. Здесь наиболее примечательным является фреймворк Symfony. В Drupal 8 использовалась Symfony 3, которая больше не поддерживается с 2021 года, и поэтому окончание срока службы Drupal 8 должно было совпасть с этим годом. Обновление до Symfony 4 означало отказ от обратной совместимости, поэтому также была необходима новая основная версия Drupal (в то время Drupal 9). Теперь, с Drupal 10, мы переходим к использованию Symfony 6. Кроме того, существует множество библиотек, которые также необходимо обновлять, например, Twig.

Что для нас это всё значит? Многие вещи совместимые с Drupal 9, особенно с его более поздними версиями, будут работать и с Drupal 10.

Модули и расширяемость

Загляните на главный веб-сайт Drupal, https://drupal.org/, и вы найдете тысячи модулей, предоставляющих новые функции, и тысячи тем, которые преобразуют внешний вид вашего сайта. Это гибкий способ расширения возможностей Drupal. Благодаря этому механизму можно утверждать, что Drupal — это не просто CMS, а фреймворк для проектирования систем управления контентом (Content Management Framework, CMF), при помощи которого можно перестраивать сайт в соответствии с конкретными потребностями.

Самым большим преимуществом Drupal является его расширяемость. Хотите использовать сервер каталогов для аутентификации? Для этого есть модуль Drupal. Хотите экспортировать данные в файлы CSV? Для этого есть несколько модулей (в зависимости от того, какие данные вы хотите экспортировать). Все эти модули доступны на Drupal.org.

Хотите интегрировать Drupal с тем пользовательским инструментом, который нужен для решения ваших конкретных бизнес-потребностей? Возможно, для этого не существует модуля, но, написав немного кода, вы сможете написать свой собственный модуль.

Технологии, лежащие в основе Drupal

Язык программирования. Drupal написан на языке программирования PHP. Это широко поддерживаемый мультиплатформенный язык сценариев, ориентированный на веб.
Очень важно отметить, что минимальная версия, необходимая для запуска Drupal 10 (и установки через Composer), PHP 8.1. Ранние версии, например PHP 7.4 больше не поддерживается, поскольку срок его службы истек в ноябре 2022 года, а срок службы PHP 8.0 до 2023 года.

Базы данных. Drupal использует мощную библиотеку PHP Data Objects (PDO), которая является стандартной в PHP. Эта библиотека представляет собой уровень абстракции, который позволяет разработчикам поддерживать многочисленные базы данных, включая MySQL, PostgreSQL, SQLite и MariaDB.

Минимальные версии баз данных для Drupal 10 следующие:

  • MySQL 5.7.8/MariaDB 10.3.7/Percona Server 5.7.8 или выше с PDO и InnoDB-совместимым основным механизмом хранения
  • PostgreSQL 12 или выше (с включенным расширением pg_trm)
  • SQLite 3.26 или выше (с включенным расширением json1)

Веб сервер. Drupal изначально был написан для Apache, но теперь многие другие веб-серверы (включая IIS, Lighttpd и Nginx) могут запускать Drupal.
Двумя наиболее распространенными веб-серверами, на которых вы обычно запускаете Drupal, являются Apache и Nginx, со следующими минимальными требованиями к версии для Drupal 10 (такими же, как и для Drupal 9):

  • Apache 2.4.7 или выше
  • Nginx 1.1 или выше

HTML, CSS, and JavaScript. Фактическим форматом веб-данных является HTML, стилизованный при помощи каскадных таблиц стилей (CSS). Интерактивные компоненты на стороне клиента создаются с помощью JavaScript.

Архитектура

Ядро, модули и темы Drupal

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

Библиотеки ядра принадлежат проекту Drupal и заимствуются по лицензии с открытым исходным кодом у более широкого сообщества PHP. Этот подход был новым в Drupal 8, затем продолжен в Drupal 9 и 10 и многими был расценен как позитивный сдвиг в направлении охвата внешних библиотек и фреймворков.

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

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

Темы (ядра и контрибные) предоставляют собой HTML-шаблоны, в рамках которых контент может отображаться пользователю, а также CSS-стили и даже JS-скрипты для интерактивного взаимодействия. Темы могут расширять другие темы, а также могут содержать некоторую логику PHP для обработки данных перед отображением.

Хуки, плагины и события

Хуки — это процедурная концепция Drupal, которая позволяет взаимодействовать ядру и модулям между собой. Работая с хуком мы модем добавлять новую функциональность или изменять существующую. Хуки работают путем сканирования в установленных модулей функции, соответствующей определенному шаблону именования (другими словами, реализации хука). В большинстве случаев это имеет следующий формат — имя_модуля_имя_хука. Кроме того, существуют также хуки, в конце имени функции которых добавлено слово «alter», и которые используются для изменения данных, передаваемых в качестве ссылки.

Разработчики, имеющие опыт объектно-ориентированного программирования (ООП) или глубокие знания шаблонов проектирования, могут признать, что это похоже на парадигму обработки событий, отраженную в шаблоне пассивного наблюдателя. Когда происходит какое-то конкретное событие, Drupal дает модулям возможность отреагировать на это событие.

В предыдущих версиях Drupal, вплоть до Drupal 8, хуки были ОСНОВОЙ. Да, я написал это заглавными буквами. Это потому, что они были способом добавления или расширения функциональности модулей. По существу, они были единственным и наиболее важным аспектом программирования Drupal. Однако, начиная с Drupal 8, хотя они все еще важны, но отошли на второй план к новым концепциям, таким как плагины и события. Ходят разговоры о том, что в какой-то момент их полностью удалят, но давайте подождем и посмотрим, потому что они все еще используются.

Начиная с Drupal 8, я осмелюсь сказать, что плагины стали ОСНОВОЙ. Большая часть логики, которая раньше была привязана к Drupal с помощью хуков, теперь добавлена с помощью плагинов (не путать с плагинами WordPress). Плагины Drupal — это доступные для обнаружения фрагменты функциональности, централизованные менеджером, которые используются для определенных задач и функций.

Третья точка расширения, введенная в Drupal 8 — это система событий. Однако, в отличие от первых двух, она не специфична для Drupal, но, по сути, является фактическим компонентом Symfony EventDispatcher (https://symfony.com/doc/current/components/event_dispatcher.html). События в основном используются в Drupal для перехвата определенных действий или потоков с целью их остановки или изменения. Многие задачи «запрос-ответ», которые в прошлом обрабатывались с помощью перехватчиков, теперь обрабатываются путем отправки событий, чтобы проверить, заинтересованы ли какие-либо модули, например, в доставке ответа пользователю.

Службы и контейнер внедрения зависимостей

Другим архитектурно важным элементом Drupal является компонент Symfony dependency injection (https://symfony.com/doc/current/components/dependency_injection.html).
Этот компонент является основой современного ООП-программирования на PHP и как таковой стал основополагающим для Drupal начиная с версии 8. Он позволяет нам создавать сервисы, которые могут быть внедрены в различные места нашего кода для выполнения определенных функциональных (и часто заменяемых) задач. Кроме того, они также могут использоваться в качестве точки расширения, поскольку контейнер служб способен группировать службы, которые имеют очень специфические обязанности, и использовать их для автоматического выполнения чего-либо. Другими словами, просто определив службу, мы можем предоставить нашу собственную функциональность или даже изменить существующую логику.

От запроса к ответу

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

  1. Пользователь получает доступ к URL-адресу http://example.com/node/123 в веб-браузере.
  2. Браузер связывается с веб-сервером по адресу example.com и запрашивает ресурс по адресу /node/123.
  3. Веб-сервер распознает, что запрос должен быть обработан PHP, и запускает (или связывается) со средой PHP для обработки запроса.
  4. PHP запускает фронт-контроллер (файл index.php), который затем создает новый объект запроса из ресурса, который был запрошен.
  5. HttpKernel Symfony обрабатывает этот объект запроса, отправляя ряд событий, таких как kernel.request, kernel.controller, kernel.response и kernel.view.
  6. Маршрут, который сопоставляется с этим запросом, определяется с помощью события kernel.request.
  7. Контроллер маршрута идентифицирован, и событие kernel.controller используется для выполнения любых изменений на ответственном контроллере, а также для разрешения аргументов, которые необходимо передать ему. В нашем случае этот маршрут регистрируется модулем узла через основную систему сущностей, которая идентифицирует идентификатор сущности, загружает его и создает разметку, которая будет возвращена как часть ответа.
  8. Если соответствующий контроллер (или обработчик) возвращает что-то отличное от объекта Response, отправляется событие kernel.view, чтобы проверить, существует ли какой-либо код, который может преобразовать это в объект response. В большинстве случаев контроллеры обычно возвращают массивы рендеринга, которые преобразуются в объекты response.
  9. Как только ответ создан, фронт-контроллер возвращает его браузеру и завершает запрос.

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

Основные подсистемы Drupal

Маршрутизация (Routing). Все начинается с маршрута, не так ли? Большинство взаимодействий с веб-сайтом Drupal начинаются с использования доступа к определенному пути (или ресурсу). Это преобразуется в маршрут, который сопоставляет этот ресурс с потоком, который возвращает успешный ответ. В основе всего этого лежит компонент маршрутизации Symfony (http://symfony.com/doc/current/components/routing.html).

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

Ядро Drupal по-прежнему поставляется с типом сущности Node, с несколькими подтипами (bundles), такими как Базовая страница (Basic Page) и Статья (Article) в стандартном установочном профиле. Кроме того, он поставляется с несколькими другими типами сущностей, такими как Пользователь (User), Комментарий (Comment), Файл (File) и так далее.

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

Понимание системы сущностей необходимо для разработки в Drupal, поскольку она предоставляет мощный способ моделирования пользовательских данных и контента.

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

Поля (Fields). Раннее упоминалось, что определенные подтипы сущностей могут иметь различные поля. Это означает, что каждый подтип типов сущностей может иметь любое количество полей, которые отвечают за хранение данных. Кроме того, каждый тип сущностей сам по себе может иметь поля для хранения данных.

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

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

Меню (Menus). Любому сайту нужна какая-то навигация. Drupal сохраняет структуру взаимосвязи контента.
Основной способ, которым он это делает — через подсистему меню. Он предоставляет API для создания, извлечения и изменения элементов, описывающих структуру сайта. Говоря простым языком, он управляет навигационными меню.
Меню иерархичны; то есть они имеют древовидную структуру. Пункт меню может иметь несколько дочерних элементов, каждый из которых может иметь своих собственных дочерних элементов, и так далее. Таким образом, мы можем использовать систему меню для структурирования нашего сайта на разделы и подразделы.

Представления (Views). Просмотр содержимого и данных всегда является важной возможностью, которую предоставляет CMS, и это то, что Views делает в Drupal. Цель модуля «Представления» — предоставить данные и контент пользователю. Он включает в себя фильтры, сортировки, параметры отображения и многие другие функции.

Представления привязаны к общей архитектуре и используются для большинства страниц (особенно страниц администрирования), предоставляемых ядром Drupal.

Формы (Forms). Если на вашем сайте нет трех страниц и пяти абзацев текста, вероятность того, что вам потребуется получать вводимые пользователем данные с помощью какого-либо типа формы, очень высока. Кроме того, если вы занимались программированием приложений на PHP, вы знаете, что формы всегда были проблемой с точки зрения безопасного и эффективного отображения и обработки отправленных данных. Как только вы начнете использовать PHP-фреймворк, такой как Symfony или Laravel, вы заметите, что существует API, который снимет большую часть этой нагрузки с ваших плеч.

То же самое касается Drupal и его мощного Form API. Исторически сложилось так, что это была большая абстракция по сравнению с необходимостью выводить ваши собственные элементы формы и иметь дело с опубликованными значениями. Это позволяет вам определить свое собственное определение формы в ООП и обрабатывать проверку и отправку логическим способом. О его отображении и обработке надежно заботится Drupal, так что вам не нужно беспокоиться ни о чем из этого.

Конфигурация (Configuration). Централизованная система конфигурации Drupal, хотя и хранит всю конфигурацию в базе данных, позволяет экспортировать ее в файлы YAML (а затем повторно импортировать). Это означает передачу её в систему контроля версий (Git). Итак, с точки зрения разработки, у нас есть хорошая связь между функциями, которые мы кодируем, и конфигурацией, от которой они зависят (например, новое поле).

Конфигурация бывает двух видов — простая и сложная (объекты конфигурации, которые мы отметили в разделе «Сущности»). Разница между ними заключается в том, что простая конфигурация всегда является единственной. Другими словами, существует только один экземпляр самого себя. Например, внутри такого элемента конфигурации хранятся имя сайта и адрес электронной почты. Вы не ожидаете, что потребуется более одного экземпляра этих двух элементов значения. Однако в случае сложной конфигурации вы бы это сделали. Например, определение представления является таким объектом конфигурации, поскольку оно следует определенной схеме, и у нас может быть несколько определений представления.

Плагины (Plugins). Это элегантное решение важной проблемы — инкапсуляции функциональности. Не следует путать их с такими вещами, как плагины WordPress, которые больше похожи на модули Drupal. Вместо этого вам следует думать о плагинах как о компонентах многократно используемого кода, которые могут использоваться и управляться центральной системой.

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

Важным аспектом их работы является возможность их обнаружения. Большинство типов плагинов обнаруживаются с помощью так называемых аннотаций. Аннотации — это форма комментариев DocBlock, заимствованная из библиотеки Doctrine (https://www.doctrine-project.org/projects/doctrine-annotations/en/latest/index.html), с помощью которой мы можем описывать классы, методы, и даже свойства с определенными метаданными. Затем эти метаданные считываются, чтобы определить, что это за элемент, без необходимости создания экземпляра класса. Второй наиболее распространенный метод обнаружения плагинов — через файл YAML, а популярный пример — ссылки меню.

Темы (Theme). Ответственность за тематизацию данных распределена между ядром Drupal, модулями и самими темами. Итак, как разработчику модулей важно знать, что и модули, и темы могут тематизировать данные или контент.

Система шаблонов, используемая Drupal — это Twig (https://twig.symfony.com), которая с Drupal 10 была обновлена до версии 3.

Кэширование (Caching). Последней важной подсистемой является уровень кэширования. Начиная с версии 8, Drupal приложил немало усилий для повышения производительности создания страниц и рендеринга данных. С этой целью система кэширования стала важной частью, которую следует учитывать всякий раз, когда мы выполняем сложные или объемные вычисления или рендерим контент.

API Drupal и стандарты кодирования

Для написания хорошего кода на Drupal требуется много базовых знаний.
Во-первых — это официальная онлайн-документация по API. Практически каждая функция в Drupal документируется с помощью документации по встроенному коду. Затем программа Doxygen используется для извлечения этой документации и ее форматирования. Вы можете получить доступ к полной документации по API онлайн по адресу http://api.drupal.org.

Наряду с использованием API Drupal, мы стремимся соблюдать соглашения Drupal о кодировании. Лучшие практики разработки программного обеспечения включают поддержание чистоты, согласованности и удобочитаемости кода. Одним из аспектов этого является устранение нюансов в форматировании кода путем следования стандарту.

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

На сайте Drupal есть руководство по стандартам кодирования, с которым должен ознакомиться каждый разработчик Drupal (https://www.drupal.org/docs/develop/standards/coding-standards). Это не произойдет в одночасье; с опытом вы станете лучше, но вы также можете настроить свою среду IDE, чтобы, например, отмечать любые проблемы с форматированием вашего кода.

Третьим ресурсом является база данных записей изменений (https://www.drupal.org/list-changes/drupal). На этой странице вы найдете перечень наиболее важных изменений в API и использовании с некоторыми удобными пояснениями. Поскольку Drupal 10 будет поставлять новые функции каждые 6 месяцев, очень важно следить за этой базой данных.

Модуль разработчика (Devel)

В вашей среде разработки вы можете установить удобный модуль под названием Devel (http://drupal.org/project/devel), который предоставляет несколько сложных инструментов, призванных помочь разработчикам создавать и отлаживать код Drupal.

Ниже приведены некоторые функции этого модуля:

  • Функции, используемые для вывода объектов и массивов в форматированный вывод Drupal
  • Инструменты для анализа использования базы данных и производительности
  • Генератор контента для быстрого заполнения вашего сайта тестовым контентом

Drush (оболочка Drupal)

Иногда гораздо проще выполнить некоторые задачи с помощью одной команды в консоли. Drush (https://github.com/drush-ops/drush) предоставляет интерфейс Drupal командной строки, и его можно использовать для выполнения задач несколькими нажатиями клавиш в консоли.
При разработке нам часто приходится очищать кэши, выполнять определенные задачи или развертывать данные на удаленном сервере. Drush может помочь в выполнении подобных задач. Кроме того, мы можем написать наши собственные команды Drush, которые выполняют различные пользовательские задачи, например, для использования в заданиях cron. Таким образом, установка Drush является обязательной для любого серьезного разработчика Drupal.

Настройки разработчика

При локальной разработке полезно (иногда) отключать такие вещи, как кэширование, чтобы ускорить работу. Для этого мы можем использовать локальные настройки, которые отключают кэширование, предотвращают агрегацию файлов CSS и JavaScript и выполняют другие подобные действия.

Эти настройки находятся внутри файла example.settings.local.php в папке /sites установки. Чтобы воспользоваться ими, вам нужно убедиться, что они включены в ваш основной файл settings.php (либо скопировав их внутрь, либо включив файл).

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

Drupal check

Чтобы облегчить обновление кода с Drupal 9 до 10, сообществом был создан хороший инструмент, который статически обрабатывает ваш код и указывает на все возможные случаи использования устаревшего кода. Это утилита командной строки под названием drupal-check, которая легко устанавливается и может значительно ускорить этот процесс. Конечно, вы также можете положиться на IDE, чтобы отмечать устаревшие предупреждения.

Инструмент можно найти здесь: https://github.com/mglaman/drupal-check.

Резюме

Эта статья была обзором Drupal для разработчиков. Мы увидели, какие технологии использует Drupal. Мы взглянули на архитектуру Drupal. Мы бегло взглянули на несколько важных подсистем Drupal. Мы также получили представление о том, какие инструменты, ориентированные на разработчиков, следует использовать при работе с Drupal.

Как установить Composer на Debian GNU/Linux 10 (buster)

Введение

Composer — популярный инструмент управления зависимостями для PHP, созданный в основном для облегчения установки и обновления зависимостей проекта.

Шаг 1 — Установка зависимостей

В дополнение к зависимостям, которые уже могут быть включены в вашу систему Debian 11, Composer требует php-cli для выполнения PHP сценариев в командной строке и unzip для извлечения заархивированных архивов.

Начнём с обновления кэша менеджера пакетов:

sudo apt update

Далее установим зависимости. Нам потребуется curl для загрузки Composer, а также php-cli для его установки и запуска. Пакет php-mbstring необходим для предоставления функций для библиотеки, которую вы будете использовать в этом руководстве. Пакет git используется Composer для загрузки зависимостей проекта и unzip для извлечения заархивированных пакетов. Все можно установить с помощью следующей команды:

sudo apt install curl php-cli php-mbstring git unzip

Теперь, когда все зависимости установлены, мы можем установить Composer.

Шаг 2 — Загрузка и установка Composer

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

Сначала убеждаемся, что мы в своем домашнем каталоге:

cd ~

Затем загружаем установщик, используя curl:

curl -sS https://getcomposer.org/installer -o composer-setup.php

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

HASH=`curl -sS https://composer.github.io/installer.sig`

Чтобы вывести полученное значение, выполните:

echo $HASH

Теперь выполните следующий PHP-код, чтобы убедиться, что запуск сценария установки безопасен:

php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

Если вы получили сообщение Installer corrupt, вам необходимо еще раз загрузить сценарий установки и убедиться, что вы используете правильный хэш. Затем запустите команду, чтобы еще раз проверить установщик. Если у вас есть проверенный установщик, вы можете продолжить.

Для глобальной установки Composer используйте следующую команду:

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Проверьте правильно ли установился Composer, выполнив следующую команду:

composer

В результате будут отображены версия и аргументы Composer, подобные следующему:

Output:
   ______
  / ____/___  ____ ___  ____  ____  ________  _____
 / /   / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/
/ /___/ /_/ / / / / / / /_/ / /_/ (__  )  __/ /
\____/\____/_/ /_/ /_/ .___/\____/____/\___/_/
                    /_/
Composer version 2.6.6 2023-12-08 18:32:26

Полезные ссылки

Ипотека. Что выбрать при погашении: срок или размер?

Давайте кратко обсудим схемы погашения ипотеки: сокращаем срок выплат или их размер?

Если вкратце, особой разницы нет, если делать это РЕГУЛЯРНО. Размер переплат будет равномерно снижаться.

А ещё эти схемы можно комбинировать. Как можно достигнуть большего эффекта? Часть свободной суммы вы можете потратить на сокращение срока, часть — на сокращение платежа.

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

❗Совет для тех, кто только думает оформлять ипотеку

Как правильно рассчитать приемлемый для вас размер платежа? Примените формулу успешной ипотеки:

1️⃣ установите для себя размер комфортного платежа (сумма, которую можно выплачивать, не сильно ущемляя себя)

2️⃣ прибавьте к нему “навес” (сумма, которую мы можем ежемесячно добавлять сверх платежа). 

3️⃣ благодаря этой формуле вы можете сделать любой ваш платёж дифференцированным.

Пример: «комфортная сумма» 10000 руб. + навес 3000 руб. = 13000 руб. ваш ежемесячный платёж. Если выбираете сократить платеж, следующая ваша оплата будет равна условно 9900 руб. Для сохранения принципа дифференцированности, нужно будет добавить к следующему платежу не 3000, а 3100 руб., чтобы компенсировать эту разницу.

Сколько вы переплачиваете по кредитам?

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

⭕️ Страховка;
⭕️ Оплата нотариуса;
⭕️ Оценка недвижимости в случае с ипотекой;
⭕️ Пенни, если просрочили платеж по кредиту;
⭕️ Комиссии от банков.

Что влияет на рост переплаты?

Чаще банки предлагают аннуитетный тип платежей — когда вы вносите каждый месяц одинаковую сумму.

💲 Чем больше срок кредита, тем больше переплата. Каждый платеж включает остаток основного долга и проценты по нему. Остаток долга при длительных сроках кредитования будет уменьшаться медленнее.

💲 Большая ставка по кредиту принесет большую переплату. Так, в вашем ежемесячном платеже сумма процентов будет прямо зависеть от размера ставки по кредиту.

Как посчитать переплату?

Если вы возьмете 1 000 000 рублей на 36 месяцев по ставке 12%, ваш ежемесячный платеж составит 33 214 рублей.

Суммарная переплата = Срок кредита * Ежемесячный платеж — сумма кредита.

В нашем случае сумма переплаты = 36 * 33 214 — 1 000 000 = 195 704 рубля. К этому значению добавьте остальные расходы по кредиту: комиссию, страховку и т.д.

Как уменьшить переплату по кредиту?

✔️ Ищите кредит под минимальный процент и по возможности на меньший срок.

✔️ В случае с потребительским кредитом и ипотекой вносите досрочные платежи. Сможете уменьшить сумму основного долга и заплатите меньше процентов.
✔️ Рефинансируйте кредит по более выгодной процентной ставке. Так, ипотеку целесообразно рефинансировать даже при разнице ставок в 1-2%.
✔️ Используйте льготы: материнский капитал, субсидии для врачей и учителей, налоговые вычеты от государства.

Сколько вы готовы дать в долг?

 Давайте поговорим про долги друзьям и родственникам. Как вы к ним относитесь? Готовы давать деньги в займы? Часто одалживаете сами?

Сервис SuperJob провел опрос согласно которому: 

  • 60% россиян никогда не берет деньги в долг
  • 44% россиян никогда не одалживают деньги

У кого чаще одалживают деньги?

  • 11% обращаются к родственникам
  • 7% к друзьям
  • 1% занимает деньги у коллег или берут заем на работе
  • 19% почти каждый пятый россиянин берет кредит в банке 

Кому готовы одолжить деньги россияне?  

  • родственникам 22%
  • друзьям — 21%
  • коллегам — 9% 

Причем мужчины более отзывчивы к просьбам сослуживцев дать в долг до зарплаты. 10% против 8% среди женщин. Больше всего тех, кто готов подкинуть денег коллеге старше 45 лет (11%).

Сколько готовы одалживать?

Средняя сумма, которую среднестатистический россиянин может одолжить родственнику — 16 тыс. руб., другу — 11 800 руб., коллеге — 5800 руб. 

А как часто вы берете или даете деньги в долг?

Всегда ли вам возвращали деньги вовремя? 

Кредит: добро или зло?

Как кредит может быть хорошим?

У кредитов, как финансового инструмента, плохая репутация. Большая переплата, штрафы и пени за просрочку, бюрократия при оформлении. Казалось бы, что может быть хорошего в кредитах и долговых обязательствах перед банками? Мы нашли несколько, примеров: 

1️⃣ Вы используете кредит, чтобы больше заработать. Например, кредит на развитие бизнеса. В этом случае кредит поможет вам увеличить доход. Или вы берете дешевые деньги у банка, чтобы свои вложить под больший процент, чем процент по кредиту.

В обоих вариантах ― это ваши не последние деньги. У вас всегда должна быть возможность погасить кредит из собственных средств. И, конечно, вы понимаете высокий риск таких вложений и готовы к ним.

2️⃣ Вы берете кредит на обучение, которое поможет вам увеличить доход. Но и в этом случае ― сумма кредита и платежи по нему должны быть комфортными для вашего бюджета. 

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

3️⃣ Недорогие кредиты (под низкий процент). Например, ипотека. Такой кредит в долгосрочной перспективе увеличит ваше благосостояние и капитал. Инфляция с годами сделает деньги банка дешевле.

А выгодное расположение недвижимости может увеличить её стоимость. Квартиру из пассива можно легко перевести в актив ― продать и разместить деньги под процент или сдавать недвижимость и окупать ипотеку. 

Плохие кредиты

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

Чаще всего плохие кредиты ― это: 

⛔️ дорогие кредиты (под высокий процент). Например займы в микрофинансовых организациях. Ставки по ним могут составлять до 1% в день (или 365% в год!) 

⛔️ кредиты, взятые вместо накоплений (бытовая техника, смартфоны, брендовые вещи). Если на товары не первой необходимости приходится брать кредит ― значит такая покупка за рамками просто не по карману покупателю. Чаще всего это потребительские кредиты или кредитки, в которых вы выходите за рамки грейс-периода.

Какая у вас кредитная нагрузка?

Как определить свою долговую нагрузку?

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

Например: 
💸 ваш доход 100 000 рублей (личный или семейный)
🏦 платежи по кредитам = 25 000 ипотека + 10 000 автокредит + 7 000 рублей за потребительский кредит на ремонт = 42 000 рублей
🏋️ваша долговая нагрузка = (42 000 / 100 000)*100% = 42% 

Уровень долговой нагрузки получился 42% ― это значит, что 42% своих доходов вы отдаете на обслуживание кредита. Это много или мало? Давайте разбираться дальше.

Какой уровень долговой нагрузки считается оптимальным?

Конечно, чем меньше, тем лучше. В идеале жить без кредитов вовсе. Но уровень долговой нагрузки до 30% считается приемлемым. Все, что выше 30% ― требует внимания и действий по сокращению: 

🟢 до 30% — приемлемый уровень кредитной нагрузки;
🟡 30-40% — повышенный уровень кредитной нагрузки;
🟠 40-50% — высокий уровень кредитной нагрузки;
🔴 более 50% — критический уровень кредитной нагрузки. 

В зависимости от уровня закредитованности, соотношения доходов и расходов и наличия накоплений выделяют 4 основных уровня финансового положения. Вот их основные характеристики:

🔴 Красный (или кризисный) уровень: 
— долговая нагрузка больше 50%;
— большое количество кредитов и кредитный карт (суммарно 3 и более);
— расходы больше доходов. 

🟠 Оранжевый (или рискованный) уровень: 
— долговая нагрузка от 30% до 50%;
— большое количество кредитов, которые невозможно закрыть за год (кроме ипотеки); 
— расходы больше или равны доходам. 

🟡 Желтый уровень: 
— долговая нагрузка до 30% (включая ипотеку);
— расходы равны доходам;
— не получается откладывать и копить. Даже, если небольшая сумма скапливается, она достаточно быстро тратится. 

🟢 Зеленый уровень: 
— отсутствие долгов или долговая нагрузка до 30%
— есть накопления, в том числе подушка безопасности;
— доходы больше расходов.

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

Поиск пути

Поиск пути (англ. Pathfinding) — термин в информатике и искусственном интеллекте, который означает определение компьютерной программой наилучшего, оптимального маршрута между двумя точками.

По своей сути алгоритм поиска пути ищет на графе, начиная с одной (стартовой) точки и исследуя смежные узлы до тех пор, пока не будет достигнут узел назначения (конечный узел). Кроме того, в алгоритмах поиска пути в большинстве случаев заложена также цель найти самый короткий путь. Некоторые методы поиска на графе, такие как поиск в ширину, могут найти путь, если дано достаточно времени. Другие методы, которые «исследуют» граф, могут достичь точки назначения намного быстрее. Здесь можно привести аналогию с человеком, идущим через комнату. Человек может перед началом пути заранее исследовать все характеристики и препятствия в пространстве, вычислить оптимальный маршрут и только тогда начать непосредственное движение. В другом случае человек может сразу пойти в приблизительном или предполагаемом направлении цели и потом, уже во время пути, делать корректировки своего движения для избегания столкновений с препятствиями.

К самым известным и популярным алгоритмам поиска пути относятся такие алгоритмы:

  • Алгоритм поиска A*
  • Алгоритм Дейкстры
  • Волновой алгоритм
  • Маршрутные алгоритмы
  • Навигационная сетка (Navmesh)
  • Иерархические алгоритмы
  • Обход препятствий
  • Разделяй и властвуй
  • Алгоритм поворота Креша

Пример визуализации поиска пути:

Hello, World!

«Hello, World!» — программа, результатом работы которой является вывод на экран фразы «Hello, World!» (в дословном переводе с английского — «Здравствуй, Мир!»; представляет собой распространённое неформальное приветствие, близкое к русскому «Всем привет!»). Обычно это первый пример программы в учебниках по программированию, и для многих студентов такая программа является первым опытом при изучении нового языка.

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

Хотя небольшие проверочные примеры использовались с тех самых пор, как появились компьютеры, традиция использования фразы «Hello, World!» в качестве тестового сообщения была введена в книге «Язык программирования Си» Брайана Кернигана и Денниса Ритчи, опубликованной в 1978 году.

В среде программирования микроконтроллеров при отсутствии дисплея простейшей программой «Hello, World» является программа «blink», реализующая мигание светодиода на одном из выходов микроконтроллера. Цель такой программы является успешная компиляция программы (при изучении нового микроконтроллера или новой среды разработки), прошивка программы в микроконтроллер и демонстрация работоспособности самого микроконтроллера.

Примеры таких программ можно посмотреть тут (коллекция реализаций хеллоуворлда на 450+ языках).

Что такое CodeIgniter и для чего он нужен

CodeIgniter — популярный MVC фреймворк с открытым исходным кодом, написанный на языке программирования PHP, для разработки полноценных веб-систем и приложений. Разработан компанией EllisLab, а также Риком Эллисом и Полом Бурдиком.

Старая версия CodeIgniter’а (CodeIgniter 2.x), как и более ранние версии, распространяются под проприетарной лицензией в стиле Apache/BSD, однако текущая ветвь CodeIgniter 4 перелицензирована под MIT.

Ссылка: https://codeigniter.com/