Node.JS *

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

Для астериска, наверное, только ленивый не писал cdr viewer. Таких решений полно: asterisk cdr viewer, agcdr,  asterisk cdr viewer mod (статья на Хабре), cdr-stats и еще много других, которых я не знаю.

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

Недолго поискав по гитхабу, я наткнулся на webcdr. Немного обработал его напильником: убрал лишнее, добавил http basic авторизацию и получил необходимый вариант cdr viewer'а. C привычным тетушке веб-интерфейсом в стиле Twitter Bootstrap. Тетушка довольна.



Далее немного деталей.

Вроде, все просто и ясно:

var module = require("./some_module.js");

module.f(); // запуск экспортируемой функции модуля
console.log(module.obj); // печать экспортируемого объекта модуля
module(); // запуск самого модуля

Что бы экспортировать что-то в самом модуле нужно прописать:

exports.f = function() { return 123; };
exports.obj = { name: "Foobar", age: 33 };

// или даже так, что вместе с предыдущими строчками
// в одном модуле не сработает!
module.exports = function() { return "I have not a name"; }

Почему не всегда работает?

Ответ на этот вопрос лежит в понимании работы функции require().

Как уже сообщалось ранее, Microsoft сделал пулл реквест с добавлением поддержки открытого JS-движка Chakra собственной разработки в Node.js. Разработчики Microsoft предложили сделать весьма спорное изменение, что вызвало ожесточенную дискуссию среди участников проекта: звучали обвинения в адрес MS, с последующими блокировками ветки обсуждения, а трезвая критика местами тонула среди чрезмерно восторженных комментариев. И несмотря на то, что сам пулл реквест до сих пор не был принят, Microsoft получил официальную поддержку сообщества Node.js.

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

Автор: Анастасия Белокурова, .NET Developer DataArt.

Я расскажу, как и зачем использовать облачную систему Azure Mobile Services для ваших мобильных приложений. Для этого мы разберем небольшое приложение, на примере которого увидим, как это всё работает, затронем и практику, и теорию.

Но перед этим давайте вспомним, каковы преимущества облачных технологий и какое отношение эти технологии имеют к мобильным устройствам.

Преимущества облачных технологий

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

Итак, почему же облака? Они предоставляют следующие преимущества вашему приложению:

• Масштабируемость.
• Надежность.
• Большой выбор сервисов.

Представьте, что вы запускаете небольшой интернет-магазин — сначала просто хотите проверить, будет ли он вообще востребован. Бюджет у вас небольшой. Поэтому вы пишете небольшое веб-приложение и размещаете его на своем компьютере, который не выключаете на ночь. К вашему сайту есть доступ извне, и он может выдержать, допустим, 10 пользователей одновременно. Со временем ваш сайт становится популярным, и вам уже нужно, чтобы он выдерживал 100 пользователей одновременно. Но ваш компьютер не способен справиться с такой нагрузкой. И тут вы начинаете думать, не превратить ли мне мою квартиру в серверную?.. Нет, это ужасно неудобно! Тогда вы покупаете сервера, предоставляемые хостингом. Теперь ваш сайт поддерживает 100 запросов в минуту и даже тысячу. Наконец в какой-то момент вы понимаете, что выходите на глобальный рынок, т. к. у вас очень много пользователей, круглосуточно, и сервера, которые вы купили, уже не справляются.

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

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

Заказчик в моем лице определил следующие требования:
1. Симуляция работы в Инстаграме как обычный пользователь, лайкание в одном треде (чтобы Instagram не забанил моего бота).
2. Возможность авто-лайкания произвольного количества аккаунтов с произвольной глубиной лайков.
3. Запуск через шедулер, работа в бэкграунде.

Выбор пал на nodejs. Почему nodejs? Потому на Perl'е (который я использую время от времени уже несколько лет) делать не хотелось, а nodejs привлек внятным менеджеров пакетов, нативной поддержкой JSON и вообще Javascript в браузере роднее чем какой-нибудь Python.

Корпорация Microsoft признала, что Node+ChakraCore работает более эффективно, чем NOde+V8. На днях редмондская компания отправила официальный запрос ( «pull request») на аппрув уже реализованной корпорацией поддержки ChakraCore в Node.js.

С самого начала своего существования Node.js всегда работал с V8 JavaScript, и эта связка работала весьма эффективно, обеспечивая функционирование многих real-time приложений, в чем Apache, nginx, Tomcat никогда не были особенно хороши. Сообщество Node.js процветало, а Node становился все более и более популярным в среде разработчиков. Крупные компании вроде PayPal, Yahoo, IBM и других присоединились к сообществу проекта.

