Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 6719 сообщений
Cообщения с меткой

web - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Node.js и JavaScript вместо ветхого веба

Вторник, 23 Августа 2016 г. 09:20 (ссылка)

Вступление



Эта статья про экспериментальный технологический стек общего назначения. Она не просто дублирует мой доклад на конференции ОдессаJS 2016, но содержит все то, что в доклад не поместилось из-за недостатка времени и исключительного масштаба темы. Я даже перезаписал доклад голосом по тексту статьи и это можно послушать, а не читать. С этой темой я уже выступил в Уханьском Университете (Китай), а в Киевском Политехническом Институте провел целую серию семинаров в 2015-2016 годах. Основная идея состоит в том, что проблемы фрагментации технологий могут быть решены, если спроектировать весь технологический стек, сконцентрировавшись на структурах данных, синтаксисе и протоколе взаимодействия компонентов. Большинство вопросов несовместимости, отпадет само собой. Пусть даже этот подход будет альтернативным и экспериментальным, но его задача будет выполнена, если он наметит путь и продемонстрирует принципиальную возможность создания простого и элегантного решения общего назначения. Эта идея является естественным продолжением подхода Node.js, когда мы сокращаем количество языков и технологий в системе, разрабатывая и клиент и сервер на JavaScript. Несмотря на экспериментальность, протокол JSTP уже используется в коммерческих продуктах, например, для интерактивного телевидения компанией SinceTV, где позволяет подключить одновременно десятки миллионов пользователей. Это решение получило приз за инновации в области телевидения на международном конкурсе Golden Panda Awards 2015 в Ченду (Китай). Есть внедрения в сфере управления серверными кластерами, готовятся решения для медицины, интерактивных игр, электронной торговли и услуг.







Слайды: http://www.slideshare.net/tshemsedinov/metarhia-nodejs-macht-frei

Аудио версия: https://soundcloud.com/timurshemsedinov/nodejs-macht-frei



Выступление



Добрый день, меня зовут Тимур Шемсединов, я архитектор SinceTV, автор Impress Application Server для Node.js, научный сотрудник НИИ Системных Технологий и преподаватель КПИ. Сегодняшняя тема не столько про ноду, а скорее про развитие той идеи, которая легла в основу ноды.



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



Каждый шаг в вебе — это борьба, каждая минута — боль, каждая строчка — компромисс или заплатка. В интернете множество статей о том, что хаос захлестнул ветхий веб и хорошие специалисты тратят недели на простейшие задачи, как то — подвинуть кнопочку на 3 пикселя вверх или поймать блуждающий баг в зоопарке браузеров. Например статья с Медиума «I’m a web developer and I’ve been stuck with the simplest app for the last 10 days» переведенная на Хабре «Я веб-разработчик и уже 10 дней не могу написать простейшее приложение».



В чем же проблема? Как мы можем ее выявить и осознать? Есть ли другие пути? И можем ли мы двигаться эволюционно, а не революционно, решая проблемы частями? Об этом и пойдет речь дальше, и в целой серии докладов и статей, которые готовлю я и весь наш коллектив, и к обсуждению которых я Вас приглашаю.



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



Представьте, что мы откажемся от HTTP, HTML, CSS, DOM, URL, XMLHttpRequest, AJAX, JSON, JSONP, XML, REST, Server-Sent Events, CORS, Cookie, MIME, WebSocket, localStorage, indexedDB, WebSQL, и всего остального, кроме одной вещи, мы оставим JavaScript и сделаем из него абсолютно все, что необходимо для разработки приложений. На первый взгляд это может показаться странным, но дальше я покажу, как мы это сделаем. Это будет целостный технологический стек на одном лишь JavaScript и вам это понравится. Мы конечно будем привлекать другие технологии для создания среды исполнения приложений, но от разработчика приложений все эти внутренности будут скрыты.



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



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



Эти системы должны быть:




  • распределенными (включающими в себя много клиентских терминальных устройств и много серверов),

  • высоконагруженными (потенциально масштабируемыми для работы с миллиардами одновременно подключенных пользовательских устройств),

  • интерактивными (поддерживающими двухстороннюю интерактивность, приближенную к реальному времени),

  • безопасными (одновременно анонимными и обеспечивающими достаточный уровень идентификации и доверия для отдельных операций),

  • гибко изменяющимися (модифицирующими экраны, функции и структуры данных на лету, без переустановки и перезапуска).



При помощи каких технологий мы можем сегодня разрабатывать такие приложения, перечислим:




  • оконные и локально установленные приложения (для Linux, MacOS, Windows) с использованием AWT, SWING, WinForms, WPF, Qt и т.д.

  • мобильные приложения (iOS, Android, и другие)

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

  • Progressive Web App (полноэкранные приложения запускаемые в скрытом браузере)

  • NW.js и Electron



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



