Node.JS *

Добрый день.
У меня выдалось свободное время, и я решил написать статью про несправедливо обойденный вниманием паттерн написания api. Он подходит в случае, если у Вас и клиент и сервер содержат сложное состояние, и есть необходимость его синхронизировать. На мой взгляд, социальные игры идеально подходят под это описание. В силу того, что я ещё не достиг того уровня мастерства, когда могу писать статьи про программирование без кода, спешу предоставить пример, демонстрирующий данный подход. Посмотреть код можно на github: https://github.com/dbalakov/studio_game.

В последнее время в IT-сообществе довольно много шумихи вокруг серверного JavaScript, в частности — NodeJS, однако, как это ни странно, оказалось довольно сложно найти информацию о том, как писать модульный, объектный код. Что я имею ввиду? Дело в том, что с js я знаком совсем недавно, до этого писал небольшие приложения на Java, а в свободное время пишу серверную часть онлайн-игры на PHP и, как и следовало ожидать, как и многим начинающим программистам на JS мне было очень непривычно вместо объектно-ориентированного использовать так называемое прототипно-ориентированное программирование. Тем более, JavaScript вносит достаточно много путаницы даже в это дело со своими Object.prototype и __proto__. Первое, что пришло мне в голову, как и многим другим разработчикам — сделать свою реализацию «привычного ООП», сделал. Немного подумав я решил, что это просто незачем, если мы работаем с nodeJS. За мою, хоть и недолгую практику, мне не довелось встретить задачу, которая бы требовала настоящего ОО подхода, я имею ввиду реальную необходимость наследования, полиморфизма и тем более инкапсуляции (конечно, все это нужно, но в той степени, которую js предоставляет).

Несколько месяцев назад мы с коллегами решили сделать многопользовательскую realtime игру, которая могла бы работать в вебе. Мы решили использовать node.js для нашего сервера. Это решение привело к очень убедительному успеху — наш сервер работал несколько месяцев без единого падения или перезагрузки процесса.

Мы решили написать нашу игру на node.js, потому что мы слышали много хорошего об этой платформе и очень хотели немного с ней поиграть. И это было потрясающе — мы очень быстро вошли в тему. Для node.js существует множество любопытных библиотек, способных решать абсолютно разные задачи. Побочным преимуществом использования node для серверной части является, собственно, javascript — очень простой в обращении язык. Это позволило нам сфокусироваться на проблемах, которые встречаются во всех realtime играх, без лишней суеты, ограничений и необходимости компилировать код, как это случается при использовании менее динамических языков.

Также node.js проявил себя как очень легковесный язык, даже в моменты пиковой нагрузки. Для нашей игры, процесс node.js использовал только один поток и потреблял всего около 3-4% CPU при одновременной работе 8-10 копий игры, каждая со своим собственным движком обнаружения столкновений.

Вчера (23 июля) интеловский Центр технологий с открытым исходным кодом выдал на-горá очередную версию движка node-webkit. Как и прежде, движок этот позволяет открывать браузероподобные окна (на основе кода Chromium) и употреблять в них API Node.js — а значит, обеспечивает нетрудное создание GUI-приложений методами веборазработки (на языках JavaScript, HTML, CSS, WebGL и т. п.) под операционные системы Windows, Mac OS X и Linux.

Новая версия получила номер 0.6.3 и содержит движок Node версии 0.10.12:



Три месяца назад (29 апреля) я обозрел одну из предыдущих версий node-webkit (версию 0.5.1). За прошедшее с тех пор время в node-webkit появился целый ряд существенных новшеств.

Важнейшим из них стало улучшение подсистемы поиска и запуска приложений. Теперь, когда вы запускаете движок node-webkit, он ищет приложение в следующем порядке:

Доброго времени суток, читатель!

Как-то понадобилась мне в проекте, работающем на node.js, обработка изображений. И чтоб скачал файлик, закинул в папку и подключил как модуль. Ан нет, таких в природе не оказалось. По этому тогда пришлось воспользоваться node-imagemagick. Но сейчас пост не о этой библиотеке.

Пост о том, что захотелось сделать такую библиотеку, которую скачал, закинул файлик в проект, подключил модуль и всё работает! Ну и сделал. Правда поддержка gif'ок не реализована, но я надеюсь на огромное сообщество, которое заинтересуется и поможет доделать библиотеку.

Назвал её по простому, imageLib.js, и на github выложил, правда под MIT.

Начало

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

Уважаемые читатели! Этой статье 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-приложений (клиент-сервер) но и десктопных.