Кто я и почему я знаю, о чем пишу

Меня зовут Артем Зернов. Я не могу сказать, что я успешен как предприниматель или я супер веб-разработчик хоть с каким-то индексом цитирования. Но если вкратце, то у меня есть небольшая веб-студия по разработке сайтов, которой не так давно исполнилось 10 лет. Стремления к огромному количеству заказов у меня нет, так как я не бизнесмен, а скорее главный мастер небольшой веб-студии OpenColour. У меня нет стремления охватить все-все технологии. Я их изучаю по мере необходимости, именно в тот момент, когда возникает потребность их применить в конкретном проекте.

MODx — любовь с первого взгляда

До MODx я писал полу-кривые сайты на Joomla, в которой все было разбросано по разным подмодулям и нужно было порой поломать голову, чтобы понять принцип организации админки. А для того, чтобы реализовать что-то более-менее нестандартное, то мозг просто разрывался на части.

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

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

Любовь со второго взгляда. Разработка прямо в админке.

Второе, что привлекло, пожалуй, еще больше, чем первое — это возможность разработки сайта прямо из админки. На первый взгляд мне казалось, что это какой-то урезанный функционал и полноценной разработки сайта только из админки быть не может. Я ошибался. Как выяснилось, для разработки сайтов без сложной внутренней бизнес-логики, этого более, чем достаточно. Конечно, в будущем, я перешел на разработку из IDE. Как ни крути, но IDE вроде PhpStorm врядли сможет переплюнуть даже самая продвинутая админка. Но эта статья совсем не об этом.

Из каких кирпичиков состоит MODx

Как и любой фреймворк, MODx также состоит из неких базовых сущностей, на основе которых разрабатывается веб-сайт или веб-приложение. В MODx основными (но не всеми) таковыми сущностями являются:

• Шаблоны
• Чанки
• Сниппеты
• Плагины
• Ресурсы
• Системные настройки

Я перечислил только их, так как понимания этих сущностей будет вполне достаточно, чтобы разрабатывать полноценные веб-сайты и веб-приложения на MODx.

Поговорим о них более подробнее в одной из следующих статей. А я продолжу о своей преданности к MODx.

Так почему же все-таки MODx является моей любимой системой?

Если мне еще не удалось донести, почему же я питаю к MODx такие преданные чувства, то сейчас я постараюсь это сделать. Работая с той же Joomla, мне приходилось ломать голову, как реализовать тот или иной функционал в рамках конкретной верстки. И чаще всего мои решения выглядели как костыли. Я не уверен, было ли это связано с моим недостаточным опытом, или с неудобностью системы, на которой я строил сайты, но точно могу сказать, что при работе с MODx решения приходили как-то сами собой. И это, однозначно, говорит об удачности архитектуры. А когда разработка не заставляет каждый раз воевать с ограничениями системы, тогда она начинает приносить гораздо больше удовольствия от того, что все получается и практически с первого раза. Собственно, пожалуй, именно поэтому мы подружились с MODx и остаемся друзьями по сей день.

Как ведет себя обычное приложение на MODx Revolution

Любой сайт на MODx по-умолчанию имеет несколько различных точек входа. Под точкой входа подразумевается конечный php-скрипт, к которому обращается браузер через веб-сервер (nginx или apache).

Точка входа #1: основной файл index.php

Данный файл лежит в корневой папке сайта.

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

По-умолчанию путь к этому файлу:

/путь/до/корневой папки/сайта/index.php

Точка входа #2: файл index.php админки

Данный файл очень похож на предыдущий index.php, но отличается тем, что инициализирует другой контекст (mgr) и ряд других классов, предназначенных для работы с админкой. Например, вместо класса modResponse и modRequest инициализируются классы modManagerResponse и modManagerRequest.

Цель данного скрипта схожа с целью предыдущего index.php. Разница в том, что в отличие от Frontend, в админке нам не нужно находить определенную страницу в базе, чтобы выдать ее контент. В админке данный скрипт находит необходимый контроллер (modManagerController) и запускает его, а контроллер, в свою очередь уже выдает в браузер запрашиваемый контент, представляющий из себя набор подключенных javascript-файлов, генерирующих интерфейс на ExtJS.

Путь к даному файлу по-умолчанию:

/путь/до/корневой папки/сайта/manager/index.php

Точка входа #3: файл index.php для коннекторов

Есть еще одна точка входа по-умолчанию – это точка входа для коннекторов.

Коннекторы (connectors) в modx – это скрипты, запускаемые через вышеупомянутую точку входа и принимающие на себя ajax-запросы из различных элементов интерфейса админки. Но при определенных условиях они также могут использоваться и для обработки ajax-запросов из frontend-части сайта.

Цель коннектора: принять запрос, проверить, является ли данный запрос авторизованным, запустить необходимый процессор (modProcessor) и отдать контент клиенту. Как правило, контент отдается в формате JSON.

Путь к даному файлу по-умолчанию:

/путь/до/корневой папки/сайта/connectors/index.php

Механизм обработки запроса

Первичная инициализация

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

Инициализация контекста web

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

Инициализация контекста включает в себя:

• Подключение кэш-менеджера (modCacheManager)
• Загрузку конфигурации контекста (набор различных системных переменных, переменных контекста и прочих общих настроек, доступных для различных компонентов)
• Подключение глобальных компонентов (extension packages)
• Инциализацию механизмов контроля сессий (sessions)
• Инициализацию механизмов обработки ошибок (modErrorHandler)
• Инициализацию языковых механизмов
• Инициализацию механизмов регистра (modRegistry)
• Установку общедоступных плейсхолдеров
• Генерацию события OnMODXInit.

Обработка запроса

После инициализации запускается процесс обработки запроса.

Данный процесс можно разделить на 2 основные части:

1. Анализ самого запроса
2. Генерация и выдача контента

Анализ запроса и поиск ресурса

Для того, чтобы понять, какой именно ресурс просит от modx клиент, обратившись к конкретному URL, modx запускает метод handleRequest соответствующего класса.

Для frontend используется метод modRequest::handleRequest. Данный метод анализирует URL, выделяя из него необходимые части, по которым можно однозначно найти ресурс в базе данных, а также обращается к системным настройкам modx для определения метода поиска ресурса.

В случае, если ресурс не будет найден, будет выдана страница ошибки. Но если ресурс обнаружен, то запускается следующий процесс – процесс генерации и выдачи контента клиенту.

Генерация контента

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

Весь процесс обработки и генерации контента можно поделить на несколько этапов:

1. Определение типа содержимого страницы
2. Подготовка содержимого страницы
3. Подключение внедряемого кода
4. Вставка специальных тегов modx
5. Генерация заголовков
6. Выдача контента клиенту

Подготовка содержимого страницы

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

Содержимое страницы в MODx состоит из кода, который генерируется шестью различными сущностями:

1. Шаблоном страницы
2. Полями ресурса (как основными вроде pagetitle, content, так и дополнительными TV-полями)
3. Плейсхолдерами (например при обращении к системной настройке или настройке контекста)
4. Вызываемыми сниппетами
5. Вставляемыми чанками
6. Плагинами

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

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

Финальные процессы

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

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

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

Заблуждения о дизайне

Типичный заказчик

То, что вы нарисовали, не соответствует тому, что у меня в голове

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

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

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

Википедия

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

Ключевое значение имеют слова "решение проблем". И, как вы догадываетесь, проблема заказчика, который заказывает разработку дизайна сайта, состоит далеко не в том, чтобы дизайнер нарисовал картинку из головы, но в том, чтобы решить вопрос "Зачем заказчику сайт?"

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

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

Семь раз отмерь...

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

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

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

Веб-дизайн – это оформление контента

А вы как думали? Да, дизайн – это оформление контента. Нет контента, тогда и нечего оформлять. Если вы не согласны с этой мыслью, тогда перечитывайте этот абзац снова и снова, пока не поймете, что это так.

В первую очередь, это понимание нужно вам, а во вторую – заказчику. Ошибочно предполагать, что сначала вы нарисуете красивую картинку и наполните ее рыбой вроде Lorem Ipsum, и натыкаете изображений из интернета, а потом заказчик вставит туда свои тексты и фотографии. В большинстве случаев это будет напоминать мемы "Ожидание vs Реальность". Когда вместо качественной фотографии вставляются замыленные фотографии, сделанные на смартфон, а вместо 1-го абзаца текста вставляется первый том "Войны и Мир" Льва Толстого. Все ваши труды дружно пойдут коту под хвост.

Донесите эту мысль вашему заказчику и не ведитесь на слова клиента:

"Вы пока что-нибудь туда вставьте, а мы потом напишем тексты и подготовим фотографии"

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

Вывод: не торопитесь побыстрее что-то нарисовать, пока нет хотя бы набросков реального содержимого.

Доверие и правильное распределение ролей

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

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

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

Вывод: отделяйте свою зону ответственности от зоны ответственности заказчика. Если заказчик вам не доверяет, нужен ли вам такой заказчик?

Когда-то давно я делал выпуск по схожей теме на одном из моих youtube-каналов:

Минимизация субъективной составляющей процесса

Сайт – это инструмент, а не просто картинка, которая должна кому-то понравиться. Все или почти все в его дизайне должно иметь практический смысл. Другими словами, любой элемент дизайна должен быть логически обоснованным, служить какой-то практической цели. Например, привлекать внимание пользователя к чему-либо, информировать о чем-либо, вызывать чувство доверия и т.д.

Поэтому, учитывая вышесказанное, оценивать дизайн словами "нравится" или "не нравится" нельзя. Такая оценка слишком субъективна и неконструктивна. При работе над дизайном важно донести заказчику, что критика должна быть объективной настолько, насколько это возможно.

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

Вывод: минимизируйте наличие субъективной составляющей при оценке результата работы.

Правки, правки, правки... Да сколько можно?

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

Я всегда стараюсь объяснить, что количество вариантов дизайна всегда одно, а количество правок – не более 3-х циклов. На вопрос "Почему только один вариант, у других как минимум 2?" я предпочитаю отвечать так:

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

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

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

Вывод: важно донести мысль о том, что нет смысла создавать несколько вариантов дизайна.

Итог

Мой опыт ведения процессов при разработке сайтов – это результат как минимум 10-ти лет работы с разными заказчиками. Но не стоит списывать мою субъективную составляющую. Для меня при работе с заказчиком в первую очередь важен комфорт и отсутствие стрессов, поэтому я стараюсь отказываться от тех заказчиков, которые потенциально могут потрепать нервы. Возможно, что для тебя, мой читатель, удовольствие от денег может покрыть достаточную долю стресса и потраченных нервов, поэтому некоторыми из моих советов можно и пренебречь.

Спасибо за внимание!

Для чего нужен FormIt?

Если вкратце, то FormIt — это компонент для MODx Revolution, представляющий из себя набор сниппетов и дополнительного интерфейса админки MODx для обработки значений форм и навешивания на них дополнительной логики при успешном/неуспешном заполнении.

Как использовать

Все довольно просто. В коде вашего шаблона/чанка, где находится ваша форма в виде html-кода, перед этой формой ставите вызов сниппета FormIt.

Например:

[[!FormIt]]

или, если вы используете Fenom-синтаксис:

{'!FormIt' | snippet}

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

Механика работы

При отправке данных формы POST запросом на адрес этой же страницы, сниппет FormIt делает обработку значений в соответствии с параметрами вызова сниппета. Если в сниппет был передан параметр submitVar, то при отстутсвии значения в этом поле POST запроса, будет считаться, что отправки формы не было. Это позволяет игнорировать POST-запросы других форм.

В примере ниже сниппет FormIt не будет реагировать на данные при отправке второй формы:

[[!FormIt?
    &submitVar=`myFormSubmit`
]]

<form action="" method="post">
    <input type="text" name="name">
    <button type="submit" name="myFormSubmit" value="1">Отправить</button>
</form>

<form action="" method="post">
    <input type="text" name="name">
    <input type="submit" value="Отправить">
</form>

Сама по себе механика работы FormIt глобально состоит из  3-х основных этапов:

• Предварительная инициализация значений, запуск скриптов preHooks
• Обработка POST-значений и запуск скриптов hooks
• Постобработка значений, запуск скриптов renderHooks и запись плейсхолдеров

Базовые параметры FormIt и пример использования

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

Сам по себе сниппет FormIt имеет не так много родных параметров. Большинство параметров – это параметры, которые необходимы для запуска вызываемых скриптов (хуков). Поэтому, чем больше хуков вы используете, тем больше параметров нужно передать в сниппет FormIt.

Типичный мой вызов FormIt на Fenom выглядит так:

Этот вызов означает, что прежде, чем выполнить хук email, отправляющий письмо по заданному адресу, FormIt проверит, заполнены ли поля name, email и comment. Также поле email будет проверено на предмет соответствия шаблону email-адресов. Если все проверки будут пройдены, то только в этом случае произойдет отправка и будет выведено сообщение об успешности отправки формы. Или же будет выведена ошибка:

[[!+fi.validation_error_message:notempty=<p>[[!+fi.validation_error_message]]</p>]]

Если бы мы не указывали хук email, то параметры:

    'emailTpl'=>'email.questionForm',
    'emailTo'=>$_modx->config.my_admin_email,
    'emailFrom'=>$_modx->config.emailsender,
    'emailSubject'=>'Задан вопрос на сайте '~$_modx->config.site_url,

Не имели бы смысла.

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

Вместо заключения

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

Как сделать свой хук для авторизации через FormIt

Зачем нам MIGX на сайте?

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

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

Первое, что пришло бы в голову: организовать такие элементы как набор заранее подготовленных TV (например, вы можете сделать заранее 20 TV для заголовков и 20 TV для описаний, но это крайне неоптимально и неудобно). Как раз, чтобы не заниматься такими глупостями, но при этом не тратить большое количество времени на создание дополнительных таблиц в БД и настройке админки, чтобы эти поля редактировать, был придуман MIGX с возможностью добавлять такого рода дополнительные поля:

Подготавливаем конфигурацию

После установки MIGX в админке появится новый одноименный пункт меню. Именно туда нам и нужно. На вкладке "MIGX" добавляем новую конфигурацию, нажав на "Добавить элемент".

