JavaScript *

В последнее время появляется довольно много Fullstack-фреймворков, они становятся популярны, их обсуждают.

Если посмотреть на результаты The State of JS 2021 в разделе «Библиотеки — Бэкенд-фреймворки», то минимум 5 из них (возможно, больше) будут как раз FullStack. Отсортировав бэкенд-фреймворки по заинтересованности, в самом верху списка мы снова увидим именно FullStack. Это понятно — они востребованы и лежат в основе разных проектов.

Однако на наш взгляд, область их применимости несколько ограничена. Почему — объясняем под катом.

Нео проснулся от бликов вспыхнувшего экрана компьютера. Экран заполняла зеленая полоска прогресса.

– Матрица – испуганно прошептал Нео.

– Александр, вы уснули на работе – прошептал тимлид.

Я взглянул на экран компьютера еще раз. Компиляция Vue была завершена. Я облегченно вздохнул.

HitBox — это чаще всего невидимая область или группа областей, которая помогает обнаруживать коснулся ли объект другого объекта, у которого тоже есть свой хитбокс.

В HTML страницах изначально нет понятие хитбокса у блоков, поэтому в этом посте мы сами получим и обработаем их с помощью JS.

Нелогичное продолжение моей старой статьи Рисуем интерференционную картину на JavaScript.

Забавы ради появилась идея сделать анимацию движения планет. Чтобы далеко не отходить от станка решено все было сделать в браузере на JavaScript.

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

Говоря техническим языком, возможно ли выполнять полнотекстовый поиск не имея удаленного сервера, удобным для пользователя способом, одновременно храня поисковый индекс в peer-to-peer системе и имея возможность быстро обновлять поисковый индекс?

Да, это возможно!

Под катом описание архитектуры поискового движка Summa на Rust и набора приемов, позволивших ответить утвердительно на все вопрос

Всем привет!

Делимся полезными материалами с недавно прошедшего митапа Frontend Mix, где экперты ЮMoney и Альфа Банка рассказали, как они создают продукт. 

Я решил перевести документацию react-redux, позвал напарника, и мы вместе решали проблемы, связанные с этим. Собственно, о проблемах и решениях пойдёт речь.

Ссылка на перевод

Кратко: поговорили с авторами библиотеки, развернули перевод на github-pages, получили домен, получаем обновления через свой сервер и хотим внимания)

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

Так вот как то раз смотря документацию Relay я наткнулся на мысль, что не понимаю, как работает связка Relay.useLazyLoad и React.Suspense.

В частности не понятно, как именно React.Suspense понимает, что вот прямо сейчас происходит асинхронный запрос и самое время отрисовывать fallback?

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

Но вот неприятность: такой алгоритм очень неравномерно нагружает потоки и не полностью утилизирует их возможности - пока кто-то простаивает, другой уже копит очередь. Как это можно обойти?

В феврале 2022 года я наконец переехал в США по рабочей визе О1. Этому предшествовало 2.5 года работы над укреплением кейса, ожидание аппрува.

За 1.5 года до этой даты я начал готовиться к интервью на позицию Front End. Сейчас работаю Senior Front-End Engineer в Roku.

Мотивацией для данного поста и создания телеграмм канала по интервью Front-End инженеров стало отсутсвие подробной информации о том, как же выглядит этот процесс в США.

Совсем недавно начал изучать фреймворк Fastify, который почему-то не особо популярен в русскоязычном сегменте интернета. Для хранения переменных конфигурации я всегда использовал файл .env. Для чтения файла .env на Express я привык использовать всем известную библиотеку dotenv, то врем как в экосистеме Fastify есть своя библиотека - @fastify-env.

Я в обратился к документации... и ничего не понял. Я попробовал реализовать то, что там указано, но у меня ничего не вышло. Туториал на youtube от какого-то индуса так же не помог (хотя у индийского программиста всё получилось)...

Сославшись на позднее время суток и усталость мозга, я сдался и начал искать какое-нибудь готовое решение в интернете, и оно быстро нашлось, которое нашлось достаточно быстро. Выяснилось, что я не один сталкиваюсь с такой проблемой и это частая сложность у программистов пришедших в Fastify после Express.

Итак, ниже пойдёт перевод этой статьи от 27.07.2021 г. (обновлено 18.02.2022 г.). Перед прочтением статьи рекомендую потратить 5-10 минут времени на чтение ооочень короткой официальной документации библиотеки @fastify-env.

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

Для этого решил адаптировать не алгоритм к схеме, а схему к алгоритму. Поскольку алгоритм BFS использует перебор массивов станций, координат линий и пересадок, то нужно было распарсить схему из Википедии в массивы: для этого я написал различные варианты CSS-селекторов.

Игра Жизнь - это клеточный автомат созданный в 1970 году Джоном Конвеем.

Это не совсем игра, а просто симуляция клеток по определенным правилам.От игрока лишь требуется размещать эти клетки.

В этом посте мы сделаем "Игру Жизнь" на HTML странице при помощи CSS & JS.

Здравствуйте, друзья!

Мы продолжаем разбирать максимально простым языком алгоритмы и структуры данных на JavaScript. И сегодня мы поговорим о, пожалуй, самом знаменитом алгоритме, про который слышал каждый разработчик — а именно о сортировке пузырьком (Bubble Sort).

Если вы еще не читали нашу первую статью (про алгоритмы поиска и Big O нотацию), то можете найти ее вот здесь.

А сейчас давайте перейдем к теме статьи.

Привет, Хабр!

Приветствую всех, уважаемые читали! Меня зовут Сергей Семенов, я frontend-разработчик в компании Домклик. Эта статья посвящена созданию интерактивного приложения для визуализации алгоритмов сортировки. Надеюсь, многим из вас тема покажется интересной. Уверен, что вы успешно пройдёте через все этапы разработки и пополните свою копилку пет-проектов.

Продолжаем серию статей, посвященных разным прикладным концептуальным решениям, которые могут существенно "прокачать" производительность вашего Node.js-приложения.

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

Начнем с достаточно типовой задачи: мы получаем некоторые сообщения, и нам их надо как-то обработать. В качестве тестового примера сгенерируем эти сообщения самостоятельно, и посмотрим, за какое минимальное время мы сможем вычислить SHA-256-хэш для каждого из них.

Первое мое знакомство с Mobx началось с удивления. Я не понимал всю магию библиотеки и задавал себе вопрос: “А как это возможно?”. Кажется, в ней используются какие-то подкапотные возможности JS или Mobx вообще написан на другом языке. 

И вот, потратив 3 месяца в исходниках, я развеял для себя магию. Mobx все таки написан на JS и даже имеет множественные ограничения, которые нужно соблюдать, чтобы ваш браузер не взорвался.

В этой статье мы создадим свой Mobx с нуля, а так же свяжем его с React, через собственно написанный HOC observer. В конце у вас будет общее понимание реактивности, которое поможет в самостоятельном осмыслении не только Mobx, но и других реактивных библиотек и фреймворков.

Одним днем возникла необходимость добавить в проект генерацию коротких css классов и id элементов в html верстке. Основные причины были следующие:

* Усложнить жизнь парсерам и блокировщикам рекламы (они зачастую на имена классов опираются).

* Уменьшить размер html страниц

* И чтобы все было как у Google, шутка ?

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