В этой части статьи про торгового бота мы сначала посмотрим на алгоритм сравнения двух комбинаций, а потом на разные методы сбора комбинаций в кластеры. Разберем как работает сам метод сбора кластеров и некоторые вспомогательные функции. Увидим как меняется формат данных после обработки разными методами.
На сайте https://showroom.hyundai.ru/ можно заказать машину без переплат, напрямую с завода Hyundai, но проблема в том, что машины уходят очень быстро. При этом новые автомобили появляются нечасто, и, чаще всего, можно наблюдать на сайте сообщение об отсутствии машин.
Чтобы успеть забронировать машину, напишем парсер-мониторинг для «Hyundai Showroom» с выгрузкой в телеграм-канал, который будет уведомлять о том, появились ли машины в шоуруме.
Все началось несколько лет назад со школьного проекта по Computer science. Моя идея была сделать компьютерную программу которая проанализирует историю рынка, определит комбинации из 4х свечей в кластеры по схожести, запомнит какая свеча шла после этой комбинации и в дальнейшем сможет найти кластер для реальной ситуации на рынке. На странице должна быть отображена ситуация на рынке, найденый кластер комбинаций и его статистика. Если в кластере большой процент комбинаций с последующей зеленой свечей - мы ставим на рост, и соответственно наоборот.
Изначально в качестве API для программы был выбран Forex Oanda. На тот момент это был единственный найденный нами брокер с Open API и кое-какой документацией. В планах сервер который работает с API и фронт для отображения работы
(на тот момент) индикатора, поэтому пишем на Node JS. Проект был доведен до логического завершения, он исправно находил похожие комбинации и собирал их в кластеры, был сделан интерфейс который изображал полу-статичную информацию. Однако протестировать все это мы так и не успели, забросив все после сдачи проекта.
Перевод статьи Alister Scott: Five reasons why Playwright is better than Cypress
На основании проведенного сравнения, могу смело рассказать о причинах, почему Cypress все еще проигрывает конкуренцию.
Привет, друзья!
На досуге разработал шаблон Node.js-сервера для аутентификации/авторизации, которым хочу с вами поделиться. Надеюсь, кому-нибудь пригодится.
Обратите внимание: шаблон — это всего лишь хорошая отправная точка, с которой можно начать разработку собственного сервиса. Он не предназначен для использования в продакшне как есть, поскольку настройки, определяющие гибкость его архитектуры и уровень его безопасности, зависят от потребностей конкретного приложения и должны быть реализованы вручную.
Также обратите внимание, что в коде имеется несколько console.log для облегчения процесса разработки приложения. В продакшне они не нужны. В производственном режиме также не следует возвращать столь информативные message.
Если возможностей, реализованных в шаблоне, окажется недостаточно, вот парочка более продвинутых инструментов:
oidc-client — разработчик отказался от дальнейшей поддержки, новый мейнтейнер пока не нашелсяoidc-provider — рекомендация моих более опытных коллегЕсли вас интересует полноценная платформа для аутентификации/авторизации "из коробки", рассмотрите возможность использования Auth0.
Сервер реализован с помощью Express.js
В качестве базы данных используется MongoDB Atlas
Как безопасно и без лишнего труда открыть доступ к этим учетным данным и использовать их при разработке на Node.js? Ответу на этот вопрос посвящена эта статья.
Содержание:
Подключение к экземпляру Kafka
Безопасная передача учетных данных
Привязка сервиса в Kubernetes
Простота использования привязок сервисов с помощью kube-service-bindings
Настройка привязки сервисов в OpenShift
Node.js и Apache Kafka: дополнительные ресурсы
Node.js имеет несколько способов исполнения CPU-bound заданий:
1. Просто запустить CPU-bound задачу в одном процессе, блокируя event loop. Кто-то может возразить, что это совсем не вариант, но если этот процесс был специально создан для этой задачи, то почему бы и нет. Правда не у всех есть пара дополнительных ядер.
2. Создать отдельные процессы (Child Processes), распределить между ними задания.
3. Создать cluster и заставить работать отдельные процессы в нем.
4. Использовать Worker Threads и создать несколько дополнительных потоков исполнения.
5. Попросить C++ разработчика написать C++ Addon, который загадочным образом выполняет CPU-bound задания. В конце концов, думаю все слышали старинные легенды про компилируемые языки программирования и о том, что “нативная” реализация ― это всегда успех (на этой фразе где-то в мире должен заплакать React Native разработчик, смотря на перформанс своего приложения).
Зачем вам это нужно?
При разработке кода на стороне сервера время от времени возникает проблема, которую очень трудно воспроизвести, наблюдаются утечки памяти или скачки процессора, которые вы не можете смоделировать локально, либо необходимо добавлять специальные журналы в приложение. При локальной разработке приложения используется инспектор Node.js для отладки и создания снапшотов памяти/процессора, которые помогут вам найти проблему, но как сделать то же самое в удаленной среде? К счастью, Node.js располагает отличной поддержкой для удаленной отладки, и в этой статье мы рассмотрим, как использовать ее в kubernetes.
Авторизация в системах одна из ключевых частей. Можно использовать какие то мощные решения, Firebase например, или что то из множества хороших библиотек. Если хочется уменьшить количество зависимостей или для самообразования - то можно написать свое.
Данное решение с использованием Nginx и Node.js приложения. Все описанное является очень частным случаем используемого подхода, в том смысле что есть некоторые условия в которых требовалось создать решение, и данный вариант реализации хорошо подходит только в в этих условиях.
Давайте представим, что есть кандидат, и у него есть несколько этапов найма (интервью с hr, техническое интервью, согласование с руководством и тд.). По некоторым этапам HR сотруднику приходилось руками передавать информацию по кандидату в разные чаты, что неудобно и требовало время и внимание HR. Поэтому появилась идея это автоматизировать.
Добрейшего времени суток %HABRUSER% и проходящим мимо, в первую очередь я очень рад что ты открыл эту статью, без шуток :)
Данная серия публикаций посвящена созданию сервиса runwith суть которого вы сможете почитать ниже. Это мой первый независимый проект, поэтому буду очень рад вашим комментариям и конструктивной критике касаемо стиля написания статьи и кода в целом, надеюсь тебе будет полезно и интересно, приятного чтения!
Если вы используете монорепозиторий, то взаимодействие между клиентом и сервером с общей моделью данных будет проблемой. Без обслуживания дублирование кода приведет к рассинхронизации.
Если модель данных изменяется на серверной части - убедитесь, что клиентский код подхватит эти изменения. Иначе клиентский код сильно пострадает при получении несовместимых данных, либо из-за игнорирования дополнений. А это не то, чего вы хотите.
Давайте рассмотрим стратегии синхронизации клиентского и серверного кода.
Я думаю, все, кто использует node.js, понимает про что эта картинка.
npm - это ужасный менеджер пакетов. В этом признавался даже сам создатель node.js. Npm для каждого вашего проекта создает папку node_modules, в которую он качает из интернета и сохраняет на диске каждый пакет из всей иерархии зависимостей.
Если у вас 100 проектов с одними и теми же зависимостями, то npm 100 раз скачает из интернета и сохранит на диске 100 копий одних и тех же пакетов. Ему плевать. Популярный yarn, к сожалению, делает то же самое.
Всем доброго времени суток.
В данной статье я решил поделиться опытом, накопленным за многие годы работы во front-end`е. Как и все вы, я был молод и мечтал создать что-то бессмертное. Ах, как я был молод, и как же я был глуп. Ничего вечного не существует и всё рано или поздно умирает. Однако, можно создать то, что протянет гораздо дольше обычного и даже будет адаптироваться к изменениям какое-то время. Поэтому сегодня предлагаю поговорить о паттернах проектирования для front-end приложений, выборе технологий и о том, чего делать не стоит. В этой статье буду проводить много аналогий со строительной тематикой и причиной тому небезызвестная история: «Если бы программисты строили дома».
Из чего строить?
Тут как бы все просто, но не всегда явно. Как говорится, давайте разбираться. Суперновые технологии с прорывными идеями сразу мимо. Вы меня спросите почему? Так давайте пофантазируем на тему того, что вы взяли их в проект: через года полтора сам проект не получил поддержки сообщества, а его создатель забил на него. Вы остались с нерелевантным стеком, отсутствием возможности найти разработчиков для создания кода и дальнейшей поддержки проекта. Нет обновлений, читай через два года у вас на руках старая коричневая субстанция.
Посмотрим и на обратную сторону медали: беря сверхнадежное решение, которому много лет, вы обрекаете проект на скорый апдейт или умирание. Знавал я одну крупную компанию, которая использовала java 8. Мотивация звучала так: она надежна как швейцарский нож. На минуточку, на дворе 2021 год и она устарела не только морально, но и технически (на момент написания, актуальной версией является java 17).
Встречался с различными парсерами JSON. Когда то было сложно сразу преобразовать дату в тот объект который хочется, иногда Enum жил своей жизнью. И вот не давно повстречал один Фреймворк для NodeJS. Речь пойдет про Ts.ED.
Нативная поддержка JSON одно из преимуществ разработки full-stack JavaScript приложений. JSON является простым, не требующим схемы и человекочитаемым - качества особенно ценимые на ранней стадии разработки, когда ваша модель данных подвержена частым изменениям. Однако за все надо платить, а именно размером и скоростью обработки данных.
JSON будучи текстовым форматом кодирует все значения как UTF-8, что приводит к увеличению размера данных при работе с нетекстовыми данными. Отсутствие схемы означает, что мы должны кодировать нашу структуру данных (ключи объекта) вместе с самими данными. Мы также делаем дополнительную работу при обработке данных, поскольку нам необходимо преобразовать бинарные данные в их текстовое представление до превращения в JSON и соответственно наоборот в случае декодирования.
Привет, друзья!
В этом небольшом туториале я хочу показать вам, как разработать простой, но довольно-таки полноценный сервер для тестирования API.
Основной функционал нашего приложения будет следующим:
GET, POST, PUT и DELETE запросов к любому существующему проекту, включая GET-запросы, содержащие параметры и строки запроса;sort, order, limit и offset;Наша админка будет выглядеть так:
Для быстрой стилизации приложения будет использоваться Bootstrap.
Разумеется, с приложением, которое мы с разработаем, сразу в продакшн не пойдешь, но при необходимости довести его до производственного уровня не составит труда.
При разработке приложения мы будет придерживаться 2 важных условий:
JSON;Обратите внимание: статья рассчитана, преимущественно, на начинающих разработчиков, хотя, смею надеяться, что и опытные найдут в ней что-нибудь интересное для себя.
Вы готовы? Тогда вперед.
Рассмотрим следующую задачу. Нам необходимо делать вызовы стороннего API, которые считаются дорогими, и, следовательно, их необходимо кешировать в Redis. Мы используем современный NodeJS (версии 14+), а значит и конструкции async / await.
Напишем сначала класс обертку над вызовом API, где сам вызов будем эмулировать 2-секундным таймаутом.