Веб мог бы быть решением для кросплатформенности, но какой набор технологий мы имеем в ветхом вебе:



Начнем с HTTP. Думаю, ни для кого не секрет, что он блокирующий, т.е. через одно соединение, которое браузер установил, может быть одновременно отправлен только один запрос на сервер и соединение ждет, пока сервер ответит. Потому, что в HTTP нет нумерации запросов, просто обычной, примитивной, самой простой нумерации нет и открытое соединение ожидает. Ведь если послать второй запрос, то получив ответ, будет не ясно, это ответ на первый запрос или на второй. Не говоря уже про передачу ответа частями, которые смешались бы. Но при загрузке приложения нужно сделать много запросов и браузер устанавливает второе соединение для второго запроса, потом третье… В большинстве браузеров это число ограничено 6 одновременными соединениями, т.е. сделать больше параллельных запросов нельзя, ни для загрузки статики, ни для AJAX. Если конечно не соорудить костыль, создать множество поддоменов и разбрасывать запросы на поддомены, ведь ограничение на 6 соединений у браузера привязано именно к хосту. Но эти десятки и сотни соединений неэффективно используют сеть.



Вообще TCP предполагает надежную доставку и долгосрочное взаимодействие, но HTTP разрывает связь очень часто, он просто не умеет эффективно переиспользовать уже установленные соединения и постоянно их разрывает и создает новые. Есть конечно Keep Alive, но мало того, чтобы он был специфицирован, его должны поддерживать веб-сервер, браузер, и разработчики должны о нем знать, правильно формировать заголовки и обрабатывать их. Обычно чего-то не хватает, то админ без руки, то разработчики не слышали про такую возможность, да и браузеры имеют особенности, как оказалось, и Keep Alive работает очень не эффективно, из-за отхода от спецификации сервер часто не может договориться с браузером и соединение не переходит в Keep Alive режим. Я об этом уже делал доклад и писал статью год назад "Как исправить ошибку в Node.js и нечаянно поднять производительность в 2 раза" https://habrahabr.ru/post/264851/ Поведение HTTP можно проследить в средствах для разработчика, которые есть в браузере. Оптимизация в HTTP это отдельная задача, из коробки ее нет да и всем безразлично.



Установление TCP соединения это тяжелая задача, она дольше, чем передача информации по уже открытому сокету. А в добавок к TCP, при установлении новых соединений HTTP повторно присылает заголовки, в том числе cookie. А мы знаем, что заголовки HTTP не жмутся gzip, вместе с cookie в крупных проектах ходят десятки и сотни килобайт заголовков. Каждый раз, а у беззаботных людей еще и статика вся гетается с отправкой cookie в каждом запросе. Всем же безразлично.



У HTTP очень много проблем, их пробовали решать при помощи Websocket, SSE, SPDY, HTTP/2, QUIC но все они зависят от бесчисленного множества вещей, которые достались в наследство от ветхого веба и ни одна из этих технологий не достигла ни приемлемых характеристик, ни широкой поддержки. Уплотнить уже имеющийся трафик, сделать мультиплексацию внутри другого транспорта можно, но структура трафика не изменится, это будут все те же HTML, AJAX, JSON, ведь задача стояла, починить транспорт так, чтобы ничего не сломалось и чрез него продолжали ходить все те же приложения. А вот не достигнута цель, все сложно, не внедряется это массово и прирост в скорости не очень ощутим при внедрении. Кардинально и комплексно ни кто не пробовал решить проблему.



Для игр, мессенджеров и других интерактивных приложений сейчас есть только один живой вариант — это Websocket, но этот слоеный пирог из протоколов достиг предела. IP пакетный, на его основе TCP потоковый с установлением долгих соединений, сверху HTTP — он опять пакетный с постоянным отключением и поверху Websocket — и он потоковый, с долгими соединениями. А еще все это через SSL может идти. И каждый слой добавляет свои заголовки и преобразовывает данные, особенно при переходе от пакетного к потоковому и от потокового к пакетному. Это похоже на издевательство, честное слово.



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



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



HTML это конечно прекрасный язык для разметки страниц, но менее всего приспособленный для сложных пользовательских графических интерфейсов. Скорость работы DOM и отсутствие транзакционности в изменении интерфейсов приводят к залипанию веб-приложений. Сложно придумать что-то более избыточное и медленное для представления пользовательских интерфейсов в памяти и динамической модификации экранов. Это решается в Shadow DOM, React, Angular, Web components но проблем все еще больше, чем решений.



