Node.JS *

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

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

Для подключения по websocket мы будем использовать SocketIOClientSwift

Скачать можно тут.

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

В нашем примере мы будем получать тикеты из системы технической поддержки которая работает на node.js

Предлагаю вашему вниманию перевод статьи "Neon: Node + Rust".

Javascript программистам, которых заинтриговала rust-овская тема бесстрашного программирования (сделать системное [низкоуровневое] программирование безопасным и прикольным), но при этом ждущих вдохновений или волшебных пендалей — их есть у меня! Я тут поработал немного над Neon — набором API и тулзов, которые делают реально легким процесс написания нативных расширений под Node на Rust.

TL;DR:

• Neon — это API для создания быстрых, надежных нативных расширений Node на Rust
• Neon позволяет использовать параллелизм Rust-а с гарантированной потокобезопасностью
• Neon-cli позволяет легко и непринужденно создавать Neon проект и дает легкий старт… и наконец...
• проекту требуется помощь!

Плохие отзывы в прессе о Node.js часто относятся к проблемам с производительностью. Это не значит, что с Node.js больше проблем, чем с другими технологиями. Просто пользователь должен иметь в виду некоторые особенности её работы. Хотя у технологии пологая кривая обучения, обеспечивающие её работу механизмы довольно сложные. Необходимо понять их, чтобы предотвратить появление ошибок производительности. И если что-то пойдет не так, необходимо знать, как быстро привести всё в порядок. В этой статье Даниэль Хан рассказывает о том, как 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-практики». Громкий заголовок только для привлечения внимания.