Всем привет, технически уже понедельник по Мск, так что я, пожалуй, начну. Меня зовут Иван Метелёв, я один из верстальщиков веб-версии ok.ru

До «Одноклассников» работал в одном из лучших питерских диджитал-агенств, а до этого делал с нуля отдел верстки в малоизвестной студии

Желание стартовать ночью вызвано стремлением понять срез местной активной аудитории перед началом недели. Итак, вы:

На самом деле тут уже был @mishcherin с каким-то рассказом о внутренней кухне и процессах ok.ru, так что постараюсь не повторять эту тему

Давайте к делу, что ли. Расскажите, какие самые неожиданные проблемы по производительности вы ловили на проектах? Мы тут только про css, да

@cssunderhood float: left в firefox вызывает relayout до ближайшего родителя с position: relative. А у тебя keypress в contenteditable

@cssunderhood multi-columns :: twitter.com/lazy_frontend/…

Что, никто никогда не клал оверлей с filter: blur поверх играющего видео? Никто не страдал от тормозов :hover в старых ie?

@cssunderhood на одном из проектов полный отказ от анимаций хорошо сказался на производительности и не ухудшил ui. Особенно на моб. адаптиве

Вообще вот вам свежий хороший доклад от @xanf_ua. youtu.be/JIkWFrHL0xo . Там и про причины просадок, и про нюансы отладки

@cssunderhood однажды ловил крэш мобильного Сафари (на iPad mini 1) из-за флексбокса для основного каркаса страницы (без него не крэшилось).

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

Первый раз я увидел реальную проблему/целенаправленную оптимизацию, когда пришел в ok и увидел там асинхронную систему бандлов. Это был 2013

@cssunderhood В Опере (кажется, 9) тормозило динамическое переключение анкеты на форму. Потом они ускорили DOM, мы открыли БЭМ, стало лучше.

Здесь есть люди, которые _в силу необходимости_ применяли critical path, отложенную подгрузку? Есть те, кто от этого всего потом отказались?

@cssunderhood с ховером где-то был хороший совет: указывать имя тега, например a.link:hover, вроде помогало в IE7.

Я на всякий случай отмечу, что оценку объема css я даю после минификации и до gzip, потому что скорее не про сеть, а про парсинг

Зачем столько стилей — отдельный разговор. Отчасти это вызвано спецификой дизайна ok. Отчасти — спецификой a/b, которого у нас всегда много

@cssunderhood да, применял оба, не отказался.

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

@cssunderhood профит отложенной подгрузки оказался ничтожен. Второстепенные стили из подгружаемых файлов вызывали перерисовку всей страницы

@cssunderhood да, мы выигрывали, параллеля загрузку/отрисовку, но проигрывали на отложенном reflow/repaint и суммарно выходили в ноль

В ok загоняются на тему оптимизаций перерисовок страницы. Год-два назад мы делали анимированные полноэкранные заставки на логин-странице,

@cssunderhood мы делали их _нормально_ — без reflow и без repaint. То есть не так, как было у твиттера, например. Кстати, как такое сделать?

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

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

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

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

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

Одна из мерзотнейших вещей, которая может испортить вам производительность — скролл. Я не имею ввиду разговоры про throttle, речь о html+css

Кто-то вспомнит статью «60fps scrolling using pointer-events: none» thecssninja.com/css/pointer-ev… — применяем, но проблема не только в ховерах

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

@cssunderhood ещё resize события негативно влияют на производительность.

Постулирую: при сочетании анимации и скролла неплохо подумать о фризе оной. Подобное на мобилках — из коробки, но полезно не только там

Отчего подумать, а не сразу делать: бывают скачки нагрузки на CPU, если анимация выполняется на композитном слое. Проверял в Chrome + FF

Прервусь на пару часов, чтобы вернуться к вам с примерами последней нашей анимационной боли, а вы пока посмотрите котиков на @catunderhood

@cssunderhood Я как-то пробовал делать прогрессивную асинхронную загрузку всего. Оно работало, но выглядело иногда фрустрирующе.

Сейчас будет продолжение про css-анимации и производительность на примере реальной проблемы, решение которой, сразу говорю, мне не известно

В ok есть понятие «подарка»-изображения, которое может быть разным, в т.ч. анимированым, обязано быть прозрачным. Подарки— прибыльный бизнес

Тестовый стенд, который даст вам представление о происходящем. Осторожно, трафик, cpu load, анимашки, desktop-only welovehtml.ru:9000/sandbox/anim-e…

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

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

Это работает, если изображений немного. Нагрузка на cpu падает, температура, энергопотребление — тоже. Однако «немного» зависит от клиента

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

При этом вне зависимости от кол-ва изображений нагрузка на cpu при скролле растет. Вроде бы простой вывод — останавливать анимацию на скролл

Однако вроде бы это хорошо работает, только если обработка на gpu не используется. Не знаю, с чем это связано, видимо браузерные оптимизации

@cssunderhood попробуй расположить кадры в спрайте вертикально, это должно снизить нагрузку на кеш процессора и ввод/вывод из памяти.

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

Также я проверял гипотезу о том, что при выносе на композитный слой «не хватает видеопамяти». Видимо, она некорректна — iStat не подтвердил

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

Обычно не очень просто найти тестовую базу. Желающим поэкспериментировать с анимашками я подготовил архив на 200mb welovehtml.ru:9000/sandbox/anim-e…

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

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

