JavaScript *

Мишко Хевери, главный разработчик Ангуляра, как-то упомянул, что приложение гарантированно работает без тормозов, если в нем не более 100 активных областей видимости. Такой подход, в общем, применим к любым приложениям. В играх давно не рендерят то, чего игрок не видит и только в вебе пока еще считается нормой отобразить целиком список из нескольких тысяч элементов. С приходом js-фреймворков ситуация должна измениться и лучшим решением станет удаление из DOM того чего нет на экране, нежели отказ от промежуточных тегов, биндингов и других вещей, облегчающих разработку. Поэтому провел небольшой анализ решений для отображения больших списков. Наткнулся на пару статей:

1. The Infinite Path of Scrolling

В ней парень рассказывает, что проходил стажировку в Гугле в команде Ангуляра и ему поручили исследовать этот вопрос. (Радует, что разработчики заинтересованы этим. Надеюсь, скоро увидим родную поддержку бесконечного скролла).

Вы, наверное, уже читали интересную статью о том, как можно отключать эффекты :hover при скроле – это позволяет здорово сохранить отзывчивость сайта, но имеет один недостаток – вам приходится опираться на один общий класс, и это плохо.

.hover .element:hover {
  box-shadow: 1px 1px 1px #000;
}

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

Docpad

«Нашумевший» проект в Twitter и GitHub. По заявлению разработчиков «Docpad снимает ограничения и убирает разрыв между профессионалами и новичками. Теперь дизайнеры и разработчики могут создавать веб-сайты быстрее, чем когда-либо прежде». Docpad — это статический генератор сайтов написанный на Node.js. Он позволяет с легкостью создавать шаблоны и блоки. Работает c PHP, Ruby, CoffeeScript и др. В нем есть file wathing, live reload и самое главное «amazing plugin system». Большим плюсом является обучающее видео (хоть и на английском).

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

Действительно, под мои требования замечательно подходил, например, RequireJS с его адаптером для Node.js, которые какое-то время с успехом удовлетворяли мои прихоти, пока меня опять не осенила гениальная мысль: «Почему я вынужден использовать кашу из двух совершенно различных форматов модулей в одном проекте? Нужно все унифицировать!».

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

Это рассказ о моем опыте разработки живого проекта на фреймворке Meteor. Фреймворк очень интересный, подход к разработке концептуально отличается от большинства существующих PHP/JS фреймворков. Фактически, с Meteor приходится заново учиться веб-разработке.

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

Вот так это будет выглядеть по окончанию редактирования:


А вот так в режиме редактирования:

Всем привет!
Мне часто приходится работать со статистическими данными и там очень много завязано на датах. Притом, одна и та же дата может быть использована на странице в разных форматах (например, в удобном для машины и в удобном для человека). Я думаю, что большинство из вас отлично представляют весь этот ужасающий по размерам код, который получается при использовании объекта Date.
К примеру, чтобы получить текущую дату в формате ДД.ММ.ГГГГ нам потребуется сделать следующее:

var d = new Date(),
       fd = d.getDate() + '.' + (d.getMonth()+1) + '.' + d.getFullYear();

А когда таких строк становится много? Легко ли упомнить, что в javascript месяц начинается с нуля, когда разрабатываешь не только на нем? Или то, что тут миллисекунды, а не секунды, как почти везде на бэкенде? Можно решить часть задач популярной библиотекой Moment.js, но она работает весьма медленно.
Рассматриваемая библиотека решает эти проблемы.
Если интересно, предлагаю вам прочитать этот небольшой обзор.

На сегодняшний момент существует масса JavaScript-библиотек для создания rich-client приложений. Кроме всем известных Knockout, Angular.JS и Ember есть великое множество других фреймворков, и каждый имеет свою особенность — кто-то пропагандирует минимализм, а кто-то — идеологическую чистоту и соответствие философии MVC. При всём этом многообразии, регулярно появляются всё новые и новые библиотеки. Из последнего, что упоминалось на хабре — Warp9 и Matreshka.js. В связи с этим хочется рассказать о собственной поделке, встречайте, JohnSmith — простой и легковесный JavaScript фреймворк для построения UI.

Задача

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

Посмотреть пример на jsfiddle

Доброго времени дня или ночи, Хабр!
В наших краях как всегда зима пришла неожиданно, но в космосе времен года нет, так что снова поговорим о различных космических штуках на webgl. Предыдущую статью о карте галактики можно прочитать здесь. Сегодня же речь пойдет про карта звездной системы.
Как всегда, рассказ пойдет по шагам. Итак…

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

На мой взгляд существует 3 популярных способа навесить событие на элемент в думе:

1. Через ID
2. Через то, что досталось от верстки
3. Через специальные классы

Идея

Идея заключалась в том, чтобы написать автоматический лайкер контакта, который бы сам все лайкал и не требовал нашего присутствия за компьютером.
Профессиональные SMM'щики поймут, а остальным, зачем это надо, объясню в конце.

Какие были успехи?
Удалось написать облайковщик постов страницы пользователя/группы без бана, в больших количествах.
Удалось написать облайковщик новостной ленты.
И еще одна интересная реализация, но она чаще актуальна пользователям с большим количеством подписок > 1000: в новостной ленте лайкается только вновь прилетевшая новость.

Привет, хабралюди

В этом топике я хочу рассказать вам о моем опыте работы с SIP телефонией через webrtc. Рассказать о том, с какими проблемами встречался, какой софт я пробовал, какие костыли писал :).

Что было использовано:

• Asterisk 11.5.1
• GSM шлюз
• SipML5

В каждой избушке — свои игрушки

До некоторого момента front-end разработчик при написании javascript кода, рассчитанного на взаимодействие с пользователем, ориентировался лишь на «мышиные» события. Затем появились различные устройства, которые использовали другие формы взаимодействия пользователя с приложением — сенсоры или перо. Типы событий для каждого устройства были предложены индивидуальные. Так, кроме mousedown, mousemove итд., появились touchstart, touchmove и другие события.

Такой подход требует наличия альтернативных функций для поддержки нового типа устройства. Это часто порождает проблемы несовместимости, если изначально приложение было расчитано на одно устройство. К тому же, текущие платформы, которые используют сенсорные события, так же реагируют и на некоторые «мышиные» события (например, mousedown) в целях обратной совместимости. Это делает неоднозначным использование таких мышиных событий, нет возможности определить с каким конкретно устройством работает пользователь. Кроме того, есть ряд серьезных отличий в работе мышиных событий на сенсорных устройствах:

• События мыши возникают только после сенсорных;
• Наведение мышью (mouseover) и другие аналогичные события не сработают без прикосновения к устройству. Обработчики таких событий должны быть запущены по умолчанию или их нужно заменить на событие 'click' по элементу;
• События по щелчку не будут запущены при изменении DOM дерева документа;
• События по щелчку срабатывают не сразу, а, приблизительно, через 300 мс;
• Touch и mouse события, в некоторых случаях, конфликтуют между собой.

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

Это не статья — скорее заметка. И да, она для новичков в Angular.

Частый вопрос — почему в Angular не работают вложенные инклуды? Работают. Просто Angular — это не php.

Планируя лэйаут, мы обычно представляем что-то такое:

• Меню сверху,
• Меню слева,
• Контент в центре
• Футер

Первое что пытаемся сделать, так это добавить в главный шаблон ngView, а в шаблоны нижнего уровня добавить ngInclude. Пробуем, у нас не получается, идём читать StackOverFlow (давайте будем честны — сначала StackOverFlow, потом, может быть, если лениво не будет, — документацию).
И там нам говорят что-то в духе, “чувак, используй angular ui-router”, или “зацени, какой я себе костылесипед собрал!”.

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

Ещё одна схема движения железнодорожного транспорта с использованием возможностей Canvas и dbCartajs.


В оригинале она называется Moscow Underground and Commuter Rail Map, её можно видеть в тамбурах подмосковных электричек. Изначально я хотел реализовать именно эту карту в качестве очередного демо к проекту dbcartajs, но в Сети нашёл лишь копию карты, снятую на мобильный телефон с неважным качеством. Зато с легкостью нашел с десяток схем Московского метро. Самая красивая, на мой взгляд, в Википедии, самая неказистая оказалась почему-то у Яндекса с его-то возможностями. Собственно SVG-вариант из Википедии я и переделал под Canvas, о чем писал в предыдущей статье.

В компании Airbnb мы многому научились за последние несколько лет, создавая мощные веб-приложния. Мы погрузились в мир одностраничных приложений в 2011 г., делая мобильную версию нашего сайта, с тех пор, кроме прочего, мы запустили Wish Lists и новый поиск. Все это — большие JavaScript приложения, что означает то, что тонны кода запускаются в браузере, чтобы обеспечить современный интерактивный пользовательский опыт.

Это обычный подход сегодня, когда такие библиотеки, как backbone.js, ember.js и angular.js помогают разработчикам создавать мощные JavaScript приложения. Мы поняли, однако, что такие приложения имеют несколько критических ограничений. Чтобы стало понятно, давайте предпримем небольшой тур по истории веб-приложений.

_{Картинка из статьи для привлечения внимания}

Наш друг Алекс Винкс распетрушил демку StarlingJS, поправил баги, допилил, портировал свою флеш-демку и выложил исходники:

Статей про WebRTC уже достаточно много и в интернетах, и на Хабре (здесь и здесь), повторять их ещё раз не имеет особого смысла, поэтому тут приведем наш личный опыт и впечатления, полученные при разработке live.pics.io.

Идея

Live.pics.io позволяет создавать приватные сессии для совместного просмотра и обсуждения изображений голосом. Это могут быть любые изображения: от фотографий, до макетов дизайна и презентаций. Pазрабатывая pics.io, мы достаточно хорошо научились работать с разными raw форматами в браузере, поэтому можно не заморачиваться с конвертацией и закидывать фотографии сразу после съемки (будут рады владельцы Canon’ов и Nikon’ов, остальные камеры пока требуют конвертации в DNG).

Очень коротко о webRTC

На самом деле, использовать WebRTC — это практически то же самое, что использовать сокеты. Но немного по-другому (совсем чуть-чуть). Нам нужно передавать изображение и звук. Берем RTCPeerConnection для соединения между пирами, MediaStream для трансляции аудио и RTCDataChannel для передачи изображений. Еще, для того, чтобы все это заработало, понадобится небольшой серверсайд для соединения пиров и передачи управляющих инструкций. Но об этом чуть позже.