Привет, мир!

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

Компания ABBYY создала хорошую программную оболочку для работы со словарями, однако не меньшим её вкладом в цифровую лексикографию стал побочный продукт разработки ABBYY Lingvo — язык словарной разметки DSL. Он давно уже вышел за границы Lingvo, стал самостоятельным стандартом и форматом для других словарных оболочек, в том числе одной из самых известных в своём роде — GoldenDict.

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

Одна из самых известных и плодотворных групп давно уже работает на сайте forum.ru-board.com. Со временем там накопилась как обширнейшая коллекция словарей, так и основательнейшая база знаний и инструментов в помощь их создателям и редакторам. Было написано множество скриптов и программ, набор которых отражает историю и изменения популярности языков программирования, более или менее приспособленных для обработки текста. Тут и Perl с Python, и языки пакетных файлов для оболочек, и макросы MS Word и Excel, и компилируемые программы на языках общего назначения.

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

На Хабре уже есть пару упоминаний об инструменте Frida («Frida-node или немножко странного кода», «Точки соприкосновения JavaScript и Reverse Engineering»). В одной статье уже упоминается использование Frida на практике, однако почти везде инструмент используют как фреймворк для реверс-инжиниринга и исследования функционала программ (может даже взлом).
 
Я же хочу рассказать о процессе превращения одной любимой для меня однопользовательской игрушки в полноценную, многопользовательскую.
 

Я — frontend разработчик и в последнее время мне все чаще приходится пользоваться нодой, будь то использование webpack-а для сборки проекта, либо настройка различных gulp тасков. Хоть у меня и нету большого опыта в использование ноды, со временем у меня накопилось три вещи, которые мне хотелось бы улучшить при работе с модулями:

• Избавиться от кучи require-ов в начале каждого файла
• Подгружать модули только тогда, когда они нужны(особенно это актуально для gulp тасков)
• Иметь возможность работать с локальными модулями проекта, как с внешними модулями, то есть вместо, например,
  вызова var core = require('../../deep/deep/deep/core/core'), вызывать этот же модуль вот так var core = require('core')

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

Привет всем жителям и гостям хабра и с новым годом! :)
В этой статье я хочу рассказать о том, с какими фичами Jii вступил в 2016-й год и что его в ждет в новом году.

Итак, начнем по порядку.

Чуть меньше года назад я написал заметку о попытке создать инструмент нагрузочного тестирования на Node.js используя встроенные возможности (модули cluster и net). В комментариях справедливо указали на необходимость анализа RPS и сравнении с другими бенчмарками. В результате сравнения я пришел к естественному выводу, что многопроцессовый сервис никогда не сравнится по производительности с многопоточным из-за очень дорогих издержек на обмен данными (позже мы убедимся в этом на примере)

В эти предпраздничные дни, когда отчасти должен проводить время на работе, но изменения в рабочие системы уже не вносятся, ибо «скоро праздники, кому нужны твои свежие баги?», можно заняться вырезанием звездочек и снежинок из бумаги и маленькими экспериментами.

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

Что получилось? Далее детали и небольшое видео.

Анализируя исходные коды прошлых проектов, рейтинг популярности прямых вызовов функций показал, что прямой вызов require() встречается в коде node-модулей почти так же часто, как Array#forEach(). Самое обидное, что чаще всего мы подключаем модули "util", "fs" и "path", чуть реже "url". Наличие других подключенных модулей зависит уже от задачи модуля. Причем, говоря о модуле "util", загружается в память node-процесса даже если вы ни разу его не подключали.

В прошлой статье Node.JS Загрузка модулей по требованию я поведал о возможности автоматической загрузкой модуля при первом обращении к его именованной ссылке. Если честно, на момент написания той статьи, я не был уверен в том, что такой подход не станет причиной странного поведения node-процесса. Но, уже сегодня с гордостью могу ручаться, что demandLoad() работает уже пол года в продакшене. Как мы его только не гоняли… Это и нагрузочное тестирование конкретного процесса, и работа demandLoad() в worker-процессах кластеров, и работа процесса под небольшой нагрузкой в течении долгого времени. Результаты сравнивались с использованием demandLoad() и с использованием require(). Никаких существенных отклонений в сравнении не было замечено.

Сегодня речь пойдет уже не о стабильности demandLoad(). Если кому интересно, задавайте вопросы в комментариях, сделаю скриншоты, могу рассказать о методах и инструментах тестирования, других возможностях использования подхода. Сегодня, как следует из заголовка статьи, мы будем избавляться от успевших уже надоесть require() в шапках каждого node-модуля.