Отдельно — проблема выяснения причины repaint конкретного элемента. Кажется, хром разучился сообщать об этом нормально, а остальные не умели

У меня была проблема с устранением перерисовки при анимации opacity кейфреймами. Помогла изоляция родителя translateZ + will-change

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

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

В одном из последних FF под виндой на тестовых «слабых» машинах недавно словили странные баги с отрисовкой контейнера с svg-маской. Откатили

Не припомню больше свежих интересных кейсов по производительности css. Отмечу, что средний собеседуемый вообще не очень владеет этой темой

Сегодня готов поотвечать на какие-нибудь ваши вопросы по ok, завтра будем говорить о рефакторинге

@cssunderhood critical path нет, а вот отложенные загрузки картинок, видео и прочих больших штук -да.

@cssunderhood js-файл в компоненты пока, кстати, не входит, — слишком уж отличается активация компонентов на клиенте в разных приложениях

Серверсайд ok реализован на java; код, который рендерит html, написан на java, соответственно частью компонента является java-код

Сегодня поговорим о рефакторинге. Расскажите о вашем самом страшном рефакторинге стилей в жизни. Зачем вы его делали? Стоило ли оно того?

Я прямо начинаю теряться — никто в цссандерхуде не рефакторил css? Никому не близка тема «разрушить до основанья, а затем»?

@cssunderhood было, конечно, но это как-то не воспринимается как некое важное карьерное достижение. Как-то уменьшил 300kb CSS до 160kb.

@cssunderhood это не минификация и гзип были, в полный рефакторинг. Выкинул стотыщ ненужных position:absolute итп, зарулил все на поток.

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

На самом деле последнее время рефакторинг css у меня связывается с процессом компонентизации. Объединение, атомизация — и тут начинается

Хотя самым незабываемым опытом для меня остается рефакторинг раздела музыки в ok — было ~ 6k строк, уменьшилось минимум на треть

@cssunderhood вот вспоминаю, как раньше все было просто:) а сейчас понастроили, всяких сборщиков!

Переезд ok с css на styl тоже оставил воспоминания, хотя и не такие яркие. Говорят об обратной совместимости, но мы наскочили на пару багов

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

@cssunderhood мне обычно задачу «разрушить до основанья, а затем» ставили как «переверстать», т.к. п-ц в CSS следовал за п-цом в разметке

У нас практикуют несколько уровней тестирования, ручное, автоматизированное, но всё равно случаются конфузы — слишком много разных сценариев

Я слышал,модно говорить о тестировании интерфейса, основанном на сравнении скриншотов. У нас такого нет, и я не очень уверен в эффективности

То есть если ваш интерфейс полностью построен на независимых компонентах, наверное вы можете тестировать компоненты. Их сочетание — сложнее

Впрочем, наш Selenium генерирует какие-то превью, и иногда это оказывается полезным. Но полностью я полагаться на автотесты не могу

@cssunderhood переделывал кипу CSS в стиле “фрилансер сверстает нам приложение”. под Angular. первым делом удалял классы из HTML.

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

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

@cssunderhood А кто-нибудь использует для тестов что-то типа Galen? galenframework.com т.е. вместо скриншотов - декларативное описание?

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

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

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

@cssunderhood делаем битбакетом.

У нас стандартный инструмент — stash, который, видимо, эквивалентен битбакету. Ревью предполагает подтверждение минимум от двух ревьюеров

У нас есть «памятка ревьюера», в которой явно запрещается обсуждать вещи «религиозного характера», что для меня неясно (неформализовано)

@cssunderhood Делаем. К сожалению внутренним аналогом Гихаба (каким он мог бы быть в 1990-е).

@cssunderhood phacility.com/phabricator/ все здесь: и код, и ревью и таски. Замечательный инструмент

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

В этом плане набор пожеланий к оформлению "css"/styl на ok далек от совершенства — оговаривается слишком многое. Например, порядок правил

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

Short-list свойств, требующих внимания: overflow, z-index, float, display:flex, position: fixed, font-size: 0, line-height не коэффициентом

@cssunderhood transform,backface-visibility,позиционирование,не кратное 4, цвета,не ложащиеся в стандартную палитру,base64 и что-нибудь еще

@cssunderhood но если фантазировать, то потенциально любой нефиксированный руками способ раскладки может дернуть reflow у потомков

О ревью препроцессорного кода:используем малое подмножество stylus,чтобы не влететь в приключения. Бан на циклы, очень аккуратно с примесями

Допустимая вложенность правил не более двух,чтобы не терять контекст в коде. Бан на составные селекторы вида &-item. С & вообще аккуратно

Мы используем только «сокращенные» модификаторы вида .block.__mod, с ними & можно. При контекстном .context & — можно. Остальное — опасно

Недавно перекрашивал на ok все кнопки из зеленого в оранжевый,чуть недооценил & и влетел на +800 селекторов. А вы удивляетесь,откуда 1mb css

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

Я вот кстати со времен верстки посредственных промосайтов очень люблю абсолюты, но теперь не очень получается ими пользоваться =)

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

@cssunderhood на ревью можно просто напомнить об использовании таких значений. Главное — следить за изменениями этого файла и вовремя банить

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

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

Вы мне сейчас будете говорить про независимые блоки, shadow dom, эмуляцию scoped styles в angular 2, генерируемые префиксы, но жизнь сложна

