Размышления про идеальный корпус

Здравствуйте. На написание этой статьи меня побудил наметившийся апгрейд домашней системы и недавняя статья Настольный. Металлический. Бесшумный. Твой?. Чтобы найти приемлемый вариант мне пришлось перелопатить кучу моделей корпусов и сейчас я хочу поделиться своей болью с вами.

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

Типичный компьютерный корпус с точки зрения термодинамики

Чтобы не было вопросов, хочу сразу пояснить, почему я не могу использовать маленький бесшумный компьютер формата типа Intel Nuc или Mac Mini.

Зачем мне нужен компьютер?

  • Интернет (с привычкой открывать 100500 вкладок в браузере)
  • Игры
  • Фильмы и сериалы (использую SVP для поднятия фреймрейта до 60ФПС)
  • Иногда программирование (на работе хватает)
  • Иногда видеомонтаж

То есть мой компьютер должен рассеивать ~500Ватт тепловой мощности (100 процессор, 300 видеокарта, 100 — всё остальное).

Также должен быть SSD под ОСь с программами и место под HDD с файлохранилищем. Для NAS я еще не созрел.

Каким требованиям должен удовлетворять компьютерный корпус?

  • Компактность
  • Хорошее охлаждение компонентов
  • Защита от пыли
  • Лёгкость обслуживания
  • Тишина (по крайней мере без нагрузки)

Какие компоненты самые шумные?

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

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

Теперь приведу в пример типичную компоновку корпуса и расскажу, что в ней не так:

  • Видеокарта типа ПЕЧ стоит под процессором с памятью и эффективно их подогревает.
  • Конвекция почти не помогает охлаждать комплектующие.
  • Много пустого места (и, как следствие, слишком большие габариты системного блока).
  • Но при этом воздушный поток от фронтальных вентиляторов перегораживают пустые корзины для жестких дисков.
  • Конкретно эта модель претендует на роль «тихой» и в некоторых местах даже установлены звукопоглощающие пластины, но по факту шум выходит через дырявую заднюю панель корпуса.

Претензии к компонентам

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

Видеокарты

Давным давно, когда приняли стандарт ATX и придумали ставшую классической компоновку материнской платы, никто не думал, что в слот AGP (позднее PCI-E) будут ставить самый горячий компонент системы. А потом видеокарты стали наращивать энергопотребление и под процессором расположилась миниатюрная печка.

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


Такая система охлаждения по сравнению с турбинкой:


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

Материнские платы

Как самый большой компонент системы.

Полноразмерный ATX сейчас редко когда нужен. Обычно в слоты PCI воткнуты только видеокарта и, в редких случаях, звуковая карта. Всё остальное и так встроено в материнскую плату.

Но это легко решается, так как есть форматы mATX и mini-ITX. Но в большинстве корпусов miniITX сложно обеспечить хорошее охлаждение и, как правило, нет слота 3.5″ под HDD, так что мой выбор — mATX.

Типичные проблемы корпусов

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

Вентиляция и защита от пыли

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


Фильтровентиляционная установка автомобильная

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

Если применить это к компьютерным корпусам — для создания избыточного давления внутри корпуса должны быть установлены нагнетающие вентиляторы с пылевыми фильтрами. Казалось бы, всё очевидно. Но давайте посмотрим сюда:


Формально всё на месте — 2 нагнетающих вентилятора за пылевым фильтром.


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

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

Еще один вариант:


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

А некоторые корпуса просто страдают излишней дырявостью:


Защита от пыли? Какая еще защита от пыли?

И — мое любимое:


Больше вентиляторов богу вентиляторов!

Без комментариев.

Есть и более-менее адекватные варианты:

2 нагнетающих вентилятора с пылевым фильтром, 2 вытяжных вентилятора, лишних дырок (кроме заглушек PCI) нет. Только непонятно, зачем СЖО с видеокарты подогревает поступающий в корпус воздух.

Еще интересно, почему не используют HEPA фильтры на вдув. Сложенный гармошкой самый грубый HEPA фильтр обеспечит меньшее сопротивление воздушному потоку и лучшую фильтрацию, чем любые сеточки. Да, эти фильтры нельзя полностью очистить. Но это же мечта любого производителя — продавать расходники с дикой наценкой! Шутка. А может быть и нет.

Лёгкость обслуживания

В данном контексте всё просто — хочется иметь возможность пропылесосить пылевые фильтры не разбирая корпус.

Также ради лёгкости обслуживания я отметаю СЖО

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

Компоновка

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

1) Корпус с материнской платой, повернутой на 90 градусов:

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

2) Горизонтальное расположение материнской платы

Тут всё понятно — горячий воздух поднимается от процессора и видеокарты наверх. Комплектующие друг друга не греют.

3) Корпуса — перевертыши

Материнская плата повернута на 180 градусов, то есть видеокарта расположена над процессором и больше его не греет.

