JavaScript *

18 апреля Frontend Dev Conf в третий раз собрала frontend и UI-специалистов. Участниками стали более 300 разработчиков. Мероприятие прошло в дружелюбной атмосфере, приятных кулуарных разговорах и жарких дискуссиях с докладчиками.

Native script (NS) – это библиотека, позволяющая делать кросс-платформенные приложения, используя XML, CSS, JavaScript. Native script решает ту же задачу, что и уже всем известный phonegap (создание кросс-платформенных приложений), но подходы у них разные. Phonegap использует движок браузера, чтобы отобразить ваш UI (фактически вы получаете веб-страницу), Native script использует нативный рендеринг, использует элементы нативного UI. Следующее важное отличие: чтобы получить доступ к камере, gps и так далее в phonegap необходимо устанавливать плагины, в то время как NS дает доступ из коробки.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости.

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

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

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

Недавно в офисе Badoo проходил юбилейный MoscowJS Meetup. Делимся с вами видео докладов.

1. «Специфика верстки мультиязычных веб-приложений»
Александр Тевосян, Badoo.




+ Выложили на GitHub нашу утилиту rtl-css специально к митапу: https://github.com/badoo/rtl-css

Месяц назад кто-то нашёл у меня на гитхабе незаконченный проект и выложил ссылку на него на Designer News. Внезапно я увидел, что на сайте проекта постоянно сидит по 50 человек, и мне даже пришлось срочно сбежать с работы чтоб экстренно выпилить хотя бы самые адовые баги. Этим проектом был интенс, UX-компонент заменяющий полосу прокрутки (скроллбар) на специальный индикатор, который подсвечивает прокручиваемую область текстурой. Выглядит это примерно так:


_{на сайте проекта можно поскроллить самостоятельно}

Сообщества UX-экспертов и программистов отреагировали очень возбуждённо:

Не могу понять, почему мне это не нравится… _{— GrumpyUX Man @ layervault}

Святые какашки, эта штука бесит _{— Thecoss @ reddit}

Да я себе скорее установлю ПЕРДЯЩИЙ СКРОЛЛ http://theonion.github.io/fartscroll.js/ в качестве дефолтного, чем КОГДА-ЛИБО заменю мою полосу прокрутки на это. _{— Kyle Donmoyer @ layervault}

Спасибо, не надо. Никогда не мог понять это желание поменять стандартные элементы интерфейса. Полоса прокрутки — это одна из тех вещей, которая просто работает. Она не мешается и легко даёт понять, насколько много контента. _{— madk @ reddit}

Шта? _{— magenta_placenta @ reddit}

…
Я не очень понял, что за проблему оно решает _{— jineshshah36 @ reddit}

(кто-то даже создал сабреддит Real Bad UX чтоб разместить там ссылку на этот проект)

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

Здесь я хочу рассказать, какие области применения у интенса, и попробую объяснить, как я себе представляю «жизнь после скроллбара». А также предлагаю читателям покритиковать этот проект, обсудить скроллинг вообще, UX вцелом, и целесообразность замены традиционных элементов в частности.

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

Проблема в картинках

Начнем с визуализации нашей проблемы. Допустим у нас есть два базовых класса и от них наследуются два дочерних класса.



В какой-то момент в дочерних классах появляется необходимость в одинаковом функционале. Обычная копипаста будет выглядеть на нашей схеме вот так:



Очень часто бывает, что данный функционал не имеет ничего общего с родительскими классами, поэтому выносить его в какой-то базовый класс нелогично и неправильно. Вынесем его в отдельное место — миксин. С точки зрения языка миксин может быть обычным объектом.



А теперь обсудим момент, ради которого написана вся статья — как правильно замешивать наш миксин в классы.

Всем привет! Сегодня мы расскажем о том, что именно должна делать хорошая система сбора отзывов для гарантированного поднятия конверсии сайта на примере нашего продукта – системы сборы отзывов Cackle Reviews. Первый релиз состоялся в ноябре 2013. За полтора года существования у нас появилось порядка 200 клиентов (из которых 150 – интернет-магазины) и чёткое представление о том, какие возможности системы отзывов честно влияют на рост конверсии:

1. Автоматическая индексация отзывов в Google с микроразметкой рейтинга schema.org/review;
2. Импорт отзывов из Яндекс.Маркета;
3. Рассылка follow-up писем после покупки с приглашением оставить отзыв;
4. Трансляция отзывов в социальные сети;
5. СПАМ-тест (mail-tester.com) с результатом не ниже 9/10 баллов.

Как это всё работает в Cackle Reviews – под катом.

• jspm — это менеджер пакетов для SystemJS, сделаный на основе ES6 module loader
• Позволяет загружать все форматы модулей (ES6, AMD, CommonJS и Globals) непосредственно из npm или Github с управлением зависимостями. Также позволяет использовать любые не стандартные источники модулей, реализованные через Registry API
• В разработке: Загружает модули ES6 как отдельные файлы, и компилирует их в прямо в браузере
• В продакшене: Собирает модули в один или несколько бандлов, с единой командой для запуска всего приложения

Начнем

Устанавливаем jspm cli

  npm install jspm -g

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

Webtorrent

Полноценный торрент клиент для NodeJS и браузеров. Стримминг будет работать прямо в браузере благодаря WebRTC (data chanels) для P2P транспортировки. А самое главное «It's Just JavaScript™», то есть не нужны никакие дополнительные плагины или расширения. Проект собрал более 3000 звезд на GitHub и на данный момент предоставляет следующие возможности: непосредственно саму потоковую передача данных, загрузка нескольких торрентов одновременно, поддержку magnet uri, peer discovery и protocol extension api, возможность подключения WebTorrent клиентов на разных доменах, стримминг видео в <video> тег в формате (webm (vp8, vp9) или mp4 (h.264)), а также в AirPlay, Chromecast, VLC player и прочие устройства.

var WebTorrent = require('webtorrent')

var client = new WebTorrent()
var magnetUri = '...'

client.add(magnetUri, function (torrent) {
  // Got torrent metadata!
  console.log('Torrent info hash:', torrent.infoHash)

  torrent.files.forEach(function (file) {
    // Get a url for each file
    file.getBlobURL(function (err, url) {
      if (err) throw err

      // Add a link to the page
      var a = document.createElement('a')
      a.download = file.name
      a.href = url
      a.textContent = 'Download ' + file.name
      document.body.appendChild(a)
    })
  })
})

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Начиная с IE10 добавлена поддержка команд «Копировать» и «Вырезать» с помощью метода Document.execCommand(). Так же эти методы доступны в Chrome начиная с версии 43.

Любой текст выделенный в браузере при выполнении одной из этих команд будет скопирован или вырезан в буфер обмена пользователя. Это позволяет предложить пользователю простой метод выделить часть текста и скопировать в буфер обмена.

Это становится крайне полезным в сочетании с API программного выделения текста, что бы задать что скопировать в буфер. Примеры будут рассмотрены в этой статье.

Джаваскриптовая ошибка «undefined is not a function» довольно загадочна. Как раз поэтому определённым спросом пользуются разъяснительные статьи, из которых читатель, начинающий изучать программирование на JavaScript, способен узнать о том, что такая ошибка (попытка использовать неопределённое значение как функцию) чаще всего возникает при вызове несуществующего метода объекта (а такой вызов, в свою очередь, чаще всего происходит в случае опечатки в названии метода). Такой разъяснительной статьёю может послужить «Ошибки в JavaScript и как их исправить», например.

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

Так и вышло:

Improved exception messages: Goodbye "undefined is not a function". Hello "http://t.co/rMIELG5VoW is not a function" pic.twitter.com/3uykfrTK9O

— Addy Osmani (@addyosmani) 21 февраля 2015

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

Но, как и любая платформа, Node.js не застрахован от ошибок самих разработчиков. В одних случаях падает производительность, в других — система становится практически непригодной к использованию. И в этом посте я хотел бы рассмотреть 10 наиболее частых ошибок, которые делают разработчики с недостаточным опытом работы с Node.js.

Всем привет,

