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

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

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

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

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

На тему шаблонизаторов статей написано великое множество, в том числе и здесь, на хабре.
Раньше мне казалось, что сделать что-нибудь своё — «на коленке» — будет очень сложно.
Но, случилось так, что прислали мне тестовое задание.
Напиши, мол, JavaScript шаблонизатор, вот по такому сценарию, тогда придёшь на собеседование.
Требование, конечно, было чрезмерным, и поначалу я решил просто игнорить.
Но из спортивного интереса решил попробовать.
Оказалось, что не всё так сложно.

Собственно, если интересно, то под катом некоторые заметки и выводы по процессу создания.

Для тех, кому только глянуть: the result, the cat.

Проблема

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

Требования следующие:

• Выбор даты, нескольких дат, интервала
• Простота настройки внешнего вида
• Желательно без каких-либо зависимостей кроме jQuery

Требования вполне логичные, ничего сверх естественного.
Каково было мое удивление, когда просмотрев десятка два плагинов я не нашел подходящего.

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

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.

I-Tier: Расщепление монолита

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

С самого начала весь веб-фронтенд американского Групона был единым исходным кодом Ruby. Код фронтенда быстро развивался, что затрудняло его поддержку и усложняло процесс добавления новых фич. В качестве решения проблемы с этом гигантским монолитом мы решили реструктурировать фронтенд посредством его разделения на меньшие, независимые и более простые в управлении части. Основой этого проекта стало разделение монолитного вебсайта на несколько независимых Node.js приложений. Мы также переделали инфраструктуру, чтобы обеспечить совместную работу всех приложений. Результатом стал Interaction Tier (I-Tier).

Вот некоторые из важных моментов этой глобальной архитектурной миграции:

• Страницы на сайте загружаются значительно быстрее

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

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

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

Резюме

Мы будем использовать VirtualBox с установленными windows и photoshop, затем интегрируем виртуальную машину в ubuntu. В итоге, мы, практически, не будем ощущать, что используется эмулятор.

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



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

С выходом CSS3 появилось множество новшеств: с новыми свойствами стили стали сложнее, но не появилось никаких улучшений для поддержки новых и старых сложностей, в том числе дупликации кода. В чистом CSS отсутствует модульность, так как разбиение стилей на файлы и их подключение через @import пагубно влияет на производительность.
Решение этих проблем нашлось в CSS препроцессорах, с их помощью стало возможным использование переменных, выполнение математических подсчетов в коде, появилась возможность повторно использовать код с помощью миксинов и наследования.

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

Сколько уже было сломано копий о задачу выравнивания элементов на странице. Предлагаю вашему вниманию перевод отличной статьи с решением этой проблемы от Стефана Шоу (Stephen Shaw) для Smashing Magazine — Absolute Horizontal And Vertical Centering In CSS.

Все мы знали о margin: 0 auto; для горизонтального центрирования, но margin: auto; не работало для вертикального. Это можно легко исправить, просто задав высоту и применив следующие стили:

.Absolute-Center {
  margin: auto;
  position: absolute;
  top: 0; left: 0; bottom: 0; right: 0;
}

Я не первый, кто предложил это решение, однако такой подход редко применяется при вертикальном выравнивании. В комментариях к статье How to Center Anything With CSS Simon ссылается на пример jsFiddle, где приводится отличное решение для вертикального центрирования. Вот еще несколько источников на эту тему.

Рассмотрим способ поближе.

Авторское отступление: Не закидывайте камнями те, кому выпало писать под разные браузеры!
В моей работе из-за использования ActiveX-компонентов сейчас поддерживается только IE. Поэтому дальнейшее изложение касается только различных версий IE.

IE10 — это особый браузер. Многое из того, что было верно для предыдущий версий IE, перестало работать.
Рассматриваются только ошибки JavaScript, возникшие при миграции legacy-кода. Различие в CSS выходит за рамки данной статьи.

Долгое время для создания Drag&Drop функционала использовались JavaScript-функции, однако браузеры не всегда корректно могли отображать результат. В HTML 5 есть способ грамотной поддержки Drag&Drop, с небольшим применением JavaScript. В этой статье подробно разобран наглядный пример применения Drag&Drop в HTML 5.

Поддержка браузерами

На сегодняшний день функция Drag&Drop в HTML 5 корректно обрабатывается всеми современными настольными браузерами, (частично даже IE 5.5!), однако мобильные такую возможность не поддерживают. Подробнее данные в таблице caniuse.com.

Animate.css

На днях наткнулся на эту замечательную вещь и решил поделиться с Хабрахабром.
Animate.css — сборка отличных кроссбраузерных CSS3 анимаций в одном файле.

