Node.JS *

6 февраля вышла новая версия Node.js v0.12. Это был длительный и трудный процесс, не без потерь для NodeJS, в результате которого от основной ветки отделился io.js, но, тем не менее, список нововведений довольно внушительный. Давайте поглядим.

Streams 3

Как обещают разработчики, реализация потоков теперь работает так, как это и ожидается. Причем самое главное, что старые API, введенные в v0.10, не поменялись.

Добавлен механизм cork/uncork для приложений, которые несколько раз синхронно пишут в поток. .cork() включает буферизацию для всех записей в поток, .uncork() же сбрасывает весь буфер.

@io.js_ru это аккаунт сообщества, занимающегося русской локализацией io.js.

Мы будем публиковать здесь переводы официальных материалов, а также другие статьи о io.js. Кроме того, каждую пятницу мы будем публиковать еженедельные новости обо всём, что связано с io.js.

Кстати, мы ищем переводчиков! Если вы хотите помочь нам — напишите о себе issue в нашем GitHub-репозитории.

Предлагаем вашему вниманию перевод статьи io.js Week of February 6th 2015 от @iojs на Medium.

Atom и nw.js перешли на io.js, Linux Tracing, а также многое другое.

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

На Хабре есть как минимум 2 еженедельных обзора мира фронтенда. Они классные, но пишут про весь фронтенд. А я пытаюсь больше уделять внимание JavaScript.

Если понравится — пишите, буду продолжать. Если нет — тоже пишите.

Когда появился node.js, многие web-разработчики стали задумываться о возможности использовать один и тот же код как на клиенте, так и на сервере. Сейчас существует несколько фреймворков, ставящих подход «пишем код один раз, используем везде» во главу угла, время от времени появляются новые. Вот и я не смог пройти мимо, пишу подобный микро-фреймворк — bnsf. Он предназначен для тех, кто предпочитает создавать front-end своих приложений по БЭМ-методологии, пользуясь соответствующим набором технологий и инструментов.

Давайте попробуем начать писать front-end для простого одностраничного web-приложения, используя bnsf. Чтобы не отвлекаться на создание back-end части, будем использовать в качестве back-end'a API vk.com. Наше приложение будет состоять всего из двух страниц, главной — с формой поиска пользователей по идентификатору — и вторичной, на ней будем выводить информацию о выбранном пользователе.

«Свершилось! Node.js получило развитие в виде форка io.js! Привет ES6! Привет новый V8!» радовались разработчики. Полез смотреть с надеждой, что вот сейчас, начав с нуля, ребята исправили фундаментальные косяки!

Какие фундаментальные ошибки допущены и почему без их исправления промышленный масштаб является спорным или попросту недостижимым. Это не статья-страшилка, как её можно понять, это просьба о помощи, т.к. нода показательно застопорилась, и надежда только в данном проекте.

В посте речь пойдет о написании утилиты для нагрузочного тестирования HTTP сервисов на Node.js, а также описание самого инструмента и области его использования.

На конференции OpenWorld 2014 корпорация Oracle объявила о том, что она работает над собственным Node.JS-драйвером для своей базы данных. На прошлой неделе был открыт его исходный код под лицензией Apache 2.0.

Драйвер включает в себя не только стандартные средства для исполнения SQL-запросов и PL/SQL-кода, но и инструменты для прозрачной работы с объектами JavaScript и массивами, продвинутые средства для работы с транзакциями и встроенными в Oracle инструментами масштабирования. Например, можно быстро прервать неудачную транзакцию на событие от сервера о невозможности корректно закончить работу, позволяя Node.js-приложению быстро переключиться на другую базу данных без потери пользовательских данных.

Много рассказывать о том, что такое TypeScript, не буду. На мой взгляд, это уже устоявшаяся и хорошо зарекомендовавшая технология, которая предоставляет возможности программирования, которых не хватало раньше в JavaScript. Самыми основными возможностями языка, на мой взгляд, стало более четкое ООП и строгая типизация. И за эти качества я этот язык полюбил и он гармонично вписался в мои проекты.

