Node.JS *

Roger Wang 14 декабря объявил о выходе новой версии движка node-webkit — созданного в недрах Intel Open Source Technology Center мощного сочетания WebKit и Node.js, позволяющего создавать кросс-платформенные графические приложения методом веборазработки на языках HTML, CSS и JavaScript.

Новая версия имеет номер 0.3.6 и выглядит вот как:



По сравнению с версией 0.3.0, которую я обозревал в октябре, за последние два месяца случались только небольшие изменения, заслуживающие не более чем последней цифры в номере версии node-webkit. Зато изменений этих накопилось порядочно.

Прежде всего нетрудно заметить, что окна утратили «округлый» и «синенький» вид, похожий на Google Chrome, а вместо того вновь обрели общесистемный вид и форму. (На иллюстрации я привожу вид окна в Windows XP.) Также вернулся значок в заголовке окна. (Для сегодняшней демонстрации я поместил туда значок сайта Хабрахабра.)

Вот список остальных новшеств этой версии (по сравнению с 0.3.0):

В прошлый раз я писал о создании приложения на nodejs с использованием expressjs как фреймворка и jade как шаблонитизатора. В этот раз я хочу остановиться на тестирование серверной части.

Для тестов воспользуемся:
— Mocha — фреймворк позволяющий писать тесты и запускать легко и просто. Генерирует отчеты в различных вариантах, а так же умеет создавать документацию из тестов.
— Should — библиотека для тестов в стиле «утверждения» _{(Не нашел правильного названия)}
— SuperTest — библиотека для тестирования HTTP серверов на nodejs
— jscoverage — для оценки покрытия кода тестами

Ровно три месяца назад я представил хабрасообществу JavaScript шаблонизатор ECT. Вчера для него вышло обновление, о котором я хочу рассказать в этой статье.

Вы знакомы с ECT?

ECT это JavaScript шаблонизатор со встроенным CoffeeScript синтаксисом (отсюда и название: Embedded CoffeeScript Templates). ECT изначально разрабатывался с упором на максимальную производительность и при этом он предоставляет разработчику богатый набор функций.

Что нового?

Вебсокеты — это прогрессивный стандарт полнодуплексной (двусторонней) связи с сервером по TCP-соединению, совместимый с HTTP. Он позволяет организовывать живой обмен сообщениями между браузером и веб-сервером в реальном времени, причем совершенно иным способом, нежели привычная схема «запрос URL — ответ». Когда два года назад я присматривался к этому стандарту, он был еще в зачаточном состоянии. Существовал лишь неутвержденный набросок черновика и экспериментальная поддержка некоторыми браузерами и веб-серверами, причем в Файрфоксе он был по умолчанию отключен из-за проблем с безопасностью. Однако теперь ситуация изменилась. Стандарт приобрел несколько ревизий (в том числе без обратной совместимости), получил статус RFC (6455) и избавился от детских болезней. Во всех современных браузерах, включая IE10, заявлена поддержка одной из версий протокола, и есть вполне готовые к промышленному использованию веб-серверы.

Я решил, что настало время попробовать это на живом проекте. И теперь делюсь, что из этого вышло.

Мне ранее не доводилось использовать в своей работе такую возможность HTML5 как History API. И вот настал тот час, разобраться в этом и провести небольшой эксперимент. Результатом этого эксперимента я решил поделиться с Вами.

И так что мы хотим:
— Навигация по сайту с использованием history api
— Получения данных с сервера в виде json объекта с последующим рендером на клиенте
— При прямом переходе рендер должен происходить на сервере
— Что бы все было легко и просто

Те, кому приходилось разрабатывать более-менее большие web-проекты на node.js, наверняка сталкивались с проблемой обработки ошибок, произошедших внутри асинхронных вызовов. Эта проблема обычно всплывает далеко не сразу, а когда у вас уже есть много написанного кода, который делает нечто большее, чем выводит «Hello, World!».

Суть проблемы

Четыре месяца назад я писал о том, как можно удобно ловить исключения в node.js, в том числе и асинхронные, то есть те, которые брошены кодом, который вызван event loop'ом. В той статье я использовал модуль control-block для борьбы с ними, так как стандартный блок try-catch не справлялся.

Как оказалось, примерно в то же время Adam Crabtree выпустил стабильную версию похожего на control-block модуля под названием trycatch.

Вернер Фогель, CTO Amazon на прошедшей конференции re:Invent заявил, что использует Node.js для своих повседневных задач. А 4 декабря вышел официльный AWS SDK для Node.js. Теперь нет необходимости в использовании сторонних библиотек, опасаясь за их стабильность, и пытаться понять их документацию.

Взять можно тут: github.com/maxatwork/expressjs_template (или в виде zip-архива).

Что есть

• код сконвертирован в coffeescript
• github.com/visionmedia/jade — шаблонизатор
• learnboost.github.com/stylus — CSS-фреймворк, аналог SASS/LESS
• github.com/TrevorBurnham/connect-assets — сборщик ресурсов а-ля Rails 3.1, автоматически компилирует coffee-script/less/stylus
• github.com/shomeya/bootstrap-stylus — порт Twitter bootstrap'а на Stylus
• github.com/visionmedia/nib — утилиты и mixin'ы для Stylus, аналог COMPASS для SASS
• github.com/kriszyp/promised-io — библиотека ввода-вывода, использующая паттерн promise
• visionmedia.github.com/mocha — фреймворк для юнит-тестирования
• github.com/visionmedia/should.js — ассерты в стиле BDD для node.js
• github.com/visionmedia/supertest — библиотека для проверки http-приложений

Это продолжение перевода «The Trello Tech Stack».

Часть 1

• CoffeeScript
• Клиент
  * Backbone.js
  * HTML5 History API
  * Mustache
• Pushing and Polling
  * Socket.io and WebSockets
  * AJAX запросы

Часть 2

• Сервер
  * node.js
  * HAProxy
  * Redis
  * MongoDB
• Итак, нравится ли нам это?

В первой части я рассказал, как программисту относительно просто запустить с нуля свой личный сайт с использованием Github, Heroku и Twitter Bootstrap.

Но запустить сайт мало. Скорее всего, вам захочется на него периодически что-то выкладывать. Например, новые проекты в портфолио, или записи в блог.

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

Довольно часто встречаю вопросы типа: «А кто вообще из крупных/известных/заметных IT компаний использует в производстве Node.js?». 19 января 2012 года в блоге компании Fog Creek, основанной небезызвестным Джоелом Спольски (Joel Spolsky), была опубликована статья «The Trello Tech Stack». Странно, что на Хабре это как-то обошли вниманием. Поэтому, чтобы исправить этот недостаток, а заодно показать пример использования Node.js в крупном проекте, я сделал перевод этой статьи.

Сама статья довольно объемная, поэтому разбита на две части:

Часть 1

• CoffeeScript
• Клиент
  * Backbone.js
  * HTML5 History API
  * Mustache
• Pushing and Polling
  * Socket.io and WebSockets
  * AJAX запросы

Часть 2

• Сервер
  * node.js
  * HAProxy
  * Redis
  * MongoDB
• Итак, нравится ли нам это?

29 ноября в офисе Яндекса в Питере я буду проводить научный семинар «DTrace — проверочная работа для вашего кода». Те, кто на YaC 2012 слушал мой доклад «Инфраструктура облачных вычислений на основе ядра Illumos» — да и многие другие — знают, что в Semonix я занимаюсь облачными технологиями, тесно связанными со SmartOS. На семинаре я расскажу, как с помощью технологии DTrace проводить глубокий анализ производительности и детально изучать работу приложения. Поиск по Хабру находит только одну статью про SmartOS, и чтобы на семинар пришло больше тех, кто уже знаком с ней, я решил заранее написать про установку SmartOS и использование Node.js на ней.