4) Можно использовать райзер для подключения видеокарты

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

Так где же идеальный корпус?

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

Не являюсь поклонником Apple, но Mac Pro мне нравится. Есть только нагнетающие вентиляторы и в потоке воздуха от них установлены радиаторы компонентов.

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


В итоге получится как с фальшивыми ёлочными игрушками — выглядят как настоящие, но радости (охлаждения) не приносят.

Что делать?

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

  • Поместить корпус туда, где его не слышно

    Без комментариев. Длинный кабель к монитору и USB хаб позволят вынести системный блок хоть на балкон. Или в домашнюю серверную. Заодно это частично решит проблему с пылью. Другое дело, что такой возможностью стоит озаботиться еще на этапе ремонта.

  • Выбрать из имеющихся вариантов

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

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

  • Сделай сам

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

Я так не сделал из-за лени и наличия любопытного кота.

  • Мелкосерийное производство

    Тут всё тоже можно сделать самому, но я не нашел, где можно достать подходящий термосифон.
    Надеюсь, webself меня прочитает.

Есть такая штука:

Гуглится по словам «алюминиевый профиль радиаторный».

Используется для охлаждения систем освещения на основе светодиодов, стоит недорого. Ширина (которую мне удалось найти) до 30 сантиметров. Толщина основания от 6 миллиметров. В некоторых случаях его можно заказать уже анодированным.

И этот радиаторный профиль можно использовать в качестве стенки корпуса.

Через термосифон:

image

… устанавливаем материнскую плату с процессором.

Снимаем штатную систему охлаждения с видеокарты и при помощи райзера через термосифон крепим её к тому же радиатору. Вы великолепны! На самом деле — не совсем. Меня смущает, что контакт термосифона и радиаторного профиля может оказаться недостаточным. Само собой, тут тоже надо использовать термопасту, но хватит ли этого?

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

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

На этом всё, надеюсь, эта статья кому-нибудь поможет.

PS

Если кто-то знает, как найти готовый термосифон — напишите, пожалуйста, в личку или в комментарии.

PPS

Спасибо evilme за статью Учимся писать на Хабр. Так писать намного удобнее чем в web-редакторе или Word’е с последующим переносом на хабр. От себя добавлю, что рекомендую поставить расширение «Russian — Code Spell Checker» для борьбы с неизбежными очепятками.


ссылка на оригинал статьи https://habr.com/ru/post/476796/

Работа «не в стол»: какие проекты по-настоящему зажглись после преакселерации?

22 ноября в Мастерской управления «Сенеж» жюри и эксперты вынесли окончательный вердикт командам, которые на протяжении двух месяцев прокачивали проекты в рамках преакселерационной программы. Спали мало, работали много — но так бывает всегда, когда

В этом посте мы подведем главные итоги преакселерационной программы — удалось ли нам достигнуть всех целей, которые мы ставили перед завершающим этапом конкурса? Много ли проектов действительно имеют будущее? Какие союзы были заключены по итогам этой непростой битвы? Довольны ли результатами сами команды?

Об этом и многом другом читаем ниже.

image

В образовательной (дистанционной) программе преакселератора приняли участие 53 команды. До очного этапа, который проходил в Мастерской управления «Сенеж» 20-22 ноября, дошли 47 проектов.

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

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

В целом о ходе программы

image

Команда FrozenLab: «На конкурсе «Цифровой прорыв» изначально стояла задача автоматизировать и классифицировать обращения пользователей, которые поступают в управляющую компанию. Мы решали ее в рамках финала конкурса и развивали на преакселераторе. Наша главная цель во время программы — не привлечь инвестиции в проект, а найти возможности для его развития. По итогам мы разработали проект на основе речевой аналитики, который определяет, кто звонит в компанию (и по какому адресу он проживает) и сразу передает информацию нужному человеку внутри компании или помогает сразу обработать заявку. В ходе преакселератора мы уже нашли первых клиентов — управляющую компанию из Уфы, которые заинтересовались нашими идеей и концепцией и согласились провести с нами платный пилот на взаимовыгодных условиях. Проектом мы можем управлять на удаленке, поэтому можем оказывать поддержку компаниям в любом городе на территории России».

Дмитрий Кузнецов, участник команды Black Pixel: «На финале, региональном этапе и в рамках преакселерационной программы мы работали над прототипом устройства, которое анализирует состояние здоровья людей, больных артериальной гипертонией. При помощи него собираются данные о состоянии больного и передаются врачу-кардиологу, который делает финальное заключение. Сбор информации происходит примерно 2-3 недели — далее ставится главный диагноз».