@cssunderhood если я полезу менять какую-нибудь карду с видео где-нибудь в ленте, я обязательно провлеку к ревью верстальщика всего видео ok

Кроме стандартного ревью до слияния с мастером у нас в ok есть еще спорная практика пост-ревью. Этот процесс живет только в команде верстки

Если в вашей команде проекта кода немало, людей немного, а верстальщиков еще меньше, попробуйте начать с внедрения пост-ревью раз в неделю

Формально пост-ревью — так себе решение. Заставить кого-то что-то переделать несколько дней спустя может быть непросто. Но есть и плюсы

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

Пост-ревьюить можно весь код, не только css. Не сомневаюсь, что у вас были случаи, когда разработчик самостоятельно менял верстку. Это оно

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

Но, допустим, вы как-то изменили код, прошли ревью, выкатились в продакшн. Бывало ли так, что впоследствии вы сожалели о проделанной работе?

@cssunderhood на самом деле до принятия решения был опыт работы с less, и тогда хотелось инструмента, в котором не было бы тесно в будущем

@cssunderhood рефакторил пару раз. Подробностей особо не помню, всё делалось постепенно, с внедрением БЭМа и базовых стилей.

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

Но вообще лично мой опыт: код размножается копипастой. Где-то что-то недорефакторили — обязательно вылезет потом. Лучше режьте сразу всё

У нас на проекте есть как минимум три разные реализации модалок. Раз мы тут про css, то, в частности, три разных стилевых конструкции.

@cssunderhood Недорефакторили в своё время.Это не единичный пример. Нужны значительные усилия, чтобы закончить рефакторинг,а не «прекратить»

@cssunderhood ага, на рефакторинге :-P.

Мои сожаления о проделанной работе связаны, например, с рефакторингом для упрощения поддержки ретины в музразделе ok — всё равно не оценили

@cssunderhood мой личный опыт — не всегда нужный и хороший рефакторинг стоит затраченного на него времени. Теперь стараюсь оценивать точнее

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

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

В таком раскладе выигрываем практически везде, кроме css: легко переключать «темы», данные шаблонизируют один раз, меньше разметки

Правда, есть опасение, что в «строгом» компонентном режиме так уже не прокатит, и рубильники придется усложнять. Но пока что живем!

И вообще. Тут есть еще люди, работающие с a/b на продакшне, или я тут сейчас буду изливать профдеформацию?

Окей, раз никто ничего не отвечает, начну с начала: a/b-тестирование — это хорошо. В нашем случае оно помогает зарабатывать _значимо_ больше

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

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

Знание об a/b может повысить вашу ценность, как специалиста, потому что a/b очень любят ux-дизайнеры, а ux — это модно.

В ok a/b может реализовываться по-разному, но с точки зрения html+css это запросто может быть контекстный класс, который меняет вообще всё

У нас есть простое правило: все ui-изменения должны выкатываться на продакшн обязательно с рубильником в отключке — аудитория теста будет 0

Простой пример a/b — обновленная версия вк. У них там есть ссылка для переключения между версиями, это интересный пример контроля a/b юзером

Мы своим юзерам контроля не даем. Мне кажется, свобода выбора при a/b — неудобно для разработчика. Возможно, я не прав и стоит попробовать

В любом случае, без a/b рискуете получить кинопоиск и не получить денег. Выкатываете фичу — вешайте классы, переключайте шаблоны и будет ok

Так, по a/b мне пообещали помочь источниками, но не сегодня

На самом деле есть еще одна причина кроме a/b, специфичная для ok, по которой мы очень любим css — это хотфиксы

Релиз ok происходит от одного до двух раз в неделю, а проблемы с ui возникают чаще =). Это требует срочной реакции, тут верстальщик полезен

Релизиться чаще _непросто_ по разным причинам, начиная от процессов тестирования до, например, работ в дата-центрах и нагрузки на сервис

Поэтому в админке ok есть поле для применения произвольного css в реалтайме.Точка врезки этого css помечена в коде «на случай ядерной войны»

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

@cssunderhood вот вам ссылка на этот доклад, если кто пропустил youtube.com/watch?v=qseu-Z…

Почему такие «хаки» неудобны: 1) нужно описывать их в правильном формате, чтобы было понятно, кто автор. У нас указывают фамилию/id таска

2) «хаки» — тоже код. Неплохо уметь его версионировать. Наша админка умеет, хотя дифф в ней смотреть не очень удобно

3) «хаки» нужно не забывать переносить в репозиторий или просто удалять. У нас это решается руками и занимает какое-то время + опрос авторов

Вообще у нас подобные поля есть и для js, и, по грязным слухам, для java, но это уже не формат этого твиттера, и за такое у нас больно бьют

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

Тут просили принудительно рисовать ценник на подарке,если тот бесплатен.Привязался к значению поля в json в data-атрибуте. Не делайте так =)

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

Тема борьбы с adblock выходит за рамки этого твиттера, но полезно знать, что разные плагины на разных браузерах режут рекламу по-своему

В рамках саморазвлечения рекомендую посмотреть, как работает adblock в ff. Они используют -moz-binding, мне это показалось занятным

@cssunderhood json в data-атрибуте скорее всего нужен другим модулям. Их потом могут изменить, формат может поменяться, у вас все сломается

@cssunderhood , причем вы даже об этом даже не узнаете. И еще где-то тут должны быть рассуждения о производительности селектора с [*=""]

