Node.JS *

Как известно, до этого в nginx не было поддержки WebSockets:
habrahabr.ru/post/124089
habrahabr.ru/post/96354

18 февраля 2013 в trunk nginx была добавлена поддержка WebSockets (http://trac.nginx.org/nginx/changeset/5073/nginx), что открывает перед разработчиками новые горизонты.

Ждём выхода релиза.

Сегодня — немного практических советов по работе с WebStorm.

Вначале пишем совсем простой HTML, после color: нажимаем <Ctrl-пробел> и получаем список цветов.



КО подсказывает: во всех IDE от JetBrains <Ctrl-пробел> — это контекстная подсказка.

Как только мы выбрали цвет, на вертикальной полоске слева от текста тут же появляется маленький квадрат такого же цвета. Теперь можно кликнуть по нему, и откроется палитра, из которой можно выбрать вообще любой цвет.



А теперь представим себе проект посложнее, небольшое приложение под node.js.

Наверно каждый веб-разработчик слышал о шаблонизаторе Smarty (php). Но так как я частенько увлекаюсь JavaScript'ом, то решено было найти подобный шаблонизатор для этого языка, но серверного (node.js, ага). Первые ссылки в поисковике выдают такие шаблонизаторы, как: ECT, JUST, Mu. Все они, естественно, не подходили для меня, т.к. слишком далеко были от синтаксиса Smarty.

Чтож, раз хочется, а решений нет — то сделай. Выискивая время на работе и иногда получая по «шапке», родился проект NodeSmarty, который, в будущем, будет частично копировать синтаксис Smarty.

Добрый день, Хабрахабр.

Предисловие

Была довольно простая задача: получить набор документов из базы, каждый документ преобразовать и отправить пользователю все преобразованные документы, порядок их менять нельзя, для обработки документа используется асинхронная функция. Если на каком-то документе вылезла ошибка — документы мы не отправляем, только ошибку и заканчиваем обработку документов.
Для решения задачи была выбрана библиотека Q, так как сам поход Promise мне симпатичен. Но возникла одна загвоздка, вроде бы элементарная задача, а выполняется больше секунды, а точнее 1300 мс, вместо ожидаемых 50-80 мс. Дабы разобраться, как все устроено и проникнуться асинхронностью было решено написать специализированный «велосипед» под данную задачу.

Между регулярными выражениями в JavaScript и регулярными выражениями PCRE (употребляющимися в Perl и в PHP) есть ряд различий, главнейшим из которых, вероятно, является отсутствие lookbehind (ретроспективной проверки) в JavaScript.

Естественной задачею программистов, раздражённых этими различиями, является внедрение PCRE в JavaScript.

На движке Node к концу нынешнего января Брайан Уайт (Brian White) решил эту задачу, создав модуль node-pcre, служащий обёрткою вокруг движка PCRE.

Этому можно порадоваться, и порадуемся.

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

Интересно, придёт ли со временем кому-нибудь на ум использовать Emscripten для перевода движка PCRE непосредственно на язык JavaScript?

Мечты, мечты.

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

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



Почти семь недель прошло с того дня (18 декабря), когда я обозревал одну из предыдущих версий (0.3.6) этого движка. Вам нетрудно заметить, что за это время успела перемениться не только последняя, но и предпоследняя цифра версии. Сейчас я расскажу, какие изменения, в node-webkit произошедшие, отражает эта перемена.

Что это такое?

LiveReload — это утилита, которая позволяет автоматически перезагружать страницу в браузере при изменение её кода и ресурсов(html, css, js, images, etc) на сервере. Кроме того LiveReload позволяет применять изменения в CSS и JavaScript без перезагрузки страницы.

Предыдущий пост с описанием фреймворка maxmertkit получил большой отклик. Фреймворк особенно понравился, почему-то, японцам, но наилучшую конструктивную критику и помощь я получил от хабрасообщества. Теперь к делу.
Нынешние фреймворки, включая мой, имеют модульную структуру. Но все эти модули в некоторой степени являются зависимыми друг от друга. Это плохо. Именно эту проблему я и хочу решить.

В статье пойдет речь о десктопном приложении, написанном на основе платформы node-webkit. На Хабре были статьи которые описывают саму платформу: раз, два, три. Но реальных приложений которые используют эту платформу не так много. В начале я раскажу о приложении, о его задачах и функционале, дальше я перейду к техническим возможностям платформы node-webkit, которые были использованы в приложении. Статья не изобилует вставками кода, весь код выложен на github. В конце статьи будут ссылки на все использованные источники информации.

Моей целью было создание полноценного приложения с использованием платформы node-webkit. Задача приложения — защита онлайн переписки, осуществляемой через мессенджеры (Skype, Google Talk, еtc.) Посылая по открытым каналам уже зашифрованную информацию, вы усложняете процесс получения доступа к данным третьей стороной. Существует множество способов зашифровать сообщение, но проблема в том, что ключ для шифрования нужно сообщить вашему собеседнику. Допустим, ваш канал прослушивают, и имеют доступ ко всему, что вы отправляете и получаете. Для решения этой задачи приложение использует алгоритм Дэффи-Хеллмана. Про этот алгоритм уже расказывали на Хабре, вот ссылка. Но больше всего впечатляет видео, которое наглядно описывает, как работает алгоритм — YouTube. Более подробно об этом алгоритме можно почитать в Википедии.

Всякий, кому из-под «Ростелекома» или другого очевидно российского провайдера доводилось зайти по адресу http://drugoi.livejournal.com/3712998.html (занесённому в «чёрный список» за изображение политического самоубийства), уж конечно видал там козла и надпись «ошибка 451!»:



Однако можно воспользоваться любым средством просмотра заголовков HTTP-отклика и видеть, что на самом деле там выдаётся ошибка 404 («Not Found»).

Сходным образом обстоят дела и в движке Node.js: код 451 не добавят к списку заранее определённых кодов HTTP-отклика до тех пор, пока соответствующее предложение Google не станет стандартом.

Каждый программист, начинающий разрабатывать под 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 объекта с последующим рендером на клиенте
— При прямом переходе рендер должен происходить на сервере
— Что бы все было легко и просто