Еще немного про масштабирование. REST, который обещал всем прозрачное решение, вместо этого забрал возможность работать с состоянием, и не сделал обещанного. Мы имеем ситуацию, когда ни кто не использует REST, да ладно, мало кто понимает, что это, но все говорят, что у них REST API. URLы идентифицируют объекты или методы? PUT, PATCH и DELETE используются? Последовательность вызовов API не важна? У кого через REST работают платежи, корзина, чат, напоминания? В основном у всех AJAX API, которое так и нужно называть. А проблема с масштабирование как была, так и решается каждый раз заново.



Проблем слишком много для того, чтобы вдаваться дальше в подробности, давайте кратким списком теперь подытожим основные:




  • Платформы для прикладных программных систем фрагментированы

  • Архаичные веб технологии уже нас не удовлетворяют

  • Фреймворки и инструменты тотально нестабильны и несовместимы

  • Протоколы ветхого веба имеют большую избыточность и убивают производительность ваших серверов

  • Сплошные проблемы безопасности и заплатки



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



Что же нам нужно:




  • Среда исполнения приложений для серверов

  • Среда исполнения приложений для пользовательских компьютеров

  • Среда исполнения приложений для мобильных устройств

  • Межпроцессовое взаимодействие по принципам RPC и MQ с поддержкой интроспекции, потоков событий и потоковой передачи двоичных данных

  • Система управления базами данных с глобальным пространством адресации, распределенностью и шардингом из коробки

  • Новые соглашения по именованию и идентификации данных и пользователей



Это уже не сеть веб-страниц, а сеть приложений и баз данных.

И теперь я покажу, что это возможно. Не утверждаю, что нужно делать именно так, но принципиальную возможность на прототипе наша команда продемонстрирует.



Metarhia — это новый технологический стек, который:




  • экспериментальный (только для демонстрации нового подхода),

  • альтернативный (не должен заботиться о совместимости),

  • в открытом коде (можно свободно распространять и бесплатно применять даже в коммерческих проектах, можно участвовать в разработке и отправлять запросы на доработку в сообщество).



Теперь давайте ближе к JavaScript, у него же есть прекрасный синтаксис описания структур данных, включающий хеши, массивы, скалярные величины, функции и выражения. А нам нужен универсальный сетевой протокол, который бы соответствовал структурам данных языка и исключал бы излишнюю перепаковку данных. Нам нужен сквозной протокол и он же формат сериализации, один на весь стек технологий, в базе данных, в памяти клиента, в памяти сервера и при передаче между процессами. Так зачем же нам JSON, XML, YAML и прочие, если таким форматом может быть подмножество языка JavaScript. При этом мы не выдумываем ни какого стандарта, ни какой формальной граматики, у нас уже есть все. По большому счету, заготовки для парсеров уже реализованы на всех языках и платформах. Более того, если мы возьмем V8 и заставим его быть парсером сетевых пакетов, то получим статистическую оптимизацию, скрытые классы и на порядок более быстрый парсинг, чем JSON. Тесты производительности я опубликую позже, чтобы не перегружать этот, и так объемный, доклад.



Пусть протокол станет центральным стержнем, на который цепляются все компоненты системы. Но протокола мало, нам нужна среда запуска, как клиентская, так и серверная. Развивая идеи Node.js, мы хотим, чтобы не только язык, но и среда запуска была почти идентичной на сервере и на клиенте. Одинаковое API, которое дает возможность обращаться к функциям платформы, например к сети, файловой системе, устройствам ввода/вывода. Конечно же, это API не должно быть бесконтрольно доступным приложениям, а обязано иметь ограничения безопасности. Область памяти и файловая система должны быть виртуальными, замкнутыми песочницами, не имеющими сообщения с остальной средой запуска. Все библиотеки должны подгружаться не самими программами, а внедряться средой запуска как DI через инверсию управления (IOC). Права приложений должны быть контролируемы, но не должна происходить эскалация управления до пользователя, потому, что он не способен принять адекватного решения по правам доступа. Пользователь склонен или запрещать все, руководствуясь паранойей или разрешать все, руководствуясь беспечностью.



Еще нам нужна СУБД, которая будет хранить данные в том же формате JavaScript. Нам нужен язык описания моделей (или схем) данных. Нам нужен язык запросов к структурам данных. В качестве синтаксиса этих двух языков запросов мы можем взять тот же синтаксис JavaScript. И в конце концов нам нужен язык описания интерфейсов двух видов, сетевых интерфейсов API и пользовательских интерфейсов GUI. Подмножество того же JavaScript прекрасно нам подходит для обоих целей.