Как и многие, я долго писал на Node.JS только высокопроизводительные сервисы, но когда в 0.11 сделали генераторы и несколько моих коллег подтвердили, что они работают на production, решил сделать на этой платформе новый учебник JavaScript.

Удобство генераторов для асинхронного JS-кода сложно переоценить. При желании он становится «плоским», меньше букв, чем чистые promise/async.

Хотелось сделать движок быстрым, простым в разработке и иметь возможность запускать некоторые модули и на сервере и на клиенте.

Получилось, если не напутал при подсчёте, около 24000 строк кода (без сторонних node_modules).

По правилам современного фронтенда отдавать пользователю надо минимум файлов с минимальным весом. Но во время разработки писать все в один файл, ещё и в сжатом виде, очень неудобно, поэтому для решения этой задачи используют разные сборки в виде готовых yeoman.io, generator-yeogurt и т.п. Или собирают сами с использование Grunt, Gulp и т.п. Но речь не об этом, речь об отладке javascript-а в этих сборках.

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

На Хабре уже есть хорошая статья на тему отладки js с помощью map файла в хроме — «Введение в Javascript Source Maps». Но если вы работает в среде разработки, особенно если эта среда от JetBrains, то лезть в хром как-то неправильно (хотя, конечно, это очень холиварная тема). Поэтому я решил написать эту статью.

Итак, приступим.

WebRTC – это API, предоставляемое браузером и позволяющее организовать P2P соединение и передачу данных напрямую между браузерами. В Интернете довольно много руководств по написанию собственного видео-чата при помощи WebRTC. Например, вот статья на Хабре. Однако, все они ограничиваются соединением двух клиентов. В этой статье я постараюсь рассказать о том, как при помощи WebRTC организовать подключение и обмен сообщениями между тремя и более пользователями.

В статье приведен пример разбора вредоносного браузерного расширения из Chrome Web Store — «Убрать рекламу (HET Рекламе)».

От переводчика: когда я начал разбираться с MVC-фреймворками для фронт-энда, каким-то чудом попалась на глаза эта статья Henrik Joreteg. Сейчас дошли руки перевести ее для Хабра, тем более, что об AmpersandJS на Хабре вообще не слышно. Попробую организовать цикл статей по этому инструменту ребят из &yet, мне кажется, он достоин внимания.



В рамках наших образовательных семинаров я даю краткий обзор JS фреймворков. Я не очень-то хотел публиковать большую часть моих мнений об этих инструментах в Сети, потому что такие вещи, как правило, вызывают бурление масс, обижают людей, и в отличие от разговора с глазу на глаз, в интернет-дискуссиях нет действительно хорошей двунаправленной связи с аудиторией.
Но мне не раз говорили, что мой обзор крайне полезен и помогает получить сжатое и, в то же время, хорошее понимание в вопросе «кто есть кто в JS фреймворках для создания одностраничных приложений». По этому поводу я решил материализовать его и опубликовать как Нечто, но, пожалуйста, помните, что я просто высказываю свое мнение, я не говорю вам, что делать, и вы должны использовать те инструменты, которые лучше подходят вам и вашей команде. Вы можете запросто не согласиться со мной, написать об этом в Твиттере, или, еще лучше, опубликовать отдельный пост, объясняющий вашу позицию.

Angular.js

за

1. очень легко начать использовать. можно просто вставить тег script, добавить немного ng- атрибутов в ваше приложение, и вы волшебным образом получаете нужное вам поведение
2. Angular хорошо поддерживается его основной командой разработчиков, многие из которых работают в Гугле на постоянной основе
3. большая аудитория/сообщество

Крупнейший международный портал разработчиков StackOverflow провёл ежегодный опрос. Участвовали более 26 тысяч человек из 157 стран. Результаты получились очень интересные.

Общая картина

Самая большая концентрация разработчиков на 1000 человек в Люксембурге, Исландии и Швеции. Средний возраст разработчика — 28.5 лет и его дата рождения приходится на апрель 1986 года. Женщин менее 6% и почти половина из них начали программировать лишь в последние 2 года.