В публикации речь идет о warnings и vulnerabilities при установке библиотек с помощью yarn и о том, как от них избавиться. Я рассмотрел несколько случаев, приведенных ниже, но решения можно применять и к другим, схожим ситуациям:
Warnings типа:
has incorrect peer dependency
has unmet peer dependency
Vulnerabilities:
Prototype pollution in webpack loader-utils
loader-utils is vulnerable to Regular Expression Denial of Service (ReDoS)
Crash in HeaderParser in dicer
В этой статье я покажу как взаимодействовать с публичным тестовым Ethereum блокчейном при помощи только библиотеки web3.js и терминала. Ethereum Testnet это уже приближенный к реальной сети Mainnet блокчейн со множеством нод и независимыми аккаунтами. Мы научимся пополнять баланс тестовыми Ether при помощи Faucet, а так же находить информацию об аккаунтах и транзакциях в обозревателе блокчейна Etherscan. Всю ту же информацию мы получим и при помощи консоли. На всякий случай: в посте будет много картинок.
Требовалось кешировать используемые в разных проектах NPM пакеты (+ хранить свои пакеты) на отдельном сервере.
Было решено делать это с помощью репозитария Verdaccio (по нему есть достаточно хорошая офф. дока), крутится это все должно в Docker, а разворачиваться на отдельном сервере через GitLab CI/CD.
Т.к. реализация данной схемы заняла у меня некоторое время (Хотелось бы и по меньше), решил написать короткий туториал по этой теме, с описание нюансов, которые для меня казались не очевидными.
На дворе 2023 год, и мы выпустили Node.js v20. Это значительное достижение, и цель этой статьи — использовать научную оценку состояния производительности Node.js.
Все результаты бенчмарков содержат воспроизводимый пример и описание аппаратного обеспечения. Чтобы уменьшить количество шума для постоянных читателей, воспроизводимые шаги будут свернуты в начале всех разделов.
Цель этой статьи — предоставить сравнительный анализ различных версий Node.js. Она подчеркивает улучшения и недостатки, а также дает представление о причинах этих изменений, не проводя никаких сравнений с другими рантаймами JavaScript.
Как я сделал удобный автодеплой ui-kit на npm с помощью pipeline's gitlab.
Что удалось сделать?
• Автоматическое обновление версии пакета при пуше изменений.
• Автоматический деплой новой версии на npm.
В предыдущей статье я рассказал как установить окружение для ознакомления с библиотекой web3.js. Тогда мы использовали ethereum-блокчейн Ganache и библиотеку Truffle. В данной статье я покажу как формировать ethereum-транзакцию используя только библиотеку web3.js и Ganache, без использования библиотеки Truffle. Мы сформируем транзакцию вручную, выполним её подписание и отправим в блокчейн. Посмотрим на тело сериализованной и подписанной транзакции в том виде, в котором она передаётся в ethereum-блокчейн (raw transaction).
Существует множество библиотек для настройки алиасов в Node.js, таких как alias-hq и tsconfig-paths. Однако однажды, изучая документацию Node.js, я обнаружил возможность настройки алиасов без использования сторонних библиотек. Более того, данный подход позволяет использовать алиасы без сборки кода. Знакомо ли вам поле imports в package.json? В этой статье мы рассмотрим, что такое Node.js Subpath Imports, узнаем о тонкостях настройки и разберемся с поддержкой в актуальных инструментах разработки.
Наверное, не многие об этом задумываются, но выбор логгера для многопользовательских веб-приложений играет важнейшую роль — из-за обработки ими большого количества запросов в секунду. По этой причине система логирования должна быть максимально быстрой.
Pino — это мощная платформа ведения логов для Node.js, обладающая молниеносной скоростью и широкими возможностями. Фактически именно скорость Pino и завоевала ему место логгера по-умолчанию в open-source веб-сервере Fastify. Также Pino способен очень просто интегрироваться с другими Node.js-фреймворками, что делает его лучшим выбором для всех разработчиков, ищущих надежное и гибкое решение для ведения логов.
При разработке приложений регулярно возникает задача кэширования каких-то данных, которые из хранилища должны читаться много чаще, чем писаться. Давайте рассмотрим на примере простого теста, когда и на каком механизме эффективнее организовать его для JavaScript-приложения - на Map или на Object.
Допустим, у вас есть идея нового проекта, который обязательно завирусится, как только он увидит свет. Однако вы не можете решить, какой же бэкенд-фреймворк вам стоит использовать. Не нужно отчаиваться. В этой статье мы рассмотрим три популярных Node.js фреймворка (Express.js, Koa.js, Fastify) и сравним их производительность, чтобы вы могли решить, какой из них лучше подходит для вашего проекта. Для замеров производительности мы будем использовать серверы с двумя простыми конечными точками. Первая конечная точка будет возвращать пустой ответ. Вторая – вычислит ряд Фибоначчи в зависимости от входных данных, которые мы предоставим, а затем вернет последовательность. Файлы конфигурации, используемые в этой статье, вы можете найти в этом репозитории. Перед бенчмаркингом давайте более подробно изучим наши фреймворки.
Я являюсь создателем проекта, который кормит меня уже больше четырех лет.
Проект находится в открытом доступе и распространяется по лицензии MIT. К сожалению, он так и не дорос до широкой публики, по причине того, что у меня не остается времени на его разработку.
Иногда приходится наблюдать статьи про разного рода автоматизацию - умный дом, локальная автоматизация, работа с разными устройствами. Каждый раз в голове всплывает мысль, что люди бы могли использовать мой проект для реализации своих идей, у меня уже все готово для этого.
Мой слог очень тяжел, писать статьи мне дается очень тяжело и все мои попытки написать полноценную статью приводили к краху. Было решено остановиться на том, что есть и опубликовать вариант, который бы меня минимально устроил.
Существует расхожее мнение, что мы, как разработчики программного обеспечения, тратим 90% нашего времени на отладку и только 10% непосредственно на написание кода. Конечно, это соотношение слишком преувеличено! Но это правда, что отладка занимает значительную часть нашего рабочего времени, особенно в эпоху расцвета микросервисных архитектур. На сегодняшний день уже никого не удивишь тем, что на наших производственных серверах одновременно работают сотни или даже тысячи микросервисов.
В современных реалиях разработки программного обеспечения бывает достаточно трудно быстро и качественно написать техническую документацию к проекту, особенно когда данному процессу уделяется недостаточно времени по разным причинам: от временных ограничений, до индивидуальной непереносимости монотонного процесса участниками проектной группы, который, порой, может тормозить рабочие процессы.
Уже сейчас существуют инструменты, которые позволяют ускорить процесс документирования программного обеспечения. Эти инструменты значительно облегчают задачи разработчиков по ведению технической документации и внесению быстрых правок, что позволяет отражать в документации актуальные положения фактического поведения системы. В данной статье будет рассмотрен один из таких инструментов.
Основное внимание в статье будет уделено автоматизации процесса создания документации API сервисов, которые разрабатываются с помощью фреймворков Express.js и Gin, используя подходящий для этой задачи инструмент - Swagger.
Об оптимизации компиляции TypeScript написано немало статей, но про один способ я не слышал и обнаружил его довольно случайно.
Некоторые библиотеки предоставляют много возможностей, из которых в вашем проекте используется от силы пара процентов. В бандл сборки они не входят благодаря tree-shaking, но жрут ресурсы во время компиляции: процессор и память.
В этой небольшой заметке я расскажу, как обнаружить прожорливые библиотеки и ускорить компиляцию.
Привет, Хабр!
Несколько дней назад в одном из обсуждений в сообществе Cypress на Discord мельком был затронут вопрос о том, как проверить данные из файла Excel с помощью Cypress. Это подтолкнуло меня сделать несколько полезных заметок, ставших основой для данной статьи.
Несмотря на относительную редкость описанного кейса и сравнительную незамысловатость подхода к его решению, я очень надеюсь, что данная статья будет полезна для совершенствования ваших навыков тестирования.
Оригинал статьи на английском языке был включен в 136th Coding Jag от LambdaTest, а также в Issue #82 Software Testing Notes.
Инструкция для получения доступа к устройству в целях получения и хранения данных с него удобным образом. Зачем? Чтобы в перспективе настроить свой Умный Дом без ограничений приложений, которые предоставляют производители.
В современных веб-приложениях асинхронные операции играют ключевую роль. Однако управление ими может быть сложным, особенно когда нужно отменить задачи, уже отправленные на выполнение. До появления AbortController разработчики прибегали к различным костылям, таким как создание глобальных переменных, которые отслеживали состояние запроса или использование оберток над XMLHttpRequest.
Всем привет! На связи Александр Разыграев, я разрабатываю модуль ESMP Metrica, а в свободное время преподаю web-разработку студентам в институте, также преподавал на курсах переподготовки.
Часть студентов во время занятия повторяют действия и код за преподавателем. Примерно треть из них часто не успевала и сигнализировала мне, например, останавливали словами: «Подождите, я не успеваю записывать код …».
Как решал эту проблему: если писали короткий пример, то брал паузу и ждал пока не успевающие перепишут код; если разрабатывали более длинный пример или одно большое приложение за занятие, то отправлял отдельный файл с кодом или весь проект приложения, например, архивом в чат или коммитами в git.
Но ощущал какую-то неудовлетворённость. Во-первых, понимал, что это не решение, а скорей экстренная помощь. Во-вторых, у меня не получалось работать на опережение, т. е. я не мог понять, как часто отправлять код, а иногда, увлекшись, забывал. Какого-то другого решения этой проблемы у своих коллег я не встречал.
В этой статье привожу свой опыт, как я ушёл от этой проблемы, написав свой раздатчик изменений кода. Статья будет полезна преподавателям IT.
Привет, Хабр!
За последние несколько лет работы с командами тестировщиков ПО в России и США мне довелось столкнуться с различными подходами к организации тестирования, разнообразными паттернами построения тестовых сценариев и разработки автоматических тестов. При этом нередко случалось, что приходя на проект и анализируя имеющуюся тестовую базу выяснялось, что существующие автотесты нуждались в серьезной доработке или вовсе переработке в целях обеспечения их надежности и сокращения времени на их выполнение. Преимущественно это касалось этапа сквозного (e2e) тестирования, и по моим наблюдениям очень часто причиной тому было не столько незнание тестировщиками встроенных команд тестового фреймворка, сколько неумение применить в тестах базовые возможности используемого языка программирования.
Это подтолкнуло меня к написанию пары статей, в которых я делюсь некоторыми наработками по оптимизации автотестов Cypress, основываясь на простых и в основном известных возможностях JavaScript. Изначально статьи были опубликованы на английском языке в моем блоге "Testing with Cypress" на Medium.