@cssunderhood smashingmagazine.com/category/uxdes…

Вообще мне очень близка тема модификации отображения стилями без изменения разметки. Еще со времен работы в веб-студии. Когда код написан ->

@cssunderhood -> непонятно кем и непонятно как, и вообще доступа к его изменению нет, дешевле наваять css-патч и выслать его автору по почте

Если я правильно помню, «отцы» развлекались с csszengarden.com . Мне было лениво, я ограничился рестайлом стандартной темы вордпресса

Я не могу доказать свою гипотезу, но полагаю способность рестайла неизменного html тренировкой интеллекта не худшей, чем какие-нибудь судоку

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

Чот как-то фидбэка совсем маловато. Есть две гипотезы: андерхудеры живут по ночам и мой текущий формат неудачен. Попробую завтра вести иначе

@cssunderhood у нас такое в легаси-проекте было. разметку менять нельзя, потому что все шаблоны в строках, в которых чёрт ногу сломит.

@cssunderhood вот это еще круче css1k.net

@iamale_ru @cssunderhood Подробности про вакансии brightcomputing.com/jobs?__hssc=17…

@cssunderhood сейчас предстоит это, я с ужасом думаю. Пытаюсь покрыть тестами регрессии :(

Я обещал другой формат. Сегодня пробую паттерн «аргументированный наброс», а заодно — немного смежную и более «человечную» тему — сотрудники

Обратите внимание, всего 10% женской аудитории. На мой взгляд, это странный результат. Наброс: вёрстка скорее женская профессия, чем мужская

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

Если вы посадите в абстрактном вакууме верстальщика и верстальщицу с одинаковым опытом, скорее всего женский код будет качественнее

Ясно, что критерии качества сложны, но можно выделить простоту, но не примитивность, аккуратность. Возможно, он будет даже документирован

Почему так? Девочки почему-то внимательнее следуют рекомендациям, правилам, не срываются писать велосипеды — ровно, предсказуемо работают

Всё меняется в агрессивных условиях работы. При фоновом стрессе выигрывают эмоционально выносливые люди. Сколько стресса на вашем проекте?

Кроме того, склонность писать велосипеды (даже очень плохие велосипеды) иногда реально «выстреливает», окупая негативные издержки

Кроме того, способность принимать рискованные решения, катить «решето» в прод под свою ответственность — то, чего иногда недостает

Зачем я тут всё это пишу: не с целью кого-то задеть или наоборот. Полезно понимать особенности сотрудников и использовать их сильные стороны

@cssunderhood какого рода стресса?

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

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

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

Если у вас в команде верстки есть девушка — хорошо. Попробуйте перераспределить задачи так, чтобы вам шло больше треша, ей — меньше

Речь не про джентльменов и вот это все. Просто такой подход скорее всего окупится по результату.

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

Если вы собеседуете девушку, которая немного «не дотягивает», возможно, лучше отнестись чуть более лояльно, отдать кусок задач «попроще»

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

@cssunderhood для социальной стабильности внутри команды. То, о чем ты пишешь, можно применить к любому джуну, вне зависимости от полу. :)

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

У меня была кандидатка, которая руками обновляла весь html на проекте, вместо докручивания туда любого шаблонизатора. Никто не заставлял

@cssunderhood это граничный случай. Практически любому джуну-мальчику было бы тупо лениво всё это перебирать руками

@cssunderhood когда команда однополая, в силу законов человеческой природы начинается дедовщина и перераспределение гендерных ролей.

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

@cssunderhood стандартный внутренний мем ok — с утра накатывал [апдейт], буду позже/работаю из дома/поликлиники/маршрутки

@cssunderhood Тут как с готовкой: обычно готовят женщины, но лучшие повара — мужчины. Если нужно хорошенько подумать, вряд ли она справится.

Смотрите, еще один наброс: хороший сотрудник — не обязательно хороший специалист

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

@cssunderhood зато каждый человек оказался порядочным, обладал конструктивными личными качествами. Я не знаю, как так вышло =)

@cssunderhood и обратное тоже верно

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

@cssunderhood если говорить человеческим языком, то я упоминал, что в среднем девушки более внимательно относятся к правилам и рекомендациям

Смотрите мой негативный опыт: в ok хантят суперспециалистов. Суперспециалист — часто суперличность, с суперопытом и суперуверенностью

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

Стандартная проблема специалистов — убеждены, что их личный опыт может перевешивать проектный. Это может быть некорректно в сложном проекте

@cssunderhood какая-нибудь специфика, по которой (примитивный пример) ресурсы клеят в спрайты, а не в base64, или наоборот

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

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

В ok есть стандартный процесс «менторства». Кажется, он применяется не во всех командах, но у верстальщиков он точно есть

Он длится весь испытательный срок (3 месяца) и подразумевает наставничество и контроль. Не все задачи в этот период могут быть продуктовыми

@cssunderhood соединить какие-то хорошие вещи и сложный проект вообще может быть той ещё задачей по сложности.

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

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

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

@cssunderhood оградить его от лишней нагрузки на старте,оберечь от лишнего стресса,«сгорания»,прикрыть его косяки,дать раскрыть способности,

@cssunderhood так и для ментора. Систематизация инструкций, аргументация причин решений, последовательность усложнения задач, вовлечение ->

