JavaScript *

Всем привет!

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

ДИСКЛЕЙМЕР: это не бескорыстный акт передачи знаний с моей стороны. Я пытаюсь найти инвестиции для своего проекта и создал чат в тг, где буду постить обновления и какие-то мысли касательно его запуска. Так что если интересно, то подписывайтесь, а еще можете поделиться ссылкой с теми, у кого есть лишние бабки =)

Предыстория

Значит решил я создать сервис для одиноких мужчин, где они могут пообщаться с прекрасными дамами, aka вебкам. Соответственно встал вопрос, как организовать видеосвязь в браузере. Обычно для этого используется WebRTC, эта технология позволяет установить p2p соединение между браузерами для передачи видео, звука и прочих данных в реальном времени с минимальной задержкой. Однако была одна проблема: что делать, если приходит жалоба от пользователя, что ему показали не то (или не показали), что он хотел. Поскольку это p2p соединение напрямую между пользователями, у меня как у владельца сервиса нет возможности провалидировать жалобу. Первое, что пришло в голову это вместо WebRTC использовать MediaRecorder API для записи видео небольшими кусочками и отправки их по вебсокету через сервер, попутно сохраняя. Я набросал прототип и столкнулся с тем, что если получатель пропустил первый пакет (там где есть метаданные), то видео у него не воспроизводится. Пришлось поиском определенного набора байт в первом пакете вычленять эти самые метаданные и сохранять их отдельно для отправки первым сообщением только что подключившемуся получателю, и это даже сработало. Вторая проблема этого решения - это задержка в пару секунд, и это только в локальной сети, что приемлемо для односторонней связи, но для двусторонней уже сомнительно. И третья проблема это то что видео у получателя со временем все больше и больше отстает, и нужно регулярно проматывать видео ближе к концу. Костыльность такого решения меня не устраивала, и я решил использовать WebRTC для связи собеседников и параллельно использовать MediaRecorder для отправки записи от модели к серверу. Некоторое время оно так работало, пока я пилил другие фичи, но неэлегантность этого решения все еще не давала мне покоя, т. к. оно повышает требования к интернет соединению модели.

Проект начал делать в 2022 году, параллельно с проектом по первой части фильма. Во второй части многие локации пришлось искать вооружившись Яндекс и Гугл панорамами. Около полугода искал человека, который сделает фото в Чикаго.

С технической точки зрения ничего не поменялось, про нее я рассказал в статье по первой части фильма. Хочу более детально остановиться на поиске и съемке локаций.

Привет, Хабр! Так вышло, что на текущем я попал под сокращение, а значит путь к собеседованиям открыт. Как раз вчера случилось одно (видимо, из многих), на котором зашла речь про useCallback.

В современном мире разработки программного обеспечения GitHub остается самой популярной платформой для хранения Git-репозиторий и управления ими. Помимо своей фундаментальной роли в управлении версиями, GitHub предлагает дополнительные функции, включая возможность размещения private NPM registry. Эта функция упрощает хранение и совместное использование JavaScript и TypeScript библиотек между проектами и командами, улучшая совместную работу и возможность повторного использования кода в вашей компании.

GitHub Actions позволяет автоматизировать задачи ваших проектов, такие как linter, sonar , запуск тестов, билд образов Docker, развертывание в различных средах и многое другое.

Говоря о Docker, общепринятой практикой является создание приложения, библиотеки или любого кода в определенном образе Docker (то есть сборка внутри Docker контейнера). В этом контейнере можно задать определенную версию Node, а также любые внешние ресурсы и библиотеки, необходимые в процессе сборки. Этот подход обеспечивает максимальное удобство, поскольку устраняет необходимость полагаться на конкретный ПК или виртуальную машину со всеми необходимыми настройками. Вместо этого вы можете один раз подготовить среду на уровне Docker и последовательно использовать ее на разных машинах и в разных средах, обеспечивая согласованность и воспроизводимость на протяжении всего процесса разработки.

Однако возникает проблема, когда вы пытаетесь создать свое приложение в Docker, и для этого требуется библиотека npm, хранящаяся в вашем частном реестре GitHub NPM. Более того, этот процесс должен быть осуществим в GitHub Actions. В этой статье я покажу вам процесс настройки, чтобы добиться этого без проблем!

Думаю, ни для кого не секрет, что все популярные JavaScript движки имеют схожий пайплайн выполнения кода. Выглядит он примерно следующим образом. Интерпретатор быстро компилирует JS-код в байт "на лету". Полученный байт код начинает исполняться и параллельно обрабатывается оптимизатором. Оптимизатору требуется время на такую обработку, но в итоге может получиться высоко-оптимизированный код, который будет работать в разы быстрее. В движке V8 роль интерпретатора выполняет Ignition, а оптимизатором является Turbofan. В движке Chakra, который используется в Edge, вместо одного оптимизатора целых два, SimpleJIT и FullJIT. А в JSC (Safari), аж три Baseline, DFG и FTL. Конкретная реализация в разных движка может отличаться, но принципиальная схема, в целом одинакова.

Сегодня мы будем говорить об одном из множества механизмов оптимизации, который называется Inline Caches.

Началось всё с того, что не нашел я библиотеки для JavaScript, которая вычисляет собственные векторы для комплекснозначной матрицы 4х4. Пришлось писать самому.

