Node.JS *

Вообще-то у меня PhpStorm, но, думаю, все будет работать и в WebStorm.

Запускаем в командной строке

cd <path to Gruntfile>
node --debug-brk=64005 $(which grunt) img2base64

Где img2base64 — название нужного задания. Можно опустить этот параметр, чтобы запустились все задания.
Получаем debugger listening on port 64005

Совсем недавно мне на глаза попался очень амбициозный проект Meteor. Меня подкупила его простота и скорость разработки приложений на нем. В этой статье будут показаны некоторые «хитрости» и полезные советы такие как: установка кастомных пакетов, добавление в проект плагинов jquery, развертывание проекта на боевом сервере и прочее.

Этот пост предназначен для тех кто уже имеет минимальный опыт в работе с Meteor.

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

Что нового?