@cssunderhood в атмосферу коллектива, подбор «подходящих» задач под уровень, контроль подопечного — всё это позитивно сказывается на менторе

Раньше в ok новый сотрудник начинал с работы над «библиотекой компонентов», которая не обладала привязкой к проду, но сохраняла специфику

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

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

С контролем нового сотрудника вообще очень сложно: плохо недоконтролировать и плохо переконтролировать. Тут где-то в области интуиции

Недоконтролируете — сотрудник потеряет время на разработку заведомо бесполезных, некорректных вариантов,переконтролируете — оба потеряете ->

@cssunderhood -> время на избыточные обсуждения. Во втором случае будет трата вашего, более «дорогого» времени, тут аккуратно нужно

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

Тактика наброса хороша тем, что привлекает внимание, но плоха тем, что за развитием темы уже не следят. Хотя фоновые обсуждения — хорошо

Сделаю еще одну попытку. Наброс: хантить сложнее, чем хорошо верстать

Каков возраст вашей легаси-верстки? Во сколько бы оценили стоимость её поддержки? (Любая хорошая верстка рано или поздно становится легаси)

@cssunderhood в первый год работы верстка становится легаси практически ежемесячно)

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

@cssunderhood код запросто может устареть за полгода. В ok можно найти используемый код какого-нибудь 2007 года. Специфика, вы понимаете

@cssunderhood О этого всем будет плохо, если он не один.

@cssunderhood Зависит от того, кто автор :-/ У некоторых она становится легаси в момент коммита.

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

Если вас привлекают к собеседованиям на каком-нибудь этапе процесса найма, ответственность, наверное, не так сильно ощущается

Когда принимаешь решение о найме единолично — тяжело. Когда принимаешь решение об увольнении — еще сложнее. Кажется, это не для всех

У меня небольшая карьера верстальщика — лет 5, я начинал с построения отдела верстки. На аутсорс, как продукта, тогда было не очень много

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

Руководство предполагает, что финальную ответственность всегда несешь лично ты. Ты несешь её в три стороны — заказчику, подчиненному и себе

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

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

Отсюда критично понимать распределение ролей участников коллектива в случае отсутствия руководства.Формирование мягкой иерархии без «базара»

Каждый из участников вашей команды силен в своей области. Отдайте ему эту зону ответственности, делегируйте — результат будет качественным,

@cssunderhood сотрудник будет морально удовлетворен, внутри коллектива будет формироваться взаимное уважение (делегировать — сложно,я писал)

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

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

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

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

Шаг назад к теме найма: какое количество людей оптимально для максимальной эффективности отдела? 7-8 человек. Параллелят 2-3 проекта

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

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

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

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

50% времени сверху — минимальный запас времени. Съедается на стыковке модулей, тестировании, устранении первичных недоработок, форсмажорах

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

Целились в преднизовую нишу рынка — не так, чтобы треш, но чтобы з\п были в районе 30к рублей. 5 лет назад это было терпимо для найма

Цену проекта формировали по статическому прайс-листу, исходя из «примерных» временных трудозатрат. Что-нибудь в духе «одна страница — 300р»

Ясно, что такая оценка смешна, но в среднем з\п на фуллтайме вполне могла пробивать 30к, если человек работал. Речь о _простой верстке_.

Еще рекомендации «коллективного» плана: собираетесь увольняться — говорите об этом заранее и только тем людям, которых зааффектит явно

Если у вас в коллективе есть человек на ваше место — спросите, интересно ли ему заниматься вашими задачами. Представьте его руководству

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

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

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

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

Ну то есть, побыв в шкуре такого работодателя, начинаешь как-то более внимательно относиться к проблемам в т.ч. «старших» коллег

Я упоминал об ответственности перед собой. Важно следить, можешь ли выполнить обещания, данные подчиненным, например, при собеседовании

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

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

@cssunderhood добавь только сюда "на неограниченное время" :) потому что с ограниченным - будет наоборот.

Теперь я готов поотвечать на ваши вопросы о личном опыте _не в ok_

Формат наброса не оправдался. Завтра попробуем обсуждать «всё спорное»—от инструментов до сайд-проектов. Вы кого-то:

Сегодня мы обсуждаем «всё спорное», и я буду пытаться ставить под сомнение какие-то известные/привычные или малоизвестные, но модные, вещи

Сколько здесь людей, которые знают, что такое CSS Modules? Сколько ими пользовалось на проектах? Кто считает, что это хорошо и удобно?

@cssunderhood знаю, но не пользовался. воспользуюсь, когда будет проект на котором не только я делаю вёрстку

@cssunderhood мы пользуемся, очень довольны, считаем, что это хорошо и удобно

@cssunderhood ещё как понял, если используешь css модули про бэм можно забыть раз и навсегда. Так ли это?

Я сразу скажу, что мы не пользуемся, не будем и попробую показать, почему мне кажется вообще этот подход (костыль?) спорным

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

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

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

Самым простым вариантом такого преобразования выглядит добавление уникального префикса, который создает «неймспейс», организующий изоляцию

@cssunderhood мы пользуемся на всех проектах, с того момента, как они появились в css-loader. Считаем, "что это хорошо и удобно" :)

@cssunderhood Я пользуюсь и считаю, что это хорошо и удобно.

@sapegin @cssunderhood и на 95% безопасней, чем обычный css #извините

Декларирую непопулярную мысль, что любое преобразование селектора, особенно «в черном ящике» — потенциальный источник багов