И в ходе реализации встала передо мной этакая бодренькая микрозадачка – из набора чисел «1, 2, 3, 4» вычеркнули два числа «x, y» (неодинаковых – кто-то придет завтра и задаст эти два числа, а мы сегодня должны приготовиться), требуется объяснить компьютеру, как определить оставшиеся, невычеркнутые числа. И я завис – все идеи, которые приходили мне в голову, казались «неспортивными и чрезмерными» – ну не пузырьковой же сортировкой перебирать четыре числа, должно же быть что-то элегантное. Например, если вычеркнуто не два, а три числа «x, y, z» из четырех «x, y, z, t» (которые «1, 2, 3, 4»), то оставшееся число «t» находится так: t = 10 – (x+y+z). Потому что t+x+y+z = 10 (всегда: 10=1+2+3+4). Вполне элегантно для одного оставшегося числа. А для двух чисел – как быть с элегантностью?!

Решение я нашел – озарило по дороге домой – прям шарахнуло с неба по башке; я даже не поверил сначала, что это оно – показалось мороком усталого мозга. И оно работает не только для четырех чисел – можно решить задачу «из n последовательных чисел вычеркнуто k различных чисел, требуется вернуть остаток» (что осталось на трубе).

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

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

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

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

Меня зовут Дмитрий Дербин – frontend-разработчик компании «Криптонит». В данном материале я поделюсь некоторой теоретической базой по теме и краткими наработками для реализации на Vue 3 на примере простого сайта с погодой.

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

В данной статье рассматриваются особенности, которые связаны с обработкой нативных событий (native events) в React-приложениях. Существует проблема частичной потери контекста функционального компонента при обработке нативных событий, которые навешиваются на элементы с помощью глобальных объектов document, window или через ссылки (refs). В статье рассматривается данная проблема и предлагается способ её решения (один из вариантов).

Hello world!

Представляю вашему вниманию вторую часть обновленного руководства по Next.js.

• Первая часть
• Третья часть
• Руководство целиком

На мой взгляд, Next.js — это лучший на сегодняшний день инструмент для разработки веб-приложений.

Предполагается, что вы хорошо знаете JavaScript и React, а также хотя бы поверхностно знакомы с Node.js.

Обратите внимание: руководство актуально для Next.js версии 14.

При подготовке руководства я опирался в основном на официальную документацию, но в "отсебятине" мог и приврать (или просто очепятаться) 😁 При обнаружении подобного не стесняйтесь писать в личку 😉

Парочка полезных ссылок:

• Официальные примеры использования Next.js
• Классные туториалы по разработке веб-приложений с помощью Next.js

Я не разбираюсь в крипте от слова "совсем". И как-то через знакомых на меня вышли ребята-криптовалютчики, которые сделали свою монету на основе Solana и хотели на сайте настроить автоматическую покупку этих самых монет за SOL (надеюсь, правильно сформулировал). Сам сайт у них на конструкторе webflow и в целом код для создания и отправки транзакций у них был написан. Однако была проблема, что вылетали ошибки при попытке подписать и отправить транзакцию через Phantom Wallet. Короткая статья о том, как я с этим разобрался.

В данной статье я бы хотел провести последний отчёт по быстродействию Cample.js. За два года работы над фреймворком, сложились небольшие результаты, которые я бы хотел рассмотреть.

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

В прошлом, вышли отчёт № 0 и отчёт № 1, в которых я в похожей манере проводил тесты фреймворка, в этом же отчёте, я думаю, заострить внимание больше на результаты работы.

Все результаты тестов основаны на показателях keyed реализации в репозитории js-framework-benchmark в github. Сами они располагаются на странице выпуска №123.

A: Не думай о помощи.
Б: Сложно не думать о помощи, когда пишешь на javascript.

Примерно такой диалог я слышал на одной из конференции. Решить проблему отсутствия строгой типизации был призван typescript.

Конкретно в этой статье я хотел бы рассмотреть один из приемов использования интерфейсов typescript, который мне кажется неочевидным, его я подсмотрел и смог оценить его преимущества в процессе написания приложений на языке golang.

Для большинства typescript разработчиков типы и интерфейсы, не имеют как таковой большой разницы.

Среду выполнения и движки часто ошибочно называют одним и тем же.

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

На прошлой неделе впервые поучаствовал в конференции по Frontend, где один из докладчиков, расказывал, как удачно его команда переехала с Redux на Mobx. Главным преимуществом он назвал отсутствие бойлерплейта и ускорение разработки в полтора раза.

Я прочитал несколько статей и посмотрел другие доклады, где все как один говорят, что Mobx лучше, чем Redux. Возможно это и так, но почему в сравнение всегда идет Redux, а не Redux-Toolkit, я не понимаю. Попытаемся конструктивно посмотреть действительно ли Mobx настолько хорош как о нем говорят.

Многие могут усмехнуться при мысли о запуске очередного фреймворка JavaScript, учитывая множество уже существующих проверенных решений. Зачем браться за создание нового?

Давайте я расскажу свою личную историю о том, что подтолкнуло меня к разработке этого фреймворка JavaScript. Однако, если мой путь к созданию не вызывает интереса, вот краткий обзор (TLDR):

Для преодоления ограничений функциональности блоков мы воспользуемся модом Sheeptester для Scratch, который позволяет подключать внешние расширения, написанные на JavaScript. Хорошей новостью является то, что писать такие расширения несложно даже в случае обладания минимальными знаниями JavaScript, HTML и CSS. Давайте взбодрим кота программным кодом для получения кодоблочной (или котоблочной) среды разработки.

Если вбить слово «фронтенд» в поисковую строку, можно найти огромное количество курсов по данному направлению. Проблема в том, что все курсы являются платными и, как правило, имеют ценник в несколько десятков тысяч рублей. 

Чтобы разбавить засилие платных курсов, мы подготовили для вас программу обучения «Frontend-разработчик с нуля», которая состоит только из бесплатных материалов.