Node.JS *

Уважаемые читатели! Этой статье 3 года, но, по-моему мнению, в ней содержатся интересные вещи. Спасибо за понимание.

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

Часть 1.

Моделируем 4 вида NoSQL-баз с помощью GlobalsDB

От переводчика
На мой взгляд на Хабре мало информации о бесплатной NoSQL-базе GlobalsDB. Оригинальная статья написана в августе 2011 года и ещё актуальна. Перед вами первая часть. Во второй части будет рассказано как с помощью GlobalsDB моделировать различные типы NoSQL-баз.

Введение

GlobalsDB — бесплатная база данных, которая использует для сохранения данных механизм Глобальных Постояннохранимых Переменных (Global Persistent Variables), т.е. переменных значения которых автоматически сохраняются на жёстком диске. Они представляют собой абстракцию над бинарными деревьями (B-trees) и могут быть использованы для хранения больших объёмов данных представленных как многомерные разреженные массивы.

С помощью Глобальных Постояннохранимых Переменных (обычно называемых «глобалами», поэтому и база называется GlobalsDB) можно выразительно и высокоэффективно решать все обычные задачи, для которых принято сегодня использовать различные NoSQL-базы.

Для управления зависимостями в проекте, node.js, как и многие другие платформы, предоставляет собственный пакетный менеджер — npm. И несмотря на то, что он внешне похож, например, на Ruby Gems, и вроде бы выполняет те же самые функции, npm обладает некоторыми особенностями, которые стоит учитывать при разработке приложений на node.js. Одна из таких особенностей — это способ хранения директории node_modules в проекте. Многие, по аналогии с другими системами, оставляют в проекте только package.json с зафиксированными версиями модулей, а node_modules добавляют в .gitignore. Такая стратегия не всегда верна, если мы обратимся в FAQ на npmjs.org, то увидим там следующее:

Q: Стоит ли хранить node_modules в git?
A: Mikeal Rogers очень хорошо ответил на этот вопрос:
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl;dr

• Храните node_modules в git для проектов, которые требуется разворачивать, таких как вебсайты и приложения.
• Добавляйте node_modules в .gitignore для библиотек и повторно используемых модулей.
• Используйте npm для управления зависимостями в dev окружении, но не в скриптах используемых для деплоя.

Под катом перевод статьи Mikeal Rogers, в котором подробно описывается, с чем связан такой непривычный подход.

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

К сожалению, в сообществе node.js, на данный момент сложилась такая ситуация, что подавляющее большинство драйверов к распространённым сервисам имеет ряд существенных недостатков, не позволяющих приложениям достигать заслуженных высот эффективности и стабильности. Вы наверняка слышали все эти ужасающие истории о том, что «node.js течёт», оно “игрушечное”, не предназначенное для применения в настоящей высоконагруженной среде. Однако, как мы убедились на собственном опыте, с умом написанное ПО для ноды блестяще справляется со всеми испытаниями суровых боевых реалий. И здесь мы приходим к главному вопросу: что же мешает среднестатистическому node.js-драйверу нормальной работе?

У нас неплохо получается хранить фотографии, поэтому мы решили упростить жизнь и вам, если вы хотите соорудить свой tumblr, facebook или imgur. Дело на самом деле нехитрое, но есть тонкости, о которых лучше знать заранее. К тому же мы сделали всё на node.js, что не слишком характерно для хранилища с более чем 100 000 000 фотографий.

Node.js развивается, и, вполне уже можно экспериментировать с написанием графических приложений либо каких-то консольных утилит и сервисов. В процессе разработки может возникнуть необходимость использовать какие-то системные вызовы, например, к WMI (к WMI нельзя обратиться напрямую из node.js, и запросы WMI могут быть долгими, что заблокирует event loop, и, например, если связь у Вас через веб-сокеты, связь может оборваться). Тут существует несколько вариантов. Можно воспользоваться модулем (например, node-ffi) и попробовать поиграться с ним. Есть ещё способ, точнее, костыль. В Windows существует так называемый WScript (Windows Script Host) — это компонент Windows, предназначенный для запуска, например, JScript, VBScript. JScript может обращаться к WMI напрямую, так что мы имеем возможность запустить child_process, в котором будет работать JScript, и получать от него данные (формировать, например, JSON и отправлять его строкой), но это костыль, бессмысленный и беспощадный. И третий способ — это нативный модуль. Я не буду описывать, как получить данные от WMI, а опишу что-нибудь менее ёмкое. Кому интересно — прошу под кат.

