Node.JS *

Введение

В данные статье я хочу вам рассказать о моем способе загрузки файлов на сервер Node.js с помощью JQuery Ajax. Да, я понимаю что есть уже и другие решения, например JQuery File Upload, но все таки иногда хочется сделать что-то уже существующее, для того чтобы понять как это все устроено. Данное решение является учебным примером, все замечания по поводу кода или предложения по его улучшению оставляйте в комментариях.

Что будем использовать

1. Bootstrap
2. JQuery
3. Модуль для Node.js Multiparty

В этом посте я хочу обобщить и поделится полученным опытом при разработке библиотеки node-queue-lib. Я расскажу о технологиях, которые помогли мне довести дело до финального конца — работоспособного кода, который уже работает на одном из моих сервисов. Особенностью данной библиотеки является кросс-платформенный клиент, т.е. клиент работающий в node.js и браузере и основан на одном и том же коде. В посте будут описаны следующие инструменты, без которых разработка этой библиотеки превратилась бы в ад:

• Тестирование (jasmine_node)
• Покрытие кода тестами (istanbul)
• Сборка клиенткой части библиотеки (browserify)
• Автоматизированное тестирование клиента (phantomjs)
• Поиск утечек памяти (memwatch)

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

И дополнительно, повторю, что статья обзорная, и не ставит целью научить Вас виртуозно пользоваться всеми перечисленными инструментами. Я лишь покажу дверь, но откроете Вы её сами…

2011 год — мы выходим на рынок со своей информационно-аналитической системой ist-budget.ru, параллельно мониторим новые стартапы по тематике госзакупок, и однажды внимание в одном из каталогов привлек проект анонимного чата nekto.me. Зашли, ознакомились, на сайте в режиме онлайн было около 1К юзеров, посмотрели похожие проекты: chatvdvoem.ru (там тоже всегда в районе 1К), американский аналог omelge.com выглядел покруче и показывал 25К. Некоторые ресурсы работали с 2009 года, кто-то вышел на этот рынок позже. Кто именно первый в истории запустил анонимный чат — мы не знаем, но в идее явно было и есть что-то необычное.

На Хабре тема анонимных чатов поднималась неоднократно, были разные мнения: кто-то говорил о бесперспективности подобных проектов, другая часть аудитории поддерживала, но факт оставался фактом: ежесуточно подобные сайты посещают от 20К до 600К пользователей. Это значит, что у подобных проектов есть своя аудитория и спрос.

Примечание от переводчика:

Я решил перевести эту статью в основном из-за личности автора. TJ вложил очень много усилий в развитие Node.js и его инфраструктуры, он автор таких проектов как express, jade, mocha, stylus, автор 550 репозиториев на npm. Существуют также теория, что под этим именем скрывается группа людей.

Как бы то ни было, JavaScript и Go сообщества в ближайшие время ожидают изменения.

Покидая страну Node.js

Я сражался с Node.js достаточно долго, что бы перестать получать от этого удовольствие, это мое официальное прощание! И, что еще важнее, я ищу людей, которые смогут поддерживать мои проекты!

Node отлично справляется с некоторыми вещами, но, к сожалению, это не самый подходящий инструмент для того, что мне сейчас интересно. Я все еще планирую использовать его для сайтов, но если вы хотели бы заняться поддержкой одного из моих проектов, дайте мне знать. Просто оставьте комментарий с вашим именем на Github, ссылкой на npm и названием проекта. Как обычно я прошу не делать больших изменений в существующих API: создать новый проект будет проще.

Я также продолжу поддерживать Koa.

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

После прочтения статьи «Генераторы в node.js (новый способ борьбы с лапшой)» меня не покидала мысль о том, что можно обойтись без лапши-callBack'ов, но я никак не мог смириться с тем, что для каждой асинхронной функции, которую мы хотим вызвать, нужно писать функцию-обёртку.

И тут родилась идея! Очень простая, а суть её в том, что внутри генератора имеется ссылка на функцию n, которую мы передаём асинхронным функциям как callBack, приостанавливаем генератор при помощи yield, а затем наша функция n продолжает выполнение генератора, передавая в него массив, сформированный из аргументов, с которыми она была вызвана.

Заинтересованных прошу под кат.

Привет Хабр! Пару месяцев назад я захотел провести тестирование производительности некоторых сетевых фреймворков, c целью понять насколько большая разбежка между ними. Надо ли использовать Node.js там, где хотелось бы Python с Gevent или нужен Ruby с его EventMachine.



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

Синопсис

В этой статье собраны полезные для новичков советы по использованию различных возможностей MVC фреймворка SailsJS. Эти советы могут быть полезны новичкам тем, что открывают некоторые «секреты» которые могут им быть незнакомы — из-за этого многие пишут множество костылей и велосипедов, это может заставить погаснуть их энтузиазм в изучении этого полезного инструмента только потому что их основные силы будут направлены на обычную рутину которую можно запросто обойти с помощью простых и удобных методов. Интересно?

Синопсис

Эта статья содержит полезные для новичков методы и способы разработки на SailsJS, которые могут быть неизвестны или непонятны тем кто только ступил на путь разработки в этом удобном и многофункциональном фреймворке. Это может быть все — начиная от обычных команд, генераторов или сервисов, и заканчивая встроенными методами запросов. Здесь собраны полезные мелочи платформы которые смогут защитить вас от написания костылей или велосипедов. Заинтересовало?

Синопсис

• Первая Часть

Ранее мы изучили написание основы для нашего блога, при написании основы мы ознакомились с организацией статики, составлением модели и написанием кода контроллера. Узнали как можно работать с конфигурациями путей (routes.js), и как работать с представлениями в SailsJS. Во второй части о написании простого блога на SailsJS, мы рассмотрим следующие пункты: Пользователи: создание. Сессии: создание (вход), разрыв (выход). Написание Админ Панели, и работа с политикой и ограничениями доступа.

Введение

Решения, написанные на JavaScript становятся сложнее из года в год. Это, несомненно, обусловлено разрастанием такого прекрасного зверя, как веб. Многие из нас сейчас работают с JavaScript модулями — независимыми функциональными компонентами, которые собираются вместе и работают как единое целое. Так же такой подход позволяет нам реализовать взаимозаменяемость компонентов, не прикончив попутно код. Многие из нас использовали для этого паттерн AMD и его реализацию в RequireJS.

Файловых менеджеров много, но есть один, о котором, думаю, будет многим интересно узнать. Ведь он двухпанельный, работает в браузере, оснащён редактором (с подсветкой синтаксиса) и консолью, состоит из клиента и сервера, а написан на JavaScript/Node.js.

22 ноября 2005 года Михаил Тулупов (2:5020/2015.39), обращаясь ко мне в эхоконференции Ru.Fidonet.Today по поводу моих замыслов гипертекстового Фидонета, так присоветовал:

Очень желательно стандартно поддержать какой-нить несложный векторный стандарт (SVG/EMF/EPS как вариант). Сильно сэкономит траффик.

И действительно, принятый в Фидонете в ту пору обычай использовать псевдографику требовал заметно больше траффика под свои нужды, чем SVG. Вот почему с тех пор я считаю, что в идеале Фидонету необходимо быть не только гипертекстовым, но также и векторным — о чём я с тех пор сообщал сперва во блогозаписи «Два идеала прозреваемых, но покамест не достигнутых», а затем и в других местах.

Что такое гипертекстовый векторный Фидонет? — в узком смысле это возможность перейти в Фидонете к векторному файлу по URLу (то есть по стандартному адресу) этого файла, для чего URL придётся либо встретить в виде гиперссылки (и жмякнуть её мышóю), либо вбить в строку адреса в фидобраузере вручную. Откроется векторная картинка, размер которой можно будет произвольно менять вместе с размерами того окошка браузера, в котором рисунок содержится — то есть совершенно так же, как и в Интернете:



Перед вами — анимированный ряд скриншотов сегодняшней сборки моего фидобраузера, которому я дал название «PhiDo» (а точнее — «φ道»); как видите, сегодня (совершив 245 коммитов со дня прошлогоднего начала разработки исходного кода PhiDo) мне удалось вплотную приблизиться к вышеозначенному идеалу.

28 мая библиотека для создания приложений реального времени на Node.js Socket.IO доросла до версии 1.0. Socket.IO возникла практически сразу же после появления Node.js и быстро стала одним из самых популярных и востребованных проектов экосистемы Node. Socket.IO реализует коммуникацию сервера и клиента в реальном времени с помощью Web Sockets, а при отсутствии этого API в старых браузерах эмулирует сокеты с помощью других доступных технологий — сокетов Adobe Flash, запросов AJAX или JSONP.

Синопсис

Эта статья предназначена для начинающих свой путь в разработку на NodeJS, и знакомит новичка с разработкой на этой платформе с использованием фреймворка SailsJS. В статье, будет рассматриваться процесс разработки простого блога, с сопутствующими пояснительными материалами, цель которых описать начальные навыки работы с этим фреймворком — который безусловно является отличной основой для любых проектов на NodeJS. Для лучшего усвоения материала желательно иметь основные представления о языке программирования Javascript, и его серверной реализации NodeJS, а также как минимум первичное представление о схеме MVC которая является основой Sails. Для лучшего понимания фреймворка вы можете почитать документацию на официальном сайте Sails, а также посмотреть касты описывающие работу с Sails достаточно подробно. При написании статьи я старался написать материал как можно более проще и понятнее, опытным пользователям эта статья не расскажет ничего нового, и некоторые приемы могут показаться неэффективными.

При разработке js и css файлы удобнее держать в исходном виде, а при в продакшене их необходимо минизировать и соединять. Существует несколько систем сборки, однако, пользоваться ими весьма сложно и проблематично. По крайней мере я устал от них до такой степени, что решил написать свой сборщик. Получился он очень удобным, поэтому я решил с вами им поделиться.

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

О чём речь?

О JS модулях, которые можно использовать в браузере и на сервере. Об их взаимодействии и внешних зависимостях. Меньше теории, больше практики. В рамках курса молодого бойца мы реализуем простое и весьма оригинальное приложение на базе Node.JS: ToDo-лист. Для этого нам предстоит:

1. «Завести» кроссплатформенные модули на базе фреймворка Express;
2. Научить их работать с платформозависимыми коллегами;
3. Создать транспортный уровень между клиентом и сервером;
4. Таки сделать ToDo-лист;
5. Осмыслить результат.

JavaScript в последние годы набрал нешуточную популярность, в связи с чем его подводные камни также стали явственно видны. Справедливости ради, стоит отметить, что любой язык в некоторой мере имеет как своё legacy, так и подводные камни.
Конкретно JavaScript обладает целым огородом камней. Подводным огородом.

На практике, подводные камни встречаются не так часто, напротив, хороший код склонен быть описанным в рамках здорового подмножества языка. Это также является и причиной, почему запомнить все заковырки языка достаточно сложно: они не являются необходимыми для каждодневной практики. Тем не менее, разнообразные граничные случаи использования языковых конструкций это отличная разминка для ума, а также стимул узнать язык немного лучше. Сегодняшний экземпляр попался мне на глаза в процессе прохождения JavaScript Puzzlers.

Меня заинтересовал вопрос номер 3:
Каков результат этого выражения (или нескольких)?

[ [3,2,1].reduce(Math.pow), [].reduce(Math.pow) ]

В качестве ответа авторами, на выбор, даются следующие варианты:
* ошибка
* [9, 0]
* [9, NaN]
* [9, undefined]

Попробуйте и вы, без запуска интерпретатора, пользуясь только своим умом ответить на этот вопрос.

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

А в этой статье вы найдёте:
* Разбор задачки.
* JavaScript reduce с чисто практической точки зрения.
* Несколько акробатических этюдов с reduce (reduce с академической точки зрения).
* Репозиторий с плюшками к статье.
* Несколько других reduce.

Если вы работаете над Node.js приложением, то есть все шансы, что у него появится некое API, которое будет использовано вами или кем-то другим. Наверняка это будет REST API и перед вами возникнет дилемма — какие инструменты и подходы использовать. Ведь выбор так широк…



Благодаря невероятно активному сообществу Node.js, количество результатов на NPM по запросу «rest» зашкаливает. У каждого есть свои реализации и подходы, но у некоторых есть что-то общее в создании REST API на Node.js.

Проблема

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

{{if app.version==versions.main}}
<!--один html код-->
{{else if app.version==versions.custom1}}
<!--другой html код-->
{{else if app.version==versions.custom2}}
<!--и ещё html код-->
{{endif}}

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

Привыкнув к удобным методам управления версиями приложения с помощью инъекции зависимостей, когда в зависимости от версии используются разные реализации интерфейсов, я решил изобрести свой велосипед для XSLT-подобного управления версиями html файлов: grunt-html-inheritance. Он позволяет подменять кусочки базового html-файла с помощью маленьких патчей.