Теперь можем перечислить компоненты технологического стека Metarhia:




  • JSTP — JavaScript Transfer Protocol

  • Impress Application Server — сервер приложений, серверная среда исполнения

  • GS — Global Storage — глобально распределенная система управления базами данных

  • Console — браузер приложений, тонкий клиент или среда исполнения приложений



JavaScript Transfer Protocol это не только формат представления данных, но и протокол, который имеет специальные конструкции, заголовки, пакеты, разделители, в общем, все то, что обеспечивает реализацию прозрачного для приложений взаимодействия по сети. JSTP объединяет клиентскую и серверную часть так, что они становятся одним цельным приложением. Можно расшаривать интерфейсы и делать вызовы функций совершенно так же, как если бы функции находились локально. С единственным ограничением, что локально функции могут быть синхронные и асинхронные, а расшаренные по по сети функции всегда асинхронные, т.е. возвращают данные не через return, а через callback, который принимают последним аргументом, как это принято в JavaScript. Так же JSTP поддерживает трансляцию событий по сети, обернутую в сетевой аналог EventEmitter. У JSTP много возможностей, но сейчас приведу только основные его особенности и преимущества:




  • Встроенная поддержка интерактивности (поддержка событийно-ориентированного взаимодействия),

  • Простой и понятный известный всем формат (не нужно придумывать еще одного стандарта сериализации),

  • Асинхронность вызовов (не блокирующий принцип использования одного соединения с мультиплексацией),

  • Двунаправленное взаимодействие, максимально приближенное к реальному времени,

  • Реактивный принцип взаимодействия (код в реактивном стиле может быть распределенным),

  • Оптимизация парсинга сетевых пакетов при помощи механизма скрытых классов V8,

  • Использованием метаданных, моделей (схем данных), интроспекции и скаффолдинга.



Теперь подробнее о последнем пункте. Метаданные позволят нам не только сделать систему гибче, но и оптимизировать ее еще дополнительно, кроме того, что мы уже используем оптимизацию V8 для парсинга JSTP. В большинстве форматов сериализации имена полей тоже передаются, в JSON они занимают по грубым оценкам от 20% до 40% от всего объема передаваемых данных, в XML этот процент гораздо выше половины. Имена полей нужны только для мнимой человекочитаемости, хотя как часто люди читают XML или JSON? Для JSTP есть два варианта сериализации, это полная форма и сокращенная, построенная на базе массивов с позиционных хранением ключей. Другими словами, мы один раз передаем схему, имена полей, их типы, другие вспомогательные метаданные из которых на клиенте строим прототип. Потом мы получаем множество экземпляров объектов, сериализованных в массивы, т.е. имена полей не передаются, а структура массива позиционно соответствует структуре прототипа, у которого определены геттеры и сеттеры. Мы просто присваиваем массиву прототип, он остается массивом, но мы можем работать с этим экземпляром, через имена полей.



Скаффолдинг и интроспекция применяется при построении прозрачного соединения между клиентом и сервером (и вообще между любыми процессами, двумя серверами или двумя клиентами). При подключении мы забираем метаданные, описывающие расшаренные интерфейсы с методами и их параметрами и строим на противоположной стороне прокси, структурно повторяющие удаленное API. Такой прокси можно использовать локально, работая на самом деле с удаленным интерфейсом. Для работы с предметной областью применяется метапрограммирование и динамическая интерпретация метамоделей, о чем я уже делал много статей и докладов (еще за 2014 год и даже за 2012 год), но обязательно подготовлю материалы о метапрограммировании в новом технологическом стеке.



Теперь становятся понятными основные идеи технологического стека Metarhia и JSTP, как его базовой составляющей:




  • Фокус на структурах данных, а не на алгоритмах,

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



Как говорит Линус Торвальдс: "Плохие программисты беспокоиться о коде. Хорошие программисты беспокоиться о структурах данных". А Эрик Рэймонд выразил это еще точнее "Умные структуры данных и тупой код работают куда лучше, чем наоборот".



Теперь короткие примеры JSTP:




  • Сериализация структуры данных: { name: 'Marcus Aurelius', birth: '1990-02-15' }

  • Полная сериализация объекта: { name: 'Marcus Aurelius', birth: '1990-02-15', age: () => {...} }

  • Метаданные: { name: 'string', birth: '[Date]' }

  • Краткая позиционная сериализация: ['Marcus Aurelius','1990-02-15']

  • Сетевой пакет: { call: [17, 'interface'], method: ['Marcus Aurelius', '1990-02-15' ] }



Сравним описание одних и тех же данных на XML, CLEAR, JSON и JSTP:



Пример XML




Seatingsnone
OK

Flap01open
OK

Flap02closed
overload

Jointdetach
OK




