Node.JS *

Автор: Анастасия Белокурова, .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.

Вы пишите сервер на Node.js, который принимает входящие TCP-соединения и ведёт с клиентами нетривиальный диалог по нестандартному протоколу? Возможно вам будет интересен пример, который я развиваю в своих проектах. Что я имею ввиду под нетривиальным диалогом?

Давайте сравним.

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

А поможет нам в этом NodeJs и npm модуль modesl для взаимодействия с Freeswitch.

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

---

Предыстория

Ранее мой опыт работы с платформой был близок к нулю, поэтому чтобы разобраться в огромном количестве сервисов платформы, я снова обратился к своему знакомому из IBM. Мне казалось очевидным использовать сервис Message Hub, но в итоге оказалось, что для решения нашей задачи лучше подойдет MQ Light. Основные причины:

• тариф в бесплатные 10 тысяч сообщений в месяц
• хорошая масштабируемость
• простой в использовании API

Знакомство с Electron

Официальная страница проекта Electron.

Изначально Electron был разработан для редактора Atom компанией GitHub.

Electron (ранее известный как Atom Shell) позволяет нам создавать кроссплатформенные приложения, используя HTML, CSS и JavaScript. Что является большим плюсом для команд, которые занимаются веб-разработкой. Отпадает надобность искать новых разработчиков для создания десктопных версий уже существующих проектов.

Electron являет собой прекомпилированый бинарник и библиотеки, нужные для работы приложения и доступа к native API операционной системы. Он включает в себя Node.js, направленный на работу в десктопной среде, и минимальную версию браузера Chromium, контролируемого JavaScript.

Продолжаем знакомство с AllcountJS — фреймворком для быстрой разработки приложений на платформе NodeJS. В этой статье мы рассмотрим пример реализации кастомного интерфейса с использованием AngualrJS и jade, а также некоторые возможности конфигурирования, о которых мы ещё не упоминали.

POS (Point Of Sale) — в прямом смысле точка (место) продажи, но обычно этот термин обозначает рабочее место кассира вместе с торговым оборудованием. Такие терминалы находятся почти в каждом месте где нам что-нибудь продают. И сейчас мы создадим простое приложение, которое позволит вести список товаров с остатками и создавать записи о продажах.



Как обычно, на результат можно посмотреть в демо-галерее.