CSSO — инструмент для минификации CSS, который недавно вернулся к активной разработке. Зачем?
Дело в том, что минификация CSS — задача сложная. Сейчас нет идеального минификатора: чтобы и эффективным был, и делал все правильно. Ведь нужно учитывать не только особенности CSS, который постоянно меняется, но и уровень его поддержки браузерами, их баги, префиксы, хаки и т.д. Все это требует решения ряда непростых задач. Поговорим об этом, а также о принципах работы CSS-минификаторов, новых идеях и развитии CSSO.
С ростом количества CSS на клиенте, разработчики озаботились его минимизацией: сначала простыми заменами, а потом и структурной оптимизацией. Первым иструментом, где появилась такая оптимизация, был CSSO и он оставался лучшим, пока не был заброшен. Не так давно он снова вернулся к жизни. Принципы работы CSSO, новые идеи оптимизаций и изменения в последних релизах от нового мейнтейнера проекта.
CSSO – инструмент для минификации CSS, который не так давно вернулся к активной разработке. Помимо исправленных багов и новых фич, он значительно ускорился и стал одним из самых быстрых структурных минификаторов CSS.
Доклад о том как это достигалось, оптимизациях, деоптимизациях, структурах данных и подходах.
Holy.js, Санкт-Петербург, 5 июня 2016
Видео: https://www.youtube.com/watch?v=8o3gKKD_J4A
Я занимаюсь CSSO. В ходе работы над ним мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом.
Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Большинство считает CSS чем-то простым и не заслуживающим внимания. Но за мнимой простотой кроется большая сложность и огромный пласт проблем, не имеющих пока решения. Современный CSS с его объёмами, новыми фичами, разной поддержкой и багами браузеров, уже почти не поддается анализу человеком. Для этого появляются программы, которые разбирают CSS на атомы, анализируют и помогают сделать его лучше. Как к этому прийти, где мы сейчас и что ещё предстоит сделать.
С ростом количества CSS на клиенте, разработчики озаботились его минимизацией: сначала простыми заменами, а потом и структурной оптимизацией. Первым иструментом, где появилась такая оптимизация, был CSSO и он оставался лучшим, пока не был заброшен. Не так давно он снова вернулся к жизни. Принципы работы CSSO, новые идеи оптимизаций и изменения в последних релизах от нового мейнтейнера проекта.
CSSO – инструмент для минификации CSS, который не так давно вернулся к активной разработке. Помимо исправленных багов и новых фич, он значительно ускорился и стал одним из самых быстрых структурных минификаторов CSS.
Доклад о том как это достигалось, оптимизациях, деоптимизациях, структурах данных и подходах.
Holy.js, Санкт-Петербург, 5 июня 2016
Видео: https://www.youtube.com/watch?v=8o3gKKD_J4A
Я занимаюсь CSSO. В ходе работы над ним мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом.
Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Производительность запросов в PostgreSQL - шаг за шагом / Илья Космодемьянски...Ontico
Вы взяли ваш любимый фреймворк™ и быстро запустили крутой проект, который раскручивается, приносит деньги и требует быстрого развития, чтобы оставить конкурентов далеко позади.
В один далеко не прекрасный момент вы понимаете, что корень всех зол - медленное время ответа базы данных, а ваш админ зло смотрит на разработчиков красными от бессонницы глазами и ругается на безумные запросы, которые генерирует ORM. Тот самый ORM, который позволил вам так быстро запустить ваш замечательный проект.
Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?
Большинство считает CSS чем-то простым и не заслуживающим внимания. Но за мнимой простотой кроется большая сложность и огромный пласт проблем, не имеющих пока решения. Современный CSS с его объёмами, новыми фичами, разной поддержкой и багами браузеров, уже почти не поддается анализу человеком. Для этого появляются программы, которые разбирают CSS на атомы, анализируют и помогают сделать его лучше. Как к этому прийти, где мы сейчас и что ещё предстоит сделать.
Олег Мохов "Куда движется вёрстка и верстальщики Яндекса"Yandex
15 октября 2011, Я.Субботник в Алматы
Олег Мохов "Куда движется вёрстка и верстальщики Яндекса"
О докладе:
Стремительное развитие браузеров и технологий требует от верстальщиков высокой скорости изучения и внедрения новых возможностей в существующую вёрстку. В докладе будет показано, как без изменения HTML можно значительно улучшить «старую вёрстку», а также куда смотрят верстальщики, кроме чейнджлогов браузеров, и чем ещё, кроме вёрстки, они занимаются.
Олег Мохов "Куда идём мы с Пятачком, или О том, куда движется вёрстка и верст...Yandex
2 июля 2012, Я.Субботник в Екатеринбурге
Олег Мохов "Куда идём мы с Пятачком, или О том, куда движется вёрстка и верстальщики Яндекса"
О докладе:
«Куда идём мы с Пятачком, большой-большой секрет, и не расскажем мы о нём...», но сегодня мы расскажем куда идёт верстка и верстальщики Яндекса, какими современными технологиями мы уже пользуемся, а на какие активно засматриваемся.
«Парсим CSS», Роман Дворнов (Avito)
В ходе работы над CSSO мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом. Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Мастер-класс: Разрабатываем сайт с нуля на полном стеке БЭМ-технологий — Жека...Yandex
БЭМ упрощает разработку сайтов, которые нужно быстро создать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться. С обширным арсеналом БЭМ, со всей его модульностью и мощью, вам останется «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали. Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты — например, autoprefixer, css-препроцессор Roole или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки на БЭМ. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельная часть мастер-класса будет посвящена декларативным шаблонам BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON. Мы вместе напишем серверную часть приложения в БЭМ-методологии и используем данные от разных социальных и поисковых сервисов (RSS с Яндекс.Фоток, API Twitter и Instagram). В результате получится работающий сайт, а вы — на практике познакомитесь с полным стеком БЭМ-технологий. После мастер-класса мы сможем свободно пообщаться на профессиональные темы. Например, вы расскажете о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
БЭМ — это технология разработки сайтов, которые нужно быстро создать и долго поддерживать. Она используется в разработке фронтенда почти всех сервисов Яндекса и успела обрасти большим набором библиотек и инструментов, которым мы хотим с вами поделиться.
Имея в своих руках обширный арсенал БЭМ со всей его модульностью и мощью, остаётся «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали.
Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое «уровни переопределения», познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты для упрощения жизни разработчика, вроде autoprefixer, css-препроцессора roole и модульной системы YModules, встраиваются в процесс разработки на БЭМ и создают по-настоящему удобную платформу. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JS. Более того, декларативным шаблонам: BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON, — будет посвящена одна из трёх частей мастер-класса.
В результате получится работающий сайт, а вы на практике познакомитесь с полным стеком БЭМ-технологий.
После мастер-класса запланировано дополнительное время на полезное общение: вы сможете рассказать о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
Презентация подготовлена по материалам выступления Юрия Бондаренко на витебском MiniQ#14, который был проведен 25 апреля 2019:
https://vk.com/miniq14;
https://communities.by/events/miniq-vitebsk-14.
Про доклад:
В докладе я расскажу о том, как писать стили на чистом "ванильном" CSS. Мы рассмотрим возникающие перед вертальщиком практические задачи и способы их решения.
Михаил Корепанов "Скорость рендеринга страниц: исследования, замеры, автомати...Yandex
28 мая 2011, Я.Субботник в Киеве
Михаил Корепанов "Скорость рендеринга страниц: исследования, замеры, автоматизация"
О докладе:
В докладе подробно разобрано, что влияет на скорость отрисовки страниц, как ее измерить и как оптимизировать, включая вопрос автоматизации процесса тестирования скорости отрисовки в разных браузерах.
Действительно ли нужно уделять время оптимизации скорости рендеринга страниц или достаточно оптимизировать только скорость загрузки? Что такое reflow и repaint и как это влияет на время отрисовки страниц? Что использовать для измерения времени reflow и repaint? Как автоматизировать процесс тестирования скорости рендеринга страниц в большом количестве браузеров?
D2D Pizza JS Тимофей Чаптыков "CSS-менеджмент в 2016"Dev2Dev
За последние 7 лет появились десятки подходов к тому, как организовывать работу со стилями на веб-проектах: от БЭМ до CSS Modules. Огромное распространение получила экосистема PostCSS. Многие из нас перешли на React. Пришло время разобраться, что из инструментов взять с собой в будущее, а что забыть, как страшный сон.
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
За последние 7 лет появились десятки подходов к тому, как организовывать работу со стилями на веб-проектах: от БЭМ до CSS Modules. Огромное распространение получила экосистема PostCSS. Многие из нас перешли на React. Пришло время разобраться, что из инструментов взять с собой в будущее, а что забыть, как страшный сон.
Архитектура HAWQ / Алексей Грищенко (Pivotal)Ontico
HAWQ — один из лучших на рынке движков SQL-on-Hadoop, который не раз доказывал свою лидирующую позицию в открытых тестированиях. Что еще более интересно, в конце сентября этого года Pivotal открыл его исходный код под лицензией Apache, а также разместил сам проект в инкубаторе Apache (http://hawq.incubator.apache.org), что делает этот инструмент доступным большому кругу пользователей и намного более привлекательным для компаний — лидеров интернет-индустрии.
Работая в Pivotal, я участвовал в развитии и внедрении этого продукта с первого дня его существования.
В этой презентации я раскрою следующие темы:
+ Что такое HAWQ и зачем он был создан.
+ Кластерная архитектура HAWQ.
+ Принципы работы HAWQ.
+ Внутреннее устройство процессов HAWQ.
+ Интеграция с внешними системами.
+ Альтернативные решения.
Автоматизация разработки курсов: путь от рутины к игреAlexey Simonenko
Принципы автоматизации хорошо применимы не только для организации кода, но и для работы с контентом. В HTML Academy мы прошли путь от скидывания заданий в базу данных до организации автоматической сборки курсов на основе статических файлов. Я расскажу о том, как мы меняли процесс разработки курсов, как добавляли в него автоматизацию и к чему мы хотим прийти в итоге.
http://htmlacademy.ru
Олег Мохов "CSS3 фарш"
Я.Субботник в Новосибирске
О докладе:
Давайте приготовим что-нибудь вкусненькое на CSS3. Сварим немного градиентов, перемешаем со скруглёнными уголками, добавим «тенюшек» и заправим всё это флексбоксом. Такой винегрет новых технологий даёт кучу интересных результатов, когда свойства бывают несовместимы друг с другом, и дизайнеры, которым дали в руки напильник из CSS3, рисуют «космические» картинки, о которых и не подозревают разработчики веб-стандартов. Рассказ пойдет о том, как верстальщики Яндекса пытаются справиться с этим «фаршем», и что из этого обычно получается.
Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Все время смущали вопросы простоты поддержки и применения, но в большей степени вопрос пропускной способности решений (производительности). Хотелось решения, простого в использовании и быстрого в работе. Готовые решения не подошли, и мы взялись делать свое.
В докладе расскажем, что из этого вышло, какие задачи решали и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов.
Видео: https://youtu.be/ULwdj_Vr_WA
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Олег Мохов "Куда движется вёрстка и верстальщики Яндекса"Yandex
15 октября 2011, Я.Субботник в Алматы
Олег Мохов "Куда движется вёрстка и верстальщики Яндекса"
О докладе:
Стремительное развитие браузеров и технологий требует от верстальщиков высокой скорости изучения и внедрения новых возможностей в существующую вёрстку. В докладе будет показано, как без изменения HTML можно значительно улучшить «старую вёрстку», а также куда смотрят верстальщики, кроме чейнджлогов браузеров, и чем ещё, кроме вёрстки, они занимаются.
Олег Мохов "Куда идём мы с Пятачком, или О том, куда движется вёрстка и верст...Yandex
2 июля 2012, Я.Субботник в Екатеринбурге
Олег Мохов "Куда идём мы с Пятачком, или О том, куда движется вёрстка и верстальщики Яндекса"
О докладе:
«Куда идём мы с Пятачком, большой-большой секрет, и не расскажем мы о нём...», но сегодня мы расскажем куда идёт верстка и верстальщики Яндекса, какими современными технологиями мы уже пользуемся, а на какие активно засматриваемся.
«Парсим CSS», Роман Дворнов (Avito)
В ходе работы над CSSO мне пришлось погрузиться в процесс парсинга CSS. В результате парсер (тот, что в CSSO) был не раз переписан. Пришло время сделать его отдельным инструментом. Новый быстрый детальный парсер CSS, его AST, области применения и кое-что ещё.
Мастер-класс: Разрабатываем сайт с нуля на полном стеке БЭМ-технологий — Жека...Yandex
БЭМ упрощает разработку сайтов, которые нужно быстро создать и долго поддерживать. Эту технологию используют во фронтенде почти всех сервисов Яндекса, и она уже успела обрасти множеством библиотек и инструментов, которыми мы хотим с вами поделиться. С обширным арсеналом БЭМ, со всей его модульностью и мощью, вам останется «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали. Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты — например, autoprefixer, css-препроцессор Roole или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки на БЭМ. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельная часть мастер-класса будет посвящена декларативным шаблонам BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON. Мы вместе напишем серверную часть приложения в БЭМ-методологии и используем данные от разных социальных и поисковых сервисов (RSS с Яндекс.Фоток, API Twitter и Instagram). В результате получится работающий сайт, а вы — на практике познакомитесь с полным стеком БЭМ-технологий. После мастер-класса мы сможем свободно пообщаться на профессиональные темы. Например, вы расскажете о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
БЭМ — это технология разработки сайтов, которые нужно быстро создать и долго поддерживать. Она используется в разработке фронтенда почти всех сервисов Яндекса и успела обрасти большим набором библиотек и инструментов, которым мы хотим с вами поделиться.
Имея в своих руках обширный арсенал БЭМ со всей его модульностью и мощью, остаётся «всего-то» придумать идею и реализовать её. На мастер-классе вы сможете вместе с нами создать то, что мы «только что» придумали.
Вы узнаете, в чём преимущество вёрстки независимыми блоками и что такое «уровни переопределения», познакомитесь с готовыми библиотеками блоков и инструментами для автоматизации сборки. Мы покажем, как разные инструменты для упрощения жизни разработчика, вроде autoprefixer, css-препроцессора roole и модульной системы YModules, встраиваются в процесс разработки на БЭМ и создают по-настоящему удобную платформу. На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JS. Более того, декларативным шаблонам: BEMHTML и BEMTREE, которые позволяют преобразовывать сырые данные во view-ориентированный BEMJSON, — будет посвящена одна из трёх частей мастер-класса.
В результате получится работающий сайт, а вы на практике познакомитесь с полным стеком БЭМ-технологий.
После мастер-класса запланировано дополнительное время на полезное общение: вы сможете рассказать о трудностях, с которыми встретились при реализации проекта на БЭМ, и мы вместе подумаем, как воплотить вашу идею в жизнь.
Презентация подготовлена по материалам выступления Юрия Бондаренко на витебском MiniQ#14, который был проведен 25 апреля 2019:
https://vk.com/miniq14;
https://communities.by/events/miniq-vitebsk-14.
Про доклад:
В докладе я расскажу о том, как писать стили на чистом "ванильном" CSS. Мы рассмотрим возникающие перед вертальщиком практические задачи и способы их решения.
Михаил Корепанов "Скорость рендеринга страниц: исследования, замеры, автомати...Yandex
28 мая 2011, Я.Субботник в Киеве
Михаил Корепанов "Скорость рендеринга страниц: исследования, замеры, автоматизация"
О докладе:
В докладе подробно разобрано, что влияет на скорость отрисовки страниц, как ее измерить и как оптимизировать, включая вопрос автоматизации процесса тестирования скорости отрисовки в разных браузерах.
Действительно ли нужно уделять время оптимизации скорости рендеринга страниц или достаточно оптимизировать только скорость загрузки? Что такое reflow и repaint и как это влияет на время отрисовки страниц? Что использовать для измерения времени reflow и repaint? Как автоматизировать процесс тестирования скорости рендеринга страниц в большом количестве браузеров?
D2D Pizza JS Тимофей Чаптыков "CSS-менеджмент в 2016"Dev2Dev
За последние 7 лет появились десятки подходов к тому, как организовывать работу со стилями на веб-проектах: от БЭМ до CSS Modules. Огромное распространение получила экосистема PostCSS. Многие из нас перешли на React. Пришло время разобраться, что из инструментов взять с собой в будущее, а что забыть, как страшный сон.
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
За последние 7 лет появились десятки подходов к тому, как организовывать работу со стилями на веб-проектах: от БЭМ до CSS Modules. Огромное распространение получила экосистема PostCSS. Многие из нас перешли на React. Пришло время разобраться, что из инструментов взять с собой в будущее, а что забыть, как страшный сон.
Архитектура HAWQ / Алексей Грищенко (Pivotal)Ontico
HAWQ — один из лучших на рынке движков SQL-on-Hadoop, который не раз доказывал свою лидирующую позицию в открытых тестированиях. Что еще более интересно, в конце сентября этого года Pivotal открыл его исходный код под лицензией Apache, а также разместил сам проект в инкубаторе Apache (http://hawq.incubator.apache.org), что делает этот инструмент доступным большому кругу пользователей и намного более привлекательным для компаний — лидеров интернет-индустрии.
Работая в Pivotal, я участвовал в развитии и внедрении этого продукта с первого дня его существования.
В этой презентации я раскрою следующие темы:
+ Что такое HAWQ и зачем он был создан.
+ Кластерная архитектура HAWQ.
+ Принципы работы HAWQ.
+ Внутреннее устройство процессов HAWQ.
+ Интеграция с внешними системами.
+ Альтернативные решения.
Автоматизация разработки курсов: путь от рутины к игреAlexey Simonenko
Принципы автоматизации хорошо применимы не только для организации кода, но и для работы с контентом. В HTML Academy мы прошли путь от скидывания заданий в базу данных до организации автоматической сборки курсов на основе статических файлов. Я расскажу о том, как мы меняли процесс разработки курсов, как добавляли в него автоматизацию и к чему мы хотим прийти в итоге.
http://htmlacademy.ru
Олег Мохов "CSS3 фарш"
Я.Субботник в Новосибирске
О докладе:
Давайте приготовим что-нибудь вкусненькое на CSS3. Сварим немного градиентов, перемешаем со скруглёнными уголками, добавим «тенюшек» и заправим всё это флексбоксом. Такой винегрет новых технологий даёт кучу интересных результатов, когда свойства бывают несовместимы друг с другом, и дизайнеры, которым дали в руки напильник из CSS3, рисуют «космические» картинки, о которых и не подозревают разработчики веб-стандартов. Рассказ пойдет о том, как верстальщики Яндекса пытаются справиться с этим «фаршем», и что из этого обычно получается.
Тестировать регресс верстки скриншотами модно, этим никого не удивишь. Мы давно хотели внедрить этот вид тестирования у себя. Все время смущали вопросы простоты поддержки и применения, но в большей степени вопрос пропускной способности решений (производительности). Хотелось решения, простого в использовании и быстрого в работе. Готовые решения не подошли, и мы взялись делать свое.
В докладе расскажем, что из этого вышло, какие задачи решали и как мы добились того, чтобы тестирование скриншотами практически не влияло на общее время прохождения тестов.
Видео: https://youtu.be/ULwdj_Vr_WA
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Rempl – крутая платформа для крутых инструментовRoman Dvornov
Фронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
CodeFest, Новосибирск, 2017
Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Talk is about CSS minification problem, how minifiers work, new advanced optimisations, how minification influences on performance, CSSO reborn and future plans.
Занимаясь разработкой интерфейсов, мы постоянно разбираемся как и что устроено. Вы задумывались, сколько времени у вас уходит на то, чтобы найти нужный фрагмент кода, который отвечает за компонент на странице? В своем докладе я покажу как это можно сделать за один клик, а так же раскрою технические детали.
Есть такая штука как инструментирование кода. Мало кто знает о ней, даже пользуясь результатами ее применения. Между тем, с инструментированием можно делать много всего интересного и, главное, полезного. Например, это может вам помочь лучше понять код или сделать процесс разработки более эффективным. Примеры инструментирования кода и принципы его работы.
С ростом кодовой базы становится все более очевидной необходимость использования компонентного подхода, когда каждая логическая часть обособлена. Если говорить про JavaScript, то в нем есть области видимости, опираясь на которые можно соорудить изолированные компоненты. Но в CSS нет подобных механизмов, поэтому и придумываются Shadow DOM (Web Components) и различные методики вроде БЭМ.
Но что если взглянуть на проблему под другим углом? Адаптируя подходы, что уже используются для других задач, можно получить куда больше выгоды, чем просто изолированные стили!
FrontendConf, Москва, 21 мая 2015
WSD, Санкт-Петербург, 20 июня 2015
Запись трансляции: https://youtu.be/V7bnSOwuO4M?t=1h31m33s
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
Видео: https://www.youtube.com/watch?v=IUtbbN9aevU
Веб-приложения становятся все больше и сложнее, так что многое остается вне нашего поля зрения. Поэтому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи решать, что необходимо для их создания.
SPA Meetup, 28 февраля 2015, Москва, Авито
Не так давно случился значимый прецедент в истории W3C. Были приняты две конфликтующие спецификации, решающие одну проблему: Touch Events и Pointer Events. Почему так получилось, что это значит и что с этим делать?
Конференция WSD, Минск, 26 октября 2014
Видео: http://www.youtube.com/watch?v=dQoz5KZUH2M
Mobile Frontend Meetup, Москва, 4 июля 2015
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Конференция FrontTalks, Екатеринбург, 19 сентября
Видео: https://vimeo.com/107694664
Шаблонизация основанная на работе с DOM становится трендом: React, Ractive, Basis.js уже используют этот подход, другие идут в эту сторону. Главным преимуществом подхода считается скорость, но оно далеко не единственное!
В докладе немного рассказано о возможностях, что дает DOM подход.
Не бойся, это всего лишь данные... просто их многоRoman Dvornov
За последние 15 лет веб сильно изменился и ускорился. Но большинство по-прежнему боится большого количества данных и сложной логики на клиенте. Потому что "тормозит".
Я хочу сломать стереотипы и показать, как начать делать крутые штуки на client-side. Тысячи и сотни тысяч объектов, разные типы, зависимые вычисляемые свойства, агрегация, множество вариантов отображения. Все это в вашем браузере. Без тормозов, регистраций, смс.
Видео этого доклада на конференции DUMP, Екатеринбург, 14 марта 2014: https://vimeo.com/90836493
Шаблонизаторы упрощают процесс формирования HTML и только. Но браузеру нужен совсем не HTML, а DOM. Необходимо преобразование. И вот тут начинается самое интересное: танцы с бубном и стрельба по ногам. В докладе пойдёт речь об общепринятом подходе получения DOM фрагмента, постпроцессинге и альтернативах. Сравним, измерим и узнаем как это делать быстрее всего.
54. 40
span {
color: red;
}
div {
color: green;
}
ul {
color: red;
}
span, ul {
color: red;
}
div {
color: green;
}
Перегруппировка
Правильно?
55. 40
span {
color: red;
}
div {
color: green;
}
ul {
color: red;
}
span, ul {
color: red;
}
div {
color: green;
}
Правильно,
у элементов одно имя
Перегруппировка
Правильно?
63. 46
.foo {
color: red;
}
.bar {
color: red;
color: rgba(..);
}
.foo, .bar {
color: red;
}
.bar {
color: rgba(..);
}
Вынос общих частей
В данном примере можно только в начало
64. 47
.foo {
color: rgba(..);
}
.bar {
color: red;
color: rgba(..);
}
.bar {
color: red;
}
.foo, .bar {
color: rgba(..);
}
Вынос общих частей
В данном примере можно только в конец
69. 52
.foo {
color: red;
}
.bar {
color: green;
}
.qux {
color: red;
}
.foo, .qux {
color: red;
}
.bar {
color: green;
}
Трансформация не безопасна,
так как мы не знаем как
используется CSS в разметке
Вспомним пример
72. 55
{
"classes": ["foo", "bar"],
"tags": ["ul", "li"]
}
.foo { color: red }
div.bar { color: green }
ul li, ol li { color: blue }
usage.json
CSS
+ .foo { color: red }
ul li { color: blue }
Результат
74. Пример
57
.module1-foo { background: red; }
.module1-bar { font-size: 1.5em; background: yellow; }
.module2-baz { background: red; }
.module2-qux { font-size: 1.5em; background: yellow; width: 50px; }
Нельзя объединить
.module1-foo и .module2-baz,
так как между ними .module1-bar
75. Пример
58
.module1-foo { background: red; }
.module1-bar { font-size: 1.5em; background: yellow; }
.module2-baz { background: red; }
.module2-qux { font-size: 1.5em; background: yellow; width: 50px; }
Минификатор не знает,
что имена не смешиваются
и можно безопасно перемещать
76. Usage data
59
{
"scopes": [
["module1-foo", "module1-bar"],
["module2-baz", "module2-qux"]
]
}
Так мы гарантируем, что классы
module1-* и module2-*
не встречаются на одном элементе
77. Результат с usage data
60
.module1-foo,.module2-baz{background:red}
.module1-bar,.module2-qux{font-size:1.5em;background:#ff0}
.module2-qux{width:50px}
На 29 байт меньше, чем без usage data
79. Что это дало нашему проекту
• 823 Kb Оригинальный CSS
• 596 Kb Базовая минификация
• 437 Kb Минификация с usage data
62
Улучшение результата на 159Kb (26%)
80. Как генерировать usage data?
63
Универсального решения нет –
все зависит от используемого стека
82. 65
.foo { color: red }
.foo.bar { color: green }
.a { color: red }
.a.b { color: green }
{
"foo": "a",
"bar": "b"
}
rename map
Результат
CSS
+
83. 66
• 823 Kb Оригинальный CSS
• 596 Kb Базовая минификация
• 385 Kb Rename (пока вне CSSO)
Улучшение результата на 211Kb (35%)
Что это дало нашему проекту
84. 67
Улучшение результата на 364Kb (61%)
Все вместе
• 823 Kb Оригинальный CSS
• 596 Kb Базовая минификация
• 232 Kb Rename + Usage data
90. 73
• ~10 Kb дополнительного выигрыша (~3-4%)
• 1431 удаленный селектор из 6904
Селекторов стало на ~20% меньше
Что это дало нашему проекту
предварительные оценки
98. Без сжатия 823 Kb – 35ms
Базовое сжатие 596 Kb – 29ms
Rename 385 Kb – 24ms
Rename + usage data 232 Kb – 22ms
81
Наколеночные тест
Влияние разного уровня сжатия на время парсинга
Размер уменьшился в ~4 раза, но время лишь на ~50%
(Chrome на MacBook Air)
99. Win10 Desktop 19ms → 11ms
Nexus 5X 68ms → 44ms
Samsung Galaxy Note 2 158ms → 108ms
82
Наколеночные тесты
Ранее, на других устройствах, были получены более
обнадеживающие цифры при улучшении сжатия
CSS 316Kb 215Kb (-39.5%)
+ usage data
104. Что изменилось
• В 10+ раз быстрее
• В 8+ раз меньше потребление памяти
• Исправлена большая часть проблем и багов
• Улучшена кодовая база и API
• Больше скачиваний и звезд на GitHub ;)
86
105. 87
ВремясжатияCSS(600Kb)
500 ms
1 000 ms
1 500 ms
2 000 ms
2 500 ms
3 000 ms
3 500 ms
4 000 ms
4 500 ms
5 000 ms
5 500 ms
6 000 ms
Версия CSSO
1.4.0 1.5.0 1.6.0 1.7.0 1.8.0 2.0
1 050 ms
clean-css
Изменение по скорости
csso
500 ms
cssnano
23 250 ms
106. postcss-csso
88
Плагин для PostCSS, aльтернатива cssnano
Работает почти также быстро как CSSO отдельно
Под капотом конвертация AST
github.com/lahmatiy/postcss-csso
111. Coming soon
• Новые оптимизации и алгоритмы: быстрее и правильно
• Учет поддерживаемых браузеров
• Семейства свойств и сортировка деклараций
• Нормализация имен и переименование
• Понимание структуры shorthand-значений
• Применение статистики
93