Пример CLEAR
1: PT004:OilPump Displacement[constant] Value[63] Control[automatic] Status[working]
2: #FlowMeter Substance[fluid] Recording[off] Role[master] Period[00:30] DataOutput[Parent.FT002.Verification]
2: #Outlet Pressure[180] Status[working]
2: #FailureSensors:Table [Module,Indication,Status]
3: [Seatings,none,OK]
3: [Flap01,open,OK]
3: [Flap02,closed,overload]
3: [Joint,detach,OK]


Пример JSON
{
"name": "PT004",
"type": "OilPump",
"displacement": "constant",
"value": 63,
"control": "automatic",
"status":"working",
"flowMeter": {
"substance": "fluid",
"recording": "off",
"role": "master",
"period": "00:30",
"dataOutput": "Parent.FT002.Verification"
},
"outlet": {
"pressure": 180,
"status": "working",
"failureSensors": [
["Module", "Indication", "Status"],
["Seatings", "none", "OK"],
["Flap01", "open", "OK"],
["Flap02", "closed", "overload"],
["Joint", "detach", "OK"]
]
}
}


Пример JSTP
{
name: "PT004",
type: "OilPump",
displacement: "constant",
value: 63,
control: "automatic",
status:"working",
flowMeter: {
substance: "fluid",
recording: "off",
role: "master",
period: "00:30",
dataOutput: "Parent.FT002.Verification",
},
outlet: {
pressure: 180,
status: "working",
failureSensors: [
["Module", "Indication", "Status"],
["Seatings", "none", "OK"],
["Flap01", "open", "OK"],
["Flap02", "closed", "overload"],
["Joint", "detach", "OK"]
]
}
}


Пример JSTP минимизированный с применением схемы данных:



["PT004","OilPump","constant",63,"automatic","working",
["fluid","off","master","00:30","Parent.FT002.Verification"],
[180,"working",[["Module","Indication","Status"],
["Seatings","none","OK"],["Flap01","open","OK"],
["Flap02","closed","overload"], ["Joint","detach","OK"]]]]


А теперь внимание, самый простой парсер JSTP на Node.js выглядит так:



api.jstp.parse = (s) => {
let sandbox = api.vm.createContext({});
let js = api.vm.createScript('(' + s + ')');
return js.runInNewContext(sandbox);
};


всего 5 строк, а его использование простое и очевидное:



api.fs.readFile('./person.record', (e, s) => {
let person = api.jstp.parse(s);
console.dir(person);
});


Теперь посмотрим более сложный пример JSTP, имеющий функции и выражения:



{
name: ['Marcus', 'Aurelius'].join(' '),
passport: 'AE' + '127095',
birth: {
date: new Date('1990-02-15'),
place: 'Rome'
},
age: () => {
var difference = new Date() - birth.date;
return Math.floor(difference / 31536000000);
},
address: {
country: 'Ukraine',
city: 'Kiev',
zip: '03056',
street: 'Pobedy',
building: '37',
floor: '1',
room: '158'
}
}


Как видно, функции могут обращаться к полям самого объекта, но для этого нужно немного модифицировать парсер:



api.jstp.parse = (s) => {
let sandbox = vm.createContext({});
let js = vm.createScript('(' + s + ')');
let exported = js.runInNewContext(sandbox);
for (let key in exported) {
sandbox[key] = exported[key];
}
return exported;
};


Моя команда разработчиков и независимые разработчики готовят сейчас JSTP SDK для более чем десятка языков, а для некоторых есть уже несколько альтернативных реализаций. Тестирование функциональности и производительности JSTP мы проведем в ближайшее время. На странице спецификации внизу есть собранные ссылки, но не все, ссылки будут обновляться: https://github.com/metarhia/JSTP



Сейчас есть такие реализации:




  • JavaScript для Browserа

  • JavaScript для Node.js и Impress Application Server

  • C and C++ for STL and Qt

  • Swift and Objective-C for iOS

  • Java for Android and JavaEE

  • C# for .NET

  • Python, Haskell, PHP, GoLang



Ссылки





Заключение



А в следующий раз я расскажу про другие компоненты стека технологий. Несмотря на кажущуюся простоту решений, сделать еще нужно очень много. Я обещаю периодически публиковать результаты и проводить тесты по нагрузкам и надежности, сравнение с аналогами по функциональности и эффективности. Пока я не могу рекомендовать все это к массовому внедрению, но зимой 2016-2017 мы выпустим SDK с примерами. Над этим трудится несколько десятков человек в специально созданном R&D центре в Киевском Политехническом Институте при поддержке SinceTV. Если Вы будете следить за проектом, то надеюсь, что он еще Вам пригодится. Даже частичное внедрение уже дало свои результаты. Спасибо за Ваше внимание.