Самое главное дальше, не испугаться такого количество вкладок и полей. Мы будем заполнять только необходимые и их не так много. Вкладки и поля, которые нам не пригодятся для примера выше, мы будем пропускать. Таким образом, у вас появится первый навык применения MIGX для простых списковых TV-полей. В дальнейшем вы сможете изучить MIGX более подробно для применения его в более сложных случаях.

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

Добавляем поля всплывающего окна редактирования

На вкладке "Formtabs" мы можем настроить содержимое формы, которая будет открываться при добавлении нового элемента или редактировании существующего. Сначала мы добавляем вкладки формы (tabs), а затем на каждую вкладку добавляем поля.

Сначала добавляем новую вкладку:

Затем внутри новой вкладки добавляем поля один за одним, нажимая "добавить элемент":

В нашем случае нам требуется всего 2 поля:

1. Для заголовка (поле типа text)
2. Для описания (поле типа textarea–текстовая область или richtext–текстовый редактор)

Поле заголовка:

Если вы хотите добавить в окно редактирования значения поле, тип которого совпадает уже с каким-то ранее подготовленным дополнительным полем (TV), то вы можете использовать имя этого TV в поле Input TV. Например, у вас уже есть TV для ввода даты и времени под названием myDateTime, для этого вам достаточно будет в поле Input TV ввести "myDateTime" и нажать "Выполнено", оставив остальные поля пустыми.

В поле Input TV type вводится тип поля. Список типов можно посмотреть на странице документации modx.

После того, как мы выполнили добавление поля title, повторяем такую же процедуру для поля description, указав его тип как textarea или richtext

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

Теперь нужно определить, какие поля будут отображаться в таблице списка.

Добавляем колонки таблицы

В разделе "columns" настраиваются колонки таблицы, которые будут отображаться на месте TV в админке. Сюда добавляются, как правило, колонки, соответствующие полям из вкладки "Formtabs" и дополнительные колонки для прочих целей (например для вывода кнопок редактирования записи или отображающие какие-то сводные данные).

Нам необходимо добавить колонку для вывода поля title.

Если мы хотим иметь возможность редактировать значение прямо из таблицы, кликнув дважды на само значение, можно на вкладке Cell Editor указать тип редактора значений:

Аналогичную процедуру повторяем для поля description, указав в поле Field значение description. Затем, мы можем добавить для удобства еще одну колонку, в которой выведем три кнопки: Редактировать, Дублировать, Удалить.

Для этого добавляем еще одну колонку, задав ей заголовок "Действия", поле Field оставляем пустым, так как она не содержит никаких данных. А во вкладке "Renderer" нам необходимо выбрать функцию this.renderRowActions.

А для того, чтобы выбрать, какие именно действия необходимо отобразить в этой колонке, на вкладке Columnbuttons указываем те действия, которые хотим отобразить:

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

Сохраняем нашу конфигурацию и приступаем теперь непосредственно к созданию TV-поля.

Добавление TV-поля

Здесь все максимально просто: вы создаете новое дополнительное поле точно так же, как делали это раньше, указав тип поля: migx, а в поле "Конфигурации" указав название нашей конфигурации, созданное на предыдущем этапе.

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

Прицепив данное поле к соответствующему шаблону и сохранив его, вы увидите его теперь на вкладке дополнительных полей ресурса:

Отображение в шаблоне

Я применяю в своем коде синтаксис Fenom, в связи с этим представленный ниже код будет написан именно на нем.

При выводе значений из MIGX TV-полей стоит помнить, что данные таких полей хранятся в виде JSON-строки. Нам необходимо преобразовать эту строку в массив и затем в цикле вывести на странице, используя необходимые обрамления в виде html-тегов.

В моем случае, где требуется, чтобы первый элемент был выведен в увеличенном виде, а все последующие в виде одинаковых колонок, такой код мог бы выглядеть так:

Все не так сложно

По итогу, для того, чтобы создать MIGX-поле, потребовалось совсем не много времени. Минимально необходимый набор действий заключается в:

1. Настройке полей на форме, требуеющей на каждое поле несколько кликов и заполнение трех-четырех настроек
2. Настройке колонок таблицы, требующей на каждое поле также несколько кликов и заполнения двух настроек
3. Создании TV поля с указанием названия MIGX-конфигурации

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

Спасибо за внимание!

Для чего все это нужно и почему не компонент Login?

Не знаю, почему, но за всю свою многолетнюю практику работы с MODX Revolution, я использовал компонент Login только один раз. Отличие Login от FormIt состоит в том, что Login решает ряд задач, посвященных конкретно авторизации/регистрации и редактированию профиля пользователя на Frontend, а FormIt — это более универсальный компонент, с помощью которого можно построить практически любую логику обработки формы, но придется немного покодить. Если перед вами не стоит задача построить сайт с регистрацией и авторизацией на Frontend за час, то я бы предпочел исползовать FormIt, написав для него несколько хуков, вместо того, чтобы разбираться в Login и кастомизировать его формы, доступные по-умолчанию.

Я буду использовать ниже синтаксис Fenom вместо стандартного синтаксиса MODX.

Создаем html-код формы авторизации

На данном шаге нам необходимо создать болванку (html-код) нашей формы, которую мы в дальнейшем будем наполнять логикой.

Возьмем для примера такой код (взят из вполне конкретного проекта):

Создаем чанк с именем b.signinForm и помещаем в него код формы в том виде, в котором он показан выше. Далее мы будем вызывать данный чанк в параметрах сниппета AjaxForm.

Делаем вызов сниппета AjaxForm в связке с FormIt

Для того, чтобы наша форма хотя бы просто отобразилась на странице, необходимо в том месте, где она должна размещаться, поставить вызов сниппета AjaxForm.

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

Валидация полей

FormIt имеет встроенный механизм валидации полей. Правила валидации мы можем задать в параметре validate. Прежде, чем будет запущен какой-либо хук из параметра hooks, все поля будут прогнаны через указанные правила валидации. В нашем случае, это простое правило required, которое проверит, есть ли хотя бы один символ во введенных полях. Если поля успешно прошли валидацию, будет запущен первый хук из цепочки хуков, указанных в параметре hooks через запятую. В нашем случае мы создадим один хук под названием loginHook.

Наполняем наш хук кодом

Сперва добавьте в параметр hooks в вызове сниппета AjaxForm или FormIt значение loginHook:

...
'hooks' => 'loginHook',
...

После чего необходимо создать сниппет loginHook, код которого нас сейчас будет интересовать больше всего.

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

Таким образом, вызов AjaxForm ниже в связке с хуом loginHook и формой b.signinForm позволит вам реализовать форму авторизации пользователя на сайте:

Как я начал ковыряться в этом вопросе

Меня зовут Артем Зернов. Я веб-разработчик, занимаюсь развитием проекта Лектория, а также веду свой youtube-канал OpenModx, а еще у меня есть веб-студия OpenColour, в которой мы создаем сайты, в основном на MODX Revolution. В процессе своей деятельности в нашей команде мы создали не одну сотню сайтов, и в процессе их обслуживания я замечал, что некоторые, наиболее посещаемые сайты начинали тормозить. Причиной тому была таблица modx_session, о которой мы поговорим позже. Столкнувшись с этой проблемой, я начал разбираться, как устроен механизм сессий в PHP и MODX в частности. И вот буквально сегодня я вновь вернулся к этому вопросу, анализируя поведение сайта Лектории. Спешу поделиться своими наблюдениями и идеями.

Как устроены сессии в PHP по-умолчанию

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

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

Пока у вас есть в куки идентификатор сессии, сервер знает, кто вы и может показывать вам какие-либо ваши данные, хранимые в сессии.

По-умолчанию, в php есть встроенные функции session_start, session_write_close и прочие функции с префиксом session_. Полный набор функций можно посмотреть по ссылке:

https://www.php.net/manual/ru/ref.session.php

Также есть глобальный массив $_SESSION, в который вы можете записывать что угодно. MODX также записывает в него свои служебные данные.

Пока сессия открыта и пока не вызван метод session_write_close, все манипуляции с данными в $_SESSION будут сохраняться при переходах между страницами в рамках вашего посещения.

По-умолчанию, в php сессии хранятся в файлах, хранимых во временном каталоге (например /tmp). Также в дистрибутиве php содержится bash-скрипт sessionclean, который автоматически устанавливается в системные таймеры (можно сказать — это cron) и с периодичностью раз в 30 минут очищает устаревшие сессии, чтобы они не занимали лишнее пространство на диске.

Сессии устаревают по принципу "Если с момента последнего обращения к сессии прошло больше времени, чем укзано в настройке php session.gc_maxlifetime, то считаем ее устаревшей".

Как и где инициализируются обработчики сессии в MODX

Прежде, чем сказать о том, как это происходит в MODX, важно сказать, что php предусматривает переопределение стандартных механизмов работы с сессиями. Это делается при помощи встроенной в php функции session_set_save_handler, с помощью которой мы можем переопределить способ чтения, записи и очистки от устаревших сессий (сборки мусора).

Стандартный механизм обработки сессий в MODX реализован в классе modSessionHandler. И, как вы наверняка догадались, сессии MODX хранятся в базе данных, а точнее в таблице modx_session. Там хранятся ID сессии (это как раз то, что хранится в куки в переменной PHPSESSID), время последнего доступа к ним и, собственно, сериализованный массив $_SESSION.

Сборщик мусора и настройки gc_probability и gc_divisor

В php механизм очистки от устаревших сессий запускается в соответствии с настройками php.ini session.gc_probability и session.gc_divisor. Очистка происходит session.gc_probability раз из session.gc_divisor.

Например, если session.gc_probability = 1, а session.gc_divisor = 100, то очистка будет происходить в одном случае из ста обращений к сайту, для того, чтобы не перегружать сервер слишком частыми процедурами очистки сессий.

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

В MODX процедура очистки от устаревших сессий происходит в методе modSessionHandler::gc. И тут стоит отметить, что механизм очистки сессии в скрипте sessionclean, запускаемый каждые 30 минут, не будет очищать сессии MODX, так как он ничего не знает о том, что MODX переопределяет стандартные механизмы в классе modSessionHandler. Поэтому, если вы хотите очищать сессии modx вручную, необходимо написать самостоятельно скрипт. Но смысла в этом большого нет, кроме случая, описанного в конце этой статьи, так как очистка сессий будет происходить согласно вашим настройка session.gc_probability и session.gc_divisor.

Время жизни куки и сессий

В настройках php, в php.ini есть настройка session.gc_maxlifetime, которая определяет время с момента последнего обращения к сессии, после которого сессия считается устаревшей и будет удалена во время следующей очистки сессий (сборке мусора) и session.cookie_lifetime, которая определяет время жизни куки PHPSESSID в вашем браузере.

Стоит отметить, что MODX переопределяет эти настройки, согласно своим аналогичным системным настройкам session_cookie_lifetime и session_gc_maxlifetime, поэтому в первую очередь смотрите именно в системные настройки вашего сайта на MODX.

Почему моя таблица modx_session весит 2Гб?

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

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

Учитывая все вышеописанное, такое происходит только потому, что данная таблица не очищается от устаревших сессий.

Как это можно решить?

1. Проверить параметр session.gc_probability на сервере, он должен быть больше 0. Если он равен 0, значит механизм очистки от старых сессий не запускается никогда.
2. Проверить, насколько часто запускается механизм очистки сессий. Если, к примеру, параметр session.gc_divisor очень большой, то возможно, при вашей посещаемости, очистка от устаревших сессий происходит 1 раз в год или еще реже.
3. Проверить время жизни сессий (настройка MODX session_gc_maxlifetime). Если она очень большая, например 1 год, то, очевидно, в течение года сессия будет оставаться живой. А если, при этом, параметр session_cookie_lifetime значительно меньше этого значения, то на одного пользователя потенциально будет создаваться больше, чем одна сессия, что является излишним.
4. Если возможности изменить настройку сессий session.gc_probability или session.gc_divisor у вас нет, то есть смысл написать cron-скрипт, о котором я писал выше.

Как можно улучшить стандартный механизм работы с сессиями в MODX

Ко мне пришла в голову идея расширить стандартный класс modSessionHandler, заставив его работать с другой таблицей, которая представляет собой копию modx_session, но где мы можем добавить свои столбцы, например столбец anonymous, столбец user_id и прочие полезные столбцы, по которым мы могли бы делать выборку сессий.

После таких манипуляций, необходимо указать системную настройку session_handler_class, вставив туда название нашего кастомного класса для работы с сессиями (при этом, к сожалению, нет настройки для указания пути к классу, поэтому файл придется класть в системный каталог MODX, туда же, где лежит файл modsessionhandler.class.php).

Какие это может дать преимущества

1. При очистке сессий мы можем делать разные условия для времени жизни сессии авторизованных пользователей и анонимных. Например, сессиий анонимных пользователей действительны в течение одних суток, а авторизованных — в течение 7 дней.
2. При авторизации одного и того же пользователя с разных устройств, мы могли бы удалять его другую сессию, предотвращая тем самым одновременный вход с разных устройств (если такое предусмотрено логикой вашего сайта).
3. При авторизации одного и того же пользователя с разных IP мы могли бы сообщать о подозрительной активности.
4. Можно расширить эту таблицу прочими полезными столбцами, которые мы могли бы использовать себе во благо и расширять сайт дополнительным функционалом.

Заключение

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

Не забывайте подписываться на мой youtube-канал: OpenModx!

В этой статье я поделюсь процессом разработки интернет-магазинов, который мы практикуем в веб-студии OpenColour. Разработкой сайтов я занялся в далеких 2000-х, а первый интернет-магазин я разработал году, эдак, в 2013-м. Я не маркетолог, а технический специалист, поэтому по большей части я буду говорить про технические аспекты интернет-магазина, но тем не менее в маркетинговых вопросах я тоже разбираюсь. Но когда я буду упоминать словосочетание интернет-магазин, я в большинстве случаев буду иметь ввиду именно веб-сайт, а не целиком всю организацию-продавца с ее логистическими связями, службами доставки, маркетинговым отделом и так далее.

Отличительные критерии интернет-магазина

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

Начало разработки. Процессы до интеграции с CMS

Постановка задачи и предварительные действия

