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

Начав разработку два года назад, желание использовать встроенную базу данных для web приложения казалось весьма странным. В самом деле, зачем? Сейчас, когда появился проект node-webkit, объяснить это гораздо легче. Используя встроенную базу данных возможно разработать web приложение двойного назначения. Такое приложение сможет работать как в классической схеме клиент-сервер, так и с использованием node-webkit как обычное загружаемое приложение. Важной особенностью и в том и другом случае является то, что код базы данных является частью вашего приложения, что избавляет от многих проблем совместимости и установки.

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

Расскажу об этих проблемах и как их решал.

Я хотел бы рассказать вам об утилите, с которой вы сможете забыть о боли создания документации для Web API. О том как это сделать прошу всех под кат.

Некоторое время назад у нас назрела необходимость в разработке нового push-сервера для сервиса «Битрикс24». Предыдущий вариант, реализованный на базе модуля для Nginx, имел ряд особенностей, которые доставляли нам немало хлопот. В результате мы поняли — пора делать push-сервер. Здесь мы хотим рассказать о том, как это происходило.

Я очень люблю статические типы, поэтому TypeScript стал незаменимым помощником при работе с NodeJS или браузерным JS.

По долгу службы приходится иметь очень много дел с JSON, и здесь система типов TypeScript не помогает ничем, даже мешает, ведь компилятор сообщает об отсутствии ошибок, JSON.parse возвращает тип Any. Кроме того, TypeScript не поддерживает рефлексию, ввиду специфики работы, а значит, нет возможности проверить тип, основываясь на уже существующем коде. Также, до последнего времени, средств для мета-программирования не было вовсе.

Зачастую проверка корректности пришедшего JSON-объекта оборачивается громадным кодом в конструкторах классов, либо такими же конфигурационными файлами. Но, наконец-то, в TypeScript 1.5 появились декораторы.

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

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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

4 июля, вышло обновление безопасности с исправлением критической уязвимости для node.js и io.js. Суть уязвимости в том, что при конвертации буфера в UTF8 строку приложение может «упасть».

Привожу мой свободный перевод текста официального сообщения:

Во-первых, очевидно, что решение проблемы не идеально, но оно поможет нам сэкономить время на разработку лучшего решения. В США сейчас вечер и сейчас выходные, связанные с 4 июля (День независимости США).

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

Эта статья подводит промежуточный итог в разработке моих приложений для asterisk'а. Все началось в новогодние праздники, когда мне захотелось сделать быстрый голосовой набор на asterisk'е. Затем был реализован поиск направления по номеру звонящего (полезная штука для входящих на номера 8-800). Затем была пара заказных проектов. А недавно еще и LCR для asterisk. Все эти приложения разработаны с использованием библиотеки ding-dong, которая позволяет работать с AGI (Asterisk Gateway Interface) в node.js приложении.

Далее я хотел бы показать, что используя node.js и ding-dong, можно быстро разрабатывать полезные приложения для астериска.

На стремительно развивающийся рынок PaaS приходят все новые игроки. Не так давно в бой вступила IBM, представив широкой программерской общественности сервис Bluemix. Просто облаком с возможностью выполнения Push-to-Deploy уже никого не удивишь, и поэтому конкуренция переместилась из зоны «посмотрите, у нас тоже есть облако!» в сторону «у нас удобный интерфейс, готовые сервисы “из коробки” — и все это совершенно бесплатно, пока ваш проект не вырос». Под катом я покажу, как с помощью этой современной системы PAAS и всего нескольких строк кода сделать сервис, который будет внимательно следить за сайтом какой-нибудь онлайн-игры и присылать push-уведомления, как только появится любопытная новость.

Вступление

Привет всем хабровчанам, любителям Yii и Node.js.
Продалжаю серию статей про фреймворк Jii и его части. В прошлых частях мы рассмотрели части фреймворка, которые можно использовать без инициализации приложения, а именно — Query Builder и Active Record. Из голосования (а так же писем и комментариев) стало понятно, что продолжать стоит. И на этот раз мы будем говорить о архитектуре и структурных составляющих фреймворка Jii.

Оригинал: New io.js Features You May Not Be Using

Платформа io.js развивается быстрыми темпами, оказывая большое влияние на всю экосистему Node. За короткое время в io.js было внесено множество исправлений, улучшена производительность, а также добавлены новые возможности и функции.

Если Вы не следили за развитием io.js, ничего страшного — в данной статье мы вкратце представим основные возможности платформы. Рассматривать их мы будет по мере выхода, то есть от старых к новым. Где это будет нужным, дадим ссылки на соответствующую документацию (на английском языке). Описывая каждую новую функциональность, будем указывать ее первую версию. Код написан с использованием стандартных функций ES6, которые доступны в io.js. Итак, начнем…

Вступление

Привет всем хабровчанам, любителям Yii и Node.js.
Это вторая статья про фреймворк Jii (GitHub), в предыдущей статье мы рассматривали Объекты доступа к данным и конструктор запросов (Query Builder).
Как и обещал, в этой статье я расскажу про использовании Active Record.