Насколько Вам интересна эта технология?
















































Проголосовал 1 человек. Воздержавшихся нет.





Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306584/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] [+] Разработка простого чата на Socket.IO [2016] \ Node.js

Понедельник, 15 Августа 2016 г. 10:35 (ссылка)

Всем привет, дорогие хабрахабровцы! Недавно я начал изучать node.js и дошёл до самого интересного, а именно — Socket.Io. Поизучав информацию в интернете, я так и не смог найти подробного «гайда» по данному модулю, поэтому пришлось копать самому. Некоторые скажут, что можно и самому понять, что написано на сайте модуля, но некоторым этого будет не достаточно чтобы понять базу web-socket'ов, поэтому я решил написать эту статью для таких людей, а именно на самом 'чётком' примере — чате.



Установка модуля



Итак, давайте приступать?! Для начала нам нужно собственно установить наш Socket.Io, как его установить можете прочитать здесь, а для тех, кто не понял, поясню: есть клиент и сервер, на сервер нужно поставить сам модуль через npm в папку проекта (для этого надо заранее открыть её в консоли, а дальше устанавливать):



npm install socket.io


После того как установили модуль, в папке с проектом (куда ставили) появится папка «node-modules»



Теперь мы должны установить сам .js файл модуля в папку с проектом (.js файл будет использоваться на клиенте), ставить отсюда => *тык*. Вы скачаете архив, и оттуда вы должны достать файл «socket.io.js» и перекинуть в папку с проектом.



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



chat: (Сама папка)
|node-modules
|--socket.io (Внутри node-modules)
|socket.io.js


После того как вы скачали .js файл и установили модуль — можно приступать к следующему этапу.



Установка дополнительных модулей



Вам понадобятся также такие модули как:



1. express # Для создания сервера

2. log4js # Отличный логгер

3. http # Сам http-сервер



express:



npm install express


log4js:



npm install log4js


http:



npm install http


После всех этих процедур, папка «node-modules» должна пополниться (*логично вроде*). Теперь можно приступать к разработке нашего чата!



Разработка чата



Теперь мы можем приступать у разработке, но перед этим, надо создать .js-файл в директории проекта «chat.js» в чем мы и будем писать наш чат. Для начала открываем наш chat.js и подключаем все модули таким образом:



var express = require('express'); // Подключаем express
var app = express();
var server = require('http').Server(app); // Подключаем http через app
var io = require('socket.io')(server); // Подключаем socket.io и указываем на сервер
var log4js = require('log4js'); // Подключаем наш логгер
var logger = log4js.getLogger(); // Подключаем с модуля log4js сам логгер


Это все что нам нужно подключить в начале. Дальше создаем переменную куда укажем наш порт для прослушивания (для сервера):



var port = 3000; // Можно любой другой порт


После этого можно прологгировать старт скрипта таким образом:



logger.debug('Script has been started...'); // Логгируем.


Дальше ставим на «прослушку» для сервера порт таким образом:



server.listen(port); // Теперь мы можем подключиться к нашему серверу через localhost:3000 при запущенном скрипте


Теперь мы должны сделать так, чтобы клиенту который подключается к нашему серверу «localhost:3000», получал пакет файлов таких как index.html; main.css; socket.io; main.js; чтобы отображалась сама страница с нашим чатом.



Это делается просто, создаем папку «public» в корне проекта, и закидываем туда наш «socket.io.js», а дальше создаем там такие файлы как index.html, main.js, main.css(Не будем пользоваться, это для наглядности). Наша структура проекта должна быть примерно такая:



chat:
|node-modules:
|-socket.io
|-express
|-log4js
|-http
|public:
|-index.html
|-socket.io.js
|-main.css
|-main.js
|chat.js


Дальше делаем такой «финт» который будет отправлять клиенту содержимое этой папки при подключении:



chat.js:



app.use(express.static(__dirname + '/public')); // Отправляет "статические" файлы из папки public при коннекте // __dirname - путь по которому лежит chat.js


Отлично, теперь при подключении на localhost:3000 (при запущенном скрипте) у нас будет открываться «index.html», только страница будет пустая из-за того что у нас «index.html» пустой :)



Накидаем эскиз чата в «index.html» (без стилей). Можете просто копировать код в «index.html»




















Прекрасно! Теперь если мы запустим скрипт и откроем localhost:3000, мы увидим наш *кривой* эскиз ) Также вы можете увидеть, что я подключил jQuery, благодаря ему мы будем извлекать текст из поля «удобно».



Как мы можем понять, сейчас наш чат не работает, по сколько не настроены «евенты» в скрипте. Сейчас мы будем всё разбирать. Для начала мы должны подключиться с клиента к серверу (socket.io) в «main.js»



