UPD. Для краткого введения в адаптивный дизайн рекомендую прочитать статью «Как сделать один сайт для всех устройств (Responsive Web Design)».

Перевод крайне ценной статьи «Responsive Web Design Techniques, Tools and Design Strategies» популярного интернет-издания для разработчиков Smashing Magazine.

Еще в январе мы опубликовали статью об адаптивном дизайне «Responsive Web Design: What It Is and How To Use It» (Адаптивный веб-дизайн: Что это такое и как им пользоваться). Адаптивный веб-дизайн продолжает привлекать к себе много внимания, но, учитывая, насколько он отличается от традиционных методов разработки сайтов, он может показаться заоблачно сложным для тех дизайнеров и разработчиков, которые его не пробовали.

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

Техники Responsive web design

1. CSS Transitions and Media Queries
CSS Transitions и Media Queries

Elliot Jay Stocks подробно рассказывает о методе сочетания CSS Media Queries и CSS transitions. Основная идея в следующем: разрабатывая адаптивный сайт с помощью Media Queries, вы постоянно изменяете ширину вашего браузера, чтобы посмотреть, как сайт ведет себя при этом. Но каждый раз, когда отрабатывает один из ваших Media Queries, виден жесткий переход между стилями (первый, например, для десктопов, второй — для планшетов). Почему бы не использовать CSS transitions для сглаживания этих жестких переходов с помощью анимации?

Mock на английском значит «имитация», «подделка». Модуль с таким названием помогает сильно упростить тесты модулей на Питоне.

Принцип его работы простой: если нужно тестировать функцию, то всё, что не относится к ней самой (например, чтение с диска или из сети), можно подменить макетами-пустышками. При этом тестируемые функции не нужно адаптировать для тестов: Mock подменяет объекты в других модулях, даже если код не принимает их в виде параметров. То есть, тестировать можно вообще без адаптации под тесты.

Такое поведение — уже не надувные ракетные установки, а целая надувная земля, вокруг которой могут летать испытуемые ракеты и самолёты.

Вчера была опубликована хорошая статья «Веб-дизайн. Каждому устройству свое представление». Несмотря на неплохие размышления, к сожалению, вывод в ней довольно глупый. А именно:

«Нужно определить, какими устройствами могут пользоваться ваши посетители, проработать и создать для этих устройств представление вашего сайта, определить устройство посредством проверки заголовков браузеров, и отправить наиболее подходящее представление.»

Почему это глупо

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



Это скриншот из презентации «Beyond the mobile web by yiibu» (очень рекомендую).

Во-вторых, если вы не facebook или yandex, скорее всего, вы не потянете создание и поддержку разных версий сайта для каждого устройства. Да и это не имеет особого смысла. Потому что ситуация становится похожа на реалии пятнадцатилетней давности. Тогда делали сайт «под браузер», а сейчас автор предлагает делать сайт «под устройство».

Как сделать один сайт для всех устройств

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

65 стартапов были продемонстрированы на традиционном демо дне Y Combinator, мы ознакомились с 39 предложениями и готовы рассказать свои впечатления вам. После ознакомления с командами и техническими особенностями, TechCrunch готова выбрать TOP-10. Меняющие принципы коммерции, помогающие нам общаться и многое для вашего телефона.

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

Наконец-то мы завершили и опубликовали перевод на русский язык документации по инструменту Selenium, пожалуй, наиболее популярному в последнее время инструменту автоматизации тестов для веб-приложений.

Русская версия в определенном смысле даже лучше, чем оригинальная, потому что в нее включены дополнительные главы, скомпилированные из статей в Selenium Wiki, которые заполняют «белые пятна», имеющиеся в официальном руководстве пользователя.

Мы надеемся, что теперь, благодаря преодолению языкового барьера, число поклонников Selenium будет расти ещё быстрее, и мы будем рады видеть Вас в наших рядах!

(Под катом — благодарности спонсорам и участникам проекта по переводу)

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

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



Ссылка на проект: http://bit.ly/eyesim

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

Основная функциональность сервиса заключается в возможности любого пользователи сети Интернете указать адрес Интернет-ресурса в поле ввода, автоматически получить скриншот указанной страницы сайта и начать применять к полученной картинке фильтры, каждый из которых соответствует тому или иному ограничению в зрении, для некоторых фильтров также отображается регулятор степени данного дефекта зрения, например для потери центрального поля зрения (регулируется площадь поля, недоступного для просмотра). Также в симуляторе реализован функционал слежения за взглядом пользователя: выбранный фильтр привязан к курсору, таким образом передвигая указатель по интерфейсу пользователь симулятора может передвигать полученное поле дефекта по картинке, что позволяет эффективно обнаруживать области, полностью недоступные пользователям с ограниченным зрением. Данные о виде видимых дефектов для различных фильтров симуляторы были взяты из разработок Cambridge Design Center, других прикладных программ-симуляторов для операционных систем Windows, технических устройств и фильтров для эмуляции зрения людей с ограниченными возможностями.

Для кого может быть полезен такой проект:

1. Профессиональным разработчикам интерфейсов информационных систем, тестировщикам и другим специалистам, так или иначе задействованным в разработке интерфейсов;

2. Для некомерческой аудитории — каждый человек, владелец сайта, сервиса сможет проверить доступность своих ресурсов для людей с ограниченными возможностями;

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

2012, Любич М.В.

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

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

Многие сталкивались с таким явлением как DDoS атака методом HTTP флуда. Нет, это не очередной туториал по настройке nginx, хочу представить свой модуль, работающий как быстрый фильтр между ботами и бэкэндом во время L7 DDoS атаки и позволяющий отсеивать мусорные запросы.

Хочу поделиться способом «изготовления» доски для записей. Свою на работе активно использую уже несколько месяцев.

Всё, что нужно —

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

> SELECT avg(amount) FROM transfer;
65.125965782378
generated in 3850 seconds

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

Друзья, я хочу вам рассказать историю развития проекта president2012.ru. Сайт является лидером по тематике выборов президента России, за 3 месяца его посетило около 2 млн. человек, в пике имел до 20 тыс. посетителей онлайн и более 1 млн. хитов в сутки, задействовано было 3 сервера облака.

Интересных моментов в процессе работы над проектом набралось столько, что держать в себе эти знания я не могу, и хочу поделится с вами. Я понимаю, что многое, о чем я сейчас собираюсь рассказать, уже описано качественнее в специализированных разделах, и ничего нового я не открою. Моя задача скорее в том, чтобы через отдельные нюансы передать ту атмосферу, в которой проходила работа над проектом. А так же в миллионный раз с помощью success story показать таким же как я людям, что всё возможно и всё в их руках.

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

Меня всегда удивляло отношение многих к анонимности и криптографии, как к универсальному средству борьбы с мировым злом. Стоит появиться новости о том, что где-то правительство закручивает гайки, или копирасты проталкивают очередной идиотский законопроект, обязательно возникает комментарий в духе “Ха! Вот мы щас I2P и TrueСrypt из широких штанин достанем, и они утрутся...” Нет, безусловно, в определённых ситуациях шифроваться можно и нужно. Анонимность может спасти жизнь в стране, где принято казнить людей, несогласных с тем, что текущий вечно живой вождь мудро ведёт свой народ к процветанию, а временные перебои с поставками продовольствия — всего лишь досадная мелочь. Но уход в подполье — это последняя надежда, аппарат искусственного дыхания для умирающей свободы, а не оружие победы.

Как-то раз я наткнулся в Сети на вики-проект со странным названием “Реконизм”. Что-то про новый общественный строй и светлое будущее. Но, пообщавшись с автором проекта и углубившись в чтение, убедился, что Рома Петров (@rpetrov) — совершенно нормальный и вменяемый человек, а не маньяк-графоман, точно знающий “как нам обустроить Россию” и черпающий вдохновение в задушевных беседах с инопланетянами. Его отношение к приватности и анонимности почти совпадало с моим, а многие статьи на его вики выглядели воплощением моих задумок и черновиков. Слово за слово, мы дообщались до того, что написали целую книгу о взаимной прозрачности, децентрализации и викификации общества. Пожалуй, одним из самых сильных стимулов к написанию книги было то, что нам так и не удалось найти изданий на русском языке, раскрывающих тему информационной прозрачности.

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

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

Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

Сегодня начал верстать очередной сайт и по привычке пошел на www.yaml.de, чтобы скачать самую свежую версию моего любимого CSS-фремворка и… не узнал внешний вид сайта.

Оказывается вышла новая версия, которая по прежнему осталась очень компактной (ядро 4.6 kB) и обеспечивает хорошую поддержку браузеров

Даже хорошие презентации, не содержащие списков из двадцати пунктов восьмым кеглем и вызывающих рвотный рефлекс картинок из бесплатных сборников клипарта “встречи и партнёрство” или “офисная жизнь”, следуют давным-давно заданному стандарту, без изменений перенесённому в офисные пакеты из мира старинных диапроекторов. Презентация всегда представляет собой набор прямоугольных картинок одинакового формата и размера. Иногда между ними добавляют переходы и анимацию, раздражающую не меньше разноцветных надписей и бессмысленно улыбающихся абстрактных офисных работников. Стандартом де-факто для хорошей презентации давно стала последовательность статичных слайдов без всякого мельтешения, с очень коротким текстом крупным шрифтом и несколькими тщательно подобранными фотографиями или скриншотами.

Основанный на трансформациях и переходах CSS3, javascript-фреймворк для создания презентаций impress.js выходит за рамки понятия “слайд” и позволяет строить презентации в открытом, неограниченном трёхмерном пространстве. Источником вдохновения для него послужил сервис prezi.com. Репозиторий impress.js на Гитхабе появился меньше месяца назад, но уже стал одним из самых популярных. Нетерпеливые могут посмотреть небольшую демку здесь, а остальные — создать пример необычной презентации прямо сейчас.

Здравствуй, %habraUser%
В этой статье пойдет речь о том, как расширять систему сбора статистики collectd путем добавления новых биндингов на python.
Эта статья является дополнением этой статьи

Постановка задачи

Нужно собирать данные с помощью collectd с модуля ustats для nginx. Нужно собирать HTTP 499, HTTP 500, HTTP 503 и TCP ошибки и выводить их на одном графике.

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