Node.JS *

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

Однако, есть и другой путь создания pdf документов: конвертирование из некоторого языка разметки с помощью соотвествующего инструмента. Данный способ будет эффективным и займет меньше времени на внесение изменений в pdf, если выбранный инструмент работает достаточно предсказуемо. Существует несколько подобных решений, но на нашем проекте мы остановили свой выбор на Wkhtmltopdf, которое генерирует pdf документ из HTML. Спустя год использования данного инструмента могу сказать, что выбор был сделан правильный, т.к. все потребности были покрыты с головой.

В данной статье я хочу поделиться библиотеками, позволяющими упростить работу c wkhtmltopdf в Node.JS.

Доброе время суток, хабраюзер! Сегодня мы попытаемся немного разобрать реактивность, которая лежит в основе одного из самых хипстерских фреймворков — Meteor.

Для начала приведем немного сухой теории из Википедии:
Реактивное программирование — парадигма программирования, ориентированная на потоки данных и распространение изменений. Это означает, что должна существовать возможность легко выражать статические и динамические потоки данных, а также то, что выполняемая модель должна автоматически распространять изменения сквозь поток данных.

К примеру, в императивном программировании присваивание a = b + c будет означать, что переменной a будет присвоен результат выполнения операции b + c, используя текущие (на момент вычисления) значения переменных. Позже значения переменных b и c могут быть изменены без какого-либо влияния на значение переменной a.

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

* велосипедируем — пишем свой велосипед, подглядывая на уже готовую реализацию.

Привет!

Отгремели фанфары, прошел звон в ушах от истязаний «евангелистов», модников в сфере фронтенд разработки. Кто-то ушел на sprockets, кто-то пустился во все тяжкие и стал писать свои велосипеды или расширять функционал gulp или grunt. Но статей по поводу популярных инструментов автоматизации процесса сборки – стало существенно меньше и это факт! Пора бы заполнить освободившееся пространство чем-то существенно иным.

Уверен многие слышали о webpack. Кто-то подумал «он слишком много на себя берет» и не стал дочитывать даже вводную статью на оффициальном сайте проекта. Некоторые решили попробовать, но столкнувшись с небольшим количеством примеров настройки — отверг инструмент решив подождать пару лет. Но в целом, разговоров «вокруг» ходит масса. В этой статье — хочу развенчать некоторые сомнения. Может быть, кто-то заинтересуется и перейдет на «светлую сторону». Вообщем желающие под кат.

Здравствуйте, любители нашего хаброблога и прочие читатели!

Мы планируем вновь отметиться на поле неувядающего Node.js и рассматриваем возможность издания этой книги:



Поскольку вполне понятен читательский интерес «а как он впихнул все это в двести страниц, и зачем мне это нужно»? под катом предлагаем перевод доскональной статьи Томислава Капана о том, зачем на самом деле нужен Node.js.

Решил создать модуль (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 атак, если таковые случатся. Потому что лучше встретиться с реальностью, нежели сидеть скрестив пальцы. Время поджимает, особенно для США, где сейчас праздники, что делает это все кошмаром для людей, развертывающих больший проекты. Но этот призыв мы делаем с полезной информацией.