Insight IT

Вакансии: PHP и Python разработчики в Киеве

Иван Блинков — Thu, 20 Sep 2012 20:16:00 +0400

Вакансии более не актуальны

Киевская команда разработчиков игр для социальных и мобильных платформ Level UP ищет опытных специалистов по веб-разработке на Python и PHP.

Senior Python Developer

Задачи:

Разработка высоконагруженных веб-приложений;
Разработка внутренних и публичных API;
Разработка архитектуры комплексных сервисов;
Конвертирование бизнес-задач в технические решения (R&D).

Требования:

Опыт разработки на Python более 3х лет;
Сильные навыки применения реляционных и нереляционных баз данных;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт работы в команде.

Плюсом будет:

Опыт разработки комплексных проектов на PHP или серверном Javascript (node.js);
Опыт разработки инструментов для верстки, автоматизации верстки, шаблонизаторов и пр.

Senior PHP Developer

Задачи:

Разработка высоконагруженных социальных веб-приложений;
Работа в небольшой дружной команде до 15 человек;
Решение нетривиальных задач и создание инструментов для внутреннего использования;

Требования:

Опыт разработки на PHP более 3х лет;
Опыт работы с MySQL и MongoDB;
Опыт в разработке высоконагруженных веб-приложений;
Дружба с Linux и Git;
Хорошее знание клиентских технологий (HTML, CSS, Javascript);
Опыт примененения функционарного и юнит тестирования.

Плюсом будет:

Опыт разработки на Python или серверном Javascript (nodejs).

Условия для обоих вакансий

Зарплата в диапазоне \$2500-4000 в месяц по результатам собеседования;
Полный рабочий день в Киевском офисе, иногородним помощь с переездом;
За успешную рекомендацию специалиста по данным вакансиям компания выплачивает бонус в размере $1000 так что сообщите своим знакомым, кому-то это может быть интересно.

Заинтересовало?

Вакансии более не актуальны

Не лишним будет, если кроме резюме Вы напишите - почему Вам нравится серверная разработка на Python или PHP и почему Вам интересна данная вакансия. Плюс упомяните, пожалуйста, что Вы узнали о данной вакансии через Insight IT.

Вакансии: команда IT-звезд

Иван Блинков — Fri, 04 May 2012 18:20:00 +0400

Вакансии более не актуальны

Благодаря сайту Insight IT, компания RDM-Soft нашла ОТЛИЧНОГО тимлида! Теперь, тимлидер ищет в свою команду единомышленников и просто IT-звезд.

О компании

История компании началась в 2003 году. С этого момента выпущено много проектов. Некоторыми из них Вы, возможно, так или иначе пользовались. Сейчас запускается еще один проект: SEO-биржа. У Вас есть прекрасная возможность оказаться у истоков будущего хита!

Кто нужен?

Mr. Backend. Он же программист. (вакансия закрыта)
Мастер-ломастер. Он же инженер по контролю качества, проще говоря тестер.
Dr. Frontend. Он же фронтендщик. (вакансия закрыта)

Mr. Backend

Требования

Отличные знания: PHP, ООП, SQL, MVC, ZendFramework (либо альтернатив), Linux.
Опыт работы по специальности: от 3 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Разработка серверной части проекта. Включает в себя :
- бухгалтерия;
- бизнес-логика;
- статистика;
- различные парсеры.

Мастер-Ломастер (SQA)

Требования

Хорошие знания: PHP, SQL, Linux.
Отличные знания принципов whitebox и blackbox тестирования.
Опыт работы по специальности: от 2 лет.
Опыт работы в команде.
Желание развиваться и изучать новое.
Отсутствие желания искать работу в ближайшие 3 года.

Задачи

Написание юнит-тестов, автотестов.
Тестирование:
- бекенда;
- фронтенда;
- бизнес-логики;
- производительности;
- безопасности.
В общем, тоже очень много интересной работы.

Dr. Frontend

Требования

Понимание, как сделать интерфейс удобным и приятным для пользователя
Отличные знания: HTML, CSS, JavaScript (jQuery, ExtJS или других распространенных библиотек)
Опыт проектирования и реализации пользовательского интерфейса

