Node.JS *

Вы веб-разработчик?

Для вас есть новости.

В чем собственно проблема?

Все веб-фреймворки можно разделить на группы. У каждой из этих групп есть свои достоинства и недостатки.

Сервер-ориентированные

Например: RoR, Django, Asp Net, Express.js
Генерируют html на сервере.
Такой подход хорош для статических страничек.
Но как только вы хотите сделать что-то интерактивное, то начинаете утопать в jQuery-коде.

Клиент-ориентированные

Например: Backbone.js, Knockout.js, Ember.js, Batman.js
Генерируют html прямо на клиенте из темплейтов. Код на клиенте структурирован.
Хорошо для интерактивных сайтов.
Не отменяет необходимость использовать сервер-ориентированный фреймворк, что ведет к дублированию кода (модели, валидация и т.д.)

Кросс-компилируемые

Например: GWT, Cappuccino
Позволяют писать всё на одном языке.
Очень большой уровень абстракции.
Шаг вправо, шаг влево — расстрел.

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

Привет, хаброжители!

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

Впервые представляю широкой публике небольшой SDK, позволяющий выполнять запросы к API ВКонтакте из NodeJS.
Как раз вчера я собрал обновленную версию, так что есть отличный повод поделиться разработками с коллегами.

nodejs-vksdk на github

• Отправка запросов через OAuth2(HTTPS) или подпись(HTTP).
• Запрос токенов OAuth для серверов приложений, получение токена по коду.
• Асинхронное выполнение запросов к API и события по готовности.
• Возможность назначать свои события на запросы.
• Совместимость с events.EventEmitter

«Node.js не подходит для серьезных сайтов и веб-приложений, а только для написания небольших API».
This is bull*hit. I have to say it.

От переводчика: недавно на coderwall.com появилась интересная статья от Ionut-Cristian Florescu об использовании Node.js для создания обычных («типовых») веб-проектов. До ее прочтения я был полностью согласен с заголовком статьи, но сейчас мое мнение несколько поменялось. Позиция автора может быть спорной во многих моментах, но его аргументы достаточно интересны. Если у вас есть собственное мнение по этому поводу, оставляйте его в комментариях.

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

Модуль позволяет

• Отправлять сообщения master->worker, worker->master, master->master
• Отправлять запросы и получать ответы (через callback)
• Использовать эксклюзивные блокировки по ключу (критические секции)

Кому интересно — прошу под кат.

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

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



Код тестового окна я сегодня открыл на Гитхабе, так что желающие могут с ним ознакомиться и убедиться воочию, что начальные (helloworldные) шаги программирования для node-webkit ничуть не сложнее обычной веборазработки, усиленной возможностями API Node.

Менее месяца тому назад (24 июля) я обозрел одну из предыдущих версий node-webkit (версию 0.6.3). С тех пор прошло не много времени, однако в node-webkit появился ряд небезынтересных новшеств:

CoffeeScript принёс в JS неплохую абстракцию классов, основанную на прототипах.
Реализовав известную модель наследования и дополнив её наследованием методов касса,
он позволяет легко строить иерархии классов, даже не зная о цепочках прототипов.
Но и эта модель может быть улучшена.

Так уж вышло, что по работе, мне приходится редактировать файлы, к которым я имею доступ только через файловый менеджер CMS Bitrix, что влечёт за собой открытие множества вкладок в браузере и огромное количество ненужных телодвижений необходимых лишь для того, чтобы отредактировать несколько файлов.
Ниже я расскажу как решил эту проблему с помощью Node.js и свободного времени.

На хабре неоднократно упоминался Meteor (тут, тут и тут) — высокоуровневый JavaScript-фреймворк для быстрого создания одностраничных web-приложений.

Сегодня вышла версия 0.6.5., основные изменения:

На днях закрыли очередной проект. Суть: создание новой версии интернет-каталога. Старая версия сайта, в силу ряда причин, клиента не устраивала. Особенностью проекта была его номенклатурная база. Объём номенклатуры каталога составлял ~26000 позиций раскиданных по дереву из 513 узлов + характеристики товара. Почти каждая номенклатурная позиция имела описание на 1-2К текста.

Файл выгрузки каталога в формате ComerceML 2 для старого сайта весил 104 MB. Формировался на стороне 1С 10 минут и после передачи на хостинг, парсился на стороне сайта полтора часа (!) со 100% загрузкой CPU.

Добрый день.
У меня выдалось свободное время, и я решил написать статью про несправедливо обойденный вниманием паттерн написания 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, в котором подробно описывается, с чем связан такой непривычный подход.