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-файла с помощью маленьких патчей.

Сегодня я вам расскажу про одно очень интересное сообщество под названием NodeSchool. Данное сообщество продвигает обучение по платформе node.js

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



Такая организация имеет свои неоспоримые достоинства, например синхронизация игровых состояний клиентов на сервере, простота в реализации и почти фиксированные задержки до пользователя. Там где есть плюсы, обычно обитают и минусы — это ограниченная пропускная способность сервера и довольно большие задержки, если клиент находится далеко от вашего сервера. Как с ними бороться подробно написано в блоге 0fps.net и есть возможность эти проблемы довольно эффективно решать оставаясь в любимой «звездочке» — купить больше серверов, но что делать если вы студент вы ограничены в финансах и горизонтальное/вертикальное масштабирование для вас не вариант?

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

Небольшой рассказ о начальном погружении в Node.js и опыте работы с Rails-like фреймворком Sails.js

Эта статья не претендует на внимание искушенных разработчиков, поскольку является лишь описанием некоторых впечатлений начинающего Rails-разработчика о Node.js. Надеюсь, кому-нибудь будет полезно.

Node.js vs Ruby on Rails

В отличие от большинства разработчиков, я начинал с баловства с Node.js, и уже после погрузился в Ruby on Rails с помощью восхитительного курса Rails for Zombies и, затем, учебника по Ruby on Rails от Michael Hartl.
Все, что написано далее, есть ненаучное сравнение Node.js и Ruby on Rails.

Это Norton Commander? Это Volkov Commander? Это Dos Navigator? Это Far Manager?
Нет, это «Деодар» — новая рабочая среда для Линукс.
Деодар хостится на GitHub, основан на Node.js, написан на JavaScript плюс немного C++.
Распространяется по антилицензии Unlicense.org. Безвозмездно, то есть даром.
В данной статье на большом количестве картинок и малом количестве пояснений вы можете ознакомится с тем, что уже есть.
Да, «Деодар» — это такое дерево, Cedrus Deodara растёт высоко в горах, очень красивое.

Когда я только-только начал играться с Node.js, для меня существовала лишь одна вещь, которая доставляла мне дискомфорт. Занятно, но я говорю сейчас о module.exports. Говоря занятно, я намекаю на то, что это, всё-таки, одна из фундаментальных частей Node.js и она достаточно проста. Сейчас же, оглядываясь назад, я не могу объяснить почему меня это так стопорило… Просто помню, что этот момент был для меня не очевиден. Ну и, полагаю, что я один из тех многих, кто встретив его разок-другой, сначала только путался, прежде чем написал что-либо применив его.

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

var x = 5;
var addX = function(value) {
  return value + x;
};

Привычный доступ к переменной x и функции addX из другого файла невозможен. Это никак не связано с использованием var. Дело в том, что Node состоит из блоков называемых модулями, и каждый отдельный файл по своей сути — отдельный блок, чья область видимости изолирована от других таких же блоков.

В комментариях к посту про Underscore/Lo-Dash я упомянул, что среди библиотек, расширяющих стандартную библиотеку JavaScript, я предпочитаю SugarJS, который, в отличие от большинства аналогов, работает через расширение нативных объектов.

Это вызвало горячую дискуссию о том, допустимо ли расширять нативные объекты. Меня очень удивило, что практически все высказавшиеся выступили против.

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

В этом материале разбираются подводные камни JavaScript, известные и не очень, а также предлагаются методы защиты. Поэтому я думаю, что статья будет интересна и полезна любому JS-разработчику, независимо от его отношения к проблеме расширения нативных объектов.

Передаю слово Andrew Plummer.

---

Итак, Sugar — библиотека, которая модифицирует нативные объекты JavaScript. Подождите, разве это не во зло? — спросите вы, — вы что, не извлекли урок из горького опыта Prototype?

По этому поводу существует много заблуждений. Sugar избегает подводные камни, о которые спотыкался Prototype, и фундаментально отличается по своей сути. Однако этот выбор — не без последствий. Ниже разобраны потенциальные проблемы, вызываемые изменением нативных объектов, и изложена позиция Sugar насчет каждой из них:

1. Модификация объектов среды
2. Функции как перечисляемые свойства
3. Переопределение свойств
4. Конфликты в глобальном пространстве имен
5. Допущения насчет отсутствия свойств
6. Соответствие спецификации

MIT опубликовал исходники проекта Mylar — платформы для создания безопасных приложений, с шифрованием и
поиском по зашифрованным данным.

Broccoli является новой системой автоматической сборки. Её вполне можно сравнить с Rails asset pipeline, однако есть и некоторые различия: он запускается на Node.JS и не зависит от серверной части приложения.

После длинной вереницы 0.0.х альфа релизов, я только что выпустила первую бета версию, Broccoli 0.1.0.

Оглавление:

1. Быстрый пример
2. Мотивация / Особенности
3. Архитектура
4. За кулисами / Общий взгляд
5. Сравнение с другими системами сборки
6. Что дальше?

Недавно появился проект pako, это порт на яваскрипт известной библиотеки для компрессии и декомпрессии данных — zlib.

Очень любопытен результат тестов.