var port = 3000; // Указываем порт на котором у на стоит сокет
var socket = io.connect('http://localhost:' + port); // Тут мы объявляем "socket" (дальше мы будем с ним работать) и подключаемся сразу к серверу через порт


Теперь когда мы написали подключение socket.io к серверу через порт, самое время обработать это событие на сервере.



io.connect(port) — Создает событие 'connection', нам надо сделать его обработчик на сервере, иначе подключение будет *пустое*, а нам надо еще присвоить никнейм тому кто приконнектился, а это делается в обработчике, просто читаем дальше.



Создаём обработчик в скрипте «chat.js»



io.on('connection', function (socket) { // Создаем обработчик события 'connection' которое создает io.connect(port); с аргументом socket
var name = 'U' + (socket.id).toString().substr(1,4); // Создаем никнейм нашему клиенту. В начале буква 'U' дальше берем 3 символа ID (сокета) после первого символа, и все это клеим с помощью '+'
socket.broadcast.emit('newUser', name); // Отсылает событие 'newUser' всем подключенным, кроме текущего. На клиенте навешаем обработчик на 'newUser' (Отправляет клиентам событие о подключении нового юзера)
socket.emit('userName', name); // Отправляем текущему клиенту событие 'userName' с его ником (name) (Отправляем клиенту его юзернейм)
logger.info(name + ' connected to chat!'); // Логгирование
});


Итак, для тех, кто не понял… io.on('event', function(arg){}) — создаёт прослушку на событие 'event' с аргументом arg; передавать аргументы будем чуть позже ) socket.id — ID подключения этого сокета (сокет — клиент), socket.broadcast.emit('newUser', name); — отправка события 'newUser' всем кроме текущего сокета, с переменной name (текущего сокета). socket.emit('userName', name); — отправляет событие 'userName' только текущему сокету c переменной name.



Для тех, кто не понял — сервер и клиент могут отправлять и принимать события одинаково:



socket.emit('event') — отправляет на сервер\клиент

socket.on — прослушивает события на клиенте

io.on — прослушивает события на сервере



Теперь создаём в «main.js» прослушки на 'newUser', 'userName'…



