Введение

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

Основные нюансы при формировании таких писем:

• Все стили должны встраиваться (inline) в виде атрибута style для конкретного HTML-элемента.
• Все изображения должны встраиваться, либо как отдельные вложения в в письме, либо в виде base64-кодированных данных (второе банально удобнее).
• Письмо должно поддерживать DKIM (настройка мэйлера), а домен отправителя — содержать SPF-запись.

На почти каждой конференции разработчиков вот-вот будет доклад, в котором будет вот эта «смешная гифка»:

Питер Гриффин из одноименного мультсериала пытается закрыть жалюзи и запутывает их напрочь, дергая за веревки как попало, пока не выходит из себя и срывает их с окна. Надпись на картинке: «CSS».

Публика всегда такое любит, и отсюда можно удачно перейти к рассказу о проблемах CSS и примерам их решения. Но в большинстве случаев — и чем более «технарская» это конференция, тем вероятнее — это начало тирады о том, какая гадость этот CSS, до чего ужасна его архитектура и как он нелогичен. И т.д., и т.п...

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

Навеяно многочисленными случаями продажи подделок или не полностью рабочих аппаратов на площадке Авито и прочих.

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

Кто на Земле подвергается наиболее сильному ионизирующему излучению? Дерек Мюллер на своем канале Veritasium рассказывает, как он проехался по земному шару в поисках наиболее радиоактивных мест в рамках съёмки документального фильма для телевидения об уране и о том, как он изменил современный мир.

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

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

• REST
• gem responders
• иерархию контроллеров
• хлебные крошки

Контроллер обеспечивает связь между пользователем и системой:

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

Контроллер содержит только логику взаимодействия с пользователем:

• выбор view для отображения данных
• вызов процедур обработки данных
• отображение уведомлений
• управление сессиями

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

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

Часто вижу, что владельцы сайтов и разработчики используют видео-плееры вроде VideoJS, Flowplayer, Uppod и т.д., но очень редко вижу стандартные HTML5 плееры на сайтах. Мне это кажется странным, ведь обычные плееры в браузерах тоже выглядят очень симпатично. Что есть у стандартного «браузерного» видео плеера:

1. Стильный дизайн. Зависит от браузера, но везде на хорошем уровне.
2. Поддержка самого популярного формата — Mpeg4 (H.264) (Chrome, Firefox, IE, Safari, Opera).
3. Очень удобное API — http://www.w3.org/2010/05/video/mediaevents.html
4. Быстрая работа и поддержка мобильных устройств.

Почему же такие плееры не популярны? Вот список возможных причин:

1. Нет простого способа добавить свой логотип.
2. Нет поддержки FLV видео, которое часто ещё встречается.
3. Нет возможности ставить метки на видео и создавать свои расширения.
4. Нет возможности менять внешний вид и стиль плеера.

С последним пунктом сложнее всего, но довольно редко эта возможность используется и на плеерах, о которых я писал в начале. Чаще используется первая стандартная тема оформления. Первые три пункта я решил восполнить, написав jQuery плагин, так появился Video Extend.

Про чаты-помощники

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

Есть с десяток подобных сервисов и все они работают по принципу "пробная версия бесплатно, а дальше за деньги".
На хабре есть несколько статей, вот одна из них (http://habrahabr.ru/company/tuthost/blog/165365/), но, я уверен, аудитория Хабрахабра знает о чем речь.
Большинству людей подойдет бесплатный вариант любого такого сервиса: нужно всего-навсего зарегистрироваться и вставить на сайт кусок JS кода. Для тех у кого много менеджеров — придется платить: например Редхелпер на 10 операторов обойдется Вам:


Скорее всего — цена адекватная для тех, кто платит зарплату десяти менеджерам.

Но я решил изобрести бесплатный «велосипед» из подручных материалов.
Запуск у себя на сервере займет 15 минут. Всем, кому идея интересна — прошу под кат.

Перевод статьи advanced css filters, авторства Vincent De Oliveira, найденная мною в последнем дайджесте.

Я не смог коротко перевести на русский backdrop и background, сохранив смысловую разницу между ними, поэтому поясню сейчас:
backdrop — то, что находится за элементом, и может быть видно через него, обрезано по его рамке;
background — тоже фон, но является частью элемента, к нему и относится свойство background.

Вернемся в 2011 год, браузеры начали вводить CSS фильтры из спецификаций. В это время поддерживались в основном SVG фильтры, а Firefox был единственным браузером, который мог применить их к HTML контенту (в основном, ничего не изменилось).

CSS фильтры такие как blur(), contrast() или grayscale() — отличное дополнение к CSS, несмотря на то, что SVG может позволить сделать восхитительные вещи. Больше узнать о них вы можете на множестве ресурсов.

Сегодня я хочу пойти чуть дальше, показав новые возможности CSS.