Перевод статьи подготовлен в преддверии старта курса «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 года назад фреймворк, какой путь он прошёл, где он сейчас, и куда прокладывает новые пути. Пройдёмся мы и по конкурентам, и по крупным игрокам, и даже по мне самому. Так что никто не уйдёт не обиженным. Статья, как обычно, длинная. Мужайтесь.

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

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

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

Доброго времени суток, друзья!

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

JSON.stringify() часто используется при отладке для преобразования объекта или обычной строки в строку в формате JSON. Но как данный метод используется, и можем ли мы обойтись toString()? Давайте попробуем это сделать.

// создаем объект user
const user = {
    name: 'Harry Heman',
    age: 29,
    job: 'developer'
}

// преобразуем объект в строку, используя стандартный метод toString(), и выводим результат в консоль
console.log(user.toString()) // [object Object]

[object Object] — это не совсем то, что мы хотели увидеть, не правда ли?

Не спрашивайте, зачем мы вообще используем toString(). Предположим, что нам жизненно необходимо перевести объект в строку.

Теперь попробуем использовать JSON.stringify():

console.log(JSON.stringify(user)) // {"name":"Harry Heman","age":29, "job": "developer"}

Мы сделали это, Карл!

Однако возможности JSON.stringify() этим не исчерпываются.

Предлагаю ознакомиться с расшифровкой доклада Виталия Левченко Go vs Python

Go — волшебное слово, решение всех проблем продакшна разом и одновременно негодная технология без эксепшнов. Истина посередине, поэтому поговорим о конкретных примерах:

• asyncio vs горутины;
• производительность узких мест;
• лаконичность vs простота кода;
• порог входа;
• тулинг и паттерны поиска проблем и оптимизации производительности;
• обслуживание в продакшне.

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

Хорошим выбором для этого мог бы стать DOOM. Мегахит 1994 года от id Software был портирован на всё, что только можно. Игра спроектирована вокруг ядра, чётко разделённого на слои. Обычно легко найти и прочитать реализацию шести подсистем ввода-вывода.

Другим выбором могла бы стать Another World 1991 года от Эрика Шайи, в Северной Америке более известная под именем Out Of This World. Я бы сказал, что на самом деле её интереснее изучать, чем DOOM, из-за полигональной графики, подходящей для диких оптимизаций. В некоторых случаях хитрые трюки позволяли игре работать на оборудовании, созданном за пять лет до выхода игры.

Компания Wargaming юридически преследует своих бывших сотрудников за работу над Open Source проектом (программным обеспечением с открытым исходным кодом), который она официально развивала до весны 2018 года. Wargaming подала персональные иски к своим бывшим сотрудникам, которые на данный момент работают в ООО «БлицТим», с требованиями о компенсациях на суммы до полумиллиона долларов с человека.

Предисловие

Всем привет! Меня зовут Саша, и я больше шести лет занимаюсь тестированием бэкенда (сервисы Linux и API). Мысль о статье у меня появилась после очередной просьбы знакомого тестировщика подсказать ему, что можно почитать по командам Linux перед собеседованием. Обычно от кандидата на позицию QA инженера требуют знание основных команд (если, конечно, подразумевается работа с Linux), но как понять, про какие команды стоит почитать во время подготовки к собеседованию, если опыта работы с Linux мало или вовсе нет?

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

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

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

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


Итак, немного о рабочих буднях тимлида:

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