Задачи

Прототипирование UI сервиса
Реализация спроектированного UI
Разработка расширений для Firefox и Chrome.

Условия

Удаленная работа.
Работа в профессиональной команде.
Полный рабочий день (5 дней в неделю по 8 часов).
Карьерный и профессиональный рост.
Прислушивание к Вашему мнению.
Зарплата по результатам собеседования:
- Mr. Backend: от $1500 до $2000
- Мастер-Ломастер: от $700 до $1500
- Dr. Frontend: от $1000 до $2000

Вакансии более не актуальны

Повторное использование шаблонов

Иван Блинков — Fri, 13 Apr 2012 08:00:00 +0400

Лень - двигатель прогресса

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

Небольшая ремарка, чтобы не было недопонимания из-за терминологии:

Шаблон (template) : HTML-документ с расширенным набором тегов, которые впоследствии используются для подстановки динамических данных.
Шаблонизатор (templating engine) : библиотека, позволяющая на основе шаблона (использующего определенный синтаксис дополнительных тегов) и динамических данных получить итоговый HTML-документ, пригодный для отображения в браузере.
Рендеринг (rendering) : в данном контексте — процесс, которым занимается шаблонизатор.

Общий принцип

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

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

HTML интерфейс просто разбирает HTTP-запросы, отправляет на его основе сообщение(ия) внутренним сервисам, получает в ответ имя шаблона и данные для его заполнения, с помощью шаблонизатора рендерит итоговый HTML и отдает браузеру или роботу.

Интерфейс сериализованных данных (если он, как и обсуждалось ранее, работает через постоянное соединение с браузером) каждому подключившемуся клиенту первым делом отправляет JSON-объект с шаблонами, по крайней мере если их не особо много, иначе лучше "по запросу". При действии пользователя JavaScript-клиент отправляет сообщение с информацией, на его основе интерфейс сериализованных данных передает то же самое (а может и как-то модифицированное) сообщение внутреннему сервису, также получает в ответ имя шаблона и данные и перенаправляет их клиенту (возможно сконвертировав в другой формат). Клиенту остается передать их своему шаблонизатору и заменить результатом его работы какую-то часть уже имеющегося в окне браузера HTML-документа.

Рендеринг

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

Отсутствие внешних вызовов при рендеринге, то есть на входе только данные, если используются какие-то фильтры или что-то такое - они должны быть частью шаблонизатора.
Шаблонизатор должен иметь реализацию на JavaScript, так как будет исполняться в том числе и в браузере.

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

В этой схеме напрашивается использование node.js для реализации HTML-интерфейса, что откроет доступ к многочисленным шаблонизаторам, реализованным исключительно на JavaScript. Тем более кроме рендеринга шаблонов эта часть проекта практически ничего и не делает. В качестве бонуса требование про отсутствие внешних вызовов станет не таким строгим, да и в целом, если минималистичное решение вроде mustache по каким-то идеологическим соображениям не устраивает - любой написанный для node.js шаблонизатор наверняка станет отличным выходом.

Структура шаблонов

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

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

Блока <head> документа
Видимой "шапки" сайта
Сайдбара(ов), если они не сильно зависят от основного контентом страниц
Видимого "подвала" сайта плюс тегов для подключения JavaScript

HTML-интерфейс при чтении их из файловой системы "склеивает" их в полные шаблоны для каждой страницы, просто конкатенацией или с использованием механизмов шаблонизатора. Интерфейс сериализованных данных "заворачивает" шаблоны страниц в JSON (или другой используемый формат) прямо в исходном виде для вставки в блок с основным контентом. Из "общесайтовых" шаблонов браузерному клиенту вероятно могут понадобиться только сайдбар(ы), и то не всегда.

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

Примечания

При использовании минималистичного шаблонизатора без внешних вызовов будьте морально готовы передавать ему "многоуровневые" объекты для вставки в шаблон. Например, если говорить о постраничной навигации, там, где в продвинутом шаблонизаторе было бы что-то вроде {% pagination(current_page, total_pages) %}, может понадобится не только написать саму верстку (что, в целом, хорошая практика), а еще и передать информацию о точном списке страниц, какая именно из них активная, где пропуски и пр.
Стоит обращать внимание на производительность используемого шаблонизатора. Например, под одну из платформ "официальная" реализация mustache, как оказалось, проигрывает сторонней с отрывом в 2 порядка.
Хоть при таком подходе добиться одинакового внешнего вида страниц при рендеринге серверной и клиентской частью достаточно легко, следить за их соответствием все же стоит - какие-то детали можно и упустить.

Заключение

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

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

Эта статья - четвертая в серии про Интерактивные сайты, автор - Иван Блинков, основано на личном опыте. До встречи на страницах Insight IT!

Jinja2

Иван Блинков — Sun, 19 Feb 2012 18:39:00 +0400

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

Встречаем!

Введение

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

Прежде чем перейти к делу, хочу напомнить что имеется ввиду под словом шаблонизатор: механизм для создания HTML-страниц путем заполнения HTML-шаблонов динамическими данными, получаемыми из СУБД или внешних источников. Шаблонизатор предоставляет некую надстройку над синтаксисом HTML для создания шаблонов и API для их использования.

Базовый функционал

Многое из этого можно увидеть и в альтернативных реализациях шаблонизаторов, так что ничего особенного:

{{ ... }} позволяет распечатать значение переменной или какого-то выражения, синтаксис достаточно свободный - можно обращаться к элементам коллекций, методам/атрибутам объектов и.т.п.
{% ... %} позволяет вызвать дополнительные теги, среди которых условные выражения, различные варианты циклов и многое другое.
Присутствиет концепция фильтров, сильно напоминающих UNIX pipes: начинается все с переменной или выражения, после чего можно через символ | указать как её обработать перед выводом в итоговый документ. Например, {{ foo|lower }} выведет содержимое строки foo в нижнем регистре. Как и в pipes, из фильтров можно делать цепочки.
Механизм наследования позволяет избежать избыточности в коде. В коде шаблона выделяются именованные блоки тегом {% block ... %}, после чего шаблон-потомок может переопределить содержимое блоков шаблона-родителя произвольным образом. Типичный пример использования:
- Создается базовый шаблон страницы, состоящий из основного каркаса страницы и всех общих для всего сайта элементов (ссылки на файлы стилей, общие JavaScript файлы и библиотеки, какие-то мета теги, title по-умолчанию)
- В базовом шаблоне содержимое каждой части выделяется в именованный блок (как минимум шапка, место под контент, 1-2 сайдбара и подвал), иногда рядом со стилями и скриптами оставляют по пустому блоку на случай, если шаблонам-наследникам потребуется что-то специфичное.
- Если какой-то блок будет содержать одну и ту же информацию на большинстве страниц сайта, то её тоже обычно помещают в базовый шаблон.
- Создается по шаблону-потомку на каждый тип используемых на сайте страниц, в которых переопределяется как правило (но далеко не всегда) только блок с конткентом и заголовок страницы. Из шаблонов-потомков также можно составить иерархию в случае, если у них есть много общей информации.
- Стоит упомянуть, что есть альтернативный механизм включения (include) шаблонов по-аналогии с PHP-файлами, но я достойных применений ему не нашел.
Очень много внимания уделено экранированию символов, хотя особо на него надеяться не стоит - с точки зрения безопасности намного важнее фильтровать попадающие на сайт данные, а не выводимые в шаблонах. Хотя как дополнительная подстраховка не помешает.
Простая интеграция с gettext придется кстати интернациональным проектам.
Опциональное считывание шаблонов с диска при каждом запросе страницы незаменимо при разработке.

Производительность

Сравнительные тесты производительности шаблонизаторов под Python довольно условны, очень многое зависит от конкретных шаблонов и динамических данных. Тем не менее, во всех из них Jinja2 определенно не в аутсайдерах, в топ5 вполне стабильно.

Шаблоны компилируются в байткод для последующего использования, с этой особенностью связаны два момента, которые спользовать:

Байткод можно хранить в memcached или любом другом внешним хранилище, достаточно лишь реализовать минимальный get/set интерфейс.
Доступен опциональный модуль на C, который берет на себя часть работы по заполнению шаблонов, что делает этот процесс несколько быстрее.

Расширяемость

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

Webassets

Этот проект позволяет делать с подключаемыми внешними Javascript и CSS файлами практически все, что угодно. В типичном варианте использования используется тег {% assets %} для:

Указания списка изначальных CSS/JS файлов, для конкатенации и последующей обработки.
Указания окружения ссылки на итоговый файл, т.е. как именно должен выглядеть тег <script> или <style>.
Списка фильтров, для минимизации или других преобразований кода.
Возможно использование sass или less файлов вместо чистого CSS.
Отключение конкатенации и минимизации при разработке доступно изменением одного флага.

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

Доступна интегрирация и с другими Python шаблонизаторами, в Jinja2 он подключается просто как расширение.

Минимизация HTML

Этот вопрос решается путем наследования от поставляемого вместе с шаблонизатором загрузчика шаблонов. API позволяет делать между чтением шаблона и генерацией байткода что угодно с текстом шаблона, например можно пропустить все через примитивную регулярку (вернее через несколько) и свернуть тем самым весь HTML в одну строку. Хочется обратить внимание, что осуществляется этот процесс очень редко (особенно при использовании кэша байт кода), так что можно делать на этом этапе даже сильно ресурсоемкие преобразования текста.

Другой формат данных

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

Да, наверняка многие скажут, что в этой ситуации надо было использовать универсальные шаблоны для JS и серверной части, но на Jinja2 такое тожно можно реализовать, с той лишь разницей, что пришлось гонять по сети не только сами данные, но и часть HTML-разметки (что, порой, тоже не плохо). Реализуется как и минимизация HTML посредством переопределения загрузчика страниц, который использовался вместо стандартного, если запрос пришел через AJAX.

Сэкономим еще пару байт

С подобного рода оптимизацией не заборачивается, наверное и 0.01% интернет-проектов, но я в свое время как-то увлекся и написал штуку для "выжимания" десятка-другого байт с большинства страниц и CSS/JS файлов. "Проблема" состоит в следующем: классы и идентификаторы, использующиеся в HTML, в "культурных" проектах имеют хотя бы отдаленно человекочитаемые названия, что почти всегда означает их длинность, что, учитывая их частую повторяемость в коде, в свою очередь негативно влияет на итоговый размер HTML/JS/CSS документов. Теоретическое решение лежит на поверхности: использовать "длинные" идентификаторы и классы в HTML при разработке, а при развертывании на публику переименовывать их в "короткие": a, b, c, ..., aa, ab, ac, ...

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

Если у кого-то возникнет желание тоже сделать что-то подобное средствами Jinja2, то советую "вмешиваться" в обработку JS/CSS посредством дополнительного фильтра в Webassets, а сами шаблоны редактировать как и в предыдущих разделах при считывании их с диска.

Спрайты и обработка изображений

Создание спрайтов как таковых не предусмотрено, так как по сути это не по части шаблонизатора. Но есть вариант подключить их к Webassets, например через интеграцию Ruby-проектом compass (у которого есть плагин-генератор спрайтов).

Если говорить просто о уменьшении размеров изображений, то это легко делается средствами самого Python и с шаблонизатором практически не взаимодействует: достаточно обрабатывать изображения при загрузке их пользователями и держать статические изображения "в форме".

Идеи для фильтров и глобальных функций

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

Форматирования даты/времени по шаблону
Фильтрации HTML с белым списком тегов
Получения атрибута объекта с неизвестным заранее именем (getattr)
Вывода строки в режиме "первая - заглавная, остальные - прописные
Генерации часто используемых HTML-тегов, например <a href="..."></a>

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

Подводим итоги

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

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

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

Спасибо за внимание, подписавшись на Insight IT можно узнавать о новых материалах одним из первых :)

Как нужно верстать?

Иван Блинков — Fri, 25 Feb 2011 00:02:00 +0300

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

HTML и CSS должны быть читаемыми (все равно потом все ужимаем):
1. HTML должен быть иерархическим, открывающие теги с новой строки (кроме случаев с), отступы 4 пробела
2. CSS желательно не свернутые в строчку, а по одной директиве на строку, тоже с отступами по 4 пробела
3. Можно сразу использовать SASS - сильно упрощает всем жизнь
4. Идентификаторы классов должны быть человекочитабельмыми английскими словами и фразами
5. Очень желательно не использование в названиях классов и идентификаторов ключевых слов из HTML/CSS/JS/jQuery
6. Очень желательно, чтобы идентификаторы и классы не были префиксными (ни одно названия не является началом или концом другого, например .icon и .icon_small) - это позволяет сократить их все до 1-2 символов на этапе постобработки
DOCTYPE предпочтителен HTML5, но в крайнем случае можно и XHTML
Кодировка: обязательно UTF-8
Валидность:
1. HTML: http://validator.w3.org
2. CSS: http://jigsaw.w3.org/css-validator/
3. WCAG: http://www.cynthiasays.com/ и http://www.w3.org/WAI/WCAG20/quickref/
Соответствие макету:
1. Проверка: https://addons.mozilla.org/ru/firefox/addon/pixel-perfect/, https://github.com/aishek/modulargrid и https://browserlab.adobe.com/en-us/index.html
2. Хоть и попиксельное соответствие приветствуется и считается обязательным, но местами возможны отклонения:
  1. Когда дизайнер нарисовал криво
  2. Когда незначительные различия в отрисовке шрифтов
  3. Когда у дизайнера разошлось вдохновение и единственный способ сделать точно так как на картинке - впихнуть здоровенный JPEG в пару сот килобайт на фон; в таких случаях стараемся разбить фон на составные части и/или паттерны и делаем его частями, стараясь минимизировать ущерб "креативу" при адекватном размере страницы