Команде PLEXeT изначально было необходимо сравнить две программы для поиска плагиата. Для упрощения задачи, чтобы не обучать систему под каждый язык программирования, команда сделала сравнение исполняемого кода программы. Данное решение позволяло проверять сразу много файлов. Но вот незадача — проблема оказалась слишком специфичной… Поэтому искать дубликаты и ориентироваться на одного клиента PLEXeT не стали: «Мы подумали — а почему бы нам не начать искать вирусы. Сейчас это объемный и емкий рынок, на котором как раз есть проблема быстрого анализа файлов. И для ее решения у нас практически все готово», — говорит Олег Бахтадзе-Карнаухов, капитан команды PLEXeT.

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

«Изначально, мы планировали создать сразу 4-5 сервисов, выстраивали экосистему. Но потом поняли, что так не годится — нужно оставить только самое сладкое» — комментирует Олег.

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

Юрий Кацер, капитан команды WAICO из Москвы: «В рамках преакселератора мы продолжили работу над созданием веб-сервиса для обработки данных с трубных дефектоскопов, с которым победили в финале конкурса. Отдельно хочется выразить респект некоторым аспектам образовательной программы, которая была крайне полезна. Больше всего нам запомнилась лекция о правовых основах создания компании — зачастую об этом все забывают».

image

Разработчики из команды Dream Team делали приложение, помогающие туристам без препятствий посещать российские заповедники. Оно позволит покупать билеты онлайн — это устранит очереди и сделает посещение таких мест более комфортным и безопасным. Сейчас многие проникают на территорию «зайцем», что чревато чрезвычайными ситуациями с вызовом сотрудников МЧС. Чтобы зарегистрироваться в системе человек должен ввести паспортные данные и расписать желаемый маршрут — это заменит долгий процесс регистрации в печатных журналах. Вход на территорию будет осуществляться по полученному по итогам QR-коду.

Сергей Иванов, трекер: «Основная задача преакселерационной программы — дать проектам дальнейшую жизнь, чтобы они дальше были востребованы для реального рынка, реальными заказчиками в лице госсектора и корпораций. Эта работа велась по двум направлениям.

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

Удалось ли достигнуть целей, поставленных в начале?

WAICO: «В преакселератор мы в первую очередь шли за контактами, партнерством или административным ресурсом. Но увы, в рамках программы нам дали только контакт эксперта из Газпром нефть (ГПН). Мы ожидали больше. Тем не менее, мы прошли в корпоративный акселератор ГПН — они заинтересованы в нашем решении, и мы обсуждаем процесс проведения пилота. Сейчас как раз происходит выбор пилотной площадки».

image

Black Pixel: «Наша главная цель на преакселераторе — привлечь средства на операционный запуск и маркетинг продукта. Наша цель была достигнута, и сейчас мы общаемся с компаниями по поводу дальнейшего сотрудничества. Также нам удалось привлечь к разработке административный ресурс и найти экспертов из корпоративного сегмента, которым зашло наше решение, и они готовы работать дальше».

Сергей Иванов: «Значимая доля проектов уже нашла первых рыночных клиентов. Соглашение о пилотных проектах подписаны у многих участников — я курировал три команды, и у две из них заключили сотрудничество. Также были заключены первые соглашения об инвестировании и проведены первые переговоры с инвесторами».

Была ли эффективна работа с трекерами и наставниками?

WAICO: «Поддержка, безусловно, была важна — трекеры мотивировали достигать результатов и создавать действительно полезные решения. Из-за того, что мы не очень хорошо понимали специфику работы с корпорациями, в развитии проекта образовался небольшой ступор. Но трекеры помогли разобраться с этим. Помимо этого, они пытались помочь собрать полезные для нас контакты и определиться с окончательным направлением проекта».

image

PLEXeT: «Рискну сказать, что презентация, которую мы делали перед экспертами из Фонда содействия инновациям, была самой крутой из всех в моей жизни. Мы чувствовали себя на одной волне со всеми членами жюри. Они все — просто невероятные ребята, которые проверяли нашу презентацию и раздатку перед защитой, а на финальном питче завалили действительно правильными вопросами: «Чем ваше решение отличается от других? Как его развивать? Вы же понимаете, что здесь требуется динамическое выполнение?». И мы поняли — они же реально шарят! Один эксперт вообще сразил нас в самое сердце — он нашёл информацию о наших конкурентах, задавал вопросы по их продуктам. У нас осталось отличное послевкусие.

Работа с трекерами также была очень эффективна — нам показали, как делается настоящий бизнес пилотов, внедрений, привлечения денег. Рассказали обо всех подводных камнях, лазейках. В общем, устроили настоящее реалити — мы все стали настоящей семьей. У нас были десятки чатиков, мы регулярно созванивались и обсуждали все вопросы. За это отдельный респект. Привет передаем нашему трекеру Виктору Степанову — он настоящий профи и в машинном обучении, и в бизнесе, и в образовании».

Что будет дальше?

