Что не так с тестированием вёрстки

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

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

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

Вы 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 на сайте.

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

Triangle

Примесь triangle (которую дизайнеры Sagi предпочитают называть «chupchick»), добавляет к всплывающей подсказке треугольник. И tooltips становится похожим на диалоговое окно. Но triangle также может использоваться в качестве автономного элемента.

/* 
* @include triangle within a pseudo element and add positioning properties (ie. top, left)
* $direction: up, down, left, right
*/
@mixin triangle($direction, $size: 6px, $color: #222){
  content: '';
  display: block;
  position: absolute;
  height: 0; width: 0;
  @if ($direction == 'up'){
    border-bottom: $size solid $color;
    border-left: 1/2*$size solid transparent;
    border-right: 1/2*$size solid transparent;
  }
  @else if ($direction == 'down'){
    border-top: $size solid $color;
    border-left: 1/2*$size solid transparent;
    border-right: 1/2*$size solid transparent;
  }
  @else if ($direction == 'left'){
    border-top: 1/2*$size solid transparent;
    border-bottom: 1/2*$size solid transparent;
    border-right: $size solid $color;
  }
  @else if ($direction == 'right'){
    border-top: 1/2*$size solid transparent;
    border-bottom: 1/2*$size solid transparent;
    border-left: $size solid $color;
  }
}

CSS Refresher

Это большая коллекция практических советов и заметок по вёрстке. Своеобразная памятка для тех, кто каждодневно использует CSS. Освещаются самые разные темы, от деталей поведения плавающих элементов до использования SVG и спрайтов. Проект постоянно обновляется, активное сообщество github также принимает в нем участие, там добавляются интересные замечания, о которых, возможно, вы и не слышали.

От переводчика

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

Было время, достаточно недавно, когда PHP и его сообщество ненавидели. Главная шутка была про то, насколько ужасен PHP.

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

Но позже, на удивление, вещи начали меняться — и достаточно быстро. Как будто пока ведьма помешивала горшочек, из ниоткуда начали появляться новаторские проекты. Наверно, самый заметный проект был Composer: наиболее полный менеджер зависимостей для PHP (как Bundler для Ruby или NPM для Node.js). В прошлом PHP разработчики были вынуждены совладать с PEAR (что было страшным сном, на самом деле), сейчас, благодаря Composer, они могут просто обновить JSON файл, и немедленно подтянуть все нужные зависимости. Здесь — профайлер, там — фреймворк для тестирования. Это занимает секунды.

От переводчика: так сложилось, что в русскоязычном интернете мало информации о TDD и в основном описываются механические действия разработчика. Главному же – идее – уделяется совсем мало внимания. Эта статья является попыткой восполнить этот пробел. Важно отметить, что она не для тех, у кого нет времени на тесты, и тем более не для тех, кто не осознает важность слабосвязанной архитектуры. Статья (оригинал) адресована тем, кто делает или собирается сделать первые шаги в TDD.

Один из самых частых ответов на вопрос «Почему я не пишу юнит-тесты» — это вопрос «А кто напишет тесты для моих тестов? Где гарантия, что в моих тестах тоже не будет ошибки?», что свидетельствует о серьёзном недопонимании сути юнит-тестов.

Цель этой заметки — коротко и чётко зафиксировать этот момент, чтобы больше не возникало разногласий.

Итак, юнит-тест — это

Я глубоко верю в методику TDD (разработка через тестирование), так как видел на практике пользу от неё. Она выводит разработку ПО на новый уровень качества и зрелости, хотя она до сих пор не стала повсеместно распространённой. Когда наступает момент выбора между функциональностью, временем и качеством, всегда страдает именно качество. Мы обычно не хотим потратить больше времени на тестирование и не хотим идти на уступки в количестве выпускаемой функциональности. Если вы не планировали использовать методику TDD с самого начала проекта, то потом очень трудно перейти на неё.

Все мы слышали

В самом начале этой недели, в понедельник, состоялся официальный релиз Laravel 5.2.
В новой версии были улучшены такие вещи, как авторизация, «связывание» модели с route и другие.
Более подробно под катом.

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

Что умеет делать сборщик:

• Собирать front-end проект для development & production окружений.
• Собирать по несколько js/css бандлов на проект.
• Использовать стиль CommonJS модулей в браузере.
• Использовать ES6-синтаксис.
• Спрайты, картинки и многое другое.

Предлагаю вашему вниманию перевод второй части цикла статей «Becoming PHP professional».
Первая часть. «Недостающее звено»

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

Предлагаю вашему вниманию перевод статьи «Becoming PHP professional. Missing link».

Введение

Когда я читаю различные блоги, связанные с PHP, вопросы на Quora (англоязычный сервис вопрос-ответ, прим. переводчика), сообщества в Google+, газеты и журналы, я часто замечаю крайнюю поляризацию навыков программирования. Вопросы бывают или уровня «А как же мне подключиться к базе данных MySQL», или что-то из области «Как мне лучше распределить ресурсы моей почтовой системы для того, чтобы отправлять более одного миллиона писем в час без использования нового сервера?»

Лично я выделяю 4 четких уровня «славы» в PHP (применимо так же и для любого другого языка или профессии): новичок, среднячок, профессионал и элита.

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

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

UPD (13 марта 2015): Заменил несколько плагинов на более актуальные + решил проблему с импортом CSS файлов внутрь SCSS

Всем привет! Меня зовут Андрей, я работаю в отделе разработки продуктов Veeam Software.

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



Сегодня я хочу рассказать свою историю.

Итак, начну с момента, когда мне исполнился 21 год, я уволился из рядов доблестной российской армии и оказался на серых и холодных улицах Санкт-Петербурга. Осень, отсутствие жилья и денег активировали все клетки головного мозга для ответа на вопрос: «Что делать?».

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

Молодой программист, едва закончивший или ещё даже не закончивший ВУЗ, готов свернуть горы, учиться, учиться и ещё раз учиться и ему близлежащее будущее кажется таким:



Но более опытные товарищи знают, что на самом деле на его пути давно уже заботливо разложены грабли и путь от Junior'а к Senior'у выглядит как-то так:



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

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Предлагаю читателям «Хабрахабра» перевод статьи «Zombie Code When Maintainability Goes Out Window».

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

Да, скажешь ты? Почему?

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

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

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.