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

Но я бы хотел рассказать про опыт использования React, который позволяет работать с мутабельной абстракцией над "иммутабельным" canvas элементом. Звучит странно, но работает отлично.

Мотивация

Я использую элемент <canvas> очень часто. Я сделал несколько достаточно сложных веб-приложений, в которых canvas — это основной элемент представления данных. Использовать canvas без всяких фреймворков и библиотек может быть действительно сложно в крупных приложениях. Поэтому я начал часто использовать фреймворки. Сейчас я поддерживаю фреймворк Konva (есть обзорная статья https://habrahabr.ru/post/250897/).

Konva помогает очень сильно, но хочется большего. Так же я начал использовать React в своих приложениях, и он мне действительно нравится. И я подумал, как же я могу использовать React для рисования графики на canvas?

Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе. Также я добавил ссылки на мой блог, чтобы в случае необходимости сразу же можно было посмотреть подробнее.



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

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

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

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Идея сделать браузерный синтезатор у меня появилась достаточно давно, ещё когда Audio API был в весьма зачаточном состоянии и практически единственным шансом извлечь звук из браузера (кроме воспроизведения готовых файлов) была генерация WAV с его последующей кодировкой в base64 и записью в аудио-тег. И если синтез и кодирование удавались без проблем (WAV формат довольно прост), то с потоковым аудио для музицирования в реальном времени всё было хуже и никакими ухищрениями не удавалось добиться бесшовной буферизации, в связи с чем идея и заглохла, так не успев родиться. За прошедшие годы браузеры в поддержке Audio API заметно прибавили, что в свою очередь вдохновило меня на новые эксперименты в этой области. В данной статье шаг за шагом описывается процесс создания браузерного синтезатора средствами HTML5, начиная с генерации простой синусоиды, продолжая коммутацией и модуляцией сигналов и заканчивая аудиоэффектами.

Содержание курса

• Статья 1: алгоритм Брезенхэма
• Статья 2: растеризация треугольника + отсечение задних граней
• Статья 3: Удаление невидимых поверхностей: z-буфер
• Статья 4: Необходимая геометрия: фестиваль матриц
  
  • 4а: Построение перспективного искажения
  • 4б: двигаем камеру и что из этого следует
  • 4в: новый растеризатор и коррекция перспективных искажений
• Статья 5: Пишем шейдеры под нашу библиотеку
• Статья 6: Чуть больше, чем просто шейдер: просчёт теней

Улучшение кода

• Статья 3.1: Настала пора рефакторинга
• Статья 3.14: Красивый класс матриц

---

Official translation (with a bit of polishing) is available here.

---

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

Цель этого цикла статей — показать, как работает OpenGL, написав его (сильно упрощённый!) клон самостоятельно. На удивление часто сталкиваюсь с людьми, которые не могут преодолеть первоначальный барьер обучения OpenGL/DirectX. Таким образом, я подготовил краткий цикл из шести лекций, после которого мои студенты выдают неплохие рендеры.

Итак, задача ставится следующим образом: не используя никаких сторонних библиотек (особенно графических) получить примерно такие картинки:



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

Лучший способ научиться чему-то — это научить другого.

Наступил январь, студенты начинают сдавать экзамены. И часто самым сложным экзаменом оказывается математика. Мой хороший друг спросил у меня: «Что такое теорема Лагранжа, как её доказать и понять?»

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

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



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

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

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

Подумайте, как решить эту задачу? Как бы эту задачу решил умный человек?

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

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