(削除) Предупреждение (削除ここまで) (追記) пособие (追記ここまで) для тех, кому надо верстать.
Используется в TeamDev и на публике.
Вёрстка — ответственный этап работы. Макеты дизайна сами по себе не работают и представляют собой лишь концептуальную ценность и исходный набор ресурсов.
Какое бы бронзовое изваяние не соорудили дизайнеры, результат будет таким, каким его сверстают и запрограммируют.
Верстальщик часто первым превращает макеты в систему. Для этого требуется инженерное мышление, в то время как зачастую у графических дизайнеров интеллект уровня лягушки.
Хороший верстальщик знает и умеет всё для того, чтобы сделать вёрстку качественной и красивой — для этого нужно хорошо разбираться в технической части и немного понимать базовые принципы дизайна, композиции и типографики, соблюдать размерности и сетки.
Для этого не нужен дизайнер. Вёрстка и есть дизайн. И немного программирования.
Конечный результат лучше, когда всё наоборот: если в макете есть недочёты, верстальщик сообщает дизайнеру или сразу верстает правильно. Это свидетельствует о внимательности к своему занятию.
Верстальщику нужно заботиться о качестве своей работы.
И не переставать учиться.
Уже умеет верстать крепкие простые страницы и сделал сайт себе или друзьям. Узнаёт о клёвых технологиях и применяет их самостоятельно. Помимо Эрика Мейера, читал книги Нильсена и Круга. Ставит себе цель делать не хуже, чем у них написано, и освоить для этого дизайн и программирование. Может рассказать почему начал заниматься вёрсткой. Учится, а не говорит, что хочет учиться. Гуглит всё, не задавая примитивных вопросов. Изобретателен в целях собственного выживания. Переделывает за собой сам. Не пропускает мимо ушей ни слова от коллег и помогает им. Понимает, что можно верстать лучше и задаётся вопросами о навыках, методах и принципах проектирования.
Формирует видение профессии, перенимая опыт у старших коллег и профессионалов в области.
Растворившись в сознательном усилии к самообучению, достигает middle-уровня.
Верстает всё, набирая и совершенствуя опыт и знания по всем фронтам одновременно. С помощью программистов на проекте оттачивает следование принципам проектирования в вёрстке. Помимо Брингхерста, читал Купера и Раскина, после чего едва не ушел в дизайнеры выяснять отношения с программистами. Не повторяет собственных ошибок. Учится делегировать задачи ученикам и проверять их. Тренируется не тупить. Умеет оформлять текст и собирать интерфейсы по спецификациям без дизайнера. Договаривается с коллегами, ставит сроки и укладывается в них, а также берёт обязательства самостоятельно вести небольшие проекты с лёгким программированием.
Формирует отношение к работе, через призму качества и профессиональных стремлений.
Может оставаться таким сколько душе угодно, но не имеет права останавливаться.
Продолжает верстать, вопреки соблазнам уйти полностью на программирование фронтенда или в руководящие должности. Подаёт пример, даже когда формально не учит. Наблюдает за прогрессом учеников, подсказывает нюансы. Жестко следит за архитектурой на проекте. Может распределять задачи по фронтенду. Не является чьей-то мамой (даже если фактически является). Работает быстро, но без спешки. Много или мало — не нашего ума дело. Оценивает бесспристрастно, но имеет право витиевато ругаться, если где-то не прекращается унизительная лажа. Заслужил твёрдый авторитет у программистов и знает тайное рукопожатие принципиальных дизайнеров.
Отношение к качеству работы у вебмастера приравнивается к отношению к самому себе.
Ниже собраны наиболее часто затрагиваемые в нашей работе темы, которыми нужно овладеть для уверенной вёрстки. Темы сложные. Верстальщики, считающие себя опытными, лажают в них похлеще новичков.
Заметьте!
Это не перечень тем, о которых достаточно прочитать и сказать «всё, я знаю кунг-фу». По всем пунктам есть ссылки, книги и рекомендации по их практическому закреплению на работе или самостоятельно.
Без практики — никак.
Ученик изучает всё по списку, миддл-верстальщик знает и практикует всё, сеньор всё проверяет и всему учит.
Для красоты есть бумажный чеклист.
Перечень тем субъективен и отражает лишь бо́льшую часть рабочих задач в TeamDev.
Вопросы можно выносить на обсуждение в группу webmasters@teamdev.com
— Oh, come on, guys,
it's not rocket science!
Осторожно! Далее текст изобилует анимированными изображениями, которые могут показаться неуместными. Why? For the Glory of Satan of course!
Если вы читаете этот опус, то вы, наверное, не настоящий сварщик.
Возможно, вы уже научились открывать и закрывать теги, но до осознанного их применения в соответствии со стилями и спецификациями дорастает не каждый верстальщик.
Умение интуитивно ощущать собственные ошибки очень важно. Это чувство означает, что вы быстро замыкаете цикл обратной связи и учитесь на ошибках.
Не решайте костылями проблемы в вёрстке, а понимайте, что верстаете и как это делать правильно.
Это лучшая практика. Стоит верстать и программировать самостоятельно, хоть в начале пути, хоть уже устроившись на n-нную работу. Так обкатываются изучаемые подходы, если в рабочих проектах их невозможно применить. Так — запрещёнными приемами и интересными решениями — компенсируется рутина.
Здесь фиксируются знания всех остальных тем. Рабочие задачи редко соответствуют уровню знаний. Они либо сильно проще и унылее, либо требуют обширного понимания темы, например, когда надо сверстать что-то простое в большом, запутанном проекте.
Возьмите идею, которая касается лично вас и интересна именно вам. Не делайте рандомный сайт «Калькулятор внутреннего и внешнего радиуса луковых колечек с одной луковицы в зависимости от их количества». Помните о собственном интересе — это единственный рабочий инструмент. Свой проект может быть глупым, но он обязан быть осмысленным и интересным вам. Иначе ничего не выйдет.
Отрядом книг уставил полку,
Читал, читал, а всё без толку... Александр Пушкин
Знания — не сила. Умение ими пользоваться — возможно. Бороться с возрастающей (削除) энтропией (削除ここまで) (追記) сложностью (追記ここまで) разрабатываемых систем (помним, что вёрстка это тоже система) можно структурируя знания и код, используя методологии и определяя принципы проектирования.
Усвоив хотя бы несколько, можно заочно стать программистом.
Основа всего ООП. Компоненты, которые могут измениться, должны быть отделены от системы, которая останется неизменной.
Применимо к вёрстке:Попытки изоляции стилей в CSS без веб-компонентов это неисчерпаемый источник приключений.
Организация программы из небольших независимых блоков, структура и поведение которых подчиняются определённым правилам.
Применимо к вёрстке:Безболезненное использование компонента вёрстки где угодно (привет, архитектура).
Классы должны быть достаточно абстрактны и независимы, чтобы можно было быстро создать новые без необходимости что-то переписывать или бороться с уже решёнными проблемами.
Применимо к вёрстке:(Привет, сниппеты).
Однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса.
Применимо к вёрстке:Не изменять изначально написанные компоненты, а расширять их модификаторами (привет, bem).
Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы.
Применимо к вёрстке:Компонент один, раз и навсегда; модификаторы не повторяются (привет, осознанность).
Yes, please.
Можно будет наконец-то читать любые книги и документацию, задавать вопросы на «Стэковэрфлоу», общаться с иностранными коллегами и заказчиками, понимать англоязычные мемчики и заставлять других голосовать за вас рублём.
Понадобятся мотивация и практика. Достаточно уметь связывать два слова и можно отправляться на письменные и устные коммуникации — только там можно научиться связывать больше трёх слов. Тренировать технологические навыки можно в личных проектах-песочницах, а общение только с живыми людьми.
Из баловства вполне помогают упражнения со словарём LinguaLeo, книги и кино.
Это не строчка в резюме, а осваивание новых и переосмысление старых подходов с доказательством их применения в работе или собственных проектах. Долгая работа в веб-студии или энтерпрайзе выжигает любознательность напрочь.
Научитесь не просто штудировать всё, а искать закономерности и общие паттерны в разных областях знаний. Так будет легче и веселее учить новое.
Все профессионалы тренируются и учатся. За учёбу никто не платит. Вы занимаетесь ею, чтобы вам платили за основную работу — и платили хорошо.
Надо смотреть внутрь всего, что выглядит и работает хорошо. Надо уметь замечать то, что хорошо свёрстано. Способность читать и понимать код, который писали не вы, очень важна, если вы работаете в команде или участвуете в открытых проектах.
Это не нелепая шутка, а суровая реальность. Опять же, всё выучить невозможно, поэтому умейте хорошо гуглить и правильно формулировать вопросы коллегам, а не гадайте на кофейной гуще.
Задавать вопросы — не стыдно. Стыдно просидеть весь день и не написать ни строчки, потому что чего-то не понял.
Для тренировки можно перестать задавать вопросы, не найдя на них ответ самостоятельно.
А ещё Гугл следит, насколько крутые и специфические запросы вводит пользователь, и начинает обрабатывать его как потенциального кандидата.
$ git know --basics 🔗
Всегда используйте версионирование. Хоть в команде, хоть в одиночку. Практика частых коммитов, возможности смотреть историю изменений и прочая красота сильно помогает. Каждый рабочий проект начинайте с репозитория. Учебные или личные проекты храните в личном «Битбакете» — там бесплатные приватные репозитории. Что-то особо клёвое можно вынести в публичный «Гитхаб».
Множество мелких решений, миксинов и стилей для базовых элементов кочует из проекта в проект и с каждым разом шлифуется. Особенно хорошо, когда они открыты на гитхабе. Не стоит переживать, что там могут оказаться банальные вещи — всем плевать. Вам должно быть не плевать.
Изобретать велосипед плохо для дела, но хорошо для обучения.
В дополнение к гитхабу со сниппетами и собственным проектом хорошо иметь запас примеров своих достижений. Это отдельные шаблоны или элементы, где вы ловко и изящно выкрутились.
Если вы ещё учитесь, интересное можно делать и в лабораторных работах — просто делайте их не по методичке, накручивайте там сок и выдавайте к скучным заданиям весёлый результат. Заодно получите хорошую репутацию у преподавателей, автомат на экзамене и даже внимание противоположного пола.
Не забывайте, что демка и скриншот — признак воспитанного человека.
Сначала архитектура. 80% времени надо думать, что где лежит, как работает и с чем взаимодействует. 10% записывать это. 10% переписывать это наново.
OOCSS всегда можно брать за основу, там низкий порог вхождения. Принципы BEM могут помочь избежать беспорядка, когда проект будет бесконтрольно разрастаться. «Атомный дизайн» тоже необходимо понять и вынести из него полезные для себя подходы.
Тема сложная. Но и вёрстка это не тупо. Здесь есть чему поучиться у программистов.
Частая ошибка тимлидов и руководства — ставить джунов в начало вёрстки большого проекта. «Надо по-быстрому заверстать»
, ага. Либо не соглашайтесь на это, либо из штанов выпрыгивайте, делая всё по правилам и требуя регулярных код-ревью. В лучшем случае после плохо организованной структуры вёрстки джуниора вскоре уволят. В худшем — будут за глаза ругать при каждом баге, ради которого нужно рефакторить всю вёрстку в радиусе километра.
Структура сайта и смысл каждого объекта должен быть понятен прямо из исходного кода. Иерархия и названия подключаемых шаблонов, переменные и имена классов попадают под это же правило.
Одна из наиболее важных частей, о которой следует помнить при написании семантического и доступного кода — это сделать всё возможное, чтобы использовать стандартный язык разметки, что возвращает нас к пункту HTML/CSS.
Странный пункт — требовать знание документации. Её достаточно единожды внимательно прочитать и забыть, чтобы спустя годы, во время какого-то затыка, вспомнить:
— Тю! Так это даже в документации есть!
Спецификации и черновики читать по желанию.
Увеличивают скорость работы, помогают в архитектуре, улучшают привычный способ организации стилей. Поначалу можно закопаться, зато потом будет приятно и незаменимо.
Надо не просто знать о существовании препроцессоров, но и уметь на практике всё от переменных и вложенности до циклов и переборов.
Забегая наперёд: всё настраиваем на автоматическую сборку. Так чтоб сразу красиво было.
«Бутстрап» не везде канает, но знать его надо. Новичкам и тем, кому туго, надо заглянуть как он сделан внутри и разобраться с принципами — это поможет правильнее применять существующие сетки, компоненты, а не клепать велосипеды; даст примеры для подражания и иллюстрации некоторых, пускай и не всегда правильных, архитектурных подходов. Неуместное использование элементов фреймворка обрекает вас на бесконечные и презрительные код-ревью.
Прежде чем изучать «Бутстрап», убедитесь в том, что вы изучили CSS, отзывчивую вёрстку, препроцессоры и методологии. Все эти вещи куда полезнее.
Как множатся стандарты
Верстальщику стоит знать дизайн интерфейсов. Самих дизайнеров мало и их можно было бы задействовать исключительно на проектировании.
Главное в дизайне — композиция и незаметная простота интерфейса. Это всё легко достигается правильным использованием шаблонов проектирования, а это значит, что нужно уметь сразу «верстать красиво».
Мы ещё вернёмся к дизайну, а пока послушаем парнишу, которого никто не любит:
Первые месяцы существования ВКонтакте я создавал весь код, графику, формулировки, интерфейсы, маркетинг. Совмещение позволило устранить расход времени на коммуникацию. Павел Дуров
Сделав код понятным для программистов, недалеко и до того, чтобы подготовить его для людей и для машин, помогающих пользователям. В первую очередь это читалки экрана для людей, которым повезло не так сильно как нам. Во вторую, микроформаты и оптимизация для поисковиков. В третью, для мобильных устройств.
Работы здесь достаточно и это даст вам левел-ап, ощущение законченности кода и гордость за результат.
📖Joshue O Connor «Pro HTML5 Accessibility»
Можно попытаться опробовать всё самим: оценить видимость и размеры кнопок и ссылок, увеличить масштаб до 150%, всё проклацать табом, тестировать заполнение форм только клавиатурой, во всё пробовать попасть маленьким ноутбучным тачпадом, держа в руке капающий вареньем бутерброд, а другой рукой управляя трактором. Вслепую.
И можно скормить вёрстку валидаторам.
Если вкратце, то надо проштудировать все Web Fundamentals и уметь отвечать на вопрос What Makes a Good Mobile Site?
@media, макро- и микробрейкпоинты;Освоить базовые принципы оформления текста необходимо всем, у кого есть клавиатура. Это занимает пару минут. Прямо сейчас:
© Максим Ильяхов
Компьютер не может причинить вред данным пользователя или своим бездействием допустить, чтобы данным был причинен вред. Первый закон проектирования интерфейсов
C заполняемыми пользователем формами нужно быть осторожными, внимательными и заботливыми.
HTML Forms Guide — там сколько всего интересного: табиндексы, автофокусы, подсказки, ограничения, html5 атрибуты полей для системной поддержки.
📖Дженнифер Тидвелл «Разработка пользовательских интерфейсов» — там и про формы, там про всё
Всего лишь знание нескольких нюансов, хорошее отношение к электронной почте и несколько практических приёмов дают вам дополнительный ценный навык.
— Теперь оно моргает при рефреше!
Со шрифтами до сих пор как-то всё коряво и все на это забивают.
Надо уметь правильно определять графику для экспорта, ловко её сохранять в любых размерах и оптимизировать PNG, SVG, JPG, понимая когда что нужно. Уметь переносить стили слоев в css руками или автоматом. Из самостоятельной работы нужны владения текстовыми и векторными инструментами.
Уметь встраивать, генерировать, анимировать, управлять содержимым и редактировать без привлечения специально обученных дизайнеров. Как в графическом редакторе, так и в текстовом.
Обязательно уметь собирать всё в спрайты.
Лучше использовать SVG, но на многих проектах шрифтовые иконки прижились в виду примитивной простоты использования.
Есть нюансы правильной конвертации: полученный шрифт должен хорошо выравниваться, содержать лигатуры и легко встраиваться несколькими способами в любой объект на странице. Иначе это плохой шрифт.
IDE, «Саблайм», «Атом», «Брэкетс», с emmet или без, да хоть вообще vim — не принципиально. Главное, чтобы вы там удобно и быстро писали всё, что приходит в голову, а не вспоминали полчаса нужную комбинацию клавиш.
Помимо настройки редактора и его плагинов, нужно хоть в какой-то мере освоить слепую печать и насобачиться в хоткеях.
В дополнение к инструментарию. Ровный код хорошо читается и вызывает ощущение надёжности, даже если он не работает.
Хорошо написанный код экономит время другим разработчикам. Следуйте чьему-то подходу или соблюдайте принятый в команде. Главное в этом деле — постоянство.
Режим отладки это теперь ваш ближайший друг и помощник.
Верстать надо так, чтобы PerfectPixel был не нужен.
Поначалу необходимы внутренние чеклисты и инструменты для валидации кода, которые дадут уйму подсказок и даже косвенно научат верстать лучше.
Соблюдайте размеры из макетов, если там они систематизированы, или сами следите, чтобы у вас в вёрстке всё было ровно. Можно воспользоваться чем-то вроде 8pt grid (и дизайнерам про это расскажите).
Сейчас, когда неуклюжих браузеров перестало быть свыше 9000, а на Хабре статьи о кроссбраузерности не появлялись с 2011 года, сам термин «кроссбраузерно» наконец-то может означать «одинаково во всех браузерах». По возможности этого и надо добиваться.
Отображение в браузерах основной аудиторией надо проверять только на живых, установленных локально, браузерах. При необходимости — на виртуалках. Проверку телефонных и планшетных версий можно репетировать в эмуляторах, а потом обязательно повторить на устройствах. Для всего остального есть Browserstack.
Всё нужное по теме можно найти в документации «Мурзиллы»: Cross browser testing.
Было бы в высшей степени непрофессионально передавать на проверку QA заведомо дефектный код. А какой код является заведомо дефектным? Любой, в качестве которого вы не уверены! Роберт Мартин, «Идеальный программист»
В jQuery используется знак $. Вам это о чём-нибудь говорит?
Сама по себе jQuery — замечательная библиотека с развитой экосистемой плагинов. Многие считают её этаким стандартом для разработки сайтов. Но это библиотека, а не язык программирования.
В первую очередь изучить основы языка (или основы программирования, если об этом надо ещё раз повторять). Без понимания фундаментальных механизмов JavaScript не получится эффективно решать возникающие проблемы.
Если нужна только работа с DOM, то можно использовать что-нибудь более простое и может даже изящное.
<!-- TODO: добавить ещё ссылок про джейквэри -->
Компиляция, валидация, оптимизация и запуск должны быть переложены на сборщик. Gulp — уже хорошо. Можно разобраться с grunt.
Незаменимое дополнение к пункту про препроцессоры и структурирование. Сборка собственных и рабочих проектов должна войти в естественный и привычный подход к организации вёрстки.
Просто научитесь настраивать хотя бы старые добрые WordPress и Bolt. Знайте htaccess и wamp/xamp. Попробуйте хипстерские jekyll, ghost. Шелестеть файлами по ftp тоже всё ещё надо. И ssh ещё живой.
Отдельной строкой npm и его друзья из секции выше.
Можно, например, упростить себе задачу с личным проектом и, установив какой-нибудь «Вордпресс», превратить его в нечто совершенно иное.
Умение программировать даёт совершенно другое понимание происходящего, независимо от языка. Можно посмотреть наследования после освоения препроцессоров и поразмыслить о том, как же всё замечательно устроено.
Кажется, что нужно срочно учить JS (фронтенд как-никак), но можно начать и с более оформленного языка вроде Питона или Си — просто чтобы просто понять что да как.
Принципы проектирования мы уже знаем. Так ведь?
Наша базовая техническая прогулка подходит к концу. Далее вас ждут приключения.
Веб-компоненты, X-Tag, Polymer, Custom Elements и прочий Shadow DOM в том или ином виде пытаются появиться на свет уже третий раз. Это новый вариант создания модулей, который позволяет получить (почти) гарантированную инкапсуляцию кода, верстки, стилей и действительно удобный и стандартизированный интерфейс к ним.
Приживётся ли — пока не ясно. Понимание этих штук полезно как «взгляд в будущее» на то, какой станет вёрстка.
Умейте писать кратко и по делу.
Письма коллегам, детали задач, описание коммитов, документация, комментарии в коде, сам код, ленивая переписка в чатике, записки на холодильник — везде надо писать хорошо.
Это может показаться неочевидным, но письменный формат помогает вытащить на поверхность идеи и мысли, структурировать и проверить их.
С окружающими нас дизайнерами и программистами есть о чём поговорить по делу.
Надо уметь излагать свои соображения, воспринимать и правильно формулировать критику, внимательно выслушивать даже самые требовательные замечания по делу и старательно отфильтровывать околесицу, которую вам могут привнести в дискуссию под видом собственного несгибаемого мнения.
Критика — основной инструмент в работе и обучении, в отличие от похвалы и лизоблюдства. Её никто не любит, но институт этикета не стоит на месте и наши заморские коллеги собрали некоторые свои соображения в книги:
Надо знать насколько важен дизайн и иметь хороший вкус. Узнайте о работе дизайнера, избавьтесь от ложных стереотипов в духе «да каждый может прямоугольники рисовать»
, «они же ничего не делают в своих фотошопах»
и тому подобных.
Делать ≠ сделать. Работу надо доводить до конца, а не поковырять немного и отдать тимлиду, чтобы тот закончил. Тимлида вообще не существует — он делает обезличенный код ревью и сыплет критикой по делу (и нет). Надо так, чтобы вас уважали, а не хвалили.
Рефакторинг, технический долг, признание собственных ошибок должно быть не в тяготу. Не клёво коммитить лажу, не проверяя или на «авось никто не увидит».
Разбивайте огромную вёрстку на маленькие этапы, на каждый создавайте задачи, следите за скоростью и ведите наблюдения за количеством подходов к снаряду, необходимых для достижения результата. Эстимейтить можно по-настоящему научиться только на жестоком фрилансе, где надо управлять бюджетом проекта самостоятельно.
Ищите помехи в своей работе и устраняйте их трюками и новыми привычками.
Отдыхайте. Лучшие идеи приходят не во время многочасового тупления в монитор с бочкой кофе, а во время паузы. Это не про вёрстку, это вообще.
Люди часто думают, что тайм-менеджмент им нужен, чтобы управлять делами. Тайм-менеджмент нужен для того, чтобы вы расчистили время для себя. Потому что вы важны.
Не нужен. Либо вы хотите стать специалистом и работаете над этим, либо нет. Люди это машины выживания и они прекрасно обходились тысячи лет без менторов и менеджеров веб-студий. Любознательность — вот что нужно. Ничто не должно мотивировать искусственно. Слушайте тимлида и работайте на результат.
Нужно получать «зачёты» от тимлида или техлида по всем темам по мере их прохождения. Проверка технических знаний и навыков их применения другими людьми не засчитывается.
📋Напечатать табель
