Предисловие

Nuxt — "фреймворк над фреймворком Vue" или популярная конфигурация Vue-based приложений с использованием лучших практик разработки на Vue. Среди них: организация каталогов приложения; включение и преконфигурация самых популярных инструментов в виде Nuxt модулей; включение Vuex по-умолчанию в любую конфигурацию; готовый и преднастроенный SSR с hot-reloading'ом

Django — самый популярный веб-фреймворк на почти самом популярном языке программирования на сегодняшний день — Python. Сами разработчики позиционируют проект как "Веб-фреймворк для перфекционистов с дедлайнами". Представляет из себя решение "всё в одном" и позволяет в кратчайшие сроки построить MVP вашего веб-приложения.

GraphQL — язык запросов изначально созданный компанией Facebook. В статье будет говориться о конкретных реализациях протокола этого языка, а именно библиотек Apollo для фронтенда и graphene для бэкенда.

О чем и для кого эта статья

В предыдущей части мы настроили структуру приложения, в данной статье мы настроим Strapi API и выведем список ресторанов.

Первая часть тут

Продолжаем разработку нашего интернет магазина. В этой части будет:

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

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

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

Как и обещал продолжаем.

В этой части:

• создадим блоки товаров "С этим товаром также покупают" и "Интересные товары"
• создадим иконку корзины с количеством товаров
• подключим модальное окно с товарами в корзине
• перепишем всю логику store

В один яркий солнечный день, когда на стройке работа просто кипит, всё вокруг ярко и позитивно, и прямо хочется вечерком пожарить шашлык, на объект проник бывший сотрудник одного из подрядчиков. Он прошёл мимо проходной, помахал рукой охраннику, который знал его в лицо (но не знал, что он уволен), и зашёл внутрь. Там он пошёл к своим друзьям из Центральной Азии. Через полчаса они уже жарили шашлык и наслаждались жизнью.

Нюанс в том, что костёр они развели между двух газовых баллонов.

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

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

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

За одного такого родственника на стройке накладывается штраф от 500 тысяч рублей и выше, и стройка может быть приостановлена от 14 до 90 дней. А это кончается очень, очень печально для генподрядчика и заказчика.

Именно после этого инцидента позвали нас решить задачу ИТ-средствами.

Перевод статьи подготовлен в преддверии старта курса «Web-разработчик на Python».

---

Введение

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

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

По традиции, можно было бы смешать Django и jQuery, чтобы получить желаемое поведение. Но сейчас есть более новые технологии JavaScript, такие как React и Vue. Поскольку наша цель состоит в том, чтобы найти фреймворк, который мы сможем использовать вместе с Django не переписывая все с нуля, мы воспользуемся Vue, как более легкой альтернативой. В этой статье я покажу, как начать пользоваться Vue вместе с Django с минимальными усилиями.

• Часть 1: Nuxt as fullstack server: frontend + backend API Server
• Часть 2: Additional SSR performance with Nuxt fullstack server

Разработчики Nuxt предлагают 3 метода доступа к API:

1. Встроенный в Nuxt сервер Connect и использование serverMiddleware
2. Интегрированные фреймворки (Express, Koa, Hapi и т.д.)
3. Внешние API сервера

Я покажу на простом примере как организовать API сервер с использованием serverMiddleware на том же инстансе Nuxt, который у нас отвечает за frontend.

Начиная с основ

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

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

Одностраничные приложения? Это вкусно?

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

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

• Часть 1: Nuxt as fullstack server: frontend + backend API Server
• Часть 2: Additional SSR performance with Nuxt fullstack server

В Части 1 я рассказал как легко организовать API Server в Nuxt. В Части 2 я хочу рассказать какие дополнительные преимущества можно извлечь из Nuxt fullstack server.

Во Vuex есть одна популярная практика — не использовать mapState и mapMutations. Вообще. Вместо это мы сразу же при создании нового значения в store делаем для него геттер, а для каждой мутации – экшен.

Что-то наподобие:

export default new Vuex.Store({
  state: {
    // 1
    count: 0
  },
  getters: {
    // 1
    count: (state) => state.count
  },
  mutations: {
    // 2
    increment(state) {
      state.count++;
    }
  },
  actions: {
    // 2
    increment({ commit }) {
      commit('increment');
    }
  }
});

Холивара не избежать. Это уже доказала вот эта статья. Опять в интернете кто-то не прав, и я должен доказать почему. И я докажу.

В этой статье пойдет речь об распространенной ошибке, которую делают большинство начинающих при разработке приложения на Vue + Vuex. Мы поговорим о геттерах (getters) и как их правильно использовать. Также мы рассмотрим вспомогательные функции mapState и mapGetters.

Примечания перед прочтением: рекомендуется иметь базовые знания Vue и Vuex.

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

Перевод статьи подготовлен в преддверии старта курса «Vue.js-разработчик».

---

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

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

1. Структурирование хранилища
2. Разделение хранилища на модули
3. Автоматический импорт модулей хранилища
4. Сброс состояния модуля
5. Глобальный сброс состояния модуля

Лицо моей жены, когда она вычитывала эту статью

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

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

Можно бесконечно холиварить о том, является ли GitLab хорошим продуктом. Лучше посмотреть на цифры: по итогам раунда инвестирования оценка GitLab составила 2,7 млрд долларов, в то время как предыдущая оценка была $1,1 млрд. Это означает бурный рост и то, что компания будет нанимать все больше и больше фронтенд-разработчиков.

Так выглядит история появления фронтенда в GitLab.



Это график количества фронтендеров в GitLab, начиная с 2016 года, когда их не было вообще, и заканчивая 2019-м, когда их стало уже несколько десятков. Но сам GitLab существует 7 лет. Значит, до 2017 года основной код на фронтенде писали бэкенд-разработчики, хуже того, бэкенд-разработчики на Ruby on Rails (ни в коем случае никого не хотим обидеть и ниже поясним, о чем идет речь).

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

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

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

Здравствуйте, меня зовут Дмитрий Карловский и я… люблю плевать против ветра. Утираться и снова плевать. Хобби у меня такое. И всё, что я создаю, делаю я без оглядки на тенденции, стараясь решать проблемы системно, а не как привычно. Зачастую бывает, что основная сложность даже не в том, чтобы придумать решение, а в том, чтобы объяснить другим, что проблема вообще существует.

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

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

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

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