Позавчера на Гитхабе в репозиторий Node.js был принят тот код, посредством которого Linus Mårtensson учёл небольшие, но важные различия в поддержке Android и стандартных POSIX-систем. Также появился автоконфигуратор, позволяющий собрать Node для Android за два шага:

1. source ./android-configure ~/android-ndk-r8d (второй параметр — это путь к NDK)
    
2. make -j8 (сборка андроидосовместимых бинарников)

С этим достижением не всё ещё гладко (вон там, например, поступило предложение получше подстраиваться под шестидесятичетырёхбитные системы). Однако новость ужé такова, что можно подпрыгнуть от радости! Со времён начала прямой (а не под cygwin) поддержки Windows-версии Node (а это было давным-давно — в 2011 году) не случалось ещё ни одного столь же заметного шага в направлении совместимости между Node и новыми (ранее не поддерживавшимися) операционными системами.

Сразу скажу, впрочем, что у меня эта новинка пока что оставляет больше вопросов, чем ответов.

Когда я начинал писать на node.js, я ненавидел две вещи: все популярные шаблонизаторы и огромное количество callbacks. Я добровольно использовал callbacks, потому что понимал всю силу событийно-ориентированных серверов, но с тех пор в JavaScript появились генераторы, и я с нетерпением жду день, когда они будут имплементированы.

И вот этот день наступает. На сегодня генераторы доступны в V8 и SpiderMonkey, имплементация следует за обновлениями спецификации — это заря новой эры!

У меня сложилось впечатление, что в обществе все же есть предубеждение против использования глобальных переменных в служебных целях. В связи с этим, хочу дать некоторые разъяснения с примерами, которые снимут всякие сомнения и будут полезны всем, кто жаждет модульности и гибкости в JavaScript разработке. Я не могу проследить источники всех идей, приведенных ниже, но я не претендую на их авторство, а лишь на творческое обобщение. Так же я отказываюсь от претензий на один универсальных паттерн определения модулей для всех случаев жизни, надеюсь, всем ясно, что такого не может быть никогда. Все это существенно отличается от подходов RequireJS, CommonJS и того, как модули оформляются в node.js через module.exports, однако, каждый из этих паттернов имеет свое место, если подходить к задаче без фанатизма и предубеждений.

Если Вы программируете на node.js, но устали писать роутинг запросов в коде, у Вас нет предубеждения против использования глобальных переменных в служебных целях и Вы согласны, что излишняя свобода губительна для масс, то тоталитарный кружок выходного дня приготовил для Вас прототип альтернативной платформы для разработки веб приложений. Предупреждаю, что тоталитарный стиль предполагает не встраивание фреймворка в приложение через require, а наоборот, встраивание своего приложения в структуру фреймворка, где фрагменты кода приложения будут на каждом шагу иметь дело с дополнительными ограничениями и навязанными структурами кода и данных. Про то, что «less-than-expert» смогут разрабатывать высокопроизводительные системы, как утверждают разработчики ноды — ну тут Вы сами понимаете, что это будут за системы, особливо асинхронные, с потерянными коллбеками и утечками памяти на каждом шагу. В плане защиты от дурака, сей прототип чудес не доставляет. И конечно же, ожидаю от Вас много конструктивной критики, потому, что прототип сырой, хоть и собрал в себе множество концептуальных наработок нашей команды за последнее десятилетие. Даже название Impress появилось всего два дня назад и, да — это самый сложный вопрос.

Devconf::JS через неделю — не пропустите
devconf.ru/js/programm/js

1. Применение AngularJS для создания standalone виджета, реализующего игровую механику
2. Модульность JavaScript на клиенте
3. YUI 3 — JavaScript фреймворк от Yahoo! Модульная архитектура и динамическая загрузка приложения.
4. Зачем мы пишем свои драйверы для баз данных?
5. KnockoutJS на примере 2ГИС-Онлайн
6. Возможности последних WEB-стандартов на примере их использования в API Яндекс.Карт
7. Использование Chromium Embedded Framework (CEF) для кросплатформенной разработки на .NET и JavaScript
8. Мастер-класс: ExtJs 4: быстрый старт

Всем привет!
На данный момент очень трендово использовать node.js. Однако не всем он нравится. В данном обзоре, я бы хотел рассказать немного о конкуренте, который был написан под влиянием node.js
Vert.x это асинхронный, event-driven фреймворк, цели которого пересекаются с популярным node.js. Высокая производительность, простая асинхронность и конфигурирование — это все по vert.x.
Первая версия фрейворка, была выпущена в 2012 году, в то время как node.js был выпущен в 2009. Однако, уже поддерживается VMware и может запускаться на CloudFoundry.
Основные характеристики продукта под катом:

С ростом популярности node.js он становится всё более привлекательным для разработки приложений. По крайней мере я в последнее время очень часто использую эту технологию для быстрой разработки оных. И на данный момент, технологически нет никаких препятствий для разработки кроссплатформенных приложений на одном языке. И не только классических Web-приложений (клиент-сервер) но и десктопных.

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

tl;dr Eсть новое API для асинхронного try\catch. Из статьи можно скопипастить пример и поиграться.

Возникла у нас на проекте прихоть — рисовать на стороне сервера графики, да не простые, а максимально похожие на уже имеющиеся графики на клиентской стороне.
Да-да, именно так, на клиенте уже были всевозможные красивости, реализованные на d3.js.
Для исследования возможностей был применен комплексный метод анализа «google-driven investigation» и в первой итерации выбор пал на ноду + фантом.

За подробностями прошу в глубины поста.

Около двенадцати часов назад Джон Резиг нащебетал в Твиттер, что на конференции Google I/O было объявлено об улучшении поддержки Asm.js в движке V8 и во браузере Google Chrome.

Так как про Asm.js упоминали на Хабрахабре (1, 2), то достоинства его могли стать известны многим читателям. Тем приятнее им предвкушать теперь в самом скором времени появление этих достоинств не только во браузере Firefox (где они впервые были внедрены Фондом Мозиллы), но и в движке V8 (а значит — и в построенном на его основе движке Node.js!), и во браузере Google Chrome.

Но для тех читателей, которые до сих пор пропускали эту новинку мимо себя, я также вкратце напомню суть. Asm.js — это особое подмножество языка JavaScript: ограничившись им в своём скрипте, автор скрипта обеспечивает возможность оптимизации интерпретируемого кода не только в момент исполнения (just-in-time, JIT), но даже и заблаговременно (ahead-of-time, AOT), то есть такому джаваскрипту становится возможно один раз однозначно заранее поставить в соответствие некоторый машинный код. Эффект этот достигается ценою заметных усилий по самоограничению. (В частности, при помощи операции «|0» и других подобных специальных приёмов тип значения каждого входного параментра функции, равно как и выходного значения, оказывается однозначно заданным и неизменным.) Зато его итогом становится небывалый рост скорости исполнения джаваскрипта — теперь по скорости он уступает скомпилированной программе (на Си или Си++) не более чем в два раза.

В современной разработке ваш код сильно отличается от кода на «боевом» сервере (production) после компиляции, минификации, объединения и разных оптимизаций. Тут-то и вступают в игру карты кода (source maps), показывая точное соответствие элементов готового рабочего кода проекта и вашего кода разработки. В этом вводном уроке мы возьмём простой проект и запустим его с помощью различных компиляторов JavaScript с целью посмотреть работу карт кода в браузере.

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

К сожалению, во втором случае обычного времени показа титров бывает недостаточно. Удлинить его можно во многих программах (например, в SubtitleEdit) — но иногда это удлинение ограничено разумными пределами, да и запускать для такого простого действия полноценный редактор не всегда удобно.

Поэтому я попробовал написать простые скрипты только под эту нужду и выбрал два принципа удлинения времени.

Позавчера (27 апреля) из праведных недр интеловского Центра технологий с открытым исходным кодом (а это тот самый Центр, который hshhhhh обозревал неделю назад во блогозаписи «Печеньки для пингвина») вышла в свет новая версия движка node-webkit — могучего объединения Node и WebKit (точнее даже не просто WebKit, а Chromium — и в дальнейшем, вероятно, Blink), обеспечивающего быстрое и бесхитростное создание GUI-приложений методами веборазработки (код на JavaScript с употреблением API от Node.js, а интерфейс на HTML да на CSS) под операционные системы Windows, Mac OS X и Linux.

Новая версия имеет номер 0.5.1; на её основе нетрудно составить и запустить, например, вот такое окно:



Одну из предыдущих версий node-webkit (0.4.1) мне довелось обозреть в начале февраля, а теперь на дворе конец апреля. Настала пора рассказать обо всех тех изменениях, которыми сопровождался выход версии 0.4.2, за нею 0.5.0, и затем 0.5.1 наконец. Рассказываю: