JavaScript *

Tic Tac Toe: содержание цикла статей

В этой статье рассмотрим реализацию бэкенда с применением C++ Boost.Beast библиотеки на примере синхронного сервера. Та же функциональность, что и в прошлой статье — получаем от бэкенда случайное число от 0 до 8 включительно. Оказалось, что поднимать контейнер для Beast ничуть не сложнее, чем для Flask'а. Главное сразу найти хороший подходящий пример. Здесь я взял Dockerfile для своего проекта.

Картинка взята из презентации к этому докладу для привлечения внимания, а также для повышения настроения и мотивации тем, кто не знает C++.

Введение

В этой статье мы, как вы уже догадались, поговорим про Screen Capture API. Этот API появился на свет в 2014 году, и новым его назвать сложно, однако поддержка браузерами все еще достаточно слабая. Тем не менее его вполне можно использовать для персональных проектов или там, где эта поддержка не так важна.

Немного ссылок для начала:

• Спецификация Screen Capture
• MDN Usage Guide
• Демо

На случай если ссылка с демо отвалится (или если вам лень туда перейти) — вот так выглядит готовое демо:

Приступим.

Введение в ES6

Template literals (Template strings)

Написано Kristofer Selbekk, в сотрудничестве с Caroline Odden. Основано на лекции с таким же названием и с теми же людьми, состоявшейся на встрече ReactJS в Осло в июне 2019 года.

От переводчика — оригинальное название The 10 Component Commandments не упоминает React, но большинство примеров и рекомендаций относятся именно к реакту, к тому же статья выложена под react тэгом и написана реакт разработчиками.

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

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

Задача: используя наименьшее возможное количество ресурсов, отрендерить осмысленный текст.

• Насколько маленьким может быть читаемый шрифт?
• Сколько памяти понадобится, чтобы его хранить?
• Сколько кода понадобится, чтобы его использовать?

Посмотрим, что у нас получится. Спойлер:

Привет, Хабр! Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" автора Jorge Ramón.

В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.

Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её. Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле.

Tic Tac Toe, часть 0: Сравнение Svelte и React
Tic Tac Toe, часть 1: Svelte и Canvas 2D
Tic Tac Toe, часть 2: Undo/Redo с хранением состояний
Tic Tac Toe, часть 3: Undo/Redo с хранением команд
Tic Tac Toe, часть 4: Взаимодействие с бэкендом на Flask с помощью HTTP

В этой статье рассмотрим взаимодействие веб-приложения на Svelte из предыдущей статьи с бэкендом на Flask при помощи HTTP запросов. Оказалось, что поднять контейнер с бэкенд приложением на Flask быстрее чем на Boost.Beast, поэтому сделал пример с Flask. Не огорчайтесь, пример с Boost.Beast будет немного позже.

Привет! Учусь на front-end, и параллельно, в учебном проекте, разрабатываю SPA на Vue.js для back-end, который собирает данные от поискового бота. Бот нарабатывает от 0 до 500 записей, и я должен их: загрузить, отсортировать по заданным критериям, показать в таблице.

Ни back-end ни бот, сортировать данные не умеют, поэтому мне приходятся загружать все данные и обрабатывать их на стороне браузера. Сортировка происходит очень быстро, а вот скорость загрузки, зависит о коннекта, и указанные 500 записей могут загружаться от 10 до 40 секунд.

Поначалу, при загрузке, я показывал спинер, недостаток которого — пользователь не знает когда закончится загрузка. В моём случае заранее известно количество записей которые отыскал бот, поэтому можно показать сколько % записей загружено.

Чтобы скрасить пользователю ожидание, я решил показать ему процесс загрузки:

1. цифрами — сколько % записей уже загружено
2. графиком — время загрузки каждой записи
3. заполнением — % загрузки. Так как график по мере загрузки заполняет прямоугольный блок, видно, какую часть блока осталось заполнить

Вот анимация результата, к которому я стремился и получил:

… по-моему, получилось забавно.

В статье я покажу как продвигался к результату шаг за шагом. Графики функций в браузере я до селе не рисовал, поэтому разработка индикатора принесла мне простые, но новые знания о применении SVG и Vue.

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

Недавно в блоге V8 появилась статья, посвящённая новому пропозалу WeakRef (Stage 3) — "Weak references and finalizers".

Попробую объяснить своими словами его суть на примере. Представьте, что у вас в браузере происходит какая-то обработка изображений, например, на них накладывается водяной знак (согласен, пример не очень реалистичный), а затем эти изображения как-то используются. Водяной знак накладывается функцией, которая интенсивно потребляет CPU. Изображения могут повторяться, поэтому, чтобы лишний раз не загружать процессор, мы создаём кеш изображений с водяным знаком в Map, ключом пусть выступает название файла изображения. Но тут возникает проблема, если какое-то изображение не будет нами использоваться, оно всё равно будет находиться в памяти, так как Map по ключу будет на него ссылаться (strong reference). Поэтому, чтобы наш Map не отжирал лишнюю память, необходимо как-то определять такие ситуации и руками чистить кеш. Это не очень удобно.