Node.JS *

^{Я попросил нашу команду маркетинга нарисовать иллюстрацию и долго объяснял, что такое вебхуки}

Не так давно передо мной встала задача реализовать работу вебхуков в Личном кабинете владельца кассы компании Дримкас. Как оказалось, в сети практически нет описания и туториалов, как это сделать. Я расскажу, как мы это реализовали без тяжелых кронов по БД.

Статья будет полезна для middle node.js-разработчиков.

Сравнительно недавно Vue.js обзавёлся полноценной поддержкой серверного рендеринга. В интернете довольно мало информации о том, как его правильно готовить, так что я решил подробно описать процесс создания необходимой среды для разработки приложения с SSR на Vue.js.

Всё, о чём пойдёт речь, реализовано в репозитории на github. Я буду часто ссылаться на его исходники и, собственно, попытаюсь объяснить, что происходит и зачем это нужно :)

В статье будут описаны достаточно общие для SSR подходы (если вам просто нужно что-то готовое для использования, то вы можете посмотреть в сторону Nuxt.js), так что вполне вероятно, что сказанное ниже можно будет частично или полностью применить и к другим фреймворкам/библиотекам типа Angular и React.

Поток — это концепция, которая была сначала реализована в UNIX системах для передачи данных из одной программы в другую в операциях ввода/вывода. Это позволяет каждой программе быть очень специализированной в том, что она делает — быть независимым модулем. Сочетание таких простых программ помогает в создании более сложных систем путем «объединения» их в цепочку вызовов.

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

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

Модуль stream предоставляет базовый API по работе с потоками в Node.JS. Документации Node.JS вполне достаточно, чтобы разобраться в данном вопросе, но мы попытаемся составить что-то вроде шпаргалки с пояснениями некоторых моментов.

Недавно мы опубликовали материал «Промисы в ES6: паттерны и анти-паттерны». Он вызвал серьёзный интерес аудитории, в комментариях к нему наши читатели рассуждали об особенностях написания асинхронного кода в современных JS-проектах. Кстати, советуем почитать их комментарии — найдёте там много интересного.



По совету пользователя ilnuribat мы добавили к материалу опрос, целью которого было выяснить популярность промисов, коллбэков и конструкций async / await. По состоянию на 9-е сентября промисы и async / await получили примерно по 43% голосов, с небольшим перевесом async / await, коллбэкам досталось 14%. Главный вывод, который можно сделать, проанализировав результаты опроса и комментарии, заключается в том, что важны все имеющиеся технологии, однако, всё больше программистов тяготеют к async / await. Поэтому сегодня мы решили опубликовать перевод статьи про переход на async / await, которая является продолжением материала о промисах.

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

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

А нам это удобнее, т.к. номера мобильных у нас уже есть (у нас есть сотни абонентов, желающих получать уведомления :), а chat id еще найти надо, да еще и для каждого свой.

Решение: небольшой чат-бот.

Это перевод поста из официального блога JS-движка V8. Статья короткая, текста мало, больше похоже на увлекательный рассказ о проблемах, подстерегающих ни о чём не подозревающих сотрудников Google в коде V8. Речь пойдёт об ускорении обработки ES6 Прокси в V8, которое будет доступно в Chrome 62 и Node v9.x, и совсем немного о том, как лучше применять прокси для получения максимальной скорости работы.

Введение

Прокси появились в JavaScript с принятием стандарта ES2015. Они позволяют перехватывать фундаментальные операции объектов и переопределять их поведение. Прокси являются основой таких библиотек, как jsdom или Complink RPC library. В последнее время мы приложили много усилий, чтобы улучшить производительность прокси в V8. Эта статья проливает немного света на общие подходы к улучшению производительности в V8 и для прокси в частности.

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

В этой небольшой заметке я описываю как настроить REPL(read-eval-print loop) или «консоль» Node JS и при этом не потерять приятную плюшку — сохранение истории. Последние версии Node автоматически сохраняют историю между сеансами в REPL в файле ~/.node_repl_history Но есть одна загвоздка, если вы хотите настроить REPL «под себя», тогда история сеансов автоматически сохраняться прекращает.