Как и любой другой сайт, интернет-магазин начинается с постановки вопросов: "Что продавать? Кому продавать? Как продавать?".

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

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

Далее мы определяемся с набором товаров и информации, которые планируем размещать на сайте и начинаем проектировать будущий сайт.

Готовые решения для интернет-магазинов

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

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

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

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

Планы и задачи

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

Спасибо за внимание!

Следующая часть

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

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

Крайне не рекомендуется создавать прототип на основе "рыбных" текстов вроде Lorem Ipsum — такие тексты не имеют ничего общего с реальными данными, которые будут в дальнейшем размещаться на сайте. Если заказчик не представляет вам тексты на данном этапе, заставьте его это сделать. Даже, если заказчик говорит, что берет всю вину на себя, переделывать дизайн-макеты, а может и вообще готовый сайт потом придется все равно вам. А объяснить заказчику (особенно российскому), что он должен за это доплачивать, будет ой как непросто. Наш заказчик привык считать, что если вы озвучили сумму, то это полный лакшери-ол-инклюзив и ни за что больше доплачивать не нужно.

Декомпозиция задачи. План действий.

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

1. Из каких разделов будет состоять сайт?

Например: Главная, Каталог, Новости, Поддержка, Контакты.

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

Например: Главная, Страница каталога, Страница раздела каталога, Страница товара, Страница всех новостей, Страница отдельной новости, Страница поддержки, Страница контактов.

Не забывайте о том, что на сайте есть еще и технические страницы. Например, страница ошибки 404 (Страница не найдена).

Постарайтесь на этом этапе подумать, какие страницы будут еще. Уточняйте вместе с заказчиком, какую еще информацию он хотел бы разместить на сайте, какую информацию ВАЖНО разместить на сайте, чтобы сайт работал и выполнял свои функции.

3. Какие типовые блоки должны быть на каждой странице?

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

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

4. Каким должно быть наполнение каждого из блоков?

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

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

5. О чем будет текст в конкретном блоке?

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

6. Что должно быть на изображении в конкретном блоке?

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

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

Сбор текстов и материалов

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

Отсекая все лишнее и невозможное, вы удивитесь, как мало на свете заказчиков, у которых есть все материалы. На деле же оказывается, что у большинства заказчиков есть 10 фотографий, сделанных на телефон и 3 файла формата .docx или .pdf, в которых все свалено в одну кучу.

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

Сборка прототипов

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

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

Заключение

Надеюсь, коллега, статья была тебе интересна и полезна. Впереди нас ждет этап дизайн-макетирования. Будет интересно!

Добра и удачи в нашем нелегком, но безумно интересном деле!

Урок посвящен:

1. Архитектуре построения админки
2. Созданию собственных страниц в ней

Контроллер — это специальный php-файл, лежащий в директории core компонента, и наследующий класс modExtraManagerController. Его назначение — подготовить нужные файлы для вывода страницы. Иными словами, нажатие на пункт меню какого-нибудь приложения, вызывает соответствующий контроллер, который запускает ряд указанных в нем действий.

Используемый контроллер можно найти в адресной строке, которая строится по следующему шаблону: {название сайта}/manager/?a={контроллер}&namespace={пространство имен} {контроллер} - имя контроллера (php-файла, например index — index.class.php) {пространство имен} - пространство имен созданное для компонента.

Структура контроллера

• Объявление класса
• Подключение стилей *.css
• Подключение javaScript-файлов
• Подключение дополнительного кода необходимого для реализации логики

Создание тестового компонента с названием "openmodx"

Шаг 1. Добавьте пространство имен openmodx

Для этого создайте папку openmodx в директории /www/core/components

Шаг 2. Добавьте в него каталог controllers

В этом каталоге хранятся все контроллеры используемые в компоненте

Шаг 3. В корне каталога контроллеров создайте файл контроллера index.class.php

Название файла контроллера стандартизировано и всегда имеет вид {название контроллера}.class.php По умолчанию (если не определено другого) MODX ищет index контроллер

Шаг 4. Объявите класс omIndexController

В начале файла добавьте следующий код

Имя контроллера должно состоять из 3 обязательных частей объединенных в одно слово (без пробелов) и каждая часть начинается с заглавной буквы. Части указываются в следующем порядке:

1. Openmodx - название пространства имен
2. Index - название контроллера
3. ManagerController - обязательное обозначение контроллера

Шаг 5. Объявите пространство имен

1. Перейдите в пространство имен (Настройки -> Пространство имен)
2. В открывшемся окне кликните по кнопке "Создать новый"
3. В сплывающем окне введите следующие данные:
4. Имя - openmodx
5. Путь к ядру - {core_path}/components/openmodx/
6. Путь к активам - {assets_path}/components/openmodx/
7. Сохраните изменения

Шаг 6. Проверьте правильность выполненных шагов

Обратитесь к созданному контроллеру через адресную строку {имя_сайта}/manager/?a=index&namespace=openmodx В случае правильного выполнения задания вы должны увидеть пустое окно без каких-либо ошибок

Наполнение созданной страницы

В предыдущем примере мы рассмотрели создание пустой страницы нашей компоненты openmodx. Далее мы будем работать с созданным выше контроллером, который по своей сути представляет собой класс.

Описание структуры класса

Класс представляет собой набор функций, как правило состоящий из следующих методов:

1. procees() - метод выполняющий подготовительные действия до загрузки страницы;
2. getPageTitle() - выводит текст для тега title страницы;
3. loadCustomCssJs() - основной метод контроллера, именно он загружает все нужные скрипты и стили для работы страницы;
4. getTemplateFile() - метод отдаёт html шаблон страницы для дальнейшего отображения;
5. checkPremissions() - метод проверки ограничительных прав на доступ к странице.

Использование всех методов является не обязательным и зависит всегда от способа решения конкретной задачи. Как видно из описания классов для описания внешного вида странички мы можем использовать два метода getTemplateFile и loadCustomCssJs. Рассмотрим их начиная с самого простого.

Метод getTemplateFile()

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

В приведенном примере для отображения используется tpl шаблон, который расположен, в нашем примере, по адресу www/components/openmodx/templates/. В указанной папке создайте файл index.tpl и поместите в него код который выведет на страницу заголовок 2 уровня с текстом "Тестовая страница для админки":

<div class="container"><h2>Тестовая страница для админки</h2></div>

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

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

Метод loadCustomCssJs()

Для корректного отображения страницы с использованием данного метода закомментируйте метод getTemplateFile или сделайте так, чтобы он возвращал пустую строку, например так:

public function getTemplateFile() {
  return '';
}

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

...
public function loadCustomCssJs() {}
...

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

Шаг 1. Создание каталогов

По пути www/assets/components/ создайте каталог openmodx, в нем папку js, подпапку mgr с файлом index.js. У Вас должна получиться структура папок представленных на изображении

www/  
 |-- assets/  
      |-- components/  
          |-- openmodx/  
                |-- js/  
                    |-- mgr/   
                        |-- index.js  

Почему именно такая структура? Это связано с правилами MODx, такое распределение позволяет упорядочить файлы по их назначению, содержанию и в дальнейшем упростит работу по модификации web-приложения. В теории такой структуры придерживаться не обязательно, но ее использование косвенно подтверждает высокий уровень разработчика. Давайте рассмотрим назначение папок:

1. assets — содержит папки файлы, которые должны быть доступны снаружи, из интернета;
2. components — каталог в котором хранятся файлы компонентов, которые должны быть доступны из браузера;
3. openmodx - каталог содержащий вспомогательный файлы нашей компоненты;
4. js — каталог содержащий js файлы;
5. mgr — каталог содержащий файлы связанные с панелью управления менеджера.

Шаг 2. Наполнение index.js

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

Шаг 3. Определение метода loadCustomCssJs()

В предыдущем шаге мы описали внешний вид нашей страницы. Теперь сделаем его доступным пользователю. Для этого вставим путь к файлу index.js в метод.

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

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

Заключение

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

1. использованием tpl шаблона с html разметкой, через метод getTemplateFile;
2. описанием содержимого страницы через библиотеку Ext JS и подключаемый методом loadCustomCssJs.

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

Для чего?

Вы уже получили навыки в создании web приложений и хотите разместить созданный сайт в интернете, но как это сделать? Все просто! Есть хостинг провайдеры, которые, как раз и предоставляют услуги, по размещению сайтов в сети. Заходя на страничку к провайдеру, вы видите, что можно взять в аренду виртуальный хостинг или VDS.

В чем разница? Давайте рассмотрим эти продукты и избавимся от боязни их использовать. Начнем по порядку от общего к частному.

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

1. размер дискового пространства;
2. количество месячного трафика;
3. количество сайтов, которые можно разместить в рамках хостинга как одной услуги;
4. количество баз данных и количество места под базы данных;
5. количество почтовых ящиков и FTP-аккаунтов;
6. ресурсы CPU;
7. количество оперативной памяти.

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

Альтернативой виртуального хостинга является использование VDS\VPS (Virtual Dedicated\Private Server) — это, виртуальный выделенный или приватный сервер, который предоставляется хостинг провайдером в аренду заказчику.Чтобы не вводить в заблуждение, сразу отмечу, что разницы между аббревиатурами VPS и VDS нет никакой. Дело в том, что два этих понятия появились практически одновременно и параллельно развивались.

Что же такое VDS? Говоря простым языком, поставщик услуг на своем оборудовании, с помощью средств виртуализации разворачивает несколько виртуальных (программных) серверов. С точки зрения функциональности такой сервер ничем не отличается от физического, на него также устанавливаются операционная система и программное обеспечение, он также расположен в сети и управляется, как и остальные ПК, средствами удаленного администрирования. При этом данный сервер находится на удаленной площадке провайдера, которая защищена от сбоев и оптимизирована под работу 24/7/365. В свою очередь хостинг провайдер берет на себя все обязательства по обслуживанию и сопровождению оборудования и системы виртуализации. Но соответственно цену на эту услугу несколько выше чем на виртуальный хостинг.

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

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

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

Исходные данные

Определим, что у нас есть некоторый сайт, работающий на php+MySQL под управлением некой CMS (в нашем случае это будет MODX Revolution, но на процесс настройки VDS это не влияет), а это значит, что помимо развертывания CMS необходимо установить и настроить основные модули php, nginx, mysql. Для этого определим следующую последовательность наших действий:

1. Регистрация на хостинге и конфигурация VDS;
2. Создание VDS из панели управления;
3. Подключение по SSH;
4. Обновление и установка пакетов системы;
5. Установка nginx + php;
6. Установка mariadb (mysql);
7. Создание нового пользователя системы;
8. Конфигурирование php-fpm;
9. Конфигурация nginx;
10. Конфигурация mysql;
11. Создание пароля для root пользователя mysql;
12. Создание нового пользователя и базы данных для сайта;
13. Создание недостающих каталогов и перезапуск сервисов;
14. Установка MODX.

Регистрация на хостинге и конфигурация VDS

В руководстве будем пользоваться услугами компании timeweb. Переходим на вкладку VPS / VDS, из предлагаемых тарифов выбираем тот, который нам подходит по характеристикам и нажимаем кнопку заказать. После этого попадаем в окно регистрации и выбора параметров виртуального сервера.

В текстовые поля вводим свою фамилию, имя и отчество, и адрес электронной почты. В выпадающем списке меняем операционную систему на Ubuntu 20.04

Далее жмем кнопку "ЗАКАЗАТЬ" и переходим к оплате. После окончания регистрации на электрону почту придет письмо, содержащее данные для подключения к виртуальному серверу (ip адрес сервера, пароль root пользователя).

Root – это суперпользователь в системах *nix. С помощью этой учетной записи можно осуществлять административные операции над важными файлами ОС.

Создание VDS из панели управления

Если вы уже зарегистрированы на этом хостинге, то заходим панель управления, нажимаем кнопку "СОЗДАТЬ СЕРВЕР" (1), вводим имя сервера (2), выбираем операционную систему "Ubuntu 20.04" (3), указываем конфигурацию сервера (выбираем тариф) (4). Чтобы создать виртуальный сервер в верхней части окна, нажимаем на кнопку "СОЗДАТЬ СЕРВЕР".

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

Подключение по SSH

Для подключения к серверу мы будем использовать встроенный терминал macOS или, если вы работаете в операционной системе windows, то программой Putty.

SSH - (Secure Shell) - это протокол удаленного управления компьютером с операционной системой Linux. В основном ssh используется для удаленного управления серверами через терминал.

Дальнейшая руководство будет построено на примере работы из под macOS, для windows все действия аналогичны и не различаются.

Откройте окно терминала и введите следующую команду

где ssh - означает подключиться к удаленному компьютеру по протоколу ssh, в записи "root@193.168.3.225" - обозначает имя пользователя (root), @ - разделитель, 193.168.3.225 - ip адрес удаленного компьютера (смените на полученный в письме)

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

Обратите внимание!

Такая запись называется приглашением терминала (командной строки), состоит из:

1. root - имя подключенного пользователя;
2. @ - разделитель;
3. 343158-artprog157 - имя компьютера
4. знак "#" на конце строки означает, что пользователь имеет права суперпользователя, у обычного пользователя знак "$".

Обновление и установка пакетов системы

Обновление пакетов системы является неотъемлемой частью перед установкой программного обеспечения и настройкой сервера. В Ubuntu используется пакетный менеджер APT (Advanced Package Tool, Улучшенный инструмент для работы с пакетами), который умеет работать с репозиториями, разрешать зависимости и взаимодействовать с dpkg, которая, собственно, и занимается установкой пакетов. APT всегда работает с локальным кешем списков, поэтому перед любыми действиями с пакетным менеджером следует обновить списки в кэше. Это можно сделать следующей командой

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

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

Установка nginx + php

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

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

И так, мы выполнили установку nginx и php с библиотеками. Проверим, как установились пакеты. Для этого откройте браузер и в адресную строку впишите ip адрес виртуального сервера. У Вас должно отобразится приветственное окно nginx.

Установка mariadb (mysql)

В качестве системы управления базами данных используется mariadb, установим ее следующей командой:

На этом установке завершена, настройка будет происходить в последующих шагах.

Создание нового пользователя системы

Теперь перейдем к созданию пользователя, от имени которого мы будем в дальнейшем работать с удаленным сервером. Так же использование root пользователя, в качестве основного создает предпосылки к нарушению системы безопасности. Определим следующую логику создания пользователей: один сайт - один пользователь с соответствующими настройками nginx, php, mariadb и правами на каталоги своего сайта. Таким образом, если один сайт взломают, то другие будут защищены благодаря нашей настройки.
Создадим пользователя с именем test, который входит в группу www-data командой:

-d - определяет домашний каталог (в нашем случае /home/test)
-g - задает группу создаваемого пользователя (www-data)
-m - создает домашний каталог если он не существует
-s - устанавливает командную оболочку

Чтобы в дальнейшем мы могли выполнять какие-либо административные действия добавим созданного пользователя в группу sudo

Осталось задать пароль пользователю, выполним команду

После этого необходимо ввести пароль и повторить его (при вводе пароль не отображается)

Проверим этот путем подключения к удаленному серверу под созданным пользователем, для этого повторим шаг "Подключение по SSH"

Обратите внимание, что приглашение теперь содержит имя пользователя test и заканчивается на знак $, что это значит можно узнать выше. Продолжим настройку сервера. Переподключитесь к нему под пользователем root.

Конфигурирование php-fpm

Начнем настройку php-fpm - это программный пакет, позволяющий выполнить обработку скриптов, написанных на языке PHP.
Настройка в операционной системе Linux, в большинстве случаев, сводится к правке конфигурационных файлов. Соответсвенно, для настройки php-fpm, необходимо перейти в каталог с этими файлами. Введите команду которая сменит каталог

Посмотрите какие файлы есть в этом каталоге

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

Новый файл будет состоять из следующих строк

Создадим файл конфигурации test.conf, с помощью встроенного редактора nano вставим строки кода приведеные выше, и сохраним файл.

На этом настройка php-fpm закончена, переходим далее.

Конфигурация nginx

NGINX – это мощный веб-сервер, использующий не потоковую, управляемую событиями архитектуру, которая позволяет ему превосходить Apache. Приступим к его конфигурированию.
Перейдите в каталог веб-сервера

В этой папке нас интересует два каталога, которые хранят настройки сайтов - sites-available, sites-enabled. Перейдем в первый каталог sites-available

Здесь находится файл default, который содержит установки по умолчанию. Удалите его командой

С помощью редактора nano создадим файл конфигураций 00-default. (00 в начале имени файла необходим для того, файл был первым в каталоге т.к. в своей работе nginx обращается сначала к первому файлу)

Внутрь файла поместите следующий код

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

Внутрь файла поместите следующий код, потом сохраните его

Продолжаем настройку nginx. Перейдите в каталог sites-enabled

В этом каталоге удалите ссылку на уже не существующую конфигурацию

Создайте две ссылки на конфигурационные файлы созданные выше

На этом конфигурация сервера nginx завершена. Двигаемся дальше!

Конфигурация mysql

Переходим в каталог mysql.

В этом каталоге находится файл my.cnf, в котором содержатся настройки нашей системы управления базами данных. Откройте этот файл в редакторе nano и отредактируйте

В конец файла вставьте следующий код, который обеспечит работу системы MODx с базой данных без ошибок

Теперь настроим парольный доступ root пользователя к базе данных. Для этого подключимся к СУБД

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

Создание пароля для root пользователя mysql

Для того, чтобы, пользователь root мог подключаться с паролем, необходимо изменить значения столбца plugin с unix_socket на mysql_native_password

Такую строку можно прочитать следующим образом:"Обнови в таблице user столбец plugin на mysql_native_password для строк где в колонке User значение root". Таким образом, мы разрешили пользователю root авторизироваться в СУБД через пароль БД. Однако сам пароль мы не задали, исправим это

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

и отключиться от СУБД

Как проверить правильность выполненных действий? Нужно войти в операционную систему под пользователем test (его мы создали немного выше) и подключиться к СУБД как root. Делаем следующие шаги - подключаемся как test

У вас должно измениться приглашение системы на пользователя test. Теперь настала очередь подключиться к СУБД

В приведенной команде -u - определяет что следующим идет имя пользователя, -р - использовать нативный пароль mysql (именно тот что мы и настраивали). После отправки команды СУБД попросит ввести пароль (нами был задан пароль testtest). Если у Вас все получилось, то шаги, проделанные выше, выполнены правильно. Далее выйдите из СУБД, подключитесь к операционной системе как root, и от имени этого же пользователя подключитесь к СУБД. Переходим дальше.

Создание нового пользователя и базы данных для сайта

Создадим базу данных для сайта с именем test

Создадим пользователя в базе данных с именем test и паролем testtest. В дальнейшем этот пользователь будет использоваться системой MODx для работы с базой данных.

Определим для созданного пользователя права при подключении к СУБД

Выдадим пользователю test все привилегии, на созданную, базу данных с правом ее передачи

После этого необходимо перезагрузить привилегии пользователей командой

Проверьте правильность выполненных шагов следующим образом: подключитесь к СУБД под пользователем test.

Создание недостающих каталогов и перезапуск сервисов

На данном этапе мы выполним следующие шаги:

1. Подготовка каталогов, которые мы использовали в настройках;
2. Перезапуск сервисов.

Для правильной установки и функционирования MODx осталось создать недостающие каталоги. Выполните следующие команды

В приведенных командах, как Вы заметили, операции по созданию каталогов (mkdir) выполняются с правами супер пользователя (sudo), от имени пользователя test (-u test). Это сделано с целью, чтобы пользователь test был владельцем этих каталогов и имел, по отношению к ним, полные права. После выполнения команд проверьте структуру каталога, там должны были появиться созданные нами папки.

Практически все готово к установке MODx, осталось перезапустить службы php, nginx, mysql. Это связано с тем, что настройки всех сервисов содержаться в текстовых файлах и считываются только при запуске служб. Выполните команды

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

Проверьте правильность выполненных действий. Введите в адресную строку браузера ip адрес сервера, Вам должна выдаться ошибка 444.

Если обратитесь по имени сайта, то ошибка должна следующей

Это является свидетельством, что все настроено правильно на данном этапе инструкции.

Установка MODX

Перед установкой MODx необходимо его дистрибутив поместить на наш виртуальный сервер. Для этого будем использовать текстовый загрузчик wget. Давайте установим его