Сравнение примитивно, но неужели никто из вас никогда не сталкивался с проблемами сконкатенированных селекторов в коде?

@cssunderhood знаю, не пользуюсь, думаю что удобно для SPA. Для лендосиков и прочей статики не очь надо имхо.

Никто никогда не пытался понять результат работы нескольких таких последовательно расположенных «черных ящиков» и исправить под задачу?

@cssunderhood пока не пользуюсь. Думаю что на новых проектиках уже попробую.

Я никогда не понимал проблем с неймингом БЭМа. Кого вообще волнует длина селектора? Или кто-то думает, что она серьезно влияет на трафик?

@Sigiller @cssunderhood как раз писал про CSS-модули в этом контексте
habrahabr.ru/post/270103/

БЭМ – это не столько про изоляцию, сколько про вменяемое описание сущностей. Изоляция – просто частное следствие из этого

Вы же не загоняетесь написать «главная неактивная кнопка»? В чем проблема написать main-button __disabled?

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

Брожения по коду в духе «Так, кнопка.Кнопка у друга.Ага, кнопка поделиться у друга в ленте» дольше, чем написать .friend-feed-reshare-button

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

@cssunderhood ЦСС-модули – это хорошо и удобно. Я считаю 👍 @jsunderhood

Некоторое время назад в ok тоже ленились писать селекторы полностью. В итоге – сотни селекторов мертвого забытого кода, недели на вычистку

Я осознаю что, вероятно, с CSS модулями такого не будет, но согласитесь, это же просто очередной костыль до прихода Shadow DOM

Что потом происходит с костылями? Их выпиливают. Долго и с болью, потому что вросло. Или не выпиливают, и остается мертвым грузом

Вы видели костыли для Shadow DOM в Angular 2? они там генерируют уникальные атрибуты и к ним привязывают стили вида [scope1] .classname

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

@cssunderhood да, и это офигенно.

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

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

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

Хотите чужой контент? Забирайте данные через API, шаблонизируйте и стилизуйте у себя. Больше контроля, меньше багов, больше денег

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

Я прервусь на N часов [потому что отпуск], а вы пока попробуйте меня убедить использовать CSS Modules,и расскажите, зачем вам postcss вообще

@cssunderhood Уникальность имён и изоляция стилей не одно и то же. CSS-модули только про первое.

@cssunderhood CSS-модули вообще не про изоляцию ;-)

@cssunderhood PostCSS — фреймворк для изменении CSS. Сам он не нужен, но позволяет просто создавать крутые инструменты

@cssunderhood postcss только начал использовать. Пока что в нем только stylelint и автопрефиксер

@IgorDTP @cssunderhood @meuwka Autoprefixer, cssnext, Stylelint, postcss-inline-svg

CSS Modules у нас нет, и убедительных реплаев с конкретными кейсами к использованию я не увидел,а вот postcss у нас в двух местах используют

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

Я не её автор, так что не знаю, насколько оправдан внутри неё postcss, но наверное да. Ну и автопрефиксер еще, да. Хотя тут был случай

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

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

Жалоба была от пользователя браузера Maxthon, это если кто не знает, такой хромообразный [теперь] зверь

Вообще идея какой-то работы с AST клёвая, и у нас есть люди, которые пытаются работать с postcss для прод-задач, но пока не очень активно

Просто я понимаю проблему производительнсти обработки большого объема кода последовательностью операций над деревом, но в студийном проекте

Поэтому я хотел ваших примеров, но пореплаило мне всего пара человек. Может, еще успешные кейсы?

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

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

В рамках одного из таких проектов я пытался построить из исходного кода все возможные состояния компонента. У меня был css и html на входе

Да, разумеется, я что-то там собрал на основе описания модификаторов в css, матчинга с разметкой, но полученный результат был весьма слаб

Если кто-то будет собирать у себя подобное, я очень рекомендую избегать использования сокращенных модификаторов — создают неопределенность

Что-то в таком ключе, если хотите поплеваться github.com/sourcejs/lego/…

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

@cssunderhood Только обычный стайлгайд: github.com/sapegin/react-…

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

В общем, действительно сложно помнить все вариации, комбинации, контекстные изменения на портале,даже для примитивных элементов вроде кнопок

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

Ну, мы им что-то подобное собрали, конечно — на основе спецификаций компонентов в @SourceJS и набора тестовых данных для шаблонизации

Был написан дополнительно плагин для Sketch на чем-то специфичном,который принимал данные заданного формата,которые я как-то готовил из спек

Идея от которой отталкивались — как-то сделать браузер из скетча. Оставили работу только по отрисовке, калькуляцию лейаута делали на сервере

В целом — загоняли в фантом шаблон, данные, стили, как-то всё сочетали, снимали computed styles и приводили их к оговоренному формату

С точки зрения фантома computed styles псевдоэлементов имели отличия от «нормальных» узлов, соответственно были нюансы по расчету их свойств

Самым простым вариантом мне показалась замена псевдоэлементов на элементы в реалтайме с применением описанных свойств без честного парсинга

С точки зрения скетча мы просто перерасчитывали все слои на абсолютное позиционирование и сравнительно без проблем отрисовывали результат

Где-то попутно возникла потребность в «дообработке» значений стилей — например, перевода процентных величин в абсолютные

Вся эта собранная конструкция в принципе неплохо работала на несложных шаблонах, хотя браузерный рендер, конечно, в деталях отличался

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

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

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

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

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

Без всяких сборок, линтеров и вот этого всего обвеса. Что там верстать-то, в лендингах — несколько десятков блоков с модификаторами

@cssunderhood параллаксы, кастомные прокрутки, модальные окна, формы, кастомные графики и чарты + это всё в адаптив... ну а так вообще да...

Кто просил ссылки про A/B — разбирайте habrahabr.ru/post/242701/ nngroup.com/articles/putti…

@cssunderhood У меня еще и года нет, как занимаюсь версткой, но первые 4 месяца так и было. Проблем не возникало.

@cssunderhood resume-driven development, есть такое

Давайте вот что. Напишите, какие инструменты вы считаете излишними, в каком контексте и почему?

@alpengol @cssunderhood Голый css это так секси! Мне нравится.

Есть набор аргументов в пользу препроцессоров, которые мне всегда казались синтетическими. Генерация сетки циклами и переменными, к примеру

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

@cssunderhood так в чем тогда выигрыш в сравнении с обычной полнотекстовой заменой?

@cssunderhood да, мы все знаем, что называть переменные так глупо, и селекторы — глупо, но иногда такое просачивается, и потом не убрать

@cssunderhood это бывает даже у умных джавистов, true story pic.twitter.com/jj9lxBXguZ

@cssunderhood ну с такими переменными без препроцессоров лучше, согласен

@cssunderhood переменные оказываются очень полезными в таких ситуациях: pic.twitter.com/lfDvR4CSRw

@cssunderhood меняли

@cssunderhood обычно решается через промежуточную переменную: $gray: #333; $bodyTextColor: $gray;

@cssunderhood меняем через darken, lighten или их аналоги

@cssunderhood описал вот как мы их на проекте используем. Мне больше всего нравится @value в них: github.com/neos/neos-ui/w…

@cssunderhood т.е. решение глобального скоупа переменных в Sass: ты точно знаешь, от чего зависит твой компонент, и можешь его изолировать

@cssunderhood мы кстати оставили и БЭМ нэйминг вместе с css modules: github.com/neos/neos-ui/w…

@cssunderhood перед использованием переменной ее нужно эксплицидно импортировать, это можно статически анализировать и проч.

@cssunderhood Добавляет строгости и проч. В реальном проекте, где много народу, очень помогает

@cssunderhood но самый большой профит, когда большую часть реюза стилей переносишь на уровень Реакт компонентов, а не на CSS классы

@cssunderhood риск нечаянно переопределить "чужой" класс в разы выше, чем что CSS modules сломаются. И это кстати будет труднее заметить

@cssunderhood Используем уже довольно давно. После css-modules невозможно вернуться к обычному css, да и к БЭМу тоже.

Сервер-сайд рендеринг, как я понял, упоминался в качестве «спорного» подхода, и тут я в немодном/невыгодном положении — буду его защищать

Сервер-сайд у нас на java, я упоминал. Серверного рендеринга на реакте, изоморфности у нас нет и не будет точно еще какое-то время

html генерируется внутренним фреймворком, суть работы которого я раскрывать не буду, чтобы мне потом не выгнали за разглашение know how

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

Шаблонизаторы я трогал в основном на клиенте, так что громкость заявления можно немного приглушить. Всё равно, если привыкнуть, оч. удобно

Средняя по ok точка зрения такова: затраты на генерацию, доставку и отрисовку с сервера меньше, чем на всё то же на клиенте. Типа, проверяли

Естественно, утверждение про скорость генерации/доставки/отрисовки выглядит спорным, поэтому каждый приходящий js-разработчик говорит «фи»

В общем, если не отклоняться от css-тематики и не обсуждать нашу борьбу с gwt, пока это утверждение никто доказательно не опроверг

Зато я могу точно сказать, что серверсайд отлично решает проблему версионирования компонентов без какой-либо просадки по производительности

А еще серверсайд хорошо решает проблему локализации и хорошей синхронной раскатки изменений на странице. У нас не совсем глупый рендер, да

Естественно, страничка перерендеривается частями, там у неё есть ajax-транспорт, и вот значит оно плюётся обновлениями по запросу или само

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

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

У нас есть разделы, которые живут полностью «на клиенте». Это, например, музыка, это исключение, и это в текущей идеологии будет переписано

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

В ok есть несколько проектов — «веб»версия, «моб»версия, и два платежных модуля — «веб» и «моб», соответсвенно. Всё +- на одних технологиях

И если «основные» версии умеют там как-то обновляться частями, то «платежки» обновляются втупую полностью.Кто-то в iframe, кто-то standalone

@cssunderhood префиксров ещё много, тот же user-select, но это правда, что большинство *популярных* префиксов ушло

@cssunderhood то есть вот реально, сколько работаю в ok — никогда не видел ни у кого таких проблем [на всём нашем мегабайте css-кода]

@cssunderhood у кого как, я тут тоже случайно отломал его, и заметили сразу все.

В контексте истории про автопрефиксер должен сказать, что мы поддерживаем на вебе ie10+. Потому что мы — Можем, да.

@cssunderhood аналогично. Да здравствуй новые технологии!

Вообще мобильная версия ok значительно отличается от «web» в плане клиентских технологий, говорят, в лучшую сторону, но я там не эксперт

