JavaScript *

Привет. Меня зовут Николай Шувалов, я занимаюсь коммерческим программированием около семи лет, владею Rust, JavaScript, PHP. Сейчас я работаю в отделе данных билайна. Наша платформа позволяет делиться с партнерами данными, не раскрывая их. Например, можно расширить данные с помощью фильтра Блума. 

Arrow в сравнении со строковыми форматами

Возьмём простую таблицу, которая состоит из трех столбцов: телефона, даты и имени. Рассмотрим, как она будет выглядеть в строковом и столбчатом форматах. Для строкового формата мы возьмем csv и json, для столбчатого формата структура будет одинаковой. Если же таблица состоит, например, из миллиона строк, а нужно получить имя на строке с номером 10 000, то придется бежать по всей строчке. В json то же самое. А в столбчатом формате ситуация иная — значения привязаны к столбцам. Когда мы хотим получить имя на строке 10 000, то сразу обращаемся к этому столбцу и получаем все его данные. 

Существуют RA (random access) файлы, в которых можно пропускать заданное количество строк, но все равно парсеру нужно читать и анализировать пройденные строчки.

Привет всем любителям size coding, сегодня я расскажу о чём-то потрясающем: крошечном движке трассировки лучей (raycasting) и генераторе города, умещающихся в автономном файле HTML размером 256 байтов.

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

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

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

Мне в голову пришла идея пет-проекта, который изначально никак не был связан с текстовым редактором. Однако, в процессе работы все дошло до того, что пользователям нужно где-то набирать текст. Я люблю Notion и пишу там много и часто, поэтому решил сделать похожий (но сильно упрощенный) редактор в своём проекте. Не столько из нужды, сколько из любопытства, ведь я никогда не занимался ничем подобным и мало что знал о том, как писать текстовые редакторы.

В статье хочу рассказать про атрибут contenteditable у HTML-элементов, про сопутствующие проблемы при его использовании, про кастомное форматирование и про работу с выделенными участками текста.

Всем привет! Меня зовут Иван Кузнецов, я Head of Frontend в Uzum Market. Расскажу о сложностях, с которыми мы столкнулись на пути к реализации микрофронтендовой архитектуры, и поделюсь результатами, которые мы получили в процессе пакетирования наших решений с помощью Lerna. Надеюсь, тебе, дорогой читатель, будет очень интересно :)

Программа обучения Frontend-разработке.

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

Frontend-разработчик обеспечивает взаимодействие пользователей с веб-приложением, создавая удобный, интуитивно понятный интерфейс, который обеспечивает приятный опыт использования.

Только что завершилась Конференция React.js. Долгожданная конференция спустя почти 3 года после предыдущей. Не менее долгожданны и обновления реакта. И именно с них была начата конференция, им и будет посвящена статья. И да, как вы увидели из превью — 19 версия перешла в статус release candidate. Полноценный же релиз нам обещают в течении двух недель.

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

Можно сказать, что главным направлениям этого обновления было достижение «Высокого UX при высоком DX». Максимальная производительность при максимально простом коде. И так, а теперь к самой конференции.

Веб-разработка часто требует реализации механизмов обновления контента на странице в реальном времени. Существуют различные сценарии, где это необходимо, например, отображение прогресса выполнения тяжелых задач на бекенде, обновление каких-либо часто меняющихся данных, будь то курсы валют или мониторинг какой-то активности, чаты, различные уведомления. Эти сценарии объединяет одна общая особенность: источник события необходимости обновления данных находится не на клиентской стороне, поэтому мы хотим получать события с бекенда. В данной статье мы рассмотрим четыре популярных подхода к реализации этой функциональности: WebSocket, Server-Sent Events (SSE), Long Polling и Short Polling.
Мы проанализируем каждый метод, выявим их плюсы, минусы и сложность реализации.

Наш браузер Ladybird неплохо справляется с качественно отформатированным веб-контентом, но я решил, что будет полезно проверить его инструментами для исследования безопасности. Поэтому сегодня мы воспользуемся Domato 🍅 — DOM-фаззером из Google Project Zero, чтобы провести стресс-тест Ladybird и устранить найденные в процессе ошибки.

Работает это следующим образом: Domato генерирует рандомизированные веб-страницы со множеством по большей части валидного, но странного HTML, CSS и JavaScript. Я загружу эти страницы в отладочную сборку Ladybird и посмотрю, что получится.

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

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

Планируется, что Angular 18 будет выпущен в мае 2024 года, и уже есть несколько подтвержденных функций для включения в предстоящую версию, которые мы рассмотрим в данном материале.

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

В процессе нашей миграции на Nuxt CAPI, а потом и Nuxt 3, я очень много переосмыслял работу с контекстом как в Vue, так и в Nuxt. Как он сохраняется, на что влияет, и как можем повлиять мы.

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

Что? Какой контекст? В setup нет this. Как его можно потерять? На что это влияет? Давайте про это поговорим.

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и то как фронтендеры пишут очередную статью про this.

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

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

Hello world!

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

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

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

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

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

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

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

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

Мы занимаемся сбором данных с ИПУ в многоквартирных домах. Наше предпочтение - проводное подключение. Обычно мы подключаем одинаковые типы счетчиков в один канал - Вода, Газ, Электричество.

Однажды к нам перешел дом, на котором в качестве счетчиков электричества стояли "Меркурий 203.2ТL". Особенность этих счетчиков в том, что они используют в качестве интерфейса опроса - CAN шину. И тут важно уточнить, что именно только CAN шину, ничего более от CAN там нет. То есть, если вы купите преобразователь Ethernet<->CAN по типу USR-CANET200 - работать у вас ничего не будет. Причина в том, что подобные преобразователи используют кадры CAN для общения между устройствами, но разработчики счетчиков "Меркурий 203.2ТL" вертели на своем вертеле все это и просто поставили внутри драйвер CAN<->UART.

Преобразователей, способных просто работать в чистом виде по CAN, не так уж и много.

Скажу честно, мы не любим зависимости, поэтому пошли своим путем. Была приобретена Orangepi Zero, USB<>SerialTTL, TTL<>CAN. Все это было слеплено вместе в один преобразователь Ethernet<>CAN. Сразу скажу, что мы пробовали несколько разных драйверов CAN и на практике они оказались довольно капризными, мы пришли к выводу, что лучше использовать драйвер VD230 с UsbSerialTTL-CH340G.

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

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

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

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

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

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

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