На официальном сайте MODx скопируйте ссылку на дистрибутив (в моем случае она имеет вид https://modx.com/download/direct?id=modx-2.7.3-pl.zip&0=abs). Теперь с помощью программы wget сохраним его в каталоге /home/test/test.site/www/ командой

После скачивания проверьте, что в каталоге www присутствуют следующие файлы и папки (для разных версий MODx состав может незначительно отличаться)

Приступим к установке MODx. В адресную строку строку браузера введите

Откроется окно выбора языка, оставьте русский и нажимайте "ДАЛЕЕ"

Выберите пункт "НОВАЯ УСТАНОВКА", нажмите "ДАЛЕЕ"

В этом окне установите базу данных mysql, сервер - localhost, имя пользователя - test, укажите его пароль (testtest), имя базы данных - test, кодировка подключения - utf8, сопоставление - utf8_general_ci.

Теперь придумайте логин и пароль администратора сайта

Удостоверьтесь, что в отчете об установке все компоненты установлены и работают

Нажмите войти и введите регистрационные данные администратора сайта

На этом установка MODx закончена.

Заключение

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

Постановка задачи

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

Принцип работы

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

Подготовка системных настроек

Если пользователь не авторизован, то ему необходимо показать соответствующую страницу. В моем случае, с этой целью создан ресурс Вы не авторизованы, его индекс - 29.

Отредактируйте системную настройку с именем unauthorized_page и в поле значение вставьте индекс ресурса - 29.

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

1. ключ authorized_templates;
2. название setting_authorized_templates;
3. в поле значение укажите идентификаторы шаблонов, к которым необходимо ограничить доступ.

На этом подготовка системных настроек закончена, перейдем к логике работы проверки авторизации.

Написание плагина

Создайте новый плагин во вкладке Элементы. Добавьте название checkAuthorizedTemplates и описание для него.

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

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

Рассмотрим представленный код. В начале получаем индекс шаблона запрашиваемой страницы

Получим значение системной настройки ‌authorized_templates, в которой перечислены индексы шаблонов, к которым есть доступ у авторизованных пользователей

Если получений список представляет собой строку, то преобразовываем ее в массив

Далее ставим условие - если шаблон посещенной страницы есть в массиве и пользователь не авторизован, то подменяем запрашиваемую страницу ресурсом, указанным в системной настройке unauthorized_page

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

Заключение

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

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

В этом руководстве рассмотрим, каким образом можно выполнить резервное копирование mysql или mariadb базы данных, а также как восстановить информацию в базе из копии. В рассматриваемых базах для резервного копирования используется дамп. Операции с ним и будем рассматривать. Что же такое дамп, для чего, зачем и как?

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

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

Создание дампа

Разберем самый простой пример использования утилиты

где:

• -u - ключ задания имени пользователя
• username - имя пользователя
• -p ключ задания пароля
• password - пароль пользователя username, вводится после ключа -р без пробела
• databasename - имя базы данных для дампа
• > - перенаправление потока вывода
• dump.sql - имя выходного файла содержащий дамп БД. Если вы не указывали путь, то файл dump.sql, будет сохранен в папке home пользователя

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

Как вы поняли, такая команда справедлива только при локальном подключении. А как быть если у нас есть VPS или БД на удаленном компьютере?

Создание бэкапа с удаленного хоста

Тогда соответственно перепишем прошлую команду с указанием хоста.

Как видите, мы указали имя хоста host.ru с использованием ключа -h. И второе отличие, как вы уже заметили, ключ -р не сопровождает пароль, а это значит, что перед тем как утилита начнет выполнение, она спросит пароль для подключения.

Бэкап таблиц

Допустим снятие дампа всей базы данных ни к чему, необходимо сделать снимок только одной таблицы, тогда после имени БД необходимо указать название таблицы (table_name).

А если надо две или больше? Соотвественно перечислим их через пробел

Вариации дампа

Допустим, нам нужна "песочница" для эксперимента, а для этих целей вся таблица ни к чему, нужна только ее часть — структура. Не проблема! Укажите атрибут --no-data

Теперь в файле dump.sql вы увидите SQL команды создания структуры этой таблицы. Такой же прием справедлив и ко всей базе данных. Думаю, пример приводить не надо, не пишите имя таблицы после указания БД.

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

где:

• --triggers - ссылка на тригеры
• --events - ссылка на события
• --routines - ссылка на процедуры

Дамп отдельных строк

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

Соотвественно, если необходимо сделать выборку по двум параметрам, то в предложении появляется связка AND

Как видно из примеров, в использовании утилиты mysqldump нет ничего сложного. Однако, до этого были приведены примеры только снятия дампа, а как быть если его необходимо восстановить?

Развертывание дампа

Команда mysqldump предназначена только для снятия дампа. Если нам необходимо, наоборот, восстановить базу или отдельную таблицу из файла, необходимо воспользоваться командой mysql

Дополнительные параметры

На использовании параметров, приведённых выше, функциональность не заканчивается. Дополнительные параметры можно посмотреть в документации на утилиту.

Заключение

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

В руководстве также используются сниппеты AjaxForm и FormIt (поэтому проверьте в менеджере пакетов, что они установлены).

Авторизация

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

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

Вызов сниппета AjaxForm производится с обработчиком форм FormIt и необходимыми параметрами, которые по порядку рассмотрим ниже.

Форма авторизации

Создайте чанк loginPopupFormTpl содержащий описание формы авторизации, со следующим кодом.

Здесь [[~3]] — это ID ресурса, куда необходимо перенаправить пользователя после успешной авторизации. Поля span предназначены для вывода ошибок в процессе авторизации. Остальной код не нуждается в комментариях.

Перенаправление при успешной авторизации

Так как, после успешной авторизации необходимо выполнить перенаправление пользователя, допустим в личный кабинет, то возложим эту задачу на JavaScript. Для этого в вызове сниппета AjaxForm укажем свой скрипт-обработчик myform.js, расположенный по адресу /assets/js/.

Cоздадим его из оригинального скрипта AjaxForm. Для этого скопируйте из папки /assets/components/ajaxform/js/ файл default.js по адресу указанному в вызове сниппета и переименуйте его в myform.js. Откройте файл в редакторе и найдите код, который выполняется в случае отсутствия ошибок при успешной отправке формы.

Перед закрывающей скобкой добавьте перенаправление на адрес, указанный в атрибуте data-redirect формы авторизации.

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

Подробнее о кастомизации AjaxForm для использования своих файлов можно узнать в этом видео.

Хук loginHook

Теперь приступим непосредственно к процессу выполнения авторизации. Создайте в сниппетах хук с именем loginHook и вставьте следующий код

Рассмотрим подробнее его логику работы.

Вначале запишем в переменную ‌$properties необходимые параметры вызова процессора. Как Вы уже поняли, функция getValue()‌ получает значение поля из формы. Обратите внимание, что имена полей формы должны совпадать с параметрами вызова этой функции.

Далее находится код, запускающий процессор login с параметрами определёнными выше. В результате переменной $response будет присвоен полученный объект.

Процессоры системы MODx находятся по адресу core/model/modx/processors/. Соответственно в нашем вызове мы работаем с файлом login.class.php лежащем в core/model/modx/processors/security/.

Далее следует код, выполняющий анализ полученного ответа процессора. Если процессор не отработал по какой-либо причине (переменная $response пустая), то в поле username выведем сообщение Системная ошибка и прекратим работу нашего хука.

Если в результате работы процессора возникли ошибки, то запишем их в соотвествующие поля и завершим работу хука.

В случае отсутствия каких-либо ошибок в работе процессора, т.е. введенные логин и пароль верны, завершим выполнение хука со значением true.

Параметры AjaxForm

Разберем оставшиеся параметры вызова сниппета AjaxForm. Параметр &validate задается разделенным запятыми списком полей для проверки. Запуск с ключом username:required,password:required определяет, что поля username и password не должны быть пустыми. Задание &validationErrorMesage и &successMesage определяет выводимые сообщения в случае ошибки и успешной отправки формы соответственно. Свойство &submitVar задает имя POST-переменной для обработки формы (значение должно совпадать с именем поля submit формы авторизации).

После того, как весь код написан проверьте работу авторизации.

Заключение

В этом руководстве рассмотрен способ организации процесса авторизации штатными средствами MODX, путем использования процессора login. Как видно, построение логики работы без сторонних плагинов, не представляет собой ничего сложного. Необходимо только разобраться в работе нужного процессора и запустить его, как правило, с набором необходимых параметров. На примере этого руководства не составит никакого труда написать обработчик формы на процессоре logout, который будет выполнять деавторизацию (выход или разлогинивание) пользователя.

Composer - это пакетный менеджер уровня приложений для языка программирования PHP, который предоставляет средства по управлению зависимостями в PHP-приложении. Использование composer позволяет автоматизировать управление пакетами, которые присутствуют в Вашем проекте, а именно производить их установку, обновление и удаление.

Экосистема менеджера состоит из двух важных частей:

1. Непосредственно сам composer, представляет собой утилиту командной строки для работы с пакетами;
2. Репозиторий пакетов - Packagist.

Приступим к установке пакетного менеджера.

Если вы предпочитаете видео-формат:

Установка composer

Проверка версии

В этом руководстве установка будет показана на примере систем Unix/Linux/MacOs. Для начала стоит сказать, что для корректной работы менеджера пакетов, требуется наличие установленного PHP версии не ниже 5.3.2. Если не знаете какая версия установлена у Вас, то в командной строке выполните следующую команду

В ответе увидим версию php, в моем случае установлена 7.3.11. Если Ваша версия ниже требуемой или php не установлен, то соответствующее руководство вы можете найти здесь.

Скачивание менеджера

Создайте директорию, в которую будет производится установка composer.

Перейдите в этот каталог.

Скопируйте файл менеджера на свой компьютер из официального репозитория

Проверка установочного файла

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

Если значение хеша, устанавливаемого файла, совпадает с эталонным, то будет выведено сообщение Installer verified

Значение хеша актуального файла ‌composer-setup.php Вы можете узнать здесь.

Запуск установщика

Запустим загруженный файл ‌composer-setup.php

В случае успешной установки увидим сообщение, что все настройки для использования composer правильные, и в ходе инсталляции создан исполняемый файл composer.phar.

Перемещение в глобальный каталог

Для того, чтобы composer был доступен для всех пользователей, переместим его в глобальный каталог /usr/local/bin/ к остальным исполняемым файлам системы и уберем расширение .phar.

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

composer.json

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

Как видно, ключ require содержит названия пакетов и ограничение версии. Т.е. в проекте используется пакет monolog с любой версией из ветки 1.0. Соответсвенно, допустимо использование следующих обозначений в ограничении версий:

Знак	Значение
<1.1	Версия ниже 1.1
<=1.1	Версия не выше 1.1 включительно
>1.1	Версия выше 1.1
>=1.1	Версия не ниже 1.1 включительно
1.*	Любая версия ветки 1
1.1	Только версия 1.1

 

 

Примеры использования

Задача 1

Вы внедряетесь в какой-либо проект. Необходимо локально развернуть этот проект и продолжить его разработку. В репозитории предложенного Вам проекта находится файл composer.json с описанием зависимостей.

Решение

Перейдите в каталог с проектом (для примера test)

Напоминаю, что в корне этого каталога должен находиться файл composer.json с описанными зависимостями. В командной строке запустите composer с параметром install

В ходе выполнения команды в консоль будет выведена информация о выполняемых действиях.

И в результате успешного выполнения в каталоге test создана папка vendor, в которые загружены пакеты описание в файле composer.json

Помимо загруженного пакета, так же был создан файл composer.lock. В него были записаны точные версии пакетов, которые были установлены и его в дальнейшем можно использовать для установки пакетов. Таким образом, если при установке присутствует файл .lock и .json, то версии и состав пакетов будут взяты из lock-файла. Такой подход позволяет создавать проект с абсолютно одинаковыми версиями пакетов.

На этом решение первой задачи завершено, переходим далее.

Задача 2

Проект над которым Вы работаете претерпел некоторые изменения, а именно перешли на новые версии пакетов. У Вас есть файл composer.json, где версия пакета mononlog задана >=2.0. Необходимо обновить пакеты до последних версий.

Решение

Проверьте нахождение нового файла composer.json в корне Вашего проекта и отсюда запустите composer с параметром update.

При выполнении команды "update" менеджер пакетов считал json-файл, установил необходимость повышения версии пакета monolog до 2.1.1 и дополнительно установить зависимый пакет psr/log.

Как видите, один пакет был установлен и один обновлен. Решение второй задачи завершено.

Задача 3

Вы начинаете работу над проектом. Знаете что в нем будет использован пакет monolog не ниже версии 2.0. Необходимо создать файл, описывающий зависимости, для передачи другому участнику проекта, и установить эти пакеты.

Решение

Перейдите в папку с новым проектом (например test). Запустите команду composer с параметром init.

Запустится генератор файла composer.json. В командной строке будут выводится сообщения менеджера пакетов composer, на которые необходимо ответить. Если не давать ответ, то в соответствующее поле запишется значение указанное в квадратных скобках. Первым предложением требуется указать имя пакета по маске "разработчик/проект". Если не указывать, то имя будет выглядеть "root/test". Укажите имя вашего пакета.

Если не хотите указывать автора, то нажмите "n".

После лицензии будет предложено указать зависимости проекта. Здесь необходимо будет указать пакет monolog.

Укажите пакет monolog для поиска

С таким названием менеджер пакетов нашел 15 вариантов. Вам необходимо ввести номер нужного пакета, в нашем случае - 0.

Далее укажите версию пакета. По условиям задачи прописываем ">=2.0"

Описание пакета monolog закончено. Если необходимо добавить еще пакет, то в предложении Search for a package: укажите имя и проделайте предыдущие шаги. В противном случае нажмите enter. После этого, composer, предложит определить зависимости необходимые для разработки. Ответьте "no".

Следующим шагом будет показано предварительное содержимое файла ‌composer.json

Если вы с ним согласны, то нажмите enter, если нет, то введите "no".

В заключении работы генератора, Вам будет предложено установить указанные зависимости. Ответьте "yes". Далее начнётся установка monolog с зависящими пакетами и сгенерируются автоматически файлы composer.json и composer.lock.

Задание выполнено.

Задача 4

При разработке проекта возникла необходимость установить в пакете monolog. Установите его используя composer.

Решение

Перейдите в каталог проекта. Если не важна версия, то наберите команду установки пакета monolog.

Соответсвенно команда с указанием версии выглядит следующим образом

После выполнения команды установится указанный пакет и создастся или обновится файл composer.json. Задача выполнена.

Заключение

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

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

Я занимался исключительно фрилансом перед тем, как открыть свою веб-студию, не считая моего первого опыта официальной работы на должности C# разработчика. Совмещал его с учёбой и в начале относился к этому, как к подработке, а позже полностью перешел на фриланс. Начинал с небольших проектов и мелких задач, а затем это стало карьерой со стабильно высоким доходом. Важно сделать первый шаг, а дальше будет только легче.

Карьера на фрилансе. С чего начать?

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

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

Совет

Как только ты решишь полностью перейти на фриланс, тебе придётся побороться за первые заказы, поэтому запасись денежными накоплениями, которых тебе хватило бы на 2-3 месяца. Это позволит не браться за всё подряд и сосредоточиться на качестве. Первое время — самое сложное, будут и взлеты, и падения, но это поможет набраться опыта. Как начать зарабатывать больше на фрилансе?

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

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

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

Какие возможности открывает программирование на фрилансе?

Сегодня люди стали понимать, какая сфера наиболее перспективная и с каждым днём будет набирать обороты. Желающих «войти в айти» много, а действительно путных специалистов не хватает. Поэтому компании важно найти такого сотрудника — фрилансер это будет или штатный работник, удаленная работа или в офисе, этот аспект уже не имеет большого значения. Работодателям не всегда получается найти в штат нужного сотрудника либо проект не требует полной занятости. Опытные программисты сегодня зарабатывают от 2-2,5 тысяч долларов.

Наиболее востребованными остаются разработчики сайтов, дизайнеры и специалисты по работе с текстами.

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

О тонкостях выбора языка программирования в 2021

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

C и C++

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

Python

Он считается самым простым языком, здесь для многих базовых задач есть готовые способы решения. Но в производительности Python уступает и C++, и более молодым языкам. В требованиях к вакансии Python часто упоминается не как основное требование, а как «дополнение» — чего будет недостаточно для отклика на неё. При выполнении рабочих задач он в каком-то смысле всегда является вторым лучшим: удобный, но всегда чем-то уступающий. Подходит в качестве языка для обучения, что касается трудоустройства — тут смотрите по ситуации.

JavaScript

Хороший вариант для тех, кто выбрал для себя область фронтенда (но сегодня это уже не совсем так). JavaScript здесь вне конкуренции по сравнению с ситуацией в бэкенде. Поэтому востребованность языка очень высокая, выбор вакансий огромный — так что проблем с устройством на работу тут не будет. Особой популярностью пользуются фреймфорки JS-а, такие как React, Vue, Angular.

Но не стоит также забывать и про NodeJS, среду выполнения JavaScript, которая позволяет исполнять JS-код не только в браузере, но и на сервере, что делает JavaScript универсальным инструментом для разработки целых веб-приложений. А наличие фреймворков вроде Nuxt.js и Next.js позволит быстрее начать создавать такие приложения.

Java

Java занял очень хорошие позиции в бэкенде, хотя и не идеален. Среди IT специалистов часто говорят о том, что она скоро умрет и довольно устарела. Не согласен! Эти предположения звучат уже лет дцать, а «старушка» не сдаёт позиции и никуда не делась. Кто-то считает Java занудной и многословной и что используется она в скучных организациях вроде банков, а другие языки могут решать те же задачи эффектнее и без лишней «воды», и их предпочитают стартапы. Здесь всё субъективно: кому-то работа с Java приносит удовольствие, и в банковской разработке находят немало любопытных задач, для других она скучная, что тоже имеет место быть.

C#

Язык C# часто упоминается в вакансиях с требованиями «построения бэкенда для веб-приложений». Но он не ограничивается этим вариантом. C# также используется в разработке игр на самом популярном движке в мире Unity — так что область применения у него шире, чем у той же Java.

Артем Зернов

Кстати, мне довелось поработать на C# в течение целого года в организации, которая использовала .NET-фреймворк и, в частности, C# для разработки специализированного банковского софта. Это была моя первая официальная работа.

PHP

Применяется преимущественно для разработки веб-приложений и со временем стал языком общего назначения. На PHP написаны популярные CMSки, такие как WordPress, Joomla!, Drupal, и, конечно же, мой любимый MODX Revolution. Фреймворки Laravel, Yii2, Symfony-разработаны именно на нем. И даже такие масштабные сервисы, как Facebook и «ВКонтакте», тоже созданы на PHP. PHP отличает то, что он имеет низкий порог вхождения в IT-разработку. Это касается как особенностей самого языка, так и доступности информации о нем.

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

О молодых языках: Go, Dart, Rust и так далее

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

Возможно. Только проблема в том, что такие языки встречаются в разработке намного реже своих «предшественников». Поэтому в вопросе трудоустройства востребованность таких вакансий очень низкая, даже в Москве, не говоря уже о небольших городах.

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

Заключение

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

Значение lifelong learning точно описывает цитата американского футуролога Элвина Тоффлера:

Элвин Тоффлер

Безграмотными в 21 веке будут не те, кто не умеет читать и писать, а те, кто не умеет учиться, разучиваться и переучиваться

Еще недавно профессия человека развивалась по известному стандартному сценарию: жизненный путь определяло одно образование-одна профессия-одна работа. Человек учился, шёл по выбранной стезе, рос по карьерной лестнице, и завершалось всё пенсией.

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

Какими навыками должен обладать востребованный разработчик на фрилансе?

Эти навыки пригодятся не только фрилансеру, но и для постоянной работы программистом удалённо и в офисе.

Технический кругозор

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

Например, платформа MODX позволяет реализовать различные нестандартные задачи и создать уникальный веб-сайт с современным функционалом (начиная от визитки до интернет-магазина). Ее особенностью является гибкость и мощь, которая не сравнится ни с одной CMS.

Умение работать с highload-проектами

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

Детальное понимание технологий

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

Способность рассмотреть задачу с точки зрения бизнеса

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

Soft skills, или гибкие навыки

К ним можно отнести умение планировать работу, справляться с большими объемами информации, отзывчивость, способность работать в состоянии неопределенности и принимать самостоятельные решения.

Умение анализировать и читать чужой код

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

Навык отладки

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

Эти навыки можно получить самостоятельно, как это сделал я. А чтобы освоить профессию быстрее, проходите онлайн-курсы.

Заключение

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

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

Именно такие навыки ты можешь получить в нашей онлайн-школе Lectoria.

На наших курсах программирования мы не только изучаем техническую сторону создания сайтов, но и разбираемся с тем, как правильно построить карьеру фрилансеру. Для этого мы создали дополнительный бонус — блок «Основы продаж», в котором ты научишься грамотно “продавать” себя как специалиста, стать узнаваемым в своей нише и повысить чек на услуги.

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

Этот и другие наши курсы основаны на платформе MODx, которая соответствует современным реалиям IT сферы и позволяет быть в курсе нестандартных решений и новинок.

Инвестируй в свое саморазвитие и будь на волне, сейчас и есть то самое подходящее время.

Удачи в любых начинаниях!

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

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

О чем говорят аналитические обзоры: основные актуальные технологии

Мы проанализировали результаты ежегодного опроса от Stack Overflow и выяснили, какие веб-технологии были наиболее популярны в 2020 году. Будем руководствоваться данными из Stack Overflow Developer Survey 2020.

Рассмотрим список популярных веб-технологий согласно Developer Survey за 2020-й год:

Согласно графику, представленному на рисунке (число опрошенных — 90 000 разработчиков), лидирующие позиции занимают FrontEnd-библиотеки и фреймворки — jQuery, React.js, Angular, Vue.js, а также технологии .NET платформы — ASP.NET и ASP.NET Core. Наряду с ними библиотека Express, которая используется в бекенде на Node.js (JavaScript). Только после них идут фреймворки Spring (Java) и Django (Python).

О некоторых из них мы расскажем ниже.

jQuery

Библиотека JQuery — это одна из библиотек языка javascript. Основная цель применения которой — манипуляций с DOM-деревом. Вставить текст, блок, анимировать блок или элемент — то, ради чего чаще всего используют jQuery, в особенности начинающие frontend-разработчики.

Для тех, кто уже сталкивался с манипулированием объектами DOM (Document Object Model — объектная модель документа) с помощью других библиотек JavaScript или встроенных функций API, jQuery намного упростит процесс работы с этими модулями.

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

React.js

Наверное нет такого программиста, который бы не слышал про React. Весь код данной библиотеки находится в открытом доступе.

Суть работы с React в том, чтобы описать элементы, которые необходимо вывести на страницу. Не нужно создавать инструкции, направленные на объяснение браузеру того, как это необходимо делать. Это дает возможность обеспечить более компактный код и снизить количество шаблонных частей, необходимых для построения сайта.

Если говорить о разработке веб-приложения, React будет недостаточно. В MVC-фреймворке (схема разделения модели, отображения и логики приложения, Model-View-Controller или по-русски Модель-Представление-Контроллер) React играет роль «V». Он делает возможным отображение данных модели пользователю и реагирует на ее изменения. Model и Controller, при этом необходимо обеспечивать дополнительными средствами.

Возможности React.js позволяют строить как большие проекты со сложной структурой, так и что-то скромное. Часто на нем пишут стартап проекты, так как с этим инструментом легче выйти на окупаемость, чем, к примеру, с Angular.

Angular

Angular — фреймворк от компании Google для создания клиентских приложений. Сферой его разработки считаются SPA-решения (Single Page Application), то есть одностраничные приложения. Его предшественником является фреймворк AngularJS. Но Angular это не новая версия AngularJS, а принципиально новый фреймворк.

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

Характерной чертой Angular является то, что на нем строятся приложение с использованием языка TypeScript. Но также при желании использовать такие языки как Dart или JavaScript. 

Если бы HTML был предназначен для приложений его можно было бы приравнять к Angular. HTML — декларативный язык для статических документов. В нем недостаточно функционала для создания приложений, и, как результат, построение в нем веб-приложений сводится к тому чтобы обмануть браузер, заставив его делать то, что я хочу.

Vue.js

Это еще одна библиотека JavaScript, которая используется для разработки веб-интерфейсов с помощью шаблона архитектуры MVVM (Model-View-ViewModel).

Теоретически его можно соотнести с jQuery. Но на деле Vue.JS претендует на лидерские позиции React.JS в области View. В силу того, что Vue работает только на «уровне представления» и не используется для промежуточного программного обеспечения и бэкэнда, он может легко интегрироваться с другими проектами и библиотеками. 

При создании Vue.JS были позаимствованы готовые решения из вышеперечисленных технологий. К примеру, в React.JS — это идея виртуального DOM, который исключает прямое взаимодействие с узлами интерфейса. То есть на первых этапах разработки сайта используется его легковесная копия (virtual DOM).

Vue.js применяется в небольших проектах, где нужно добавить реактивности, представить форму с помощью AJAX, отобразить значения при вводе данных пользователем, авторизацию и т.д. Он считается передовым фреймворком, так как легко масштабируется и может использоваться для создания мощных одностраничных веб-приложений, с использованием таких расширений VueJS как Router и Vuex. 

Vue.js также отличный вариант для разработки frontend блога на популярных CMS и для создания динамических интерфейсов.

Заключение

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

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

А если говорить о программировании на фрилансе… в этом есть особая романтика. Поверьте мне, тому, кто прошел 15-летний опыт от штатного сотрудника до владельца собственной веб-студии и онлайн-школы.

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

"Онлайн и студент" — раньше эти слова были несочетаемыми, и даже абсурдом. Но посмотри, как поменялась жизнь. Цифровые технологии и концепция непрерывного обучения (lifelong learning) становятся нормой жизни.

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

• компьютерные науки
• бизнес
• социальные науки
• науки о данных
• личностный рост

Программирование: особенности сферы, как быстро меняется, почему важно постоянное обучение и мало одного диплома бакалавра

Да-да, фраза о том, что IT-отрасль - лидер по развитию среди остальных сфер экономики, уже мозолит глаза. К счастью или нет, но это факт. Поэтому если ты вошел в IT, будь уверен — зарплата твоя будет выше средней по стране. Заработная плата на одной и той же вакансии в традиционных и IT-компаниях отличается в 1-2 раза. А в случае со специалистом с опытом работы от 3 лет разница может быть в 5-10 раз больше, чем в других отраслях.

Рынок труда изменился и теперь ты не можешь просто закончить ВУЗ с дипломом в 20 с чем-то лет и больше ничего не делать. И речь идет не только о программировании. Предсказать то, какие профессии будут через несколько лет, невозможно. Привычные профессии уже исчезают, новые — появляются. Работать за станком, водить машину, подавать еду в кафе, и даже защищать вас в суде скоро будут роботы.

IT-сфера обладает огромным преимуществом — это ее всеобъемлющее распространение, благодаря чему в этой сфере требуется очень много специалистов самых разных направлений. Хороший «айтишник» всегда будет трудоустроен, к его услугам весь мир, ведь работать можно и дистанционно. А высокая востребованность — это высокая зарплата.

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

А что насчёт ВУЗов? По себе знаю, что в наших вузах довольно слабый уровень подготовки IT-специалистов, и не только. Об этом откровенно говорят и сами «Айтишники». А вот тут многие, узнав себя, спросят: "И что теперь делать?". Придется добывать эти знания самостоятельно, изучая тонны специализированных источников и набивая собственные шишки.

А нужен ли тогда диплом? И в России, и за границей по-прежнему важны дипломы. Причина в бренде или в самом образовании? — сказать сложно. Безусловно, в топовых иностранных вузах нет проблем с квалифицированными учеными. Чего не скажешь о российских преподавателях. У них низкие зарплаты — отсюда и нехватка ведущих специалистов. Поэтому частные компании берут на себя роль так называемого образовательного портала. К примеру, Яндекс и Сбербанк в тандеме с университетами создают программы по специальностям, которые сегодня востребованы.

Западные университеты впереди планеты всей? Хах, не тут-то было, они также не успевают подстраиваться под потребности работодателей. Ведь вузы — консервативные организации. Если мы говорим о направлениях типа блокчейна или селф-драйвинг технологий, думаю, в мире можно по пальцам одной руки посчитать такие университетские программы.

Распространенные мифы об изучении программирования

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

Миф 1. Чтобы освоить программирование, нужно быть очень умным.

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

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

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

Миф 2. Программирование — это скучно

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

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

Миф 3. Программисты всё пишут с нуля

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

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

Миф 4. Чтобы устроиться работать программистом, нужно очень долго учиться

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

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

Какие возможности есть у бесплатного обучения и в чем нюансы платных курсов

Из чего состоит бесплатное обучение? Мы сейчас говорим о самостоятельном пути.

• Поиск информации
• Тестирование информации
• Набивание шишек на практике
• Применение опыта в жизни/работе

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

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

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

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

Конечно, платные курсы перекрывают все эти нюансы. В жизни и мире IT все настолько быстро меняется, что можно не заметить, как ты уже остался за бортом. Поэтому не экономь на образовании — иногда лучше заплатить денег за обучающие курсы и поймать ту самую золотую рыбку уже в первые месяцы работы.
И еще, перед тем, как отдавать кому-то деньги, изучи нишу и сразу отсортируй курсы инфоцыган, которыми сейчас кишит интернет.

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

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

Итог

Мы создали сервис Currency, который полностью настраивается через конфигурационный файл, в котором мы можем задавать курс валют и отображать их в различных местах вашего веб-приложения или сайта. Гибкость данного подхода в том, что в AppServiceProvider вы можете задать другой источник курсов валют — например какой-то внешний сервис или база данных. Также в методе getDefaultUserCurrency класса CurrencyService вы можете определить свою логику получения валюты пользователя по-умолчанию.

Удачи в веб-разработке! Если хочешь получать больше полезных материалов по Laravel, подписывайся на мой канал в Youtube: Lectoria. Обучение веб-разработке

Первая причина, почему MODX это идеальный выбор для создания интернет-магазина — он БЕСПЛАТНЫЙ. Самый популярный компонент, на котором строятся магазины на MODX — miniShop2 стоит ровно 0 рублей.

В данном случае бесплатное не значит некачественное. Дополнительные компоненты для MODX и miniShop2 можно приобрести бесплатно или за сравнительно небольшую сумму. Благодаря этому, ты не будешь тратить время на разработку с нуля, бери готовые решения, адаптируй и применяй их на своём сайте.

Ты можешь также использовать MODX и как фреймворк для построения своего веб-приложения. Его использование не ограничивается только в качестве CMS (именно поэтому ты можешь встретить такую аббревиатуру: CMS/CMF, что означает Content Management System/Content Management Framework).

MODX распространяется с помощью специальной лицензии GPL. Это позволяет использовать ее для выполнения самых разных задач и любого типа сайтов, от простой визитки до крупного интернет-магазина или информационного каталога.

Преимущества MODX для интернет-магазинов

Простая структура админки

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

Простая структура шаблонов

Это очень экономит время и позволяет создавать проекты с любым дизайном и функционалом. Иначе на создание даже самого примитивного проекта у тебя уйдёт вагон времени.
Здесь понадобится только стандартный html-код и немного тегов MODX. Поэтому, если есть навыки работы с HTML и CSS, проблем с настройкой дизайна не будет.
Это важно, в особенности для начинающего разработчика, у которого ещё нет большого багажа проектов. В MODX достаточно изучить инструкцию и любой junior разберется без труда.

Легкость продвижения и рекламы сайта

MODX — одна из самых SEO-дружественных систем.
Здесь есть все необходимые инструменты для продвижения сайта: чистый код без громоздких конструкций, возможность создавать произвольные SEO-поля для каждой страницы, в которых можно указать метатеги keywords, description, title, canonical и так далее.

Вместо обычных и длинных URL страницы создаются с максимально понятными, а главное настраиваемыми ЧПУ-адресами. Они хорошо распознаются поисковой системой. Есть инструменты для быстрого создания карты сайта, содержащей ссылки на все страницы, она способствует максимально быстрой индексации.
Также MODX хорош тем, что позволяет закрепить один URL за конкретной страницей, что способствует отсутствию дублей страниц. В коде страницы нет лишних строчек, которые не имеют значения.

Простая установка на хостинг

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

Это касается и требований к хостингу. Для работы MODX достаточно наличия базы данных MySQL, веб-сервера Apache или Nginx и поддержки PHP. Такая конфигурация найдется у подавляющего большинства доступных хостеров не только в России, но и во всем мире.

Разнообразие компонентов для расширения функциональных возможностей сайта

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

Вот некоторые из них:

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

Возможности miniShop2

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

Для каких-то конкретных задач многие разработчики создают и делятся готовыми сборками интернет-магазинов на miniShop2 и Modx.

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

Курс по разработке интернет-магазинов на MODX и miniShop2

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

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

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

Также на курсе будет:

• Постоянная поддержка и обратная связь по практическим заданиям.
• Закрытый чат, база знаний и база часто задаваемых вопросов

По окончании курса ты получаешь сертификат о его прохождении.

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

Если у тебя уже есть этот фундаментальный опыт и ты обладаешь уровнем знаний junior или middle разработчика, то на курсах Лектория ты сможешь повысить навыки и стать более востребованным специалистом. Наш проект «Лектория» тоже работает на платформе MODX, которая, как мы уже выяснили, обладает большими возможностями.

Всем легкой разработки и прибыльных интернет-магазинов ;)

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