Все начиналось с того, что я в командной строке вызывал компилятор после каждого изменения проекта и пересобирал проект. Это было жутко не удобно и очень сильно замедляло разработку. Для grunt было расширение grunt-ts которое решало мои задачи и я им какое-то время пользовался. У компилятора TypeScript есть одна особенность (не бага и не фитча, политкорректность), которую во всех расширениях, которые я перепробовал, не учитывалась. Это жутко мешало и заставило писать свой код. grunt-tsc — расширение для grunt, позволяющее собирать проекты на TypeScript, о нем я и хочу рассказать.

Что и зачем

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

В тот момент пришлось столкнуться с ограничениями: сайт стал выдавал ошибку при слишком частых запросах (чаще нескольких запросов в секунду). Ну, не проблема, подумал я и решил это известным способом, сделав эдакий «асинхронный цикл». То есть в конце обработки одной страницы стал запускать таймер для обработки следующей.

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

Код Conveyor лежит на гитхабе, поставить можно через npm (называется dataconveyor). Более структурированная справка также на гитхабе. Использовать его можно как угодно и где угодно, без ограничений.

Ниже описание инструмента Conveyor.

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

FutoIn — с одной стороны, это «клей» из стандартов/спецификаций разных мастей для унификации программных интерфейсов различных существующих проектов по устоявшимся типам, с другой — это концепция для построения и масштабирования компонентов проекта и инфраструктуры, написанных на разных технологиях, без потребности в добавления этого самого «клея».

AsyncSteps — это спецификация и реализация программного интерфейса для построения асинхронных программ в независимости от выбранного языка или технологии.

Цели, поставленные для концепции:

• реализация (с оговорками) должна быть возможна на всех распространённых языках программирования с поддержкой объектов и анонимных функций. Репрезентативный минимум: С++, C#, Java, JavaScript, Lua (не ООП), PHP, Python;
• написанная программа должна легко читаться (сравнимо с классическим вариантом);
• должны поддерживаться исключения языка (Exceptions) с возможностью перехвата и разворачиванием асинхронного стека до самого начала;
• требуется удобство для написания асинхронных библиотек с единым подходом для вызова, возврата результата и обработки ошибок;
• предоставить простой инструмент для естественного распараллеливания независимых веток программы;
• предоставить простой инструмент создания асинхронных циклов с классическим управлением (break, continue) и меткой для выхода из вложенных циклов;
• предоставить место для хранения состояния исполняемой бизнес-логики;
• возможность отменять абстрактную асинхронную задачу, правильно завершая выполнение (освобождая внешние ресурсы);
• возможность легко интегрироваться с другими подходами асинхронного программирования;
• возможность ограничивать время выполнения задачи и отдельно каждой подзадачи;
• возможность создавать модель задачи для копирования (улучшения производительности критичных частей) или использования как объект первого класса для передачи логики в качестве параметра (а-ля callback);
• сделать отладку асинхронной программы максимально комфортной.

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

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

К счастью, Marak создал опрятное средство, которое позволяет нам генерировать фейковые данные на лету: Faker.

Это же очень просто (ага, когда есть пример).

[демо] — мультизагрузка с линейками прогресса, требуется регистрация.
[исходники] — комментарии по коду ниже.

Пишем драйвер поддержки графовой базы данных Neo4j для Meteor

В Meteor любая работа с даными связана с двусторонней реактивностью. На данный момент 100% реактивностью обладают встроенная в Meteor MongoDB и Redis (оба драйвера разработаны в стенах Meteor), частично реактивность реализована для MySQL и MSSQL (сторонними разработчиками).

Для вышеуказанных баз данных реактивность реализована посредством observer'ов, которые сообщают где, как, когда и какие данные изменились, для того чтобы драйвер, обслуживающий связь [данные <-> представление], знал какие данные и у каких Клиентов обновить. Neo4j лишен каких-либо watcher'ов и observer'ов, но это нас не остановило. Как мы вышли из данной ситуации и зачем нам нужен Neo4j читайте под катом.

Статей по использованию сервисов распознавания речи в asterisk от Google и Яндекса на Хабре уже есть несколько. Но всегда хочется сделать что-нибудь свое и как-нибудь по-своему.

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

Короткое видео с демонстрацией работы:

Элементарно! Но если бы мне показали подобную инструкцию раньше…

Задание

