Одной из наименее обсуждаемых функций, все чаще появляющейся в последних браузерах, является поддержка файлов формата SVG. Этот формат характеризуется абсолютной свободой в отображении: легко изменяется в размере, может быть отображен в любом разрешении без потери качества. Во многих случаях SVG весят гораздо меньше, чем, например, PNG или JPG.



Но самое клевое свойство SVG, о котором многие разработчики не знают, это то, что этот формат построен на спецификации XML. C помощью этого мы можем манипулировать элементами SVG файла используя технологии вроде CSS или JavaScript, с которыми разработчики уже знакомы.

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

Опять понедельник, и опять что-то интересное у нас на столе в Box Overview! На этот раз — интеллектуальное зарядное устройство для Ni-Mh аккумуляторов типоразмера AAA и AA.
Почему интеллектуальное?


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

Предыдущий пост с описанием фреймворка maxmertkit получил большой отклик. Фреймворк особенно понравился, почему-то, японцам, но наилучшую конструктивную критику и помощь я получил от хабрасообщества. Теперь к делу.
Нынешние фреймворки, включая мой, имеют модульную структуру. Но все эти модули в некоторой степени являются зависимыми друг от друга. Это плохо. Именно эту проблему я и хочу решить.

Я обожаю twitter bootstrap. Прост, местами логичен, достаточно красив, подходит для быстрого прототипирования веб-интерфейсов. Но этого оказалось недостаточно. Взяв twitter bootstrap в большой проект, мне пришлось целиком его разобрать и переосмыслить css-фреймворки как боевые единицы в веб-проектах. В результате переосмысления родились требования к любому css-фреймворку, удобному как верстальщику, так и frontent-разработчику.

Достаточно древняя задача отслеживания события изменения размеров произвольного элемента на странице. Актуально при создании модульно-независимой структуры для корректировки размеров и иных сss-атрибутов нужного элемента на странице, в частности блоков с периодической Аякс-подгрузкой (например: новостных). Типично решается через таймирование и периодический опрос размеров элемента. Новый вариант, — не использующий таймирующий опрос.

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

До весны 2012 года у нас вместо такой базы существовали две базы данных разного уровня — со стороны спайдера, который имел свою собственную базу URL-ов, и со стороны индексатора. Это было крайне неудобно: допустим, если пользователь жаловался, что его сайт не индексируется, то для того, чтобы найти причину, при старой архитектуре пришлось бы анализировать массу данных. На это требовалось день-два, иногда даже неделя.

Задачи, которые обрабатывали данные, такие как антиспам или ссылочный граф, вынуждены были работать отдельно, создавая еще большую путаницу. Мы понимали, что нужно что-то менять.

Нам нужно:

1. Установить на сайте собственные иконки с помощью SVG.
2. Они должны управляться с помощью CSS (форма, размер, заливка, эффекты в том числе и их поведение).
3. Они должны иметь маленький вес и находиться в одном месте для экономии http запросов.
4. Работать во всех основных современных браузерах.

демо

Проблема z-index в том, что многие просто не понимают, как он работает.
Всё, описанное ниже, есть в спецификации W3C. К сожалению, не все её читают.

Описание проблемы:

Итак, пусть у нас есть HTML код, состоящий из 3 элементов.
Каждый из них внутри себя содержит по одному . А каждый , в свою очередь, имеет свой фон: красный, зеленый и синий, соответственно. Плюс ко всему, каждый позиционирован абсолютно левого верхнего края документа таким образом, что он немного перекрывает собой следующий за ним . Первый имеет z-index, равный 1, у остальных двух z-index не задан.

Многие уже слышали о проекте WebRTC, некоторые даже используют его (или пытаются применять в существующих проектах), а кто-то злобно потирает руки, предвкушая постепенную расправу со Skype и Flash.

Погуглив в Хабре (хе-хе) я почему-то не нашел статей, которые углублялись в техническую сторону WebRTC, показывали бы примеры его использования.

Что же, я попытаюсь порадовать вас схемками, кодом. В общем, именно тем, что всем по вкусу. Так пройдем же под кат, мой любимый читатель.

Webshell.io предназначен для создания прототипов и мэшапов на основе JavaScript API различных веб-сервисов. Что-то вроде IFTTT, но для программистов. С его помощью можно в интерактивном режиме писать запросы на JavaScript и CoffeeScript к клиентским и серверным API Google, Facebook, Twitter и многих других популярных сайтов и видеть их ответы в консоли, а так же создавать свои приложения, API которых, в свою очередь, будет доступен другим разработчикам. Webshell также поддерживает рендеринг HTML из шаблонов EJS.

Какие грабли зарыты в IMAP

Уже некоторое время IMAP работает в Почте Mail.Ru в полную силу, и я готов рассказать о том, с какими проблемами мы столкнулись при его запуске. Часть из них была связана с особенностями самого протокола и с его историей, другие были обусловлены спецификой взаимодействия IMAP с нашим хранилищем. Отдельная категория трудностей вызвана многообразием почтовых клиентов.

За подробностями — добро пожаловать под кат.

В сентябре Почта Mail.Ru включила HTTPS-шифрование для всех пользователей.

Преимущества защищенного соединения очевидны всем разработчикам крупных интернет-проектов. Большинство современных web-серверов (nginx, Apache, etc) и браузеров поддерживают HTTPS. В то же время сайтов, на которых безопасный протокол включен всегда и по умолчанию, не так много. Почему это так? С какими трудностями мы столкнулись при поддержке HTTPS? Читайте под катом.

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

Я работаю в Почте Mail.Ru, и моей прямой обязанностью является работа с JavaScript во всех его проявлениях. Прикрепление файлов к письму — одна из основных функций любой почты. Мы тут не исключение: у нас уже был Flash-загрузчик, который вполне исправно работал и долгое время нас устраивал. Однако у него был ряд недостатков. Вся верстка, графика, бизнес-логика, и даже локализация были зашиты в нем, в результате чего решение было громоздким, а внести правки мог только Flash-разработчик. В какой-то момент мы поняли, что нам необходим новый механизм. О том, как его создать, пойдет речь в этой статье.

В начале декабря в Санкт-Петербурге при партнерстве Mail.Ru Group прошел полуфинал чемпионата мира по программированию ACM ICPC. В рамках чемпионата я встречался с участниками и рассказывал о том, как сделать веб-сервис системой реального времени; а сейчас хочу поделиться своим докладом на Хабре.

Говоря о системе реального времени, мы представляем атомную станцию, самолет или нечто подобное, где от скорости реакции информационной системы зависит жизнь людей. Если в системе реального времени команда будет тормозить 10 секунд из-за сборки мусора, последствия могут быть более чем плачевными. Реакция должна быть моментальной, причем за гарантированное время.

При работе веб-сервиса, конечно, жизнь человека не зависит от того, насколько быстро он открыл письмо в почте, но требования к веб-сервису почти такие же. Еще 15 лет назад, когда пользователь кликал на ссылку, он ожидал реакции 10 секунд; для медленного интернета того времени это было нормально. Современный интернет – это широкие каналы, быстрые компьютеры. У пользователей все работает быстро, и они ждут от сервисов того же.

Когда пользователь куда-то кликает, он ожидает моментально получить реакцию на свой клик. Что такое моментально? Для человека комфортной задержкой считается время отклика порядка 200 миллисекунд, хотя на самом деле человеческий глаз различает время около 10 миллисекунд. Веб-сервис должен реагировать на действия пользователя не более чем за 200 миллисекунд — чем меньше, тем лучше.

Итак, современный веб-сервис, по сути, должен быть системой реального времени. Как сделать так, чтобы он отвечал этому требованию, я расскажу на примере Почты Mail.Ru.