JavaScript *

28 мая библиотека для создания приложений реального времени на Node.js Socket.IO доросла до версии 1.0. Socket.IO возникла практически сразу же после появления Node.js и быстро стала одним из самых популярных и востребованных проектов экосистемы Node. Socket.IO реализует коммуникацию сервера и клиента в реальном времени с помощью Web Sockets, а при отсутствии этого API в старых браузерах эмулирует сокеты с помощью других доступных технологий — сокетов Adobe Flash, запросов AJAX или JSONP.

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

Dat

Dat — data package management. Это инструмент, который позволяет обмениваться большими наборами данных с целью построения совместного рабочего процесса, подобно git с исходными файлами. Важно упомянуть, что текущий статус проекта pre-alpha.

npm install dat -g

После публикации статьи «Яндекс.Карты для angular.js утекло немало воды, а также появились новые возможности. В настоящий момент в модуль angular.js для использования карт „Яндекса“ на ваших страницах добавлена поддержка версии 2.1 yandex map api. Не скажу, что суть модуля сильно поменялась, но все же некоторые изменения были внесены. Хотите знать какие, добро пожаловать под кат.

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

Всем привет!
Хочу начать вольный перевод замечательной книги «Learning Three.js- The JavaScript 3D Library for WebGL». Я уверен, что эта книга будет интересна не только новичкам, но и профессионалам своего дела. Ну не буду долго затягивать вступление, только приведу пример того, что мы совсем скоро сможем делать:

Сегодня я сделал небольшой сниппет кода для себя и решил поделиться с сообществом его содержимым и историей его создания.

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

Для начала озвучу чего мне так хотелось:
Мне нужен слайдер — аналог регулятора громкости, совмещенный с прогресс-баром. Эдакий компонент управления мощностью чего-либо, совмещенный с одновременной индикацией этой мощности. Иногда мощность может превышать установленный предел в 100% — необходимо отображать этот уровень и правильно высчитывать процент. Иногда мощность может заходить ниже нуля ( не знаю может ли — но я на всякий случай предусмотрел такую возможность) и этот уровень тоже надо отображать. Более того, то устройство, которое мы регулируем может быть инертным и разгоняться не с той скоростью, с которой мы выставляем значение. Если вы нажали кнопку форсажа на самолете — то двигатели выйдут на форсажный режим через некоторое время. То есть надо отдельно задавать значение прогрессбара и также отдельно получать-устанавливать текущее значение ползунка слайдера.

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

Синопсис

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

Приветствую вас, уважаемые хабравчане! Сегодня я бы хотел осветить вопрос рендеринга в веб-разработке. Конечно, на эту тему уже написано много статей, но, как мне показалась, вся информация довольно разрознена и отрывочна. По крайней мере, чтобы собрать всю картину в своей голове и осмыслить её, мне пришлось проанализировать немало информации (в основном — англоязычной). Именно поэтому я решил формализовать свои знания в статью, и поделиться результатом с сообществом Хабра. Думаю, информация будет полезна как начинающим веб-разработчикам, так и более опытным, чтобы освежить и структурировать свои знания.

Данное направление можно и нужно оптимизировать на этапе вёрстки/frontend-разработки, поскольку, очевидно, что разметка, стили и скрипты принимают в рендеринге непосредственное участие. Для этого соответствующие специалисты должны знать некоторые тонкости.

Автор картинки: Donovan Shortey, использовано по лицензии Creative Commons.

Познавательная книжка Discover Meteor теперь переведена усилиями сообщества на русский язык и находится в свободном доступе. Английская версия по-прежнему требует подписки и стоит (разумных) денег.

В начале марта авторы оригинальной книжки Sacha Greif и Tom Coleman бросили клич, приглашая любителей фреймворка MeteorJS перевести ее на все языки мира. Локализированные версии книжки выкладывались бы под свободной лицензией Creative Commons, свободно доступные для всех желающих быстро познать мир Meteor. В настоящий момент существуют переводы на 22 языка мира, в разной степени готовности. Проект доступен на GitHub, и если кто-то заметил опечатку, или желает как-то дополнить перевод — добро пожаловать в команду.

