JavaScript *

UPD: приложили запись докладов и слайды

Привет, Хабр ? Меня зовут Михаил Подгорный и я руковожу отделом Frontend платформы в Ozon. В нашей компании уже около 500 фронтенд-разработчиков, силами которых было создано более 400 веб-приложений. Мы пишем на TypeScript и Vue, шаблонизируем на JSX, для тестов используем Jest и Playwright. Контейнеризация через Docker, разворачиваем через GitLab и K8s, а следим за всем с помощью Grafana, Prometheus, Thanos, Graylog, Sentry и собственных решений.

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

Приглашаю в гости на открытый Frontend Meetup Ozon Tech, который состоится 27 октября в 18:00.

Привет, друзья!

В продолжение разговора, начатого в этой статье, хочу рассказать вам еще о некоторых API, которые редко встречаются в "дикой природе", но могут оказаться весьма полезными в "пограничных ситуациях":

• Beacon API
• Clipboard API
• Notifications API
• Performance API

Репозиторий с примерами.

Всем привет. Меня зовут Ярослав Карманников, я разработчик команды SmartTV/Web в онлайн-кинотеатре KION МТС Digital. Это четвертая часть сериала, посвященного фиче Autoplay в нашем кинотеатре. Сегодня обсудим нюансы реализации фичи на платформе SmartTV: я расскажу о том, как мы внедряли автоплей, с какими трудностями столкнулись и как их решали.

Добро пожаловать под кат!

В прошлых частях цикла мы:

- рассмотрели базовые концепты работы с многопоточностью в JavaScript на примере среды Node.js;

- научились формировать общую очередь и каналы обмена данными и сигналами, чтобы более эффективно управлять загрузкой потоков;

- использовали разделяемую память и Atomics-операции как самое быстрое средство обмена большими блоками данных;

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

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

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

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

Кто заинтересован - добро пожаловать под кат.

Вдохновившись документацией MDN, которая позиционирует себя как - Resources for Developers, by Developers, я решил сделать серию статей «От новичка, для новичков», где попытаюсь максимально простым языком рассказывать о разных концепциях в программировании, в основном связанных с JavaScript. Я буду стараться избегать технически-сложного контента, или буду максимально его упрощать.

Это первая статья серии, будет посвящена событийно-ориентированной парадигме применительно к Node.js, а также паттерну «EventEmitter».

 P.S. Рассчитываю на конструктивную критику читателей! Всегда буду рад обратной связи. Не стесняйтесь указывать на ошибки или хвалить, пишите в комментариях и в личку. Особенно буду благодарен если вы предложите темы для статей!

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

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

Но почему-то, в случае с регэкспами у программистов как будто появляется слепое пятно на чувстве стиля. Вот такая регулярка – совершенно обычное дело:

/^(0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])[- /.]((19|20)\d\d)$/

Тестирование приложений через сквозные (end-to-end) тесты сейчас довольно популярно. Этот вид тестирования позволяет оценить работоспособность приложения со стороны пользователя. Поэтому компания, в которой я работаю, внедряет этот вид тестирования в проекты.

Летом 2022 года мы разрабатывали блокчейн приложение. Моя задача заключалась в проведении E2E тестирования DApp [Децентрализованное приложение — приложение, которое базируется на технологии блокчейн совместно с механизмом распределенного выполнения необходимых инструкций]. Но мы столкнулись с проблемой - готовых решений для проведения end-to-end тестирования DApp под нашу конкретную задачу не было. Эта статья о том, как мы решали эту проблему.

Создадим приложение с использованием фреймворка Next.js, настроим облачные сервисы Amazon S3, Amazon CloudFront, AWS Lambda@Edge, развернем приложение и настроим маршрутизацию доменного имени.

Привет, друзья!

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

Дорогой React, мы встречаемся уже почти 10 лет. Мы прошли долгий путь вместе. Но ситуация вышла из-под контроля. Нам нужно поговорить.

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

Правильное решение - это со старта внедрять бухгалтерию с двойной записью (double ledger).

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

Есть MVC-приложение на frontend, которое активно расширяется:  создаются новые модели, представления и контроллеры.
Со временем такое приложение начинает напоминать лабиринт из моделей, а баги, живущие в этом лабиринте превращаются в настоящих минотавров. Но все не так плохо, похоже есть нить, которая ведет из этого лабиринта…

Всем привет! Сталкивались ли вы с ситуацией, когда в вашей админке пользователям трудно интуитивно разобраться, возможности быстро исправить это нет, а существующую документацию по ней никто не читает? Знакомы ли вам частые вопросы вида "А как это настроить?" или "А можно ли сделать настройками X?", ответы на которые уже описаны?

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

Реализация автоматического импорта событий из календаря Notion в свой Google Calendar. Также, под катом, ссылка на npm пакет, упрощающий данную процедуру и пример запуска данного решения без аренды своего сервера.

Идея создать проект «По местам съёмок фильма «Брат» пришла спонтанно, когда я собирался в поездку в Санкт-Петербург. Подумал о том, что я могу объединить профессиональные знания в картографии и своё почтительное отношение к фильму, тем более, что совсем недавно было 25 лет со дня выпуска фильма. Стандартные туристические маршруты надоели. Мне не нравится гулять там, где ходят толпы туристов, делая одни и те же фотографии.

Первый этап — это понимание того, где конкретно снят тот или иной фрагмент. Информацию искал в интернете, но многие точки были описаны очень неконкретно. Двор на такой-то улице или Морская набережная, 15Б, а по факту этот дом на 29 подъездов. Приходилось на месте искать точки съемки и делать фото, потом уточнять точки в геоинформационной программе на карте QGIS.

В голове почти любого человека начиная с 2018-2019 года появляются мысли о том, чтобы поменять профессию на что-то около IT. Эти мысли сразу разбиваются о скалы нескольких больших мифов.

Я люблю сталкиваться с трудностями. Но с такими, которые можно решить, подумать над интересным решением, подобрать технологию. Люблю быть в потоке, а после решения чувствую себя настоящим профессионалом.

Но есть кое-что, из-за чего я не люблю программировать. Как ни странно, это тоже трудности, только другого рода. Например, когда, чтобы пофиксить баг, приходится разбираться с легаси-компонентом, который написан на классах на 300 строк кода. Разбираясь уже второй час, ловлю себя на мысли, что уже 10 минут просто смотрю в экран, а в голове «из-за угла» выглядывает мысль «Псс, парень, программирование — это не твое». Такие задачи не вызывают удовлетворения.

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

Привет, друзья!

Представляю вашему вниманию перевод этой замечательной статьи, посвященной 4 малоизвестным API, которые в некоторых ситуациях могут оказаться весьма полезными:

• Page Visibility API;
• Web Share API;
• Broadcast Channel API;
• Internationalization API.

Код примеров на GitHub.