Для начала расскажу, для чего нужна SmartOS. Если коротко, её предназначение – быть хост-системой для виртуальных машин. Она часто используется как основа для публичных и частных облаков, например, облачных служб Joyent и MITAC. Службой Joyent пользуется LinkedIn: вся его мобильная серверная часть сделана на Node.js, который запущен в облаке Joyent. Мы подробно писали об этом в блоге компании Semonix в статьях о SmartOS и об облаках, основанных на illumos, а я рассказывал в докладе на YaC 2012, который уже упоминал.

Типичные случаи применения SmartOS – системы для ЦОДов, системы для разработки и эксплуатации нагруженного веб-приложения, платформа для создания приватного или публичного облака. При работе над этой статьей я активно использовал статью Сту Радниджа, который проделывал примерно такой же путь установки SmartOS, как и я, но с использованием VMware вместо VirtualBox.

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

Меня аккаунт Вконтакте, и даже в Фейсбуке в качестве своего сайта не устраивает. Слишком много лишнего, навязанный формат и прочие неудобства.

Если бы я не был веб-разработчиком, мне пришлось бы плакать и грызть кактус. К счастью, я им являюсь, поэтому решил сделать себе сайт сам. Чтобы выкладывать на нём статьи вроде этой, небольшие хобби-проекты, и чтобы было что указать в поле «сайт» профиля на Хабре.

Если вы тоже хотели бы иметь сайт, который полностью контролируете, на котором всё именно так, как вам хочется, но всё никак руки не доходили разобраться и сделать, то эта статья для вас.

Некоторые знания HTML и JS вам пригодятся. Опыт работы с Node.js не обязателен.

Статья для node.js программистов, понимающих принципы асинхронно-событийного программирования, но не знающих как это устроено изнутри. Если для вас уже недостаточно стандартной картинки с «зацикленными» кружочками и хочется хотя бы взглянуть, что же у цикла событий под капотом, то вам под кат.

Многие сервисы и приложения (особенно веб-сервисы) принимают древовидные данные. Например, такую форму имеют данные, поступающие через JSON-PRC, JSON-REST, PHP-GET/POST. Естественно, появляется задача валидировать их структуру. Существует много вариантов решения этой задачи, начиная от нагромождения if-ов в контроллерах и заканчивая классами, реализующими валидацию по разнообразным конфигурациям. Чаще всего для решения этой задачи требуется рекурсивный валидатор, работающий со схемами данных, описанными по определённому стандарту. Одним из таких стандартов является JSON-Schema, рассмотрим его поближе.

Приветствую, уважаемые читатели Хабрахабра. Хочу поделиться с вами своим опытом использования backbone.js под node.js. Ранее я активно поработал с backbone.js на клиенте, и эта библиотека оказалась крайне удобной для структурирования кода.

Сервис без работы с какой либо базой данных — не сервис. В моем случае, в качестве СУБД была выбрана mongodb. Я посмотрел существующие решения ORM для mongodb, и мне показалось более удобным пользоваться знакомыми инструментами, тем более они же будут использоваться и на клиенте, поэтому решено было попробовать применить для моделей класс Backbone.Model и заодно проверить, как все это можно кастомизировать под mongodb.

Хочу поделится с вами очень интересным приемом оптимизации в Javascript.

Добрый день.
Складывать в отдельный лог-файл сообщения об ошибках 404 — настолько обычное дело, что, казалось бы, и сложностей с этим быть не может. По крайней мере, так думал я, пока за одну секунду клиент не запросил полторы тысячи отсутствующих файлов.
Node.js-сервер выругался «EMFILE, too many open files» и отключился.

Не прошло и полгода как я наконец добрался до написания второй главы учебника. Первую главу я тоже немного переработал с учетом пожеланий хабражителей, так что можете снова ее просмотреть — Web-разработка на node.js и express. Изучаем node.js на практике

Глава 2. Демонстрационное приложение и первые тесты

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