… а именно как писать LL парсеры для не очень сложных структур при помощи конструирования сложного парсера из более простых. Изредка возникает необходимость распарсить что то несложное, скажем некую XML-подобную структуру или какой нибудь data URL, и тогда обычно возникает либо простыня хитрого трудно читаемого кода либо зависимость от какой то ещё более сложной и хитрой библиотеки для парсинга. Здесь я собираюсь совместить несколько известных идей (какие то из них попадались на Хабре) и показать как можно просто и лаконично написать довольно сложные парсеры уложившись при этом в совсем немного строчек кода. Для примера я буду писать парсер XML-подобной структуры. И да, я не буду вставлять сюда картинку для привлечения внимания. В статье вообще картинок нет, поэтому читать будет трудно.

В последнее время, ввиду отсутствия нормальной документации по derby версии 0.6, мне стали часто по почте и через различные сервисы задавать вопросы.

Чтобы информация накапливалась, я завел для этого отдельный репозиторий — derby-faq. Сейчас там пара десятков вопросов с подробными ответами и примерами кода. Предлагаю всем поучаствовать в его развитии.

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

Intercooler.js

Кто нибудь помнит FullAjax — разработку Руслана Синицкого sirus (нынешний основатель Jelastic)? Вкратце это библиотека для работы с AJAX с помощью объявления определенных атрибутов у элементов, а подробнее об этом написано в постах «Прямые ссылки на AJAX веб-сайтах – наша технология Fullajax Direct Link», «Полный AJAX. Теория и Примеры. Фишки и Фичи» и «Fly AJAX — пишите меньше, имейте больше. Нестандартный AJAX и индексация поисковиками». Вернемся к Intercooler, это нечто похожее:

<div id="targetDiv">Results Div...</div>
<i id="indicator" style="display:none" class="fa fa-spinner fa-spin">
<input id="hiddenInput" type="hidden" name="hidden" value="42"/>

<div ic-trigger-on="click" ic-verb="POST" ic-src="/example" ic-include="#hiddenInput" ic-indicator="#indicator" ic-target="#targetDiv" ic-transition="none">
    Click Me!
</div>

После клика по div, отправляется POST запрос со значением поля с #hiddenInput, а в процессе будет отображаться #indicator. Ответ будет передан в блок #targetDiv. Разве не здорово?

Не всё так просто

На первый взгляд, JavaScript может показаться достаточно простым языком. Возможно, это из-за достаточно гибкого синтаксиса. Или из-за схожести с другими известными языками, например, с Java. Ну или из-за достаточно малого количества типов данных, по сравнению с Java, Ruby, или .NET.

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

В JavaScript поиск данных зависит от двух вещей: прототипного наследования и цепочек областей видимости. Для разработчика понимание этих двух механизмов совершенно необходимо, ибо ведет к улучшению структуры, а, зачастую, ещё и производительности кода.

Перевод статьи Ричарда Корнфорда Javascript Closures.

• Введение
• Разрешение имен свойств объектов
  
  • Присваивание значений
  • Чтение значений
  
  
• Разрешение имен идентификаторов, контексты исполнения и цепь областей видимости
  
  • Контекст исполнения
  • Цепь областей видимости и свойство [[scope]]
  • Разрешение имен идентификаторов
  
  
• ...

Введение

Замыкание

Замыкание — это выражение (обычно функция), которое может иметь свободные переменные, вместе со средой, которая привязывает эти переменные (т.е. “замыкает” это выражение).

Замыкания относятся к наиболее мощным особенностям ECMAScript (javascript), но они не могут быть применены должным образом без понимания. Несмотря на то, что их легко создать, даже случайно, их создание может иметь пагубные последствия, в частности, в некоторых относительно распространенных окружениях браузеров. Чтобы избежать случайных столкновений с недостатками и использовать преимущества замыканий, необходимо понимать их механизм. Это сильно зависит от роли цепи областей видимости в разрешении имен идентификаторов (identifier resolution) и от разрешения имен свойств в объектах.

