Здравствуйте, уважаемые хабравчане!
Буквально пару дней назад мы опубликовали первую часть топика, посвященного верстке e-mail рассылок, а конкретнее — использованию изображений. Вторая часть посвящена ещё четырем «подводным камням» верстки, которые нам удалось обнаружить.

Второй камень — «Якоря»

Если рассылка большого объема на несколько страниц, появляется необходимость навигации внутри рассылки. Как известно, для такой навигации на html-странице используются «якоря».

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Натолкнулся в разделе QA на интересный вопрос. Ответ на него заставил написать эту статью как бОлее полный ответ на вопрос «как организовать поиск по множеству параметров, как в Яндекс-маркете, например».

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

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.

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

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

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

Наши пользователи следят за спецпредложениями авиакомпаний и дешевыми перелетами, каждому интересно своё направление, пунктов вылета и прилета — тысячи, пользователи хотят одновременно следить за несколькоми городами, странами или регионами. Появилась задача — как предоставить удобный механизм подписки? Без долгого тыканья в мульти селект, без кнопок «Добавить пункт вылета». Ответ выглядит так —

Решением стал контрол из Фейсбука и Контакта — пользователи знакомы с ним, а значит не нужно объяснять как он работает. Осталось скрестить его с django.

Стояла задача: найти или создать загрузчик файлов на сервер, использующий возможности HTML5 для мультизагрузки. Загрузчик должен:

• отправлять методом POST любые параметры вместе с файлом;
• отправлять куки;
• предоставлять возможность выбора сразу нескольких файлов (или нескольких тысяч – тут как пользователь захочет);
• отправлять файлы группами;
• файлы собираются в группы до определенного количества мегабайт, или до определенного количества файлов в группе; (это связано с тем, что на сервере есть ограничение на размер POST запроса и на количество файлов в одном пакете)

Именно по причине отсутствия опыта работы с флешем, для создания загрузчика был выбран только JavaScript.

Итак, что из этого получилось

У каждого из нас, полагаю, в любимом браузере постоянно открыты несколько вкладок одновременно. Не раз бывают случаи, что и заголовка вкладки не видно — лишь favicon'ки. Но часто они информации, кроме как отображения логотипа сайта, не дают. И, наверное, зря. Но мы постараемся и здесь использовать это место (целых 16px*16px!) так, как хотим. По крайней мере, будем знать, как это можно сделать.

Часть хабралюдей честные и бескорыстные и привлекают их всякие техническия штучкэ. Но кое-кто кое-где у нас порой и не столь бескорыстен. Честно жить не хочет. Я расскажу вам о том, как можно по сути воровать, но при этом не выходя за рамки уголовного кодекса. Эдак с $15,000,000.

Не так давно была опубликована статья про ICQ на Python, которая меня подтолкнула развить тему, правда в несколько другом направлении. Несколько лет назад у меня были трудности с домашним интернетом: доступ только в локальную сеть, из связи с внешним миром только ICQ и локальный Jabber сервер; никакой другой возможности попасть наружу не было. В результате чего родилась идея туннелировать HTTP трафик в XMPP.

Это не попытка создать список всех существующих инструментов для CSS разработки. Только некоторые, наиболее полезные были отобраны и размещены в соответствующих категориях.


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

В рамках проекта для одного из наших заказчиков в очередной раз встала задача построить систему конвертации/ хранения/ доставки видео в интернет. Типичная такая задача создания своего маленького (или не очень маленького) “Тьюба” только с профессиональным, а не UGC-контентом.

С момента создания первых “Тьюбов” технологии видео в интернете прошли некоторый путь развития, позволяют сейчас делать намного больше, да и требования к современному видео-сайту стали несколько иными.

Наиболее интересными трендами последнего времени, на наш взгляд, являются:

• возможность смотреть один видео-сайт с разных устройств,
• технология адаптивного HTTP стриминга

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

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

Не буду растекаться по древу насчет «до 5-7 тыс. у.е. в месяц в качестве физлица вы никому в упор не интересны».

Допустим без юрлица ну никак нельзя, да еще и на сайт с рекламой денег нет.  Что делать? 

По шагам:
1. Изучаете товары (Я.Маркет, запросы в Директ, ближайший рынок) на предмет «что бы такого не слишком приевшегося и конкурентного, но при этом простого в доставке, и чтобы геморроя с гарантиями/лицензиями поменьше.
Хинт: сувениры, игрушки, коллекционеры всех мастей. Берете одну/несколько специфических ниш для отработки.
Не надо брать строительство, окна, бытовую технику/электронику. Там, где кокурентов дофига.

2. Идем на ближайший рынок, торговый комплекс, а лучше отраслевую выставку(там народ крупнее и плотнее).

Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.

Под катом:

• как упростить код вьюх ровно в 2 раза
• легкий способ рисования графиков
• почему Ian Bicking воскликнул «Cool!»
• приложения для ВКонтакте на django за 5 минут
• хорош ли pymorphy?
• пара фишек насчет выкладки пакетов на pypi
• что общего между декораторами и with-контекст-менеджерами
• принимаем оплату на django-сайтах
• показываем Яндекс.Карту для заданного адреса

Мужик сидит, слушает радио.
— В Москве полночь, в Благовещенске 6 утра, во Владивостоке, Хабаровске, Южно-Сахалинске 7, в Магадане 8, в Петропавловске-Камчатском 9 часов.
Мужик сидит, сидит, потом встаёт, и с некоторым сожалением произносит:
— Эх, ну и бардак же у нас в стране!

Текст перепечатан с аудиозаписи позывных «Маяка».
Для справки: в Петропавловске-Камчатском теперь UTC+11 (летом UTC+12), поэтому теперь в полночь по московскому времени там было бы 8 часов, а не 9.

Во многих местах на сайтах отображается время. И во многих случаях лучше всего отображать не время по Гринвичу, не время на сервере, а время в часовом поясе пользователя.

Часто предлагается выбрать свой часовой пояс из огромного списка возможных вариантов. Конечно, возможность приятная, но удобнее, если сайт может определить часовой пояс пользователя сам. А сделать это, как можно догадаться, совсем несложно — достаточно получить локальное время и отступ от UTC с помощью JavaScript и передать этот отступ на сервер с помощью XMLHttpRequest.

Как потратить совсем немного времени и сделать что-нибудь простое и оригинальное, поражающее своей глобальностью — но абсолютно бесполезное? Очень просто. Давайте сделаем свой принтер.

Нам понадобится (кроме головы и рук) только работающий web-сервер с поддержкой cgi-bin, к которому у нас есть доступ по FTP. Есть такой? Поехали!

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

1. Верстка, аутсорсинг и технические задания

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

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

Этот топик — очередной топик про реализацию динамических поддоменов на сайте, коих много в интернете и даже есть пара топиков на хабре.

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

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

Например, у нас есть готовый сайт, на котором работают профили по такому url: www.example.com/users/username, и есть всякие дополнительные возможности (например www.example.com/users/username/contact и другие страницы, связанные с этим юзером).

И мы теперь хотим вынести все, что связано с юзером, на поддомен, например username.example.com, username.example.com/contact и т.д.)

Решения, которые были найдены в интернете, меня не удовлетворили по 2 причинам:

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

На нашем сайте стоит nginx над апачем (как и на многих других), поэтому пришлось изобретать велосипед самому, используя эту связку (nginx+ apache, благо сейчас почти на всех крупных сайтах стоит проксирующий nginx над апачем)