Node.JS *

Релиз 1.5.0, Buffer.indexOf(), Tessel 2 и многое другое.

Во многих веб-приложениях требуется разбор URL, такой как извлечение доменного имени, имплиментация REST API или поиск пути к файлам изображений. Типичная структура URL показана на рисунке ниже:

Здравствуйте, меня зовут Александр, и я пишу велосипеды по выходным программист.



В нашем клубе анонимных велосипедостроителей считается особым шиком не только сотворить очередной шедевр, но и поделиться им с сообществом. Так как существует просто огромное количество статей о том, как выложить проект на Github или npm, я не буду в 100500 раз пересказывать одно и то же.

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

Команда «npm install» в менеджере пакетов npm чаще всего употребляется для локальной установки зависимостей некоторого модуля, совершаемой в его подкаталоге «/node_modules».

Однако возможен и запуск этой команды с ключом «-g» (от слóва «global»). Он обеспечивает установку указанного ей пакета в некоторое глобальное (то есть общее для всей системы) место. Кроме того, в PATH (для последующего запуска из любого желаемого каталога) оказывается прописанною та команда, которая была указана в свойстве «"bin"» в файле package.json у установленного пакета.

Таким общим местом, согласно документации, под Windows служит подкаталог «/node_modules» в каталоге установки Node. В остальных же системах таким общим местом чаще всего оказывается каталог «/usr/local/lib/node_modules» (тогда как Node там устанавливается в каталог «/usr/local/bin»).

Обыкновенно этот подход употребляется для глобальной установки различных утилит, предназначенных для запуска из командной строки. Вот некоторые примеры:

• Команда «npm install jshint -g» обеспечивает появление в PATH команды «jshint», служащей для запуска JSHint.
   
• Команда «npm install browserify -g» обеспечивает появление в PATH команды «browserify», служащей для запуска Browserify.
   
• Команда «npm install less -g» обеспечивает появление в PATH команды «lessc», служащей для запуска Less.js.

Однако на CLI (на командной строке) свет клином не сошёлся — и читателям Хабрахабра должно уж вполне быть известно, что приложение на языке JavaScript, употребляющее API Node.js, можно снабдить и GUI (графическим интерфейсом пользователя), сочинённым на языках HTML и CSS. Для этого придётся и запускать такое приложение вместо Node на том движке, который до прошлого года назывался node-webkit, а в нынешнем (2015) году оказался 14 января переименованным в nw.js.

Ваши GUI-приложения также могут глобально быть установлены в системе из npm-пакета при помощи npm. Давайте поговорим об этом.

Телефонный справочник для Active Directory

Для тех, кто статью читать не захочет, сразу репозиторий на github.

А остальных под катом ждёт бессвязная и бессмысленная история о том, как я дошёл до жизни такой, при помощи node-webkit, написал приложение, которого джва года ждал.

В наше время при помощи JavaScript и HTML можно сделать практически всё. А благодаря Node-WebKit (недавно переименован в NW.js) можно делать даже десктопные приложения, которые выглядят, как нативные и имеют доступ ко всем частям ОС. Сегодня мы покажем, как создать простое десктопное приложение при помощи Node-WebKit, используя jQuery и несколько модулей для Node.js.

Node-WebKit — комбинация Node.js и встроенного браузера WebKit. Код JavaScript выполняется в особом окружении, из которого есть доступ и к стандартному API браузеров, и к Node.js.

Релиз 1.3.0, MongoDB, планы развития и многое другое.

В прошлом году понятие «внебраузерный JavaScript» чаще всего означало движок Node.js (а не, допустим, Rhino или SpiderMonkey, сильно уступающие ему в популярности в этой области) или какой-нибудь итог его встраивания (например, node-webkit).

В нынешнем году в игру вступают форки Node (например, io.js), и их также начинают встраивать — например, проект node-webkit переименовался в nw.js, потому что теперь он использует не Node, а io.js (да и не WebKit, а Blink — с тех давних пор, как Chromium перешёл на этот движок).