socket.on('userName', function(userName){ // Создаем прослушку 'userName' и принимаем переменную name в виде аргумента 'userName'
console.log('You'r username is => ' + userName); // Логгирование в консоль браузера
$('textarea').val($('textarea').val() + 'You'r username => ' + userName + '\n'); // Выводим в поле для текста оповещение для подключенного с его ником
});

socket.on('newUser', function(userName){ // Думаю тут понятно уже =)
console.log('New user has been connected to chat | ' + userName); // Логгирование
$('textarea').val($('textarea').val() + userName + ' connected!\n'); // Это событие было отправлено всем кроме только подключенного, по этому мы пишем другим юзерам в поле что 'подключен новый юзер' с его ником
});


$('textarea').val('текст'); — изменение текста в текстовом поле. \n — переход на новую строку



Теперь когда мы откроем localhost:3000 мы увидим встречный текст в поле с нашим ником! Прекрасно? Я знаю ^^ Но согласитесь, это еще не чат. Теперь нам надо сделать так, чтобы при нажатии на кнопку «Отправить» <= index.html отправлялся текст на сервер. Для этого дописываем в «main.js» обработчик на кнопку 'button' через jQuery.



$(document).on('click', 'button', function(){ // Прослушка кнопки на клик
var message = $('input').val(); // Все что в поле для ввода записываем в переменную
socket.emit('message', message); // Отправляем событие 'message' на сервер c самим текстом (message)- как переменная
$('input').val(null); // Заполняем поле для ввода 'пустотой'
});


После этого мы можем спокойно делать обработчик события 'message' на самом сервере.



chat.js:



io.on('connection', function (socket) {
var name = 'U' + (socket.id).toString().substr(1,4);
socket.broadcast.emit('newUser', name);

logger.info(name + ' connected to chat!');
socket.emit('userName', name);
// Обработчик ниже // Мы его сделали внутри коннекта

socket.on('message', function(msg){ // Обработчик на событие 'message' и аргументом (msg) из переменной message
logger.warn('-----------'); // Logging
logger.warn('User: ' + name + ' | Message: ' + msg);
logger.warn('====> Sending message to other chaters...');
io.sockets.emit('messageToClients', msg, name); // Отправляем всем сокетам событие 'messageToClients' и отправляем туда же два аргумента (текст, имя юзера)
});
});


Отлично! Теперь когда мы будем отправлять текст со страницы, он у нас будет логгироваться в консоли node, так же мы всем клиентам отправили событие 'messageToClients', сейчас мы будем на клиенте делать обработчик этого события…



main.js:



socket.on('messageToClients', function(msg, name){
console.log(name + ' | => ' + msg); // Логгирование в консоль браузера
$('textarea').val($('textarea').val() + name + ' : '+ msg +'\n'); // Добавляем в поле для текста сообщение типа (Ник : текст)
});


Наш чат готов! Теперь вы можете его модернизировать как угодно.



Этот пост был создан потому, что топики, которые на Хабре по созданию чата, были запощены 5 лет назад, а за это время много чего произошло и я решил создать свой топик ) Тем не менее, вот топик, по которому я вдохновлялся — ссылочка. Может я где-то ошибся, поправляйте! Все люди ошибаются.



Спасибо всем за внимание!
Original source: habrahabr.ru.

https://habrahabr.ru/post/307744/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Почему я люблю работать с вебом. Рэми Шарп

Вторник, 09 Августа 2016 г. 20:00 (ссылка)

Рэми Шарп — создатель таких сайтов, как сonfwall, jsbin.com, html5demos.com, responsivepx.com, nodemon, mit-license.org, snapbird.org, 5 minute fork и jsconsole.com. Предлагаю вашему вниманию перевод статьи Реми Шарпа «Почему я люблю работать с вебом».



«Легко значит скучно. Вот почему я люблю веб и браузеры» – автор


Мне нравится, что мой код может работать где угодно и для кого угодно. На самом деле, это вызов. Веб — чрезвычайно многообразная среда, где каждый человек может просматривать что бы то ни было так, как ему хочется.



Круто, конечно, если посетитель использует современный и мощный настольный компьютер. Но так же вероятно и то, что он просматривает веб-сайт с рабочего компьютера, используя старый и встроенный браузер Internet Explorer 8.



Дуглас Крокфорд как-то сказал:

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


И он чертовски прав. Это та враждебность, которая даёт мне доступ в мир. Это та «враждебность», которую я называю своим ежедневным вызовом.



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



Я не говорю, что достигаю этих целей каждый раз. Например, я много лет стремился сделать так, чтобы jsbin.com работал в IE7 и IE8, и где-то в процессе мы лишились поддержки IE8 (на что я постараюсь выделить время и однажды исправить).



Просмотреть код: приветственный жест веба



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



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



В моём случае наибольший прорыв в понимании JavaScript случился, когда я пытался осознать исходный код jQuery (ещё во времена первых версий, около 10 лет назад).



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



Труднее ли сейчас?



Я читал пост Джейка Арчибальда «Если мы стоим на месте, мы движемся назад» и задумался об услышанной мной аналогии о сложности, которую используют для сравнения с вебом раньше.



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



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



Сами посмотрите: и это всё уже готовые части!







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



Вот и всё, если предполагать, что у вас уже есть все компоненты. А чтобы получить эти компоненты, вам нужны фреймворки и рабочие инструменты. Сомнений нет: работа сложная.



Это не единственный путь, я уверяю вас.



Неудивительно: основы всё ещё тут



Веб всё ещё состоит из HTML, CSS и JavaScript и работает чертовски хорошо в своей ванильной форме. Взять, например, этот блог: моё первое представление себя в вебе – всего лишь HTML, CSS и немного скопированного JavaScript.



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



Почему я люблю работать с вебом







Из-за его простоты. Рождённый из потребности связывать документы. В той же степени, в которой это могло измениться с последним поколением веб-разработчиков, которые скажут вам, что веб теперь сложный и запутанный (и будут правы), одновременно он не является сложным. Он всё ещё гениально прост.



Кто угодно может сделать это. Кто угодно может выложить контент в сеть: будь это обычный текст или простой HTML, состоящий только из

<р>-тегов, или же что-нибудь более сложное и изысканное. Веб не стесняется своего контента. Проходит всё и вся.



Веб сегодня – действительно потрясающее место для разработчиков. Существует впечатляющее множество библиотек, фреймворков, плагинов и утилит, которые очень облегчают жизнь при создании супер-сложных штук – лет 10 назад некоторые смельчаки писали их вручную. Также, если вы хотите писать на JavaScript и игнорировать все части ES6 / ESnext, вы можете делать и это (и по большей части, из-за ограничений, я поступаю так же!).



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



А как насчёт вас?
Original source: habrahabr.ru.

https://habrahabr.ru/post/307468/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
trabche

Экипировочный центр adidas в москве футболка adidas techfit power web seasonal shortsleeve tee

Вторник, 09 Августа 2016 г. 05:35 (ссылка)

Экипировочный центр adidas в москве футболка adidas techfit power web seasonal shortsleeve tee.


Читать далее
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<web - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda