При разработке приложений регулярно возникает задача кэширования каких-то данных, которые из хранилища должны читаться много чаще, чем писаться. Давайте рассмотрим на примере простого теста, когда и на каком механизме эффективнее организовать его для 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.
Привет, Хабр. Так получилось, что по специальности я программист, а по призванию — поэт. Не просто рифмую палку с селёдкой, а публикуюсь в литературных журналах, взял парочку небольших премий — в общем, это немного больше, чем хобби.
Иногда хочется как-то объединить эти две стороны своей жизнедеятельности. Написать скрипт четырёхстопным ямбом. Или наоборот — скрипт, который напишет четырёхстопный ямб. Обычно это желание мимолётно и ни к чему не ведёт. Но недавно мне очень захотелось написать биткоин-стихотворение — и я это сделал.
Ниже вы сможете познакомиться с моим великим творением и историей его создания, а также выяснить, что это вообще за ерунда — биткоин-стихотворение, и чем оно полезно народному хозяйству. Я постараюсь, чтобы статья была интересна и понятна как моим коллегам-программистам, так и моим коллегам-литераторам.
Hello, world!
В этом туториале мы разработаем простое типобезопасное (typesafe) клиент-серверное (fullstack) приложение с помощью tRPC, React и Express.
tRPC позволяет разрабатывать полностью безопасные с точки зрения типов API для клиент-серверных приложений (предпочтительной является архитектура монорепозитория). Это посредник между сервером и клиентом, позволяющий им использовать один маршрутизатор (роутер) для обработки запросов HTTP. Использование одного роутера, в свою очередь, обуславливает возможность автоматического вывода типов (type inference) входящих и исходящих данных (input/output), что особенно актуально для клиента и позволяет избежать дублирования типов или использования общих (shared) типов.
Руководство по tRPC находится в процессе подготовки — следите за обновлениями ?
Для тех, кого интересует только код, вот ссылка на соответствующий репозиторий.
Интересно? Тогда прошу под кат.
Привет, я Влад, и это статья о том, как перемена обстановки повлекла за собой кардинальные изменения в механизме расчета моего бюджета и дальнейшую разработку средства его подсчета.
Для многих разработчиков процесс установки зависимостей представляет собой некую "магию", которая происходит при выполнении npm install. Понимание принципов работы этой "магии" может сильно помочь при возникновении ошибки во время установки очередной библиотеки. Нынешний NPM — результат многих лет проб и ошибок, поэтому для его детального понимания я предлагаю начать с самого начала.
Недавно после очередного копирования файлов react-компонентов из проекта в проект я решил что хватит это терпеть и пора научиться публиковать npm-пакеты. Прошерстив интернет в поисках простого рецепта, который позволял бы с минимальными усилиями сделать пакет из react-приложения, я нашел несколько рабочих вариантов. Но, к сожалению, все они имели различные недочеты. Поэтому мне пришлось вооружиться напильником и составить эту памятку по результатам своих манипуляций.
Очень хочется пошутить про пакет с пакетами. Но нет. Статья про другое. Для начала давайте разберемся, почему я ее написал, и кому она может быть полезна:
Всем привет, меня зовут Виталий, я являюсь Test automation engineer и по совместительству один из создателей библиотеки который называется sqrt.app. В IT-сфере я около 6 лет и успел повидать много говна решений но сегодня я бы хотел рассказать про то - зачем любому инженеру будет полезно использовать данный тул.
