Решил создать модуль (C/C++ Addons) для NW.js для работы с Рутокенами и поделиться с сообществом кодом, а так же пригласить вас поучаствовать в этом Open source проекте.

Суть идеи в том, чтобы можно было использовать все возможности Рутокена в NW приложении с помощью чистого и понятного JavaScript, а также этот модуль может быть использован в Node.JS или io.js.

API RutokenJS

• CKR initialize()
• bool isInitialize()
• CKR finalize()
• object countSlot()
• object getLibInfo()
• object getSlotInfo(int slot)
• object getTokenInfo(int slot)
• object getMechanismList(int slot)
• object getObjectList()
• CKR login(int slot, string pin)
• CKR loguot()
• object random(int size)
• CKR initToken(int slot)
• CKR openSession()
• CKR closeSession()
• CKR closeAllSessions()
• object getSessionInfo()
• CKR getOperationState()
• CKR setOperationState()

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



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

В популярной платформе для быстрого создания веб-приложений скоро появится официальная поддержка SQL. Ранее разработчики неоднократно отказывались это делать, мотивируя тем, что SQL не вписывается в философию проекта. Однако, настойчивость сообщества сделала своё дело и уже сейчас вы можете попробовать предварительную реализацию поддержки SQL в Meteor. Все подробности — под катом!

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

В начале был Netscape. И возжелал Netscape выполнять Scheme-код в браузере Netscape Navigator. И наняли они Брендана Айка (Brendan Eich), чтобы он в поте лица своего работал над этим. Но потом они передумали и решили, что Java хотят они. И вот, рождён был JavaScript. И было это (достаточно) хорошо.

Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера. И возник Node.js. И npm. И люди возрадовались.

И стали люди писать веб-сервера на JavaScript, и запускать вертолёты с JavaScript на борту, и водружать его на планшеты и смартфоны, и встраивать его в термостаты и холодильники, да и во всё, во что их душа желала. И распространился JavaScript весьма и весьма широко. И презирали Нормальные Программисты™ (Serious Developers) простых людей, пишущих на JavaScript, но простые люди продолжали писать на JavaScript всё больше и больше.

И ждали люди Слово, способное вместить в себя всю широту проникновения JavaScript, ибо слово «JavaScript», как оно есть, более не вмещало той широты. И изрёк Чарли Роббинс (Charlie Robbins) мысль, что термином «Isomorphic JavaScript» можно назвать JavaScript-код, выполняющийся и в браузере, и на сервере. И никто нафиг не понимал значения сего, но, вместо просто программирования на JavaScript, люди стали программировать на изоморфном JavaScript.

Секундочку, что?

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

Бот был написан. Я заметил, что потребление им памяти росло с каждым запросом к API, уличив в проблеме тяжеловесный Request, я решил попробовать написать свой модуль для HTTP запросов, максимально простой, легковесный и быстрый.

Хочу представить вашему вниманию boilerplate (skeleton) на базе React.js + Backbone для быстрого старта разработки приложения любой сложности. Эта связка помогла нашей команде в срок сделать сложное приложение с минимальным количеством проблем а простота позволила быстро подключать новых разработчиков в процесс.

Пакет node-red-node-what3words доступен для установки с помощью npm. Он предназначен для конвертации геопозиции в адрес what3words и наоборот. Если у вас уже есть ключ для what3words API, можно приступать к установке.

Современные хостинг-системы (Heroku, Amazon etc.) предоставляют широкий выбор устройств и настроек для проектирования архитектуры балансировки нагрузки на сервер. Вы можете настроить как более простой Round Robin-алгоритм для последовательной разгрузки сервера, так и более сложную систему, учитывающую количество instanc'ов, текущую нагрузку, среду окружения и другие факторы.

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

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

Как-то давно мы задумали написать один проект для 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. Итак, начнем…