Заранее отмечу, ни в коем случае не агитирую использовать предложенный метод в продакшене. Практика изложена для ознакомления и не претендует на статус «true-практики». Громкий заголовок только для привлечения внимания.

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

Ничто в таких топиках не выводит меня из себя больше, чем эта фраза. Она не помогает ничего понять, ничего не проясняет, а самое главное, в контексте топика, как правило абсолютно бессмысленна!

Привет всем.
Не так давно прочел статью Что нам стоит сайт распарсить. Основы webdriver API и вспомнил, что давно собирался довести хотя бы до относительно рабочего состояния одну забавную задумку. Руки все-таки дошли, а значит пора поведать, что же получилось.
Есть такая замечательная программа — Fiddler, позволяющая перехватывать и модифицировать http/https запросы. Есть замечательная штука под названием NW.js, она же node-webkit, позволяющая тыр… парсить разнообразные сайты в том числе. Вы красивы, я прекрасен — почему бы нам не подружиться?
Собственно, затея вот в чем: можно было бы, конечно, отдельно поднять Fiddler, написать в нем логику и гонять через него трафик с node-webkit-но это не так интересно. А значит, будем совмещать все под одной крышей, благо у Fiddler есть библиотека на C# — FiddlerCore.
Под ноду есть отличный модуль — Edge.js. Это такая хитрая штука, которая позволяет исполнять код C# (и не только). Есть под ноду? Замечательно, можно завести и под nw.js, благо даже мануал есть — да вот же он!

Это перевод статьи Крэга Баклера (Craig Buckler) «SitePoint Smackdown: PHP vs Node.js» и судейских решений Бруно Шкворца и Джеймса Хиббарда (Bruno Škvorc, James Hibbard) статьи Крэга Баклера.

От переводчика

Существует много статей на эту тему, с качественными характеристическими анализами и прогнозами производительности. Однако, мне все же хотелось найти такую статью, где профессиональные программисты делятся своими мнениями и пытаются что-то подсказать, предостеречь новичка, который только изучает PHP или NodeJS (cерверный JavaScript). Многие не любят PHP и говорят, что PHP создан, чтобы умирать (да, там есть сборщик мусора, который убивает наши переменные после выполнения скрипта, а не потому что его забросил Расмус Лердорф), однако, что теперь не учить PHP совсем, в то время как на нем работает 80% сайтов в интернете. Поэтому, если мы хотим быть профессионалами и пытаться хоть как-то расширить свой кругозор, нам нужно четко разделять задачи PHP и задачи NodeJS, а не сливать все в кучу.

«10 раундов боксеров разных весовых категорий»

Одним прекрасным днем Крэг Баклэр (Craig Buckler) на сайте SitePoint.com опубликловал сравнительный анализ PHP и NodeJS под названием «10 раундов», чтобы определить кто является абсолютным чемпионом. Однако, в это же время он отметил, что такой анализ является несколько спорным. Поэтому, для некоторого развлечения, он пригласил двух судей, которые внесли бы свою лепту в этот боксерский поединок. Он попросил Бруно Шкворца (Bruno Škvorc, редактор колонки PHP на сайте SitePoint.com) и Джеймса Хиббарда (James Hibbard, редактор колонки JavaScript на сайте SitePoint.com) прокомментировать каждый из раундов, удар за ударом — оценка.

Представители КРОК, Traffic Inspector, WebMoney Transfer и Softline рассказали, что принес 2015-й год в сферу веб-разработки. Эксперты перечислили важнейшие события индустрии и отметили основные тренды уходящего года.

Ключевые события и тренды

2015-й – это год утверждения стандарта HTTP/2 (предыдущая версия протокола была принята в 1999). Это год массового перехода на стандарт HTML-5 с устаревшего Flash, который уже не поддерживается большинством современных браузеров. Это год появления WebAssembly, который в дальнейшем позволит перенести требовательные к производительности приложения в Web, что по мнению Сергея Дорогина, ведущего инженера-разработчика Департамента информационных технологий компании КРОК, означает “начало нового мира”.

Большинство тенденций уходящего года в сфере веб-дизайна, связаны с ростом популярности гаджетов и распространением мобильного интернета. Среди них такие как использование адаптивной верстки вместо создания отдельной мобильной версии сайта. Один из основных трендов – минималистичный дизайн, заданный Apple, помимо этого эксперты пророчат долгоиграющую популярность материальному дизайну от Google.