WAICO: «Несмотря на то, что мы планируем сотрудничать с ГПН, мы все равно активно ищем контакты и другие возможности пообщаться с нефтегазовыми и нефтесервисными компаниями. Наше решение будет полезно для них. В дальнейшем мы планируем создать полноценное MVP и расширить функционал решения».

PLEXeT: «Деньги от инвесторов мы брать отказались — это накладывает на нас определенную ответственность (а если решение не выстрелит и мы потратим все в пустоту?). Тем не менее мы получили средства от ФСИ. С помощью них мы сможем полноценно протестировать пилот со всех сторон и рисков будет меньше. Тратить их будем в основном на научные исследования. Также нам нужно много средств для развития машинного обучения — понимать, как это будет выглядит в боевых условиях».

image

Dream Team: «После конкурса мы планируем интеграцию нашего решения с онлайн-сервисом МЧС для информирования служб спасения о том, что на территории заповедника находятся туристы. В приложении они смогут уведомлять о начале и завершении маршрута, с помощью чего спасатели МЧС смогут вовремя выходить на поиски заблудившихся или пострадавших групп».

Трекер Сергей Иванов также рассказал о возможных сценариях развития проектов после преакселерационной программы:

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

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

Третий сценарий — венчурный путь, где команда будет продолжать работать над своим продуктом и привлекать инвестиции. Это интересный и наиболее агрессивный путь, который, с одной стороны, дает большие перспективы, но с другой — большие риски. Все эти дороги для выпускников «Цифрового прорыва» открыты. Ребята могут делать выбор, основываясь на своих интересах, потому что на конкурсе они получили практический опыт, обросли знакомствами, нарастили компетенции».

О судьбах проектов также высказался инвестор Алексей Маликов: «Послушав финальный питч, перспективы на развитие некоторых проектов после преакселератора я вижу, но есть один важный момент. Так как большинство решений появилось по результатам хакатона, у многих команд нет бизнесового опыта, и им будет сложно создать что-то крупное. Потому что сделать продукт — это одно, а вот договориться с корпорацией — совсем другое. На мой взгляд, 50% питчей абсолютно не живые, про 25% сказать что-то внятное сложно, а вот остальные 25% — им можно доверять. Для меня как инвестора самое главное — видеть в глазах участников четкое понимание того, как будет развиваться их будущая компания. Если за два месяца преакселератора они не сделали бизнес-модель, то дальше ее также не будет».

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


ссылка на оригинал статьи https://habr.com/ru/company/leadersofdigital/blog/477858/

Как вы избавляетесь от неиспользуемого CSS-кода? Часть 2

Сегодня публикуем вторую часть перевода материала о борьбе с неиспользуемым CSS-кодом.

Первая часть

Постпроцессинг CSS

Предположим, в некоем проекте CSS пишут с использованием Less или Sass, а затем, для компиляции имеющегося кода в обычный CSS, применяют постпроцессор. В таком проекте, вероятно, имеется автоматическая система избавления от неиспользуемого CSS, которая запускается после выполнения препроцессинга CSS. Выглядеть подобное может так:

  1. Sass.
  2. PostCSS / автоматическая система работы с префиксами.
  3. Удаление неиспользуемого CSS.
  4. CSS-код, готовый для продакшна.

Это, с одной стороны, имеет смысл, а с другой — выглядит в моих глазах немного странным. Речь идёт о том, что при таком подходе не производится исправления исходного кода, содержащего команды стилизации, на основе которого создаётся итоговый CSS-код, в который входит и неиспользуемый CSS. Вместо этого ненужный CSS просто убирают в конце процесса сборки проекта. Подозреваю, что в JavaScript, при реализации алгоритма tree-shaking, нечто подобное делается уже довольно давно. То есть, подобное обращение с CSS — это совсем не новость. Но мне это, всё равно, кажется неправильным, так как кодовая база CSS — это то, что, можно сказать, лежит на поверхности веб-проектов. Такой подход почти что подталкивает разработчиков к небрежному написанию CSS, к тому, чтобы сваливать в исходный CSS-код всё попало. И правда — от ненужного CSS система избавится автоматически. Но это совершенно лишает разработчиков стремления понять то, как именно стилизуются их проекты, как именно в них используется CSS.

PurgeCSS

PurgeCSS — это ещё один проект, который направлен на борьбу с неиспользуемым CSS. Хотя это и не относится напрямую к возможностям этого проекта, но он мне нравится тем, что в его документации чётко разъяснены его отличия от конкурентов. Выше мы уже приводили фрагмент сравнения PurgeCSS и PurifyCSS. А вот — ещё одно извлечение из документации PurgeCSS, посвящённое PurifyCSS. Речь идёт о том, что главная проблема PurifyCSS заключается в низком уровне модульности этого проекта. Однако в этом кроется и основная сильная черта PurifyCSS. Как уже было сказано, PurifyCSS считает CSS-селекторами все слова, находимые им в файлах. Такой подход чреват ошибками. Но PurifyCSS решает эту проблему, давая возможность создавать функции-экстракторы. Такая функция принимает содержимое файла и извлекает из него список используемых в нём CSS-селекторов. Это позволяет очень хорошо решить задачу избавления от неиспользуемого CSS-кода.