Кроссбраузерность:
1. Перед приемом/сдачей работы проверить на http://browsershots.org/ (или аналоге) и во всех доступных под рукой браузерах
2. Не забыть мобильные браузеры Opera Mini, iPhone и Android.
3. Хаки для IE в conditional comments, не забываем правильно фильтровать для разных его версий
4. IE6 должен адекватно воспринимать специфичные для HTML5 теги
5. Помимо этого желательно проверить все разрешения от 1024х768 до 1920х1080 - везде все должно смотреться пристойно, без скроллбаров и излишних пустых областей
Гибкость шаблона:
1. При этом не смотря на то, что в макетах для примера используется какой-то текст, шаблон должен нормально себя вести при любом количестве текста (как нулевом, так и очень большом) в любом элементе
2. Если пункт меню, заголовок или просто текст в 5-10 раз длиннее или короче того, что на макете - все должно отображаться корректно (по возможности, естественно)
3. Если в макете не было всех шести видов заголовков, ссылок в тексте, картинок, цитат, аббревиатур, блоков pre и code - это не значит, что стиль по-умолчанию для всех стандартных html-элементов может отсутствовать в CSS - возьмите цвета и стиль от других элементов шаблона и сделайте хоть как-то, для образца все элементы можно добавить в текст, даже если их там не было
4. У всех ссылок должно быть отдельное поведение для :hover, у ссылок внутри текста - и для :visited
5. Если в макете все же были заголовки: их структура должна быть перенесена верно
6. Надеяться, что WYSIWYG или Word проставит какие-то особые стили к тексту и все будет нормально нельзя
7. Если используем HTML5, то верстка должна быть семантической, то есть блоки навигации заворачиваем в nav, сайдбар в aside и.т.п.
8. Стили для печати и мобильной версии указываем отдельными файлами с соответствующим media
CSS:
1. Не забываем о производительности CSS: селекторы обрабатываются справа-налево, подробнее здесь: http://code.google.com/speed/page-speed/docs/rendering.html
2. CSS3 правила для нормальных браузеров (border-radius, gradient, text-shadow, box-shadow), с остальными извращаемся отдельно, никаких хаков с кучей <b> и подобных
3. Размеры и позиционирование элемента должны указываться в одних единицах измерения
Изображения:
1. С умом относимся к выбору формата и уменьшаем их объем (см. "Инструменты для минимизации размера изображений"
2. Иллюстрации и элементы интерфейса с четкими краями лучше сохранять в PNG8, фотографии в progressive JPEG - но в целом руководствуемся минимизацией объема не в ущерб качеству
3. Отсутствие title и alt непростительно
4. По возможности всегда указываем размеры изображений, особенно если они являются частью дизайна и заранее известны
5. Для групп небольших изображений приблизительно одинаковой ширины или высоты (иконки, картинки разных буллетов и.т.п.) используем CSS Sprites: http://css-tricks.com/css-sprites/ (для ленивых есть ряд инструментов для автоматизации процесса)
6. Для совсем маленьких изображений используем data:URI+MHTML: http://www.phpied.com/inline-mhtml-data-uris/
Шрифты:
1. Указываем базовый размер шрифта в em, там где нужен размер больше или меньше - в % от базового
2. Line-height задаем в долях
3. Должно быть как минимум одному шрифту для Windows, Linux и Mac OS. Примеры:
  1. Arial,Helvetica,FreeSans,"Liberation Sans","Nimbus Sans L",sans-serif
  2. "Courier New",Courier,FreeMono,"Nimbus Mono L","Liberation Mono",monospace
  3. Georgia,"Bitstream Charter","Century Schoolbook L","Liberation Serif",Times,serif
  4. "Lucida Sans","Lucida Sans Unicode","Lucida Grande",Lucida,sans-serif
  5. "Lucida Console",Monaco,"DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono",monospace
  6. Palatino,"Palatino Linotype",Palladio,"URW Palladio L","Book Antiqua","Liberation Serif",Times,serif
  7. Tahoma,Geneva,"DejaVu Sans Condensed",sans-serif
  8. "Times New Roman",Times,"Nimbus Roman No9 L","FreeSerif","Liberation Serif",serif
  9. Verdana,"Bitstream Vera Sans","DejaVu Sans","Liberation Sans",Geneva,sans-serif
4. Если требуется нестандартный шрифт, используем кроссбраузерный font-face: http://randsco.com/index.php/2009/07/04/p680
Формы:
1. Ко всем полям должен быть label или, если так задумано, toggleval
2. Если используем HTML5, то и поля форм тоже делаем по этому стандарту (email/tel)
3. Проверить работу tabindex
Использование микроформатов желательно, если они уместны (hCard, hCalendar, hAtom, XFN)
JavaScript:
1. Весь используемый JS располагается перед закрывающим </body>
2. Желательно использование асинхронной загрузки файлов
3. Работоспособность проверяем средствами Firebug
4. Сайт должен нормально функционировать с выключенным JavaScript (и Flash тоже, к слову)
5. Если на странице имеются формы - они должны валидироваться еще до отправки и нормально отображать ошибки (как минимум просто цветом)
Остальное:
1. Полное отсутствие комментариев в html, кроме условных
2. Копирайт пишем правильно: http://habrahabr.ru/blogs/typography/23812/
3. Никакого CSS или JS внутри HTML, только внешние файлы
4. Ссылки на внешние ресурсы должны быть с target="_blank" и по необходимости могут снабжаться иконками: https://github.com/joshuaclayton/blueprint-css/blob/master/blueprint/plugins/link-icons/screen.css
5. Текст лучше оттипографить перед публикацией: http://rmcreative.ru/blog/post/tipograf
6. Логотип должен вести на главную страницу
7. Ссылки на внешние ресурсы (изображения, CSS, JS) лучше делать относительными
8. Не забываем <title> всей страницы, должен быть понятен как человеку, так и поисковым системам
9. HTML, JS и CSS лучше минимизировать не на этапе верстки, а автоматически при генерации шаблонов
10. Не забыть выкинуть не используемые стили (вроде красной рамочки для выделения элементов в процессе верстки)

Микроформаты

Иван Блинков — Sun, 27 Jan 2008 19:31:00 +0300

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

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

Что представляют собой микроформаты?

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

Как не трудно догадаться, измение существующих и добавление новых тэгов к стандарту XHTML в микроформатах недопустимо, ведь иначе документ перестанет соответствовать исходному стандарту. Именно по-этому для реализации микроформатов используются атрибуты тэгов XHTML, в которых допускаются некоторые вольности - rel и class.

Что же может дать осмысленность разметки?

В перспективе вся эта затея направлена на повышение качества сервисов, предоставляемых в Сети. На данный момент большая часть сервисов, основанных на анализе данных расположенных в Сети, способна лишь на частичное использование разметки документа для уточнения смысла той или иной информации. Показать это лучше всего на примере: тэги <em> и <strong> говорят о том, что содержащаяся внутри них информация имеет некий смысловой акцент, но в то же время многие другие тэги не несут за собой никакой дополнительной смысловой информации, помимо содержащегося внутри них текста. Одним из таких тэгов является <a>, который говорит о наличии ссылки на некоторую интернет-страницу, как-то связанную с текстом между открывающим и закрывающим тэгами, а также расположенную по URL, указанному в атрибуте href, можно конечно к этому прибавить атрибут title, но так или иначе на этом информация о ресурсе, на который ссылается автор документа, заканчивается. Один из микроформатов, позволяющих расширить возможности простых ссылок, называется XFN и предоставляет авторам документов возможность описать свое отношение к другим авторам, на работы которых они ссылаются, выглядит это примерно следующим образом:

<a href="http://www.my-friend.ru" rel="friend">
    Сайт моего друга
</a>

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

Классификация

Наверняка к Вам в голову приходила мысль: а почему необходимо пользоваться именно вот этими микроформатами? Если в XHTML допускаются любые значения тэгов rel и class, почему я не могу придумать свои микроформаты и пользоваться ими? Ответ прост: микроформаты призваны повысить качество Сети вцелом, а не какого-то конкретного сайта отдельно. Только часть микроформатов получила широкое распространение, и именно ими приходится пользоваться всем остальным сайтам под влиянием сетевого эффекта (т.е. того факта, что ценность технологии прямо пропорциональна обширности ее применения, в нашем случае в рамках Сети), просто чтобы быть совместимыми с остальной частью Интернета.

Но не смотря на это - количество и разнообразие распространенных микроформатов велико, и как-либо классифицировать их достаточно сложно. Самым простым и точным вариантом можно назвать разделение по структуре формата:

элементарные - применимые только к одному конкретному типу тэгов. В эту группу попадают упомянутый выше XFN, а также множество других, например rel-tag, rel-nofollow*, и так далее;
композитные (или составные) - имеют более сложную структуру, и для своей реализации требуют модификации нескольких тэгов одного элемента. Микроформаты из этой категории предназначены для описания более сложной структуры, например hCard, используемый для описания людей или организаций (можно посмотреть на пример его использования на моей странице "О себе").

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

Применение на практике

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

Многие поисковые системы активно используют при составлении своего индекса микроформат rel-nofollow, об этом мне уже доводилось упоминать в одной из предыдущих записей;
Plug-in для Firefox под названием Operator - позволяет просматривать используемые на текущей странице микроформаты, а также предлагает небольшой ассортимент действий, с ними связанных. Например, hCard предлагается экспортировать в адресную книгу, а для rel-tag - осуществить поиск по скромному списку интернет-сервисов. Лично я уже достаточно его себе установил и всегда держу включенным, не для того, чтобы реально им пользоваться, а просто чтобы быть в курсе, что тот или иной ресурс вдруг начал поддерживать эту замечательную технологию;
Появляется все больше и больше CMS, поддерживающих различные микроформаты "из коробки" или с помощью plug-in'ов, что ведет к все более активному расширению списка сайтов, следующих этим стандартам представления данных. WordPress, ~~на которой работает этот блог~~, тоже относится к категории CMS, поддерживающих микроформаты, в чем вы можете убедиться, установив упомянутый в предыдущем пункте Operator. Сам по себе этот факт какой-либо полезности не несет, но является лишним стимулом для разработчиков программного обеспечения и интернет-ресурсов, поддерживающих микроформаты.

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

Подводим итоги

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