Хорошо сегодня поговорили. Убедили меня использовать переменные в препроцессорах вот. Завтра буду собирать всякую мелочь — предлагайте темы

@cssunderhood для верстки не годится вообще, а приложения всякие писать клево ж.

А подскажите плагин для grunt/gulp который бы собирал все стили, используемые на странице в отдельный файл @cssunderhood

@aelyseev Все оказалось проще: gulp-uncss Может я задачу неверно описал. Но, помог мне uncss @cssunderhood

@cssunderhood Знаю, но не использую. Пробовал баловаться, показалось, слишком неочевидно работает, теряешь контроль над оптимизацией

@cssunderhood заодно все возникающие «слайдерные» проблемы, расширение функционала затем происходит в одном месте, выходит качественнее

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

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

Убежден, что «в сложном компоненте мне не разобраться в параметрах» — проблема не компонента/его отображения/поведения, а документации

box-sizing и прочий normalize мне совсем не хочется обсуждать — не вижу значимой специфики. Я просто умею со всем этим работать, и вы тоже

В ok все самостоятельные. Никто не стоит за спиной и не предъявляет, что вот сегодня ты час не код писал, а читал какие-то блоги

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

Но иногда так бывает, что интересы нескольких сотрудников совпадают, и они добиваются выделения времени на обучение чему-то конкретному

Верстальщики добились курсов по основами java, чтобы не быть совсем уж беспомощными в нашем стеке. Были слухи, что лектор потом был поощрен

Есть мероприятия образовательного плана, организуемые строго внутри команды — что-нибудь вроде технологического хакатона, не связанного с ok

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

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

Принудительно тащить лентяев в светлое будущее — неблагодарное дело. Коллеги не могут? Растите с теми, кто может, или сами, иначе увязнете

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

Личное убеждение — оптимального роста для преподавателя и для студента можно добиться, только заперев их один на один на фулл-тайм проекте

Всё остальное смещает баланс либо в пользу одного, либо в пользу другого, и это смещение будет нелинейно зависеть еще от других факторов

Хотите вырасти сами? Попробуйте спроектировать и прочитать курс лекций по верстке на семестр.Только потом не жалуйтесь на падание самооценки

Предполагаю, при системной подготовке лекций вы поймете, что сами много не знаете о своей предметной области, и начнете в себе сомневаться

Затем,если это лекции в вузе, то вне зависимости от уровня вуза вы вероятно будете не в восторге от активности (и прогресса) ваших студентов

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

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

@cssunderhood из обсуждений выходит, что это хороший показатель, хотя неясно, справедливо ли такое сравнение между дисциплинами

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

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

Зато с осени буду читать про веб-дизайн! Вот сижу, читаю книжки, пытаюсь нарисовать программу. Связать свой опыт с теорией, преподнести

@cssunderhood от группы зависит, обычно из человек 20 - от 1 до 3-4 человек. Так что так примерно и выходит. Правда, дисциплина не IT

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

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

Мы дипломы пытаемся про js писать.Пару лет назад demiurg.es/,в этом году техконсультировал по моделированию анонимного p2p на js

@cssunderhood это шикарно. Моим дипломным руководителем был Java архитектор и он мне кучу полезной инфы дал, за что я ему очень благодарен

@muhas Мы тут про других лентяев. Про тех, кто не хочет вырасти из первой стадии — medium.com/humans-create-… @cssunderhood

Вот тут много людей учило верстке. Расскажите, с чего вы начинали курс обучения? Как мотивировали студента? Остался ли студент в отрасли?

По возможности, избегайте такого при обучении студентов (и на ревью тоже) pic.twitter.com/TgbZNT2Z4w

Какие-то финальные мысли и ответы на отложенные вопросы обещаю сформулировать в воскресенье

А кто поможет с картами кода для css разобраться? gulp-sourcemaps+concat+cssmin дают карту кода, которая ... @cssunderhood

... проходит валидацию, но в браузере неверно подсвечивает файлы @cssunderhood

@jsunderhood @dimaip @cssunderhood github.com/garris/Backsto… вполне достойно для тестирования регрессий. Если достаточно phantomjs.

Классно всё-таки сделать перерыв в использовании социальных сетей на выходные. В их разработке, кстати, тоже иногда классно делать перерыв

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

За неделю я постарался раздельно обсудить некоторые вопросы производительности css, рефакторинга и ревью, кадровые и наставнические

Завершить хочу рассуждением о смысле всех этих процессов — иначе к чему тогда иметь столько технических решений, споров и реализаций

Знаете, мы отлично живем. Нет никакой общей объективной метрики, какой дизайн хорош, а какой плох. Наша метрика выражается в нашем доходе

Наша метрика построена на годах экспериментов и общения с пользователями, их отзывах, благодарностях и негодованиях. Длинная история

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

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

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

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

У меня есть один из любимых отрывков в кино — «Предел риска». ok.ru/video/63868334… . Он примерно про это

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

Господа, «верстка со смыслом» — это вообще не про то, как вы там закрываете теги,и используете ли вы <li> вместо <div>. Это всем безразлично

В своё время я задумался, что я буду говорить детям о своей профессии, если буду дальше верстать лендинги со сроком годности в полгода

Так что — верстайте со смыслом и ничего не бойтесь. Даже если ничего не знаете. Даже — вести андерхуды =)

На этой неделе с вами был @from_anywhere, верстальщик, «Одноклассники».