Сейчас проект PurgeCSS выглядит крупным игроком рынка средств для очистки CSS-кода. Многие им пользуются, многие пишут о нём.

  • Вот материал о том, как пользоваться PurgeCSS, в частности — при работе с Bootstrap.
  • Из этой статьи можно узнать о том, что PurgeCSS не удалят селекторы в необычных обстоятельствах с использованием белых списков.
  • Здесь можно узнать о том, как PurgeCSS используют в связке с npm-скриптами и с PostCSS.
  • Тут написано о том, как PurgeCSS работает с Tailwind.

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

Я так думаю, что суть этого сводится к следующему: Tailwind создаёт большой CSS-файл, полный вспомогательных селекторов. Но не предполагается, что в проекте будут использованы все эти селекторы. Разработчик применяет их для решения всех задач по стилизации своего HTML-кода, а затем PurgeCSS анализирует этот HTML-код и убирает ненужные селекторы, формируя готовый к продакшну CSS.

Правда, до PurgeCSS ещё нужно донести сведения о каждом HTML и JavaScript-файле, используемом на сайте. Другими словами — нужно самостоятельно настроить всё, что имеет отношение к внешним ресурсам, и учитывать то, что данные, поступающие в проект из неких хранилищ, вероятно, не смогут быть проанализированы в ходе сборки проекта. В результате использование PurgeCSS при сборке проектов предполагает немалый объём ручной работы.

Мой любимый подход к избавлению от неиспользуемого CSS

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

Я видел один экстремальный подход к выяснению того, используется ли на сайте некий селектор. В CSS-блоке применялась конструкция наподобие background-image: url(/is-this-being-used.gif?selector);. После её применения периодически проверялись серверные логи для того, чтобы выяснить, был ли сделан запрос на получение соответствующего изображения. Если такой запрос был — значит исследуемый блок CSS используется. Если не было — значит не используется.

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

Исследование проектов методом визуальной регрессии

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

Затем, прежде чем объединить с веткой master любую другую ветку, создаются новые скриншоты, сделанные на основе материалов новой ветки, и сравниваются с теми, что были сделаны для ветки master. Это, конечно, делается не вручную, а программным способом.

Собственно говоря, вот видео, в котором это показано.

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

Atomic CSS и CSS-in-JS

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

Если так — то это просто замечательно.

Возможно, речь идёт об Atomizer. Возможно — это инструмент Tachyons, результаты работы которого пропускают через UnCSS и соблюдают при этом повышенную осторожность. Может — это комбинация Tailwind + PurgeCSS, которая сейчас у всех на слуху.

Может — со стилями работают ещё как-нибудь. Если некто тесно связывает JavaScript-компоненты и стили, скажем, как при использовании React и Emotion, или даже просто применяет CSS-модули с чем бы то ни было, среди преимуществ таких вот СSS-in-JS-подходов можно отметить уменьшение объёма неиспользуемого CSS в готовых проектах. Кроме того, так как при сборке многих проектов, основанных на JavaScript, применяются реализации алгоритма tree-shaking и техники разделения кода, в таких проектах не только будет меньше ненужного CSS. В ходе их работы загружаться будет только то, что нужно в каждой конкретной ситуации. Но, конечно, недостатки есть и у подобных подходов к работе с CSS.

Итоги

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

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

Технологии CSS-in-JS совершенно естественным образом двигаются в этом направлении. При применении таких технологий стили привязаны к компонентам. А это в данном случае самое главное. Но привязка стилей к компонентам — это необязательно. Мне нравится универсальный подход, подразумевающий использование CSS-модулей. Он практически полностью нацелен на разделение областей действия стилей и не заставляет разработчика пользоваться каким-то конкретным JavaScript-фреймворком.

Может быть, всё вышесказанное кажется вам чем-то теоретическим или далёким от реальных нужд веб-разработчиков. У вас просто есть сайт, на котором используется Bootstrap, и вам хотелось бы уменьшить размер CSS, который загружается пользователями этого сайта. Если так — я посоветовал бы вам пользоваться исходным кодом Bootstrap, а не его стандартной сборкой. Этот исходный код написан с использованием SCSS и состоит из множества подключаемых модулей. А это значит, что если вам некоторые части Bootstrap не нужны — соответствующие модули можно просто отключить.

Удаление модулей dropdowns, badges и breadcrumbs из Bootstrap перед сборкой проекта

Желаю всем удачи в нелёгкой борьбе с ненужным CSS-кодом.

