Когда речь заходит об асинхронных операциях в Unity, на ум первым делом приходит coroutine. И это не удивительно, так как большинство примеров в сети реализованы именно через них. Но мало кто знает, что Unity поддерживает работу с async/await еще с 2017 версии.

Так почему же большинство разработчиков до сих пор использует coroutine вместо async/await? Во первых, как я уже упомянул, большая часть примеров написана с использованием coroutine. Во вторых, async/await кажется очень сложным для начинающих разработчиков. Ну и в третьих, когда речь заходит о коммерческих проектах, где основным из критериев является стабильность, предпочтение отдается проверенному годами подходу.

Но технологии не стоят на месте и появляются библиотеки, которые делают работу с async/await в Unity удобной, стабильной и самое главное высокопроизводительной.

Ночь. Стук в дверь. Открыть. Стоят двое. "Верите ли вы в Event loop, нашу главную браузерную цепочку?" Вздохнуть. Закрыть дверь. Лечь досыпать. До начала рабочего дня еще 4 часа. А там уже ивент лупы, лейауты и прочая радость…

В первой части мы говорили о первой загрузке и работе с ресурсами. Сегодня я расскажу о второй части оптимизации производительности фронтенда. О том, что происходит с нашей страницей, когда она загружена, на что уходит процессорное время и что с этим делать. Ключевые слова: event loop, paint \ repaint, layout \ reflow, composite.

Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.

Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube

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

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

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

1. Зачем думать о производительности
2. FMP, TTI + подробнее в докладе
3. Critical render path, DOM, CSSOM, RenderTree
4. Шаги по улучшению производительности первой загрузки + подробнее в докладе

Общеизвестно, что каждый программный продукт в конечном итоге обретает номер поставляемой версии. Изначально это может быть цифра в README файле, на борде в JIRA либо просто в голове у тимлида или ПМа. Но в какой-то момент становится понятно, что нужно формализовать процесс назначения версии релизу, отобразить номер в приложении, интегрировать версионность в CI, аналитику и другие места. 

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

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

Привет, Хабр! В не такие уж далёкие годы, на первом курсе «программистского» факультета, мне нравилось задавать товарищам по учёбе вопрос: «Зачем вы вообще пошли сюда учиться?» Точной статистики ответов я, конечно, не вёл, но доподлинно помню: больше половины хотели делать игры. Большинство тех, кто так отвечал, оказались не готовы к обилию разных видов «математик» и «физик», которыми нас завалили в первые два года учёбы. Выдерживали не все — уже к концу второго курса из пяти переполненных групп осталось три неполных.

Не так давно нашей фронтенд-команде предоставилась возможность попробовать себя в роли gamedev. Очень коротко, задача такая: сделать самую настоящую 3D-игру, да так, чтобы можно было поиграть, просто открыв браузер. Даже мобильный. Даже в WebView.

В этом посте я постараюсь рассказать о том, как мы спроектировали архитектуру игры, с какими проблемами столкнулись, используя один из самых популярных и актуальных технологических стеков — React + Redux, и какими «хорошими практиками», вероятнее всего, придётся пожертвовать, если вы для схожих задач выберете этот же стек.

Введение

Краткий обзор

Необходимое вступление

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

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

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

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

Пишем код чище, используя паттерны деструктурирования

Вы, наверное, уже знакомы с деструктурированием в JavaScript. Оно пришло к нам в 2015 году в спецификации ES6, но если вам нужно освежить знания, то на сайте Mozilla можно почитать большую подробную статью, как это всё работает.

Но знать как работает совсем не то же, что знать как использовать. Вот три паттерна, которые помогут вам сделать код чище, надёжнее и читаемее!

1. Именованные аргументы функции

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

def sum(a=1,b=2,c=3):
  return a+b+c

sum(b=5,a=10)

Видите? Порядок не важен, если вы явно указали имя параметра. Преимуществами по сравнению с позиционными аргументами является то, что:

1. Можно опустить один или несколько параметров при вызове функции
2. Порядок при передаче аргументов теперь не важен
3. Код стал читаемее 

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

function sum({a = 1, b = 2, c = 3}) {
  return a + b + c
}

sum({b: 10, a: 5}) // 5 + 10 + 3 = 18

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

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.