По запросу /profile без ключа отдаю шаблон login, если пользователь «не того», иначе отдаю шаблон на добавление newProfile или редактирование profile (editMode) своего профиля. А по запросу /profile/key отдаю шаблон на просмотр profile (not editMode) любого профиля; при этом userId не светится, и неверные ключи отвергаются на invalidProfile.

[исходник]

Как известно, io.js ориентирован на новые версии движка V8, в которые включена поддержка стандарта ES6. В то время как в NodeJS для поддержки новых фич ES6 приходилось использовать флаг --harmony при запуске и другие заморочки, в io.js предусмотрены 3 группы новшеств:

• shipping — новшества, помеченные как stable в V8, такие как генераторы, шаблоны, новые строковые методы и т.д. Все они включены по умолчанию и не требуют специальных флагов при запуске
• staged — почти завершенные, но не оттестированные, либо не приведенные к стандарту ES6. Это новшества из разряда «используйте на свой страх и риск», которые требуют флаг запуска --es_staging (или --harmony)
• in progress — все остальные новшества, которые должны быть включены индивидуальным флагом (например --harmony_arrow_functions)

Это не первая вводная статья про Impress на Хабре, но за последний год я получил много вопросов и приобрел некоторый опыт в объяснении архитектуры и философии этого сервера приложений и, надеюсь, стал лучше понимать проблемы и задачи разработчиков, начинающих его освоение. Да и в самом сервере произошло достаточно изменений, чтобы назрела актуальность совершенно новой вводной статьи.

Impress Application Server (IAS) — это сервер приложений для Node.js с альтернативной архитектурой и философией, не похожий на мэйнстрим разработки под нодой и призванный упростить и автоматизировать широкий круг повторяемых типовых задач, поднять уровень абстракции прикладного кода, задать рамки и структуру приложений, оптимизировать как производительность кода, так и производительность разработчиков. IAS покрывает сейчас только серверные задачи, но делает это комплексно, например, можно объединить на одном порту API, веб-сокеты, стриминг, статику, Server-Sent Events, проксирование и URL-реврайтинг, обслуживать несколько доменов и несколько приложений, как на одном сервере, так и на группе серверов, работающих в связке, как одно целое, как один сервер приложений.

npm — это пакетный менеджер Node.js. С его помощью можно управлять модулями и зависимостями.

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

Ниже представлен набор показателей. Некоторые из них я отслеживаю, а некоторые просто решил посмотреть. Еще указано то, насколько они изменились с 1 января по 31 декабря 2014 года.

Количество пакетов в реестре:

1 января: 53 459
31 декабря: 115 194
Темпы роста: 2.1x.

Не все JSON нельзя комментировать (например, Хром[иум] вполне переносит комментарии в manifest.json), но в стандарте не предусмотрены комментарии к нему. Поэтому ряд функций в NodeJS не обрабатывают комментарии в формате JS и считают их ошибкой. Точно так же, AJAX с форматом JSON принимает их за ошибку. Поэтому для конфигурационных файлов в формате JSON имеется масса неудобств при попытках их использовать как человеко-читаемые файлы. Может быть, это иногда хорошо. Если хотим прокомментировать, то будем вынуждены оформить комментарий под или над строкой как «ключ-значение».

...{...
    "some-key_comment":"my comment for key and value",
    "some-key":"some-value",
...}...

Но если комментарии не пишем, следуя суровости протоколов, ошибки возникают уже из-за другого фактора — забывания смысла параметров настроек при редактировании человеком.

...{...
    "some-key":"some-value", //какой-какой key?? Ай, комментарии - нельзя!
...}...

Придумаем JSON-подобный формат с комментариями в стиле JS, чтобы их можно было выполнять как JS, а, очистив от комментариев — читать как JSON. ("TL:DR: покажите мне код.")

В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Buffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений Impress. И простого использования util.inherits уже как-то не хватило, поискал я статьи и не найдя полностью всего, что мне нужно, изучил примеры наследования в исходниках самой ноды, подумал и сделал пример родного нодовского наследования себе на память и написал эту небольшую заметку, чтобы она, надеюсь, помогла еще и вам. Сразу предупреждаю, что реализация вызова метода родительского класса из переопределенного в дочернем классе метода, мне не очень нравится из-за громоздкости, поэтому, приветствую альтернативные способы и приглашаю коммитить их в репозиторий или в комментарии к этой заметке.