Уважаемые читатели! Как вы боретесь с неиспользуемым CSS-кодом, который попадает в продакшн?



ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/477276/

TabPy для работы с данными в ClickHouse из Tableau

Выстраивание коммуникаций между брендами и людьми — то, чем мы в Dentsu Aegis Network занимаемся каждый день, и неотъемлемой частью этой работы является анализ данных. В ряде случаев этот процесс не требует data science (хотя и он у нас есть), тогда мы используем BI платформу Tableau. Ее основная цель — дать нашим сотрудникам и клиентам удобный интерфейс для потребления данных без написания скриптов, SQL запросов и т.п.

В этой статье мы расскажем, как нам удалось решить проблему взаимодействия Tableau с ClickHouse.

Общая формулировка задачи

Перед нами стояла классическая задача. У нас есть люди. Они любят фрукты. Какие-то люди любят один фрукт, какие-то любят все фрукты, а остальные могут любить любое сочетание фруктов.
image
Итак, необходимо дать возможность пользователю в дашборде, построенном в Tableau, произвольным образом выбирать несколько фруктов и смотреть, сколько людей любят хотя бы один фрукт из набора. У нас конечно были не фрукты, но люди были настоящие, просто на “фруктах” легче понять задачу.

Объем данных в нашем случае достаточно большой. Разных “фруктов” было 13 тысяч. У самого популярного “фрукта” было почти 34 миллиона поклонников. В среднем каждый “фрукт” любят 450 тысяч человек. Всего любителей фруктов — 282 миллиона.

Первое решение “в лоб”

Так получилось, что данные для этой задачи у нас лежали в PostgreSQL (PG) и в ClickHouse (CH). В PG была таблица-справочник по “фруктам”, в CH — большая таблица со структурой: идентификатор “фрукта” и идентификатор человека, который этот “фрукт” любит. Нативного коннектора для CH в Tableau нет, а перекладывать данные куда-то ещё не хотелось, потому что это потребовало бы серьезных переработок существующей системы.

Попробовали подключить Tableau к CH с помощью ODBC драйвера и посмотреть, что получится.

  • Hе все ODBC драйверы одинаково полезны. Нужна определённая версия, в которой работает нужная часть функционала, но нет гарантии, что остальная часть будет работать, если вдруг она вам понадобится.
  • Затянуть в экстракт Tableau все данные нам так и не удалось, потому что это 13 000 * 450 000 = 5 850 000 000 записей.

Дальше мы решили использовать sampling внутри запроса к базе CH, то есть делать нашу оценку количества любителей выбранного сочетания “фруктов” не на всех людях, а на пятипроцентной выборке, чтобы сделать экстракт меньше. Плюс, мы сразу сделали inner join выборки из CH со справочником “фруктов” из PG, чтобы получить имена “фруктов”. Это помогло — наш экстракт смог сгенерироваться за 5 часов.

Обновлять данные в дашборде нам нужно было раз в день, поэтому 5 часов обновления экстракта вроде бы ничего страшного — будем обновлять ночью. Но в будущем нам бы потребовались дополнительные мощности: “фруктов” должно было становиться больше, соответственно, количество и размер групп людей, пересечение которых нам нужно было вычислять, тоже должно было увеличиться. Поэтому долгое обновление экстракта — это совсем не наш вариант.

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

Тогда мы решили не создавать экстракт вообще. Чтобы избежать загрузки огромного объема данных, разделили датасеты и для CH использовали live connection. Между датасетами устанавливали связь посредством встроенного функционала Tableau Edit relationship. Датасорс PG делали основным и связывали его с CH, как со вторичным, с помощью идентификатора “фрукта”, который был в обеих таблицах.

Таким образом, мы получили возможность фильтровать вторичный датасорс с помощью основного (Data blending). Но нас ожидала неудача, так как после пробрасывания фильтра из одного датасорса в другой нам надо было применить функцию подсчета людей в получившемся подмножестве (COUNTD), а у Data blending есть ограничение, которое просто не дает это делать. Такая функция напрямую при таком соединении данных не работает в принципе.

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

После этого мы попробовали еще один вариант. Датасеты все еще были разделены и для CH использовали live connection. Здесь фильтр из датасета с описанием “фруктов” в датасет с любителями “фруктов” прокидывали внутри Tableau уже с использованием set action. Но этот вариант в итоге не подошел из-за неудобного UI. Пользователю вместо привычного ему фильтра пришлось бы смотреть весь список и выбирать “фрукты” через cntrl + click, при этом отсутствовала функция apply, когда все выбранные значения применяются разом.

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

image

Найденное решение

Очевидно же, что не нужно нам тянуть в экстракт Tableau все данные. Пользователю неудобно видеть все данные сразу — количество людей, любящих все “фрукты”. Ему нужен набор в среднем из 10 “фруктов”. Жаль, что Tableau так делать не умеет.