Востребованные профессии 2021

IT специальности

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

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

Среди работодателей самыми популярными позициями являются специалисты в области разработки и внедрения программного продукта. На них приходится более 50% от всех востребованных профессий. В лидерах — backend-специалисты. На каждом сайте есть вакансии веб-разработчика. 

Ещё 2 категории — разработчики-универсалы (full-stack) и разработчики пользовательского интерфейса, знающие несколько языков, фреймворков и сред программирования. Их востребованность составляет больше 80% от количества вакансий в этой группе, разработчики мобильных приложений — только 1%.

Кому подойдёт?

Профессии в сфере IT подойдут тем, кто обладает:

• Аналитическим и математическим складом ума
• Техническим английским языком
• Креативностью, современным подходом
• Внимательностью — даже небольшая ошибка способна привести к некорректному функционированию приложения или сайта;
• Трудолюбием, усидчивостью — на эту работу может уходить много времени, а если приближается дедлайн, придется работать практически 24 часа в сутки;
• Обучаемостью и любознательностью — важно постоянно развиваться, повышать квалификацию;
• Быть ответственным и уметь работать в команде.

Дизайнер

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

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

Профессии в сфере дизайна будут оставаться востребованными еще очень долго.

Кому подойдет?

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

Также очень важна любовь к деталям. Эта работа подойдёт только внимательным людям, которые любят порядок во всём, начиная с папок на компьютере. Если не любить копаться в мелочах, то будет сложно.

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

Хороший дизайнер должен понимать и следить за современными трендами.

Маркетолог-аналитик

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

Маркетолог остается востребованной профессией, потому что также является частью бизнеса, как и дизайн. Реклама «в лоб» выпячивает достоинства и преимущества товара или услуги. Маркетологи используют совершенно противоположный хитрый и умный подход. Нужно иметь высшее образования или пройти курсы маркетинга онлайн и постоянно заниматься самообразованием.

Кому подойдет?

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

И ещё несколько личностных характеристик:

• лидерские качества — для эффективного управления большой группой людей человек должен быть несомненным лидером;
• умение обрабатывать большой объём информации;
• быть эрудированным и иметь «пытливый» ум;
• обладать хорошей памятью;
• иметь способность много работать;
• быть коммуникабельным и уметь общаться с различного рода людьми.

Системный аналитик

Системный аналитик помогает оптимизировать и автоматизировать работу компании и её подразделений. Такой специалист должен разбираться в менеджменте, экономике и информационных технологиях — организует процесс разработки ПО так, чтобы достичь максимальных показателей.

Его можно назвать посредником между заказчиком — руководством компании и исполнителем — разработчиком. Итог такого сотрудничества — программный продукт.

Кому подойдет?

Системным аналитиком может стать человек, обладающий: 

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


• Хорошими коммуникативными навыками. Эта работа не для тебя, если тебе тяжело общаться с людьми и ясно доносить информацию.

• Аналитическим складом ума. Здесь говорится о том, что аналитик умеет предсказывать разные варианты решения задачи.

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

Проект-менеджер

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

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

Кому подойдет?

Какими качествами должен обладать проект-менеджер?

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

Продакт-менеджер

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

Каким должен быть продакт-менеджер?

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

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

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

Между какими профессиями можно переключиться максимально быстро и какие профессии дополняют друг друга

Все вышеперечисленные профессии так или иначе «варятся в одной каше», пересекаются с IT сферой.

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

Профессия «маркетолог» больше граничит с направлениями в бизнесе. Маркетолог может легко переключиться на позицию продакт-менеджера: у них много схожих обязанностей и профессиональных навыков. Работа маркетолога, как и продакт-менеджера, начинается задолго до того, как продукт поступит в продажу. Ещё до начала производства (в торговых фирмах – задолго до решения о закупке) они определяют, на кого товар будет рассчитан, какова потенциальная ёмкость рынка, анализируют деятельность конкурентов, занимаются мероприятиями по продвижению продукта. Иногда компании объединяют эти позиции в одну.

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

Вообще для системного аналитика двери открыты во многие позиции: от тестирования до технического писательства.

Чтобы стать проект-менеджером, можно начать путь в разработке, вырасти до senior-developer и дальше определить, куда идти — в проекты, архитектуру или управление командой;

Если ты уже разработчик / тестировщик / кто-то из ИТ и хочешь попробовать что-то новое, то переход — это хорошая возможность. Эти специалисты уже знают, что такое ИТ, разработка проектов и продуктов, теперь будет стоять задача научиться управлять командой в целом и разбираться в бизнес-процессах. 

Заключение

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

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

Итак, 4 базовых правила хорошего кодинга по версии Артема Зернова aka Lectoria.pro

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

Я думаю, про сессию и хранение аутентификации в сессии все, даже начинающие разработчики более-менее понимают. А вот когда мы создаем точку доступа API своего приложения, то здесь аутентификация происходит немного иначе.

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

Какие способы аутентификации запросов к API могут быть

Логин и пароль

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

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

Одноразовый пароль

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

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

Аутентификация по сертификату

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

Токен или API-ключ

Ну и наконец, самый доступный и распространенный способ аутентификации — по токену или api-ключу, который пользователь может получить одним из следующих способов:

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

Практическая часть

Как выглядит проверка ключа на стороне сервера. На примере фреймворка Laravel.

Создаем Middleware для защиты маршрутов API

Создаем файл app/Http/Middleware/AuthenticateApi.php

Это можно сделать как вручную, так и при помощи команды:

php artisan make:middeware AuthenticateApi

Кладем в него следующее содержимое

Удачи в веб-разработке! Если хочешь получать больше полезных материалов по Laravel, подписывайся на мой канал в Youtube: Lectoria. Обучение веб-разработке

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

Для тех, кому удобнее видео-формат, смотрите видео ниже. Если же вы предпочитаете текстовый формат, крутите ниже.

Как работают формы обратной связи

Как правило, форма обратной связи работает следующим образом:

1. Вы вводите свои данные и нажимаете "Отправить"
2. Сервер принимает этот запрос и начинает его обработку. Сначала происходит валидация введенных вами данных — эта операция быстрая и не требует большого времени на выполнение.
3. Далее запускается логика отправки данных на почту, в CRM и так далее. И именно здесь у нас возникает самая длительная задержка, потому что нужно обратиться к почтовому серверу, отправить данные, дождать ответа, обратиться к API CRM, отправить запрос, дождаться ответа и так далее.

А что, если отправка происходит не на 1 почтовый ящик, а на 3 (например, в техподдержку, менеджеру и гендиректору, потому что он тоже хочет все контролировать). В этом случае время ожидания увеличится в несколько раз.

Как ускорить обработку?

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

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

Как настроить очередь в Laravel

Если мы заглянем в файл config/queue.php, то заметим, что в настройке connections находятся 5 различных видов соединений:

1. Синхронная очередь. По сути — это имитация или некоторый "совсем базовый" вид очередей, так как одна из сильных сторон очередей — асинхронность выполнения задач и возможность выполнить задачу с отсрочкой по времени.
2. Очередь на основе таблицы в базе данных
3. Очередь на основе пакета beanstalkd.
4. Очередь на основе сервиса очередей от Amazon
5. Очередь на основе сервера redis

Давайте разберем процедуру настройки очередей на основе таблицы в базе данных.

1. Подготовим таблицу БД для очереди

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

2. Указываем вид соединения

В файле .env находим настройку QUEUE_CONNECTION и указываем соединение для работы с очередями.

Если данной настройки не было в файле .env ранее, то скопируйте строку выше и добавьте в конец файла или между любыми другими настройками.

3. Создаем асинхронную задачу (Job)

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

Создаем отдельный Job-класс для нашей долгой задачи, выполнив следующую команду:

Как вы понимаете, имя MyVeryLongJob вы можете заменить на свое. Как правило, я в своих проектах, оставляю в названии класса его принадлежность к определенной сущности. Например, если это Job, то в конце имени класса будет "Job". Если это контроллер, то это может быть, например, "MainUserController".

4. Внедряем необходимые зависимости и аргументы в Job

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

5. Опишите логику вашего джоба

В методе handle() класса App\Jobs\MyVeryLongJob опишите всю необходимую логику работы вашей задачи (джоба), используя внедренные зависимости через $this->.

6. Запуск джоба

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

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

7. Запуск воркера

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

В качестве параметра --queue мы указали очередь под именем "default" — это именно то имя очереди, в которую отправляются задачи по-умолчанию, если мы явно не задали имя очереди. Не путайте с соединением. Напротив, в каждом соединении в файле config/queue.php с помощью параметра queue задано имя очереди по-умолчанию (то самое "default", которое мы указали в параметре команды php artisan queue:work).

Заключение

Все, что я описал выше — это всего лишь основы работы с очередями. Так сказать, мануал для быстрого погружения, чтобы попробовать здесь и сейчас. Попробуйте сделать одну и ту же задачу с очередью и без нее. Добавьте в код логики что-нибудь вроде sleep(5), чтобы заметить, насколько долго выполняется задача. И после этого сравните, как ведет себя страница вашего сайта при работе с очередями и без. Разница будет очевидной!

Удачи в веб-разработке. Задавай вопросы в комментариях, подписывайся на Youtube-канал Lectoria и обязательно подписывайся на наши соцсети: Instagram, VK, Facebook.

В чем трудности работы на фрилансе?

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

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

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

Тайм-менеджмент для фрилансера или управление временем.

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

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

Советую разграничить рабочий день: время, когда он начинается и когда заканчивается. И поставить в известность своих клиентов, коллег. Мне удобно работать с 9:00 до 17:00. Со временем это поможет определить собственные пики продуктивности.

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

Для меня главный мотив к управлению своим рабочим и нерабочим временем — внутри меня самой. И эта “свободная” жизнь фрилансера на самом деле и кроет в себе опасность — посвятить свое время только работе. Так вот нельзя допускать того, чтобы рабочие проекты занимали время личное.

Список лучших инструментов для тайм-менеджмента

Если честно, я не успеваю все. Да даже половину. Но это потому что иногда хочется успеть все и сразу🤯

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

1. TickTick

🔗 https://ticktick.com/

Приложение можно полностью кастомизировать под себя с помощью настроек и опций. Здесь встроен календарь и срабатывает напоминание. К любой задаче можно добавить комментарии, чек-листы, файлы, теги и метки, назначить приоритетность. Есть возможность «привязать» задачу к конкретному адресу, например, если нужно купить продукты в конкретном магазине. Если нет времени печатать, можно надиктовать задачи голосом.

2. Google Календарь.

🔗 https://workspace.google.com/products/calendar/

Я его использую как планировщик времени, задач и напоминаний о следующем проекте. Ключевая особенность в том, что на любую задачу я сразу закладываю время. Разработать новый модуль для клиента? Окей, на это уйдет ориентировочно 3 часа и полчаса вначале, чтобы уточнить детали. Записать новый видео-урок: подготовить материал 1 час, записать урок 1 час, смонтировать и выложить — еще примерно 2 часа. Благодаря этому я быстро понимаю, что день не резиновый и не пытаюсь запланировать на день 10500 дел.

3. Sectograph

🔗 https://sectograph.com/

Приложение для визуалов с наглядным расписанием на часовом циферблате. Приложение переносит ваши планы из Google Календаря на 12-часовой циферблат и вместо линейного списка ваше расписание превращается в наглядную круговую диаграмму.

4. Trello.

🔗 https://trello.com/

Подойдет тем, кто практикует подход "Канбан". Смотрели сериал "Кремниевая долина"? Именно после того, как там показали аналоговую версию Trello, коллега начал использовать его более эффективно. Даже несмотря на то, что он чаще всего работает один, организация задач в виде списков и досок помогает наглядно оценивать объем работ и видеть прогресс. Неоспоримым плюсом Trello также является возможность его всесторонней интеграции с различными внешними сервисами, в том числе и с Google календарем. Именно в такой связке он использует Trello (Trello + Cronofy).

5. Notion

🔗 https://www.notion.so/

Еще один мощный инструмент, содержащий в себе множество способов организации заметок, сроков, задач и не только. Преимущество Notion перед Trello заключается в его более гибком устройстве. Вы можете адаптировать рабочее пространство под свои цели практически как угодно. При создании новых страниц Notion предлагает различные шаблоны под различные виды проектов — от простых Todo листов до больших проектов вроде съемки кино.

6. Rescue Time.

🔗 https://www.rescuetime.com/

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

Желание все откладывать на потом.

Или когда пришла пора спросить себя, куда уходят те 1440 минут, которые у тебя есть на каждый день?

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

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

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

Удачи тебе в продуктивности и планировании!

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

Что это означает для веб-разработчика.
Что такой сайт должен быть безопасным, оптимизированным под поисковые системы, быстрым, удобным в использовании и конечно же mobile-first. Также не нужно забывать о его наполнении — контент должен быть качественным и уникальным.

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

Это нужно учитывать ДО начала разработки интернет-магазина

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

Структура категорий

Важно продумать структуру каталога товаров. Если ты будешь делать это самостоятельно, то, скорее всего, сделаешь неправильно. Потому что:

1. Если говорить о владельце бизнеса, то он хорошо осведомлён об особенностях своего товара, но не разбирается в технической реализации каталога товаров.
2. Ты, как разработчик, хорошо компетентен в технических моментах, но не разбираешься в товарах, который предлагает бизнес.

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

Структура товаров

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

Настраиваемые поля.

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

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

Контроль остатков

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

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

Обмен данными (экспорт/импорт)

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

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

Быстрые решения для создания интернет-магазина. Какие CMS самые оптимальные для интернет-магазина?

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

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

Tilda

Здесь достаточно мало шаблонов для интернет-магазинов — всего 20. Несмотря на это, разнообразие тем позволяет создавать сайты для многих товаров. Одежда, украшения, мебель, цветы, постеры, растения и даже отдельные продукты.

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

Цена. 14 дней бесплатно. Потом — от 500 руб./мес.

Wix

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

Цена — от 123 р./месяц.

Bazium

Обладает обширным функционалом не только для создания интернет-магазина, но и управления продажами. Есть шаблоны для разных сфер, широкие возможности для SEO, полноценная встроенная CRM. Из минусов: экспорт/импорт товаров разрешен только на самом дорогом тарифе, есть ограничения по количеству товаров (до 10000).

Цена. 14 дней бесплатно. Потом — от 480 руб./мес при оплате за год (магазин до 500 товаров, не доступен экспорт/импорт и промо-коды).

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

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

Какая CMS лучше?

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

MODX Revolution

Как по мне, так это идеальное решение. Я пользуюсь им уже на протяжении 10 лет. Одна из главных причин в том, что MODX БЕСПЛАТНЫЙ. Самый популярный компонент, на котором строятся магазины на MODX — miniShop2 — тоже бесплатный.

В данном случае бесплатное не значит некачественное. Дополнительные компоненты для MODX и miniShop2 можно приобрести бесплатно или за сравнительно небольшую сумму. Благодаря этому, ты не будешь тратить время на разработку с нуля, бери готовые решения, адаптируй и применяй их на своём сайте.

Ты можешь также использовать MODX и как фреймворк для построения своего веб-приложения. Поэтому можно встретить такую аббревиатуру: CMS/CMF

MODX распространяется с помощью специальной лицензии GPL. Это позволяет использовать ее для выполнения самых разных задач и любого типа сайтов, от простой визитки до крупного интернет-магазина или информационного каталога.

Что выбрать: готовое решение или разработку?

Как я уже сказал, на начальном “пробном” этапе (когда возможно нужна экономия затрат) можно воспользоваться готовыми шаблонами. В будущем их можно объединить в систему управления или же вообще использовать готовые инструменты для разворачивания интернет-магазина — такие как онлайн-платформы для продаж или же готовые CMS-движки с бесплатными шаблонами для онлайн-коммерции.

Фактически выходит готовый интернет-магазин, который нужно только наполнить контентом. Иногда могут потребоваться быстрые доработки дизайна или структуры, добавление новых модулей. Затраты на такой сайт будут минимальны.
До тех пор пока у бизнеса не появятся новые требования к сайту, такой проект имеет место быть. Говоря о требованиях, я имею в виду нестандартный калькулятор или фильтр поиска, расширение базовых возможностей, фундаментальные изменения в структуре страниц или каталога. Выполнить их будет сложно, так как технические возможности у конструктора не рассчитаны на такие доработки. А если клиент планирует развивать бизнес и расти (если проект перспективный — то это в любом случае), то без продвинутых решений не обойтись.

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

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

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

Как может развиваться карьера программиста.

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

Вертикальный рост

Это классический и наиболее распространенный путь от стажера до руководителя. Это и есть продвижение по карьерной лестнице. Повышение на службе-увеличение зарплаты-новые обязанности и расширение зоны ответственности.

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

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

Горизонтальный рост

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

Какие здесь есть варианты:

• Можно стать экспертом в определенной области, что предполагает накопление редких знаний и опыта, которыми обладают далеко не все.
• IT-евангелист. Подойдёт в том случае, если ты находишься в статусе senior и тебе нравится обучать и мотивировать коллег. Задача в том, чтобы популяризировать технологии, делиться опытом и давать советы.
• IT-консультант. Позиция актуальна для сервисной IT-компании, где услуги не ограничиваются только разработкой ПО, а также есть комплекс дополнительных услуг. Здесь senior-разработчик сможет совмещать должность программиста и роль IT-консультанта.

Карьера программиста: ожидания и реальность

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

1. Ожидание: у программистов большие зарплаты.

Реальность: да, действительно так и есть.

Но тут есть подвох. Они большие, но не сразу. Первые 1-1,5 года, возможно, придется поработать за маленькую зарплату или даже бесплатно стажироваться, чтобы набрать опыт. Если повезет, то получится сразу устроиться на зп 30-50 тыс.

2. Ожидание: устроиться программистом очень легко.

Реальность: найти работу программисту не проще чем, менеджеру или переводчику.

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

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

3. Ожидание: Программистом работать интересно.

Реальность: интерес иногда быстро угасает.

На первый взгляд многим кажется, что программирование это красочные приложение на смартфоне, анимированные веб-сайты, игры или ПО аж для космических разработок. На самом же деле за всем этим стоит работа десятков специалистов, бесконечные строки кода и т.д. Могу представить себе мысли такого новоиспечённого «зелёного» специалиста и уровень его разочарования.

Вторая причина в низком качестве образования и погоня компаний за количеством, а не качеством. Такая ситуация в нашей стране во многих областях, и у юристов, и у экономистов.

4. Ожидание: IT специальности это безвредное производство.

Реальность: страдает физическое и психологическое здоровье.

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

В каких компаниях больше возможностей для профессионального роста.

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

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

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

Когда вы создаете новое приложение (даже если это обычный веб-сайт), рано или поздно встает вопрос деплоя, или простым языком переноса на боевой сервер, на котором, скорее всего отличается некоторый набор параметров. Например:

• Настройки подключения к базе данных
• Доменное имя

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

$connection = new DbConnection('vasya', 'superStrongPassword');

Написать что-то вроде такого:

$connection = new DbConnection($config->user, $config->password);

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

А сама переменная $config где-то в момент запуска приложения будет наполняться значениями, которые хранятся в конфигурационном файле.

Как хранить настройки приложения

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

Выглядеть этот файл конфигурации может так:

<?php

return [
	'domain' => 'example.com',
	'username' => 'example',
	'password' => 'pleaseСhangeMe',
	'dbtype' => 'mysql',
	'dbserver' => 'localhost',
	//... и так далее
];

Хранится такой файл наряду с другими конфигурационными файлами различных подмодулей в каталоге config (так, например, устроено в Laravel и некоторых других фреймворках).

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

Настройки окружения (.env)

По сути, файлы настроек окружения — это такие же файлы настроек, но:

1. во-первых, файл окружения, как правило не хранят в git-репозитории (а хранят как пример example-файл)
2. во-вторых, в этот файл выносят ограниченный набор настроек, с которыми вы чаще всего будете работать
3. в-третьих, в этом файле чаще всего содержатся именно те настройки, которые нужно поменять при переносе на другой сервер — это могут быть флаги отключения отладочного режима, ключи доступа к API, настройки почты и так далее — все то, что на локальном сервере имеет другие значения

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

<?php

return [
	'domain' => env('APP_DOMAIN', 'example.com'),
	'username' => env('DB_USERNAME'),
	'password' => env('DB_PASSWORD'),
	'dbtype' => env('DB_TYPE', 'mysql'),
	'dbserver' => env('DB_SERVER', 'localhost'),
];

При этом файл настроек окружения (в Laravel) лежит в корневом каталоге проекта, называется .env и выглядит примерно так:

APP_DOMAIN=mywebsite.com
DB_USERNAME=vasya
DB_PASSWORD=myStrongPassword
DB_SERVER=localhost

Резюме

Файлы настроек окружения содержат относительно узкий набор часто меняемых настроек и настроек, которые зависят от рабочей станции (или, если правильнее — от окружения), а файлы настроек содержат весь набор варьируемых параметров, от которых зависит работа приложения или его подмодулей, среди которых есть те параметры:

• которые чаще всего работают "из коробки"
• которые нужно изменить всего один раз и они будут иметь одинаковые значения вне зависимости от окружения (сервера)
• которые транслируются из настроек окружения.

Удачи в веб-разработке. Задавай вопросы в комментариях, подписывайся на Youtube-канал Lectoria и обязательно подписывайся на наши соцсети: Instagram, VK, Facebook.

В этой статье я хочу затронуть тему “домашней работы”, почему в реальности выходит все не так, как пишут в “интернетах”. О том, как обойти эти недостатки удаленки и выстроить эффективный рабочий процесс.

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

В чем сложность удаленки для программистов?

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

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

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

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

7 шагов к эффективной работе на удаленке

А теперь о принципах, которые помогут облегчить удалённую работу:

Планируй все и распределяй по важности

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

Я расставляю приоритеты так:

1. Задачи, за которые я ручаюсь головой
2. Задачи, у которых выходит дедлайн
3. Задачи, результаты которых могут повлиять на работу всех сотрудников

Создай рабочую атмосферу

Личное мне не помогает этот фокус с переодеваниями в работника дома — пиджак, кофе в корпоративной кружке, туфли, то есть делать вид, что ты в офисе. В первое время это может помочь, но не надолго.

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

Отдыхай, когда устал

Режим офисной работы в 9:00 до 18:00 с перерывом на обед с переходом в «Хоум-офис» становится непродуктивным, а иногда даёт обратный эффект, а то и отторжение. Потому что как раньше уже быть не может.

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

Установи дедлайны

Работники уходят на удаленку для того, чтобы избавиться от прессинга и давления со стороны. А я недавно поняла, что мне лучше работается, когда на меня оказывается хотя бы небольшое давление. Поэтому дома тоже нужно определить для себя какие-то ограничения. Ставить дедлайн на каждую задачу, тогда работается лучше. Чем больше времени у меня есть, тем медленнее идёт работа, и тем меньше я делаю. Так что приходится самостоятельно устанавливать себе сроки.

Поработай где-то вне дома

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

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

Определи длительность рабочего дня

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

Поощряй себя «плюшками»

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

Ожидание какой-то «плюшки» — это не только отличный стимул, но и помощь в ускорении работы.

Кому подходит удаленка

Я думаю, что домашний формат подойдет тем, кто любит работать, ориентируясь на отдельные задачи. А ещё для творческих профессий — с тем условием, что работник сумеет себя «собрать» и организовать процесс. Но если ты хочешь набраться опыта и увидеть весь процесс изнутри, нужно хотя бы на первых порах устроиться в офис. Или, если чувствуешь, что дома не та обстановка. Офис помогает быть «в тонусе», позволяет общаться с коллегами и заводить новые знакомства. Но принципиально твой подход к делу это не изменит.

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

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

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

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

Регистрация событий и слушателей

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

Явная связка

Явный способ позволяет наглядно задать событие и набор классов-обработчиков, реагирующих на это событие при помощи поля $listen вышеупомянутого класса App\Providers\EventServiceProvider:

Динамическая связка

В отличие от предыдущего способа, мы также имеем возможность связывать обработчик (слушатель) с событием в процессе выполнения при помощи фасада Event, например в методе boot класса EventServiceProvider:

Групповая связка

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

Автообнаружение слушателей (неявная связка)

В отличие от двух вышеуказанных методов данный способ доступен только в том случае, если внутри класса EventServiceProvider описан метод, дающий Laravel инструкцию для запуска механизма автоматического обнаружения обработчиков, лежащих в каталоге app/Listeners:

Для того, чтобы понимать, как именно Laravel будет связывать события с обработчиками, необходимо понять структуру класса обработчика. В минимальном варианте класс обработчик (слушатель) должен содержать в себе метод handle:

Именно благодаря сигнатуре метода handle, указывающей явно на класс события MyEvent, Laravel "поймет", что данный обработчик слушает событие MyEvent.

Для того, чтобы Laravel произвел процедуру связки через автообнаружение и закешировал связь событий и слушателей, можно запустить команду:

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

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

Генерация классов событий и слушателей

Автоматическая генерация классов слушателей и событий

Вы можете сгенерировать заготовки под них при помощи команды

Данная команда создаст классы для тех событий и слушателей, которые перечислены в поле $listen класса EventServiceProvider и классы которых еще не созданы

Самостоятельная генерация классов слушателей и событий

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

Параметр --event в команде создания слушателя позволяет автоматически в методе handle указать явно класс события, которое должен слушать данный обработчик (слушатель).

Добавление слушателей в очередь

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

Размещение анонимного обработчика в очередь

Добавление параметров очереди

Также вы можете задать параметры обработки через очередь:

Обработка неудачных событий

При возникновении проблем при обработке события, вы также можете перехватывать такие ситуации:

Запуск класса-обработчика автоматически в очереди

В отличие от анонимных обработчиков, классы-слушатели могут быть обработаны через очередь путем указания имплементации интерфейса Illuminate\Contracts\Queue\ShouldQueue:

При этом параметры очереди можно задать при помощи полей внутри класса:

Если вы хотите определить очередь и соединение динамически во время выполнения, используйте методы:

Помимо прочего, вы можете динамически определять, стоит ли данный обработчик отправлять в очередь или исполнить его в текущем потоке немедленно:

Дополнительные детали обработки неудачных выполнение обработчика можно задать при помощи методов, реализуемых трейтом InteractsWithQueue

Отправка событий (генерация события)

Достаточно вызвать метод dispatch класса события. При этом в качестве параметров передаются те же параметры, которые требуются в конструкторе класса события:

Класс-подписчик

Еще один способ сгруппировать логику событий и обработчиков — создать класс-подписчик, который реализует внутри себя логику подписки на одно или несколько событий. Для того, чтобы Laravel мог понять, какие подписчики необходимо запустить, перечислите их в поле $subscribe класса EventServiceProvider:

Далее определяем класс подписчик:

Заключение

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

Успехов в веб-разработке!

В этой статье я не буду показывать, как сделать форму аутентификации, но попытаюсь объяснить, как связаны все эти термины между собой. Разобравшись в этом, ты сможешь лучше понимать механизм аутентификации Laravel, а также сможешь создавать свои нестандартные решения.

Терминология

Итак, давай определим для начала, что означает Guard и Provider.

Guard Driver — это способ аутентификации пользователя при каждом запросе. Одним из стандартных драйверов guard-ов является session — способ, при котором с помощью механизма php-сессий и cookies состояние пользователя восстанавливается при каждом запросе и система "опознает" таким образом пользователя, который совершает запрос.

User Provider — это способ, с помощью которого пользователи вытаскиваются из некоторого постоянного хранилища. В Laravel по-умолчанию предусмотрен способ с помощью моделей Eloquent и с помощью Database Query Builder (строителя запросов к базе данных). User Provider определяет драйвер модели (Eloquent или Database Query Builder) и дополнительные параметры, которые нужны для этого провайдера (например класс модели, или имя таблицы с пользователями). Каждый User Provider имеет свое уникальное имя (ключ), которое указывается в настройках Guard.

Guard — в рамках настроек Laravel это связка определенного guard-драйвера и user-провайдера, обозначенная уникальным именем (ключом), например web, admin, manager и так далее, и являет собой механизм аутентификации пользователя и хранения (или не хранения) состояния.

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

Guard по-умолчанию

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

В настройках приложения, а именно в файле config/auth.php есть такая настройка:

AuthManager и фасад Auth

При помощи фасада Auth и класса AuthManager, в который ведет этот фасад, в Laravel мы можем осуществлять операции, связанные с аутентификацией пользователя: аутентифицировать с проверкой реквизитов (логин/пароль), аутентифицировать безусловно по id пользователя, "разлогинивать" пользователя и так далее.

Слабая связанность и абстракция

Чтобы AuthManager мог абстрагироваться от конкретной реализации вашей модели пользователей и от того, каким классом представлен User Provider, на помощь приходят контракты (интерфейсы):

• Illuminate\Contracts\Auth\UserProvider
• Illuminate\Contracts\Auth\Authenticatable

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

Второй позволяет абстрагироваться от класса модели пользователя.

Все, что вам нужно, чтобы реализовать какую-либо свою, нестандартную логику — это реализовать методы данных интерфейсов в соответствующих своих классах.

По-умолчанию, модель пользователя App\Models\User, которая идет в Laravel "из коробки" уже реализует интерфейс Authenticatable неявным образом через наследуемый класс Illuminate\Foundation\Auth\User:

А вот внутри класса Illuminate\Foundation\Auth\User уже реализован упомянутый выше интерфейс (контракт).

Как аутентифицировать пользователя

Аутентификация с проверкой реквизитов с использованием guard по-умолчанию

Метод attempt вернет true и аутентифицирует пользователя в случае, если указан корректный email и пароль и false — в ином случае.

Аутентификация с проверкой реквизитов с явным указанием guard

Безусловная аутентификация по id

В отличие от метода attempt, данный метод ничего не возвращает, и просто успешно аутентифицирует пользователя с id = 5

Безусловная аутентификация по id с указанием guard и запоминанием в сессии

Работа с аутентифицированным пользователем

После того, как мы аутентифицировали пользователя, мы можем обращаться к методу Auth::user() или Auth::guard('имя_guard-a')->user(), чтобы получить доступ к объекту пользователя, который в данный момент работает с приложением.

Условное отображение блоков в зависимости от аутентифицированности пользователя в шаблонах blade

Заключение

Уверен, что теперь ты стал лучше понимать, как работает механизм аутентификации в Laravel, а если вдруг чего-то не понял, задавай вопросы в комментариях или в нашем telegram-чате