Раньше для сохранения истории использовался отдельный пакет rlwrap(ReadLine Wrap).
Который позволяет например разукрашивать promt консоли, но при использовании rlwrap перестает работать автозавершение(autocomple) команд по клавише Tab. По этому его использовать не буду.

Кроме того в контекст REPL сразу загрузим часто используемые модули, такие как axios и lodash.

Иногда для модулей lodash или underscore используют символ подчёркивание _
В REPL этого делать не следует, так как этот символ имеет специальное значение — результат предыдущей операции.

По умолчанию если ввести

let a=1;

или любой другой код в результате которого ничего не возвращается или правильнее сказать возвращатся undefined, в консоли выведется это самое undefined, что как по мне раздражает.
За это поведение отвечает параметр
ignoreUndefined: true

Другой параметр: replMode: Repl.REPL_MODE_STRICT,.Это эквивалент 'use strict';. То есть теперь, например, не получится присвоить переменной значение без ее объявления.

Иначе говоря

b=2;

выдаст ошибку и нужно писать

let b=2;

Все параметры REPL описаны на сайте Node

Остальной код интуитивной понятен.

Несколько лет назад, когда я начал работать в Node.js, меня приводило в ужас то, что сейчас известно как «ад коллбэков». Но тогда из этого ада выбраться было не так уж и просто. Однако, в наши дни Node.js включает в себя самые свежие, самые интересные возможности JavaScript. В частности, Node, начиная с 4-й версии, поддерживает промисы. Они позволяют уйти от сложных конструкций, состоящих из коллбэков.



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

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

Тема создания ботов для Telegram становится все более популярной, привлекая программистов попробовать свои силы на этом поприще. У каждого периодически возникают идеи и задачи, которые можно решить, написав тематического бота. Для меня, как программиста на JS, пример такой актуальной задачи — мониторинг рынка вакансий по соответствующей тематике.

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

Больше десяти лет я был PHP-разработчиком, но недавно перешёл на JavaScript, используя его серверные и клиентские возможности. До этого я уже был знаком с JS. Сначала работал с jQuery, потом освоил Angular, и, наконец, начал пользоваться React.

Когда я начинал писать на PHP, я встраивал его в HTML-файлы. Получался не код, а полный бардак. Поэтому, для того, чтобы привести мои разработки в приличный вид, я начал пользоваться фреймворками, в частности, ZF1 и ZF2. Через некоторое время подход, при использовании которого начинают разработку с API, привёл к тому, что у меня оказался сервер, состоящий из сгенерированных REST API и из нескольких сотен строк моего собственного кода.



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

Сегодня я расскажу, в основном, о своём путешествии с серверной стороны PHP на серверную сторону JS в виде Node.js. Здесь я не буду рассказывать о Webpack, React и о других клиентских технологиях JS.

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



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

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

Сегодня мы начнём с того, на чём обычно заканчиваются другие материалы по автоматизации браузерных тестов с помощью Selenium для Node.js. А именно, мы расскажем о том, как повысить надёжность тестов и «отвязать» их от непредсказуемых явлений, которыми полны браузеры и веб-приложения.

Герои сериала «Шерлок»

Привет! Я Алексей Тимин, инженер из команды локализации Badoo. В этом посте я расскажу вам о том, как мы помогаем переводчикам в их нелёгком труде, и о новом Open Source-решении, позволяющем генерировать скриншоты дизайна, подготовленного в Sketch, для разных языков.

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

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

• Логики – это программисты с классическим флёром. Чтобы познакомиться с новой технологией они идут и читают документацию. Четкость кода – повышенная, ни шага влево, ни шага вправо. От забора и до обеда. Непритязательность к удобству работы с кодом пугает – кажется, что они могут работать и с минифицированным кодом, пользуясь одной только функцией поиска.
• Визуалы – это люди, подходящие к коду более творчески, абстрактно. Чтобы изучить технологию они идут в youtube и смотрят видео про дельфинов уроки. В коде им важно разделение на осязаемые блоки, отсутствие простыней на 1000+ строк, возможность реализовать по-новому. Выполняя новую задачу они будут пристреливаться и искать свой вариант решения вместо поисков уже имеющегося на просторах интернета.

