Node.JS *

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

В этой статье будет рассмотрена небольшая control flow библиотека «Flowy», являющаяся развитием идей проекта Step Тима Касвелла, и ядро которой базируется на концепциях CommonJS Promises, а также приведены аргументы, почему же Promises — это так неудобно.

Давно хотел написать свою небольшую игрушку. И вот, изучив подходящие технологии, создал «шедевр».

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Начал изучать NodeJS. Нигде не нашел актуальный стек мейнстримных библиотек (технологий) применяемых в node. Поэтому решил сам составить список.

Не так давно, прочитав статью idoroshenko «Почему eval — это не всегда плохо», я задумался, можно ли использовать подход с генерацией тела функции для клонирования объектов. Даже написал небольшую библиотеку для этого. Бенчмарки давали невероятные результаты, но применимость этого подхода ограничивалась лишь множественным клонированием одинаковых объектов.

Поэтому и у меня возник вопрос: неужели в v8 нет другой возможности избежать расходов, связанных со множественным пересозданием скрытых классов? Ведь это составляет основные траты ресурсов, когда мы клонируем объекты. Как оказалось, такая возможность действительно есть: в самом v8 у объектов существует метод v8::Object::Clone. Этот метод клонирует объекты в широком смысле этого слова, то есть собственно объекты, а также массивы, даты, регулярные выражения, функции и т.д., при этом сохраняя все их свойства, в том числе нестандартные (например, именованные свойства массивов) и даже скрытые.

Была только одна маленькая проблема. Этот метод использовался только в недрах node.js, и не был открыт наружу, для javascript'а.

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 программистов, понимающих принципы асинхронно-событийного программирования, но не знающих как это устроено изнутри. Если для вас уже недостаточно стандартной картинки с «зацикленными» кружочками и хочется хотя бы взглянуть, что же у цикла событий под капотом, то вам под кат.