В нашей команде есть ребята, пишущие на Python. Поэтому мы решили в наших поисках двигаться в этом направлении и нашли TabPy.

TabPy — это веб-сервис, который позволяет внутри калькуляции в Tableau получать результат выполнения Python скриптов.

Как это работает:

  1. Tableau взаимодействует с TabPy и, в свою очередь, с Python при помощи так называемых Script Functions. Script Functions содержат в себе сам скрипт на языке Python, требуемый тип данных результата и аргументы, которые мы в эту функцию передаем. В нашем случае аргументами были идентификаторы “фруктов”, количество любителей которых мы хотели посчитать.
  2. TabPy преобразует полученный текст Script Functions в скрипт и отдаёт его интерпретатору. Подключение к базе CH прописывалось нами внутри скрипта.
  3. Далее TabPy возвращает обратно в Tableau результат выполненного скрипта.

image

В Script Functions аргументы всегда передаются в виде массивов, результат тоже возвращается массивом.

Не все сразу заработало. Главное, что мы поняли: писать Python скрипт прямо в вычисляемом поле в Tableau — не слишком хорошая идея. По двум причинам:

  1. Внутри Script Functions иногда сложно использовать привычный синтаксис Python. Например, не воспринимаются множественные кавычки.
  2. Подумав о будущей поддержке дашборда, мы поняли, что если нам потребуется как-то поменять скрипт, то каждый раз придется менять его в самой книжке Tableau. А это явно не оптимальный путь, поскольку мы всеми силами пытаемся избегать ручной поддержки дашбордов.

Поэтому использовали еще одну штуку — TabPy Client.

TabPy Client — это библиотека, которая позволяет публиковать питоновские скрипты на сервере TabPy и дальше вызывать их внутри Tableau. При ее использовании вместо того, чтобы писать скрипт внутри Tableau, мы вызываем лежащий на TabPy сервере файл .py с помощью прописанных в нем самом параметров, передаем в него аргументы и выполняем.

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

Для решения нашей конкретной задачи пришлось сделать следующее.
Сначала мы пробовали решить ее без использования TabPy Client. В таком варианте внутри Tableаu создавался Calculation field следующего вида:

IF FIRST()==0
THEN
SCRIPT_INT(«
from clickhouse_driver import Client
client = Client(host=host_name, database=database_name, user=user_name, password=password)

——script_text——

«, SUM([people]), ATTR([fruits_id]))
END

Работало, но были проблемы, которые описывались выше. Когда мы разобрались с TabPy Client, то поняли, что разделив Calculation field и сам скрипт, получается более удобная и правильная система. Так выглядели Calculation field и файл .py со скриптом:

Calculation field SCRIPT_INT(«
return tabpy.query(‘people_count_test’,_arg1, _arg2)[‘response’]
«, SUM([people]), ATTR([fruits_id]))
Файл .py from clickhouse_driver import Client
import tabpy_client
connection = tabpy_client.Client(‘http://localhost:9004/’)
def unique_people_count(people, fruits_id):
client = Client(host=host_name, database=database_name, user=user_name, password=password)

——script_text——

connection.deploy(‘people_count_test’, unique_people_count, ‘comment’, override = True)

Здесь видно, что ‘people_count_test’ — это идентификатор для TabPy Client, благодаря которому понятно какой скрипт выполнять в этом Calculation field.

И в итоге именно такой подход нас полностью устроил.

image

Итог

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

BI разработчики довольны, что можно работать с ClickHouse из Tableau, при этом не подключаясь к нему напрямую.

Наш Tableau Server доволен, что не нужно по ночам делать огромный экстракт.

В целом, TabPy даёт BI разработчикам больше свободы для работы с данными, когда из коробки Tableau не имеет подходящего решения. Например, чтобы встраивать data science модели прямо в Tableau, но это уже совсем другая история…

Статья написана совместно с моими коллегами Димитрием Щербенко (dima_vs) и Суховеевым Иваном (suho_v) R&D Dentsu Aegis Network Russia.


ссылка на оригинал статьи https://habr.com/ru/company/dentsuaegisnetworkrussia/blog/477864/

Вышел PHP 7.4! Как Badoo переходит на новую версию

Сегодня, наконец, опубликован релиз PHP 7.4!

Его новые фичи уже были многократно описаны, в том числе и на Хабре. Это стрелочные функции, типизированные свойства классов и ещё много всякого синтаксического сахара. Но больше всего мы ждали новый релиз из-за производительности: в версии 7.4 не только появился preload, но и сам PHP стал значительно быстрее.

Плохая (или хорошая?) новость — с выходом PHP 7.4 прекращается активная поддержка PHP 7.2. Его последний релиз запланирован на середину декабря. Мы давно проводим эксперименты с PHP 7.4, а недавно активно занялись переходом на него, так как сейчас мы на уже почти не поддерживаемой версии 7.2.

Поздравляю всех с долгожданным релизом! А ниже расскажу немного о том, как мы переходим на новую версию.

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

Если сильно упростить, то можно выделить несколько шагов:

  • Добиваемся того, что unit-тесты начинают успешно проходить на новой версии.
  • Делаем обязательными прогоны тестов на новой версии для всех изменений кода (чтобы не пришлось повторять пункт 1, так как новый код пишется постоянно, и он может быть снова несовместимым).
  • Переключаем на новую версию девел-площадку, чиним проблемы и живём какое-то время в таком состоянии.
  • Повторяем это для стейджинга.
  • Плавно выкладываем на разные кластеры продакшена.

Наши правки в репозитории PHP

Проблема с preload (фикс)

В этот раз в процессе кое-что изменилось: так как мы очень ждали preload, начали проводить часть работы еще в июле, во время версии 7.4.0beta1. В итоге это вылилось для нас в достаточно большое количество времени, потраченного на отладку, ведь PHP 7.4 тогда был совсем сырым. Но с другой стороны, в результате мы нашли неприятный баг, починили его и отправили фикс в апстрим, чем помогли всему сообществу.

Дальше настало время заняться тестами.

Проблема с доступом к приватным свойствам (фикс)

Для того, чтобы вообще прогнать тесты, нужно обновить PHPUnit, SoftMocks и PHP-Parser как их часть. У нас большая кодовая база, и даже для обновления PHPUnit потребовалось переписать огромное количество тестов.

После того, как нам удалось прогнать тесты, мы увидели очень странное. Было много падений со следующей ошибкой:

PHP Fatal error: Cannot access private property ClassLoader::$classMap in vendor/composer/ClassLoader.php

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

Проблема осложнялась тем, что воспроизводилась нестабильно. Долгий дебаг при помощи gdb показал, что действительно в EG(fake_scope) по каким-то причинам оказывается не тот класс, в рамках которого происходит обращение к свойству, а другой, не связанный с ним.

После того, как мы нашли минимальный репродьюс-кейс (который, на минуточку, требует наличия трёх классов, автолоадера и Reflection), починили причину проблемы и запушили исправление в апстрим, оказалось, что эта проблема существовала ещё со времён PHP 7.3 (скорее всего, после вот этого изменения), весь мир жил с ней год и никому до нас она не мешала.

Правим несовместимости кода Badoo

Сейчас мы правим все несовместимости нашего кода с PHP 7.4. Подавляющее большинство несовместимостей для нас (больше сотни мест, >80% от всех несовместимостей) было вызвано добавлением ошибки «Trying to access array offset on value of type null/bool/int» (соответствующий RFC). Она возникает при использовании синтаксиса обращения к элементу массива на других типах данных. 

Проблему хорошо показывает вот такой пример:

$a = false; var_dump($a[‘somekey’]);  // PHP 7.3:  // NULL //  // PHP 7.4: // Notice: Trying to access array offset on value of type bool in Command line code on line 1 // NULL

Навскидку кажется, что такого в реальном коде не должно встречаться, но, как показала практика, это достаточно частый случай: например, функция может возвращать массив в нормальном случае и false/null в случае ошибки, а дальше вверх по стеку информация о false/null теряется, и этот случай не обрабатывается отдельно. 

Это достаточно слабо распиаренное, но полезное изменение в PHP: оно позволяет найти много потенциальных ошибок в коде.

Второе по количеству доставленных проблем обновление — это изменение в работе method_exists(). Кстати, в настоящий момент информации о нём нет в release notes или upgrading guide. Суть его заключается в следующем:

 class A1 {      private function priv() {}  }   class B1 extends A1 {}   var_dump(method_exists(B1::class, 'priv'));  // PHP 7.3: bool(true) // PHP 7.4: bool(false)

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

Конечно, мы в разной степени сталкиваемся и с другими несовместимостями, в том числе с многочисленными изменениями, связанными с рефлексией (пример один, пример два), с изменениями в hexdec() и подобных, запретом array_key_exists() даже для ArrayAccess-объектов, с несовместимостями в различных бибилотеках зависимостей, подключаемых через Composer, и даже со всякими экзотическими штуками вроде ставшим обязательным stream_set_option() для stream wrapper’ов при include’ах. Но в сумме затраты на адаптацию ко всем этим изменениям не сравнятся со случаем использования синтаксиса массивов на не-массивах.

В настоящий момент мы закончили работу с юнит-тестами: они полностью проходят на PHP 7.4. Ведём работу над API-тестами и до конца года планируем начать переключение различных кластеров и окружений.

Этой краткой заметкой хочу пригласить к обсуждению: пробовали ли вы уже PHP 7.4? Если да, то каким был ваш опыт? Собираетесь ли переходить?


ссылка на оригинал статьи https://habr.com/ru/company/badoo/blog/477822/