Речь в этой статье пойдет об инструменте разработки, без которого я, как представитель второго типа, уже не мыслю разработку проектов размером больше 250 строк и который, я уверен, будет полезен нашим коллегам из классического типа – он сделан в сотрудничестве с одним из вас – восходящей звездой мира программирования Степаном! Итак!

Представьте себе сервис (или веб-приложение), который выдаёт вам сообщение вида «пятый символ введённого вами пароля неверный» в ответ на вашу попытку аутентификации. Выглядит абсурдно, не так ли? Предоставляя потенциальному злоумышленнику информацию подобного рода, мы попросту даём ему шанс «сбрутить» (подобрать, методом перебора) пароль от сервиса.

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

Сама по себе «тайминговая атака» или «атака по времени» — это нападение на систему по открытому каналу доступа, когда атакующий пытается скомпрометировать систему с помощью анализа времени, затрачиваемого на исполнение алгоритмов. Каждая операция (особенно математическая, будь то сложение, вычитание, возведение в степень и т.д.) требует определённого времени на исполнение, и это время может различаться в зависимости от входных данных. Располагая точными измерениями времени, которое расходуется на эти операции, злоумышленник может восстановить данные, необходимые для входа в систему.

В компании Duo много лет, в качестве основной платформы, использовали Node. Однако, в последнее время они экспериментировали с очень новым, ещё не вполне оформившимся языком Crystal. По их словам, чем больше они им занимались — тем сильнее к нему привязывались.

Сегодня мы хотим поделиться с вами переводом их рассказа о сильных и слабых сторонах платформ Node и Crystal, и о том, почему в Duo всё больше серверных проектов переводится на Crystal.

Прочитав статью Episode 8: Interview with Ryan Dahl, Creator of Node.js и комментарии к переводу, я решил протестировать эффективность блокирующей и неблокирующей операции чтения файла в Node.js, под катом таблицы и графики.

UPD: Под катом некоректний бенчмарк. Как правильно указали в комментариях, по сути сравнивается взятие из кэша одного и того же файла с помощью fs.readFileSync и fs.readFile.

UPD2: Статья отредактирована, бенчмарк исправлен, результаты добавлены.

Рассказ о том как я участвовал в highloadcup (чемпионат для backend-разработчиков) от Mail.Ru, написал на php сервер обслуживающий 10000 RPS, но всё равно не получил победную футболку.

Перевод отрывка из интервью с создателем Node.js Раяном Далом (Ryan Dahl) в котором обсуждается модель программирования и язык Go.

— Расскажи нам, как проходила начальная разработка Node? Это ведь уже было достаточно давно, ты создал Node в 2009.

Райан: — Я думаю для себя лично, что нет лучшего момента в жизни, когда ты, как это говорится, «в потоке» и у тебя есть идея, в которую ты сильно веришь. И при этом есть время, чтобы сесть и на самом деле работать над ней. И я думаю, Node была именно такой идеей, которая ждала, чтобы её кто-то ухватил, и если бы не я, то это бы сделал кто-то другой. Но так случалось, что я был тогда достаточно свободен от работы и имел время, и мог работать нон-стоп несколько месяцев, которых как раз были нужны, чтобы выкатить начальную версию. Так что да, это был отличный период.

— Отлично, супер. Node построена на идее «полностью асинхронной» модели программирования. Удачна ли она была для Node?

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


Картинка по запросу «области видимости». Извините, если вызвали приступ ностальгии )

Элементарное определение области видимости выглядит так: это область, где компилятор ищет переменные и функции, когда они ему нужны. Думаете, что звучит это слишком просто? Предлагаем разобраться вместе.

Юдель Пэн. Часовщик. 1924

«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы» 
Алан Кокс, прим. Википедия

“Знай свой инструмент” — твердят все вокруг и все равно доверяют. Доверяют модулю, доверяют фреймворку, доверяют чужому примеру.

Излюбленный вопрос на собеседованиях по Node.js — это устройство Event Loop. И при всем том, очевидном факте, что прикладному разработчику эти знания будут полезны, мало кто пытается самостоятельно погрузиться в устройство событийного цикла. В основном, всех устраивает картинка сверху. Хоть это и похоже на пересказ фильма, который ты не смотрел, а о котором тебе рассказал друг.