Для программистов это означает, в частности, что может отвалиться (или, наоборот, появиться) поддержка той или иной операционной системы. Давайте поговорим об этом.

Какие операционные системы перестают поддерживаться?

Во-первых, первые версии io.js нельзя было установить на Windows XP, нельзя было установить и на Windows 2003. Ещё в середине января казалось, что с этим ничего нельзя поделать: объяснение «io.js компилируется в Visual Studio 2013 Windows Desktop Edition, потому что движок V8 стал полагаться на возможности C++11» воспринималось как приговор — однако затем разработчики поправили дело, так что в файле CHANGELOG.md ветви v1.x можно прочесть, что поддержка этих версий системы Windows возвратилась в io.js, начиная от версии io.js 1.0.3 (20 января).

Подобно кругам по воде, эти изменения прошли по всей экосистеме движков; например, в nw.js версии 0.12.0-alpha3 на поддержку ещё можно надеяться (хотя лично я ещё не успел погонять эту версию на Windows XP), а в предыдущих альфа-версиях её точно нет (потому что они основаны на более ранних версиях io.js).

Во-вторых, KaneUA 19 февраля упомянул, что io.js не поддерживает тридцатидвухбитные версии OS X, в отличие от Node.

Поддержка каких операционных систем может появиться?

Доброго времени суток, всем! Кто-то умный, не помню в какой статье именно на Хабре, буквально недавно размышлял о процессе разработки с явным призывом автоматизировать все, что только можно автоматизировать. И лучше один раз потратить время на автоматизацию, чтобы потом экономить его на протяжении всего проекта.

У веб-разработчиков есть прекрасный инструмент для автоматизации массы задач, который называется Grunt. И моя страсть к таксономии заставила себя собрать огромную коллекцию почти из 100 ценных плагинов для этого сборщика. Думаю многие кто уже использует Grunt найдут для себя что-то нужное, а кто нет, глядя на возможности, получит хорошую мотивацию установить его и понять как эта штука работает.

А еще я выложил подборку на GitHub, чтобы каждый мог пополнить коллекцию.

Локализация на 29 языках, релиз 1.2.0, и многое другое.

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

6 февраля вышла новая версия Node.js v0.12. Это был длительный и трудный процесс, не без потерь для NodeJS, в результате которого от основной ветки отделился io.js, но, тем не менее, список нововведений довольно внушительный. Давайте поглядим.

Streams 3

Как обещают разработчики, реализация потоков теперь работает так, как это и ожидается. Причем самое главное, что старые API, введенные в v0.10, не поменялись.

Добавлен механизм cork/uncork для приложений, которые несколько раз синхронно пишут в поток. .cork() включает буферизацию для всех записей в поток, .uncork() же сбрасывает весь буфер.

@io.js_ru это аккаунт сообщества, занимающегося русской локализацией io.js.

Мы будем публиковать здесь переводы официальных материалов, а также другие статьи о io.js. Кроме того, каждую пятницу мы будем публиковать еженедельные новости обо всём, что связано с io.js.

Кстати, мы ищем переводчиков! Если вы хотите помочь нам — напишите о себе issue в нашем GitHub-репозитории.

Предлагаем вашему вниманию перевод статьи io.js Week of February 6th 2015 от @iojs на Medium.

Atom и nw.js перешли на io.js, Linux Tracing, а также многое другое.

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

На Хабре есть как минимум 2 еженедельных обзора мира фронтенда. Они классные, но пишут про весь фронтенд. А я пытаюсь больше уделять внимание JavaScript.

Если понравится — пишите, буду продолжать. Если нет — тоже пишите.

Когда появился node.js, многие web-разработчики стали задумываться о возможности использовать один и тот же код как на клиенте, так и на сервере. Сейчас существует несколько фреймворков, ставящих подход «пишем код один раз, используем везде» во главу угла, время от времени появляются новые. Вот и я не смог пройти мимо, пишу подобный микро-фреймворк — bnsf. Он предназначен для тех, кто предпочитает создавать front-end своих приложений по БЭМ-методологии, пользуясь соответствующим набором технологий и инструментов.

Давайте попробуем начать писать front-end для простого одностраничного web-приложения, используя bnsf. Чтобы не отвлекаться на создание back-end части, будем использовать в качестве back-end'a API vk.com. Наше приложение будет состоять всего из двух страниц, главной — с формой поиска пользователей по идентификатору — и вторичной, на ней будем выводить информацию о выбранном пользователе.

«Свершилось! Node.js получило развитие в виде форка io.js! Привет ES6! Привет новый V8!» радовались разработчики. Полез смотреть с надеждой, что вот сейчас, начав с нуля, ребята исправили фундаментальные косяки!

Какие фундаментальные ошибки допущены и почему без их исправления промышленный масштаб является спорным или попросту недостижимым. Это не статья-страшилка, как её можно понять, это просьба о помощи, т.к. нода показательно застопорилась, и надежда только в данном проекте.

В посте речь пойдет о написании утилиты для нагрузочного тестирования HTTP сервисов на Node.js, а также описание самого инструмента и области его использования.

На конференции OpenWorld 2014 корпорация Oracle объявила о том, что она работает над собственным Node.JS-драйвером для своей базы данных. На прошлой неделе был открыт его исходный код под лицензией Apache 2.0.

Драйвер включает в себя не только стандартные средства для исполнения SQL-запросов и PL/SQL-кода, но и инструменты для прозрачной работы с объектами JavaScript и массивами, продвинутые средства для работы с транзакциями и встроенными в Oracle инструментами масштабирования. Например, можно быстро прервать неудачную транзакцию на событие от сервера о невозможности корректно закончить работу, позволяя Node.js-приложению быстро переключиться на другую базу данных без потери пользовательских данных.

Много рассказывать о том, что такое TypeScript, не буду. На мой взгляд, это уже устоявшаяся и хорошо зарекомендовавшая технология, которая предоставляет возможности программирования, которых не хватало раньше в JavaScript. Самыми основными возможностями языка, на мой взгляд, стало более четкое ООП и строгая типизация. И за эти качества я этот язык полюбил и он гармонично вписался в мои проекты.

Все начиналось с того, что я в командной строке вызывал компилятор после каждого изменения проекта и пересобирал проект. Это было жутко не удобно и очень сильно замедляло разработку. Для grunt было расширение grunt-ts которое решало мои задачи и я им какое-то время пользовался. У компилятора TypeScript есть одна особенность (не бага и не фитча, политкорректность), которую во всех расширениях, которые я перепробовал, не учитывалась. Это жутко мешало и заставило писать свой код. grunt-tsc — расширение для grunt, позволяющее собирать проекты на TypeScript, о нем я и хочу рассказать.

Что и зачем

Понадобилось мне однажды спарсить с одного сайта информацию. Взял я в руки Node.js и взялся за дело.
Сайт состоял из разделов, каждый раздел состоял из страниц. Для обработки одного раздела приходилось делать много запросов, по количеству страниц.

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

Далее я вспомнил, что надо парсить разные разделы этого сайта и понял, что становится уже слишком неудобно. Поэтому сделал инструмент Conveyor, умеющий обрабатывать некие «элементы данных» (т.е. применять функцию-обработчик к заданных объектам) с временной задержкой между обработкой. Удобным это оказалось и для «тяжёлых» вычислений, которые могут долго выполняться в цикле.

Код Conveyor лежит на гитхабе, поставить можно через npm (называется dataconveyor). Более структурированная справка также на гитхабе. Использовать его можно как угодно и где угодно, без ограничений.

Ниже описание инструмента Conveyor.