Постановка проблемы

Система маршрутизации ASP.NET MVC избавляет разработчика от необходимости вручную поддерживать URL, используемые в приложении при помощи таблиц маршрутизации и url шаблонов. Таким образом, с программиста снимается задача по формированию URL вручную. Напротив, в его распоряжении оказывается богатый набор URL-хелперов. Это замечательно! Но все меняется, когда приходят они — AJAX-запросы.

Проблема заключается в том, что таблицы маршрутизации и механизм генерации URL являются частью серверной архитектуры asp.net mvc и недоступны из Javascript-файлов.

От переводчика:
Я собрался изучить новый для меня паттерн Стратегия, но не нашёл толкового русского описания его реализации на javascript. Статья на wiki пугает своей сложностью, а наглядность примера оставляет желать лучшего. По этому и взялся за перевод этой статьи, одновременно разбираясь, что же из себя представляет данный паттерн.
Спойлеры и текст, выделенный серым, являются моими комментариями.

Далее мы разберём примеры того, как я использую СТРАТЕГИЮ в Javascript, и как он используется реальной библиотекой, для разбиения её на небольшие части.

Разрабатывать интерфейс Android приложений — непростая задача. Приходится учитывать разнообразие разрешений и плотностей пикселей (DPI). Под катом практические советы о верстке макетов дизайна Android приложений в Layout, который совпадает с макетом на одном устройстве а на остальных растягивается без явных нарушений дизайна: выхода шрифтов за границы; огромных пустых мест и других артефактов.

UPD: Пост спорный, но много ценных советов в комментариях

Многие заметили, что на YouTube и на Medium появился небольшой новый элемент UI — прогресс-бар в виде тонкой цветной полоски в самом верху страницы, который примостился прямо под панелью браузера.

Внимание к новому элементу привлек недавний популярный пост New UI Pattern: Website Loading Bars на UsabilityPost. Как выяснилось, причина использования прогресс-бара в том, что вместо загрузки новой страницы содержимое подгружается через JavaScript, и поэтому собственный индикатор браузера о загрузке страницы может не срабатывать. Чтобы у пользователя не возникало ощущения, будто страница «зависла», эту функцию переложили на плечи маленького UI-приема.

Теперь у всех желающих появилась возможность быстро сделать на своем сайте точно такой же прогресс-бар благодаря плагину NProgress.js [Демо][GitHub].

Свободный движок WebKit теперь поддерживает srcset атрибут изображений, IMG элементов (официальная спецификация от W3C). Это позволяет вам, как разработчику, использовать картинки с высоким разрешением для пользователей использующих ретина-дисплей без ущерба для остальных пользователей. Также важно отметить о наличие изящного решения для браузеров, которые еще не поддерживают данный функционал.

Обратите внимание, в необходимости использовать последние ночные сборки WebKit.

Более двух лет прошло после начала продаж iPhone 4 летом 2010 года, и за эти два года сайтостроители привыкли проверять джаваскриптом значение window.devicePixelRatio (или же использовать в CSS медиазапрос device-pixel-ratio) как простое и бесхитростное средство, позволяющее тотчас же выяснить, запущен ли сайт на сетчаточном дисплее (retina display) или нет. Если величина devicePixelRatio равна двойке, то перед нами сетчаточный дисплей (четвёртый iPhone, четвёртый iPod Touch, третий iPad, или более новые устройства, или портативный компьютер «MacBook Pro with Retina Display»); если же величина devicePixelRatio равна единице (или не определена), то перед нами дисплей обычной чёткости.

Чуть сложнее, по сравнению с эппловскими, бывает учёт устройств, работающих под Android: там приходится воспринимать дробные величины, не равные единице или двойке. Peter-Paul Koch сообщил во блогозаписи «More about devicePixelRatio» о том, что (по его наблюдениям) в Nexus One величина devicePixelRatio равна 1,5, тогда как в Galaxy Nexus и в Galaxy Note она равна двум в WebKit и 2,25 в Opera Mobile.

Но эти мелкие отличия не меняют картины в целом: все привыкли думать о значении величины devicePixelRatio как о таком свойстве устройства, которое на одном и том же мобильнике (или планшете, или ноутбуке) остаётся беспрерывно постоянным. В частности, именно на этом были основаны все, все рецепты из хабрахабровских блогозаписей «Адаптируем графику под Retina экран», «Распознаём retina-дисплеи джаваскриптом», «Отображаем карты OpenStreetMap на iPhone 4 с учётом сетчаточного дисплея при помощи Leaflet», «Как отличить версию iPad в Safari», «Оптимизация графики для Retina-экранов», «Комплексная подготовка сайта к Retina» и им подобных.

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