Node.JS *

В прошлом году понятие «внебраузерный JavaScript» чаще всего означало движок Node.js (а не, допустим, Rhino или SpiderMonkey, сильно уступающие ему в популярности в этой области) или какой-нибудь итог его встраивания (например, node-webkit).

В нынешнем году в игру вступают форки Node (например, io.js), и их также начинают встраивать — например, проект node-webkit переименовался в nw.js, потому что теперь он использует не Node, а io.js (да и не WebKit, а Blink — с тех давних пор, как Chromium перешёл на этот движок).

Для программистов это означает, в частности, что может отвалиться (или, наоборот, появиться) поддержка той или иной операционной системы. Давайте поговорим об этом.

Какие операционные системы перестают поддерживаться?

Во-первых, первые версии io.js нельзя было установить на Windows XP, нельзя было установить и на Windows 2003. Ещё в середине января казалось, что с этим ничего нельзя поделать: объяснение «io.js компилируется в Visual Studio 2013 Windows Desktop Edition, потому что движок V8 стал полагаться на возможности C++11» воспринималось как приговор — однако затем разработчики поправили дело, так что в файле CHANGELOG.md ветви v1.x можно прочесть, что поддержка этих версий системы Windows возвратилась в io.js, начиная от версии io.js 1.0.3 (20 января).

Подобно кругам по воде, эти изменения прошли по всей экосистеме движков; например, в nw.js версии 0.12.0-alpha3 на поддержку ещё можно надеяться (хотя лично я ещё не успел погонять эту версию на Windows XP), а в предыдущих альфа-версиях её точно нет (потому что они основаны на более ранних версиях io.js).

Во-вторых, KaneUA 19 февраля упомянул, что io.js не поддерживает тридцатидвухбитные версии OS X, в отличие от Node.

Поддержка каких операционных систем может появиться?

Доброго времени суток, всем! Кто-то умный, не помню в какой статье именно на Хабре, буквально недавно размышлял о процессе разработки с явным призывом автоматизировать все, что только можно автоматизировать. И лучше один раз потратить время на автоматизацию, чтобы потом экономить его на протяжении всего проекта.

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

А еще я выложил подборку на GitHub, чтобы каждый мог пополнить коллекцию.

Локализация на 29 языках, релиз 1.2.0, и многое другое.

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

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)