Самое простое объяснение замыкания в том, что ECMAScript допускает вложенные функции, определения функций и функции-выражения (function expressions) внутри тел других функций. И эти вложенные функции имеют доступ ко всем локальным переменным, параметрам и функциям, находящихся внутри их внешней функции (внешних функций). Замыкание образуется, когда одна из этих вложенных функций становится доступной вне той функции, в которую она была включена, таким образом, она может быть выполнена после завершения внешней функции. В этот момент она все еще имеет доступ к локальным переменным, параметрам и внутренним декларациям функций (function declarations) своей внешней функции. Эти локальные переменные, параметры и декларации функций (изначально) имеют те же значения, которые были во время завершения внешней функции и могут взаимодействовать с внутренней функцией.

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

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

Итак, а как вообще принятно решать проблему сборки в последнее время? Grunt/Gulp плагины, require.js, browserify — самые популярные варианты.

Но есть нюанс. Когда вы имеете дело с Angular-приложением, вы сталкиваетесь с необходимостью декларирования зависимостей между модулями для их правильной сборки. Поясню на примере.

Если у вас простейшее приложение, которое состоит из нескольких файлов:

app.js
controllers.js
services.js
directives.js
filters.js

То никаких проблем нет. Вы можете вручную прописать порядок их подключения в том же Grunt/Gulp.

Но, допустим, если вы захотите реализовать такую архитектуру, при которой каждый отдельный сервис, контроллер, директива и т. д. находятся в отдельных файлах, то есть:

app.js
controllers/
	FirstCtrl.js
	SecondCtrl.js
services/
	FirstSrv.js
	SecondSrv.js

То вы столкнётесь с рядом трудностей. Главным образом, трудности будут с тем, как сшить все файлы так, чтобы при этом Angular работала без ошибок. Итак, что можно сделать?

Данный урок, продолжение серии уроков по derbyjs — реактивному фуллстек фреймворку. Читать предыдущие уроки обязательно (первый, второй).

Этот урок будет состоять из двух частей: первая — обзор серверной части дерби-приложения, и вторая — использование модуля derby-auth (обертки над passportjs) для регистрации/авторизации в дерби-приложении с использованием в том числе и социальных сетей.

Привет, друзья.

Так получилось, что мы пишем разные высоконагруженные вещи на JS. В отличие от простых сценариев в браузере, оптимизация производительности JS на сервере (речь в основном о Node.js) – тема очень интересная практически. Думаю, присутствующим не надо объяснять, почему быстрый код лучше, чем медленный.

Вообще оптимизация – это далеко не только переписывание на Си или ассемблере «горячих» участков кода. В нашей команде дискуссия о том, как заставить скрипт работать шустрее – явление перманентное. А поскольку существуют объективные критерии оценки (бенчмарк и юнит-тесты), не допускающие патологической ситуации «о вкусах не спорят» – в результате действительно получается быстрый код, снижение нагрузки на сервер, процветание, радость.

Всем привет!

Пару дней назад мне на почту пришло письмо от Codeschool.com, в котором очень красочно (как можно заметить из картинки в шапке поста) представлялся новый курс по AngularJS. Т.к. платной подписки у меня сейчас нет, я решил отложить просмотр до лучших времён, а сегодня случайно узнал, что курс оказывается «Sponsored by Google», а соответственно бесплатный. Закончив работу над первым уровнем, я поспешил проверить наличие заметки об этом чудном событии на Хабре, но с удивлением обнаружил, что никто до сих пор не поделился этой новостью. Значит придётся взять всё в свои руки.

Намедни я решил посмотреть новости через Google. Нажимаю правой кнопкой на ссылку «другие новости» и в контекстном меню нет пунтка открыть в новом окне. Я решил глянуть исходный код и вижу javascript:void(0);
Для меня это стало новостью, ведь все что читал до этого — было однозначно против такого решения.

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.