Active Record

Вступление

Привет всем хабровчанам, любителям Yii и Node.js. Почему объединены любители PHP-фреймворка и серверного JavaScript?
Потому что Yii теперь доступен и на JavaScript (как для Node.js, так и для браузера)!

В этой статье мы рассмотрим Query Builder, полностью сохранивший API от Yii2 и работающий на Node.js.
Конструктор запросов — это лишь одна из реализованных частей Jii (не путать с Yii), в данной статье я специально не буду рассматривать фреймворк в целом, потому что его вполне можно использовать и частями.

Что такое Jii?

Jii — это компонентный JavaScript MVC фреймворк, который повторяет архитектурные решения легендарного PHP фреймворка Yii 2, в большинстве случаев сохраняя его API. Отсюда происхождение названия Jii — JavaScript Yii.

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

Деплойд — самый простой способ создать свой АПИ

Это просто как раз, два… ну вообщем вы счас все поймете:

1. Никаких бойлерплейтов
Всего лиш одной командой, вы можете запустить свой API. Это абсолютно пустой контейнер, который только и дожидается вас, чтобы вы заполнили его ресурсами. Работает из коробки — дополнительный код необязателен.

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

3. Панель управления
Добавляйте и управляйте вашими API ресурсами через интуитивный веб интерфейс панели управления.

4. Развертка в 1 шаг

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

Звучит красиво, но что собственно под капотом? А давай те глянем:

У опытного программиста, сталкивающегося с новой технологией для решения конкретной прикладной задачи, сразу возникает множество практических вопросов. Как правильно установить платформу? Где и что будет лежать после установки? Как создать каркас проекта, как он будет структурирован? Как разбивать код на модули? Как добавить библиотеку в проект? Где вообще взять готовую библиотеку, которая делает то, что нужно? Как и в чём отлаживать код? Как написать модульный тест?

Ответы на эти вопросы можно при желании легко найти в сети, но придётся перечитать дюжину статей, и на каждый вопрос ответов будет, скорее всего, несколько. Некоторое время назад мне понадобилось написать небольшой туториал по node.js, который бы позволил быстро запустить разработку и познакомить новых программистов в проекте с этой технологией. Рассчитан он на опытных Java-разработчиков, которые и язык JavaScript хорошо знают, но node.js как платформа для бэкэнда для них в новинку.

Думаю, что данная статья будет полезна не только разработчикам из мира Java, но и всем, кто начинает работу с платформой node.js.

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

Предположим, мы разрабатываем простой пакет для npm. Назовём его, например, storage (хранилище). Заранее предусмотрим возможность использования одного из нескольких типов хранилищ, например, FsStorage (файловое хранилище), MysqlStorage (MySQL-хранилище), MongoStorage (Mongo-хранилище).

Во всех современных системах сборки фронтенда есть режим watch, при котором запускается специальный демон для автоматической пересборки файлов сразу после их сохранения. Также он есть и gulp.js, но с некоторыми особенностями, делающими работу с ним немного сложней. Работа gulp.js основана на обработке файлов как потоков данных (streams). И ошибки в потоках не всегда можно перехватить, а когда ошибка случается, то будет выброшено неперехваченное исключение и процесс завершится.

Чтобы этого не происходило, и watcher мог игнорировать отдельные ошибки и запускаться снова и снова при сохранении файлов, в gulp нужно сделать несколько дополнительных настроек, о которых и расскажется в этой статье.

Тема актуальная. Для меня как для корпоративного телефониста лет пять-десять назад всегда была задача настроить функцию ARS на Panasonic TDA100/200/600 или LCR на LG LDK100/300. В общем, сделать так чтобы подешевле звонить было. Но времена меняются, и сейчас у многих компаний используется Asterisk, а я уже не настраиваю УПАТС Panasonic, LG и прочие.

В Астериске, всем известно, вся маршрутизация делается в диалплане. Но если у оператора много направлений и цена на каждое из них различна, то в диалплане получаются портянки на несколько страниц. Решения разные: кто-то разбивает по разным файлам диалплана, использует макросы, кто-то подключает к работе БД, кто-то выносит на отдельный сервис.

Я хочу поделиться своим решением: вынести поиск оператора с наименьшей стоимостью заданного направления в стороннее приложение на node.js, с которым Астериск взаимодействует посредством AGI.

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

Исходная позиция: разрабатываю и эксплуатирую с коллегами онлайн-систему, которая обслуживает сотни клиентов. Наша система работает на нескольких серверах, использует несколько БД, использует очереди сообщений, внешние сервисы для отправки смс и почты. Типичная ситуация? Вполне.

Что хочу получить?

Хочу получить более прозрачную систему для охвата всей картины подшефного хозяйства, чтобы видеть узкие места, видеть зависимости одних частей системы от других, знать, что ssh на одном сервере крайне важен для «вон того маленького обработчика», который работает по ночам на другом сервере.

+

Несколько дней назад состоялось заседание технического комитета проекта io.js, на котором принято решение о воссоединении с Node.js и дальнейшем совместном развитии под эгидой организации Node Foundation.