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

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

Платформы с предложениями о работе в IT-сфере, просто кишат вакансиями фронтенд разработчиков со сознанием React.

С одной стороны React нам дал возможность частями программировать интерфейс пользователя, разбирая его на части. А с другой стороны мы получили “молоток и гвозди” с помощью которых нам придется построить дом. И получилось так что сообщество программистов использует фреймворк React, чтобы написать свой фреймворк. И поэтому на рынке появляются новые фреймворки, основанные на React, которые уже решают конкретные задачи на реальных проектах. Одним из таких фреймворков является Next.js. 

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

А вот что конкретно сделали разработчики Next.js мы рассмотрим и сравним в этой статье с технологией MastermindCMS2. Поехали!

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

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

Один из таких подходов разнесения логики был паттерн программирования MVVM(Model-View-ViewModel). Его активно продвигали во фреймворках для C#. Структурно с точки зрения разнесения логики, я считаю этот паттерн самым удобным.

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

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

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

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

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

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

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

Все началось в далеком 2017 году, когда мне пришла идея написать для себя сайт. Я, недолго думая, взял Drupal и настроил его как headless-cms. Мне хотелось написать отдельно фронтэнд и не копаться с темами от Drupal. Но что-то пошло не так! Я столкнулся с множеством ограничений в проектировании сущностей в административном интерфейсе. Тогда я решил попробовать это сделать на WordPress. Но я совсем не ожидал, что мне придется создавать отдельные контроллеры под каждый тип сущности. Но честно признаться - меня это расстроило. В Drupal хотя бы есть Views, которые относительно легко сконфигурировать в административной консоли и создать endpoint'ы для доступа через REST API, но тем не менее там есть свои ограничения. После этого я провел небольшой анализ существующих CMS и понял, что придется писать все под себя.

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