Вот кстати возможно тут мне подскажут ответ на давно мучающий меня вопрос. Какой юридический статус у GPL в России? Как и у других распространённых лицензий опенсорса
Есть ли прецеденты, когда кто-то судился за несоблюдения этих лицензий?
Это очень удобно, кстати. Особенно для скриптов, устанавливающих в систему ноду ботнета, например. Будет бекапиться каждую ночь и восстановится если какой-то шутник вдруг пришлёт очередной rm -rf /*
Так конечно же тоже не сработает. Это же wget, он не передаёт файл в пайп, а сохраняет на диск. При этом текущий каталог может быть запрещён для записи, а сохранённый файл не будет иметь правильных атрибутов для запуска
Вот так правильно:
sudo wget xxx && sudo chmod 777 xxx && sudo ./xxx
Но на этом проблемы могут не закончиться. Бывает ведь что при подключении к хосту выскакивает надоедливая ошибка про невалидный TLS сертификат. Поэтому совсем надёжным будет такой способ запуска программы установки:
Нам некогда тратить время на глупости вроде изучения контента скриптов или исследование проблем с TLS, поэтому нужно заранее учесть все возможные проблемы
Я вот только после этой статьи узнал, что есть такой формат
Кстати исследовать команду пробовал, но лениво. Я обычно догадываюсь, что обманка может быть с двойным дном и обычно не запускаю ничего на полезных машинах. Вот сейчас попробовал раскодировать в онлайн-декодере. Но UUE оказался невалидный, и я решил читать статью дальше :)
Надо подумать, можно ли как-то пошутить над теми, кто раскодирует онлайн…
Тут есть несколько моментов. Возможно, каждому дома удобно, но вот всей команде вместе может быть не так удобно от того, что все дома, и работа замедляется. Есть люди, которые действительно страдают без офиса. Да, среди работников IT есть экстраверты.
И есть класс людей, у которых дома условий нет. Например, там постоянно бегают дети или там родители, например, просят вынести мусор, а не играться в компьютер.
Так что есть аудитория, которой важен опыт успешной организации как личной работы, так и работы со стороны команды. Особенно большой команды.
По поводу шрифтов – интересный вопрос. Могу сказать, что first contentful paint точно не ожидает появления шрифта и считается временем, когда отрисовалось что-либо кроме белой страницы или цвета фона.
А вот по поводу наших приближений TTFMP – скажу честно, пока не проверяли.
К сожалению не так всё хорошо ) Процент медленных запросов на мобильных сетях не превосходит 10%, но достаточно близок. Это примерно и есть доля Бабули.
Учитывая наш опыт, я бы всё-таки рекомендовал попробовать вместо кэширования в LS сжатие в brotli и вечное кэширование в HTTP-кэше для преодоления проблем сети:
В этом случае получится файл меньшего размера, и браузер ни при каких обстоятельствах не будет ходить за 304-м ответом. Остался какой-то процент не поддерживающих immutable, но это может быть проблемой только если высок процент навигаций через refresh.
Статистику о типе навигации можно собрать через Navigation Timing API, свойство performance.navigation.type.
Мы в Поиске Яндекса тоже когда-то давно догадались до оптимизации путём складывания статики в LocalStorage.
Для нас это было более актуально, так как мы много инлайним в страницу. Не от хорошей жизни – вариативность страницы большая, и HTTP-кэш практически не работает на кусках статики, которые нужны множеству уникальных блоков.
Так вот, внедрили кэширование в LS, увидели драматическое уменьшение размера HTML, не смогли увидеть ухудшение в DevTools – обрадовались и стали использовать.
Шли годы, скорость обрастала аналитикой и прочим А/Б тестированием, и в голову пришла идея перепроверить – примерно на двухтысячном тикете про баги в фиче, где не оттестировали сценарий, когда статика берётся из кэша. Дело близилось к середине 2017, на тот момент мы уже умели получать со всей аудитории скоростной фидбек в виде метрик. У нас были:
время отрисовки шапки (страница отдаётся чанками, и шапка приходит сильно раньше выдачи)
начало парсинга выдачи
окончание инициализации клиентского фреймворка
разработанные другими командами метрики поведения пользователя на странице
Провели А/Б эксперимент и увидели:
+12% времени скачивания HTML – логично, мы же начали передавать по сети то, что раньше не передавали;
-3% времени до отрисовки шапки – уже не так логично – мы же оптимизацию отключаем;
-1% времи до начала парсинга выдачи, и примерно на столько же – времени до инициализации клиентского фреймворка;
уменьшилось время до первого клика по выдаче, что косвенно говорит о том, что выдача раньше отрисовывается и становится доступной пользователю для взаимодействия; позже у нас появились более конкретные метрики на эту тему, но тогда не было.
После этого кэширование в LS благополучно отключили, а после удаления машинерии по управлению этим кэшированием и множества noscript на случай отключенного JS, увидели на потоке ещё большее ускорение.
И про ServiceWorker мне есть что рассказать. Как-то раз мы решили его попробовать, и начать не сразу с места в карьер, а с умом и пошагово – сперва снять показания с самой лёгкой вариации. Добавили sw.js, который ничего не умел, кроме как устанавливаться и навешивать пустой обработчик на событие fetch.
И снова поймали замедление. Сотни миллисекунд по всем метрикам, начиная со времени до первого байта. Так что для кэширования я бы рекомендовал SW только после серьёзного исследования – иначе есть риск сделать всё не правильно, а совсем наоборот. Если попадание в HTTP-кэш хорошее (у нас 80–90%) – будет точно медленнее.
Если это SPA, где не так важны сотни миллисекунд загрузки оболочки, зато важен оффлайн – вопрос совершенно обратный, тут оно стоит того и используется именно для того, для чего задумывалось.
В итоге сейчас мы пришли к следующей схеме:
весь CSS инлайновый – так быстрее рисуется; даже если стили в дисковом кэше – так быстрее; даже не пытаемся кэшировать это в браузерных хранилищах – всё равно так останется быстрее;
jQuery (да, у нас всё ещё jQuery) и бандл с фреймворком i-bem и общими сущностями загружаются внешними скриптами – с хитрыми префетчами для прокачки кэша;
скрипты асинхронны (defer) и расположены в первом чанке HTTP-ответа для WebKit, в остальных – синхронные с предзагрузкой с помощью link[rel=preload] из первого чанка (отключено для FF – там пока баги с preload); это связано с разными нюансами работы разных движков с синхронными и асинхронными скриптами;
вычисляем медленные запросы и отправляем на лёгкую версию – там в плане схемы со статикой всё то же самое, но функциональность сильно беднее, и вёрстка сильно хитрее свёрстана – всё с целью уменьшения размера; про это даже есть отдельный пост.
Можно заметить, что это сильно отличается от рекомендуемого в постах "Как по-быстрому оптимизировать фронденд". И так же как рекомендации из этих постов строго не рекомендуется к применению бездумно.
Есть, конечно, очевидные вещи, которые можно внедрять не размышляя: вечное кэширование всего, что можно, gzip/brotli для сжатия, скрипты не должны блокировать отрисовку, не нужно сушить кошку в микроволновке. Но в остальном – нужно измерять скорость на реальных пользователях своего сервиса, считать статистику и полагаться на эксперименты. Сервисы разные, пользователи разные – оптимизации подходят разные.
Там почему-то неправильные данные. Указано, что Chrome не поддерживает, но это не так. Можно убедиться на практике – попробовать отдать этот заголовок на каком-то ресурсе и попробовать нажать Ctrl+R – если он в кэше, и кэш ещё валиден – ресурс не будет скачан.
Вряд ли это решение подойдёт для давно разрабатываемого проекта или для разработки в команде, где пишут только на чистом JS. А это не такой уж вырожденный случай, я вот так и работаю, например, как и многие фрондендеры в крупных компаниях.
Скорее это идеология npm – если это есть в репозитории – не пиши заново. Все модули маленькие и выполняют единственную задачу. В какой-то мере опасно, но удобно и быстро.
В тёплые LAMP'овые времена в проектах не было такого количества мелких зависимостей – всё писалось самостоятельно.
мне кажется что рекурсивная стратегия никак не связана с решениме конфликтов при ребейзе, а автору я бы посоветововал включить rerere если у него часто такие кейсы возникают :)
Ну не просто же так он был упомянут. Вряд ли на IT-ресурсе напишут «Иосиф Кобзон не считает Telegram безопасным. Зачем мы это написали? Да так просто». Если человек упоминается в контексте, значит, его мнение считается значимым для темы.
Тут смущает вот эта формулировка:
Кажется что речь скорее про музыку, видео и книги. Или я ошибаюсь?
Вот кстати возможно тут мне подскажут ответ на давно мучающий меня вопрос. Какой юридический статус у GPL в России? Как и у других распространённых лицензий опенсорса
Есть ли прецеденты, когда кто-то судился за несоблюдения этих лицензий?
Это очень удобно, кстати. Особенно для скриптов, устанавливающих в систему ноду ботнета, например. Будет бекапиться каждую ночь и восстановится если какой-то шутник вдруг пришлёт очередной
rm -rf /*Так конечно же тоже не сработает. Это же wget, он не передаёт файл в пайп, а сохраняет на диск. При этом текущий каталог может быть запрещён для записи, а сохранённый файл не будет иметь правильных атрибутов для запуска
Вот так правильно:
Но на этом проблемы могут не закончиться. Бывает ведь что при подключении к хосту выскакивает надоедливая ошибка про невалидный TLS сертификат. Поэтому совсем надёжным будет такой способ запуска программы установки:
Нам некогда тратить время на глупости вроде изучения контента скриптов или исследование проблем с TLS, поэтому нужно заранее учесть все возможные проблемы
Я вот только после этой статьи узнал, что есть такой формат
Кстати исследовать команду пробовал, но лениво. Я обычно догадываюсь, что обманка может быть с двойным дном и обычно не запускаю ничего на полезных машинах. Вот сейчас попробовал раскодировать в онлайн-декодере. Но UUE оказался невалидный, и я решил читать статью дальше :)
Надо подумать, можно ли как-то пошутить над теми, кто раскодирует онлайн…
Тут есть несколько моментов. Возможно, каждому дома удобно, но вот всей команде вместе может быть не так удобно от того, что все дома, и работа замедляется. Есть люди, которые действительно страдают без офиса. Да, среди работников IT есть экстраверты.
И есть класс людей, у которых дома условий нет. Например, там постоянно бегают дети или там родители, например, просят вынести мусор, а не играться в компьютер.
Так что есть аудитория, которой важен опыт успешной организации как личной работы, так и работы со стороны команды. Особенно большой команды.
Скользящая средняя в мониторингах выбирается небольшая, в пределах часов, чтобы можно было оперативно отреагировать на проблему.
Для критерия Манна-Уитни используем функцию
mannwhitneyuизscipy, никак её не кастомизируем.Спасибо!
По поводу шрифтов – интересный вопрос. Могу сказать, что first contentful paint точно не ожидает появления шрифта и считается временем, когда отрисовалось что-либо кроме белой страницы или цвета фона.
А вот по поводу наших приближений TTFMP – скажу честно, пока не проверяли.
К сожалению не так всё хорошо ) Процент медленных запросов на мобильных сетях не превосходит 10%, но достаточно близок. Это примерно и есть доля Бабули.
Учитывая наш опыт, я бы всё-таки рекомендовал попробовать вместо кэширования в LS сжатие в brotli и вечное кэширование в HTTP-кэше для преодоления проблем сети:
В этом случае получится файл меньшего размера, и браузер ни при каких обстоятельствах не будет ходить за 304-м ответом. Остался какой-то процент не поддерживающих immutable, но это может быть проблемой только если высок процент навигаций через refresh.
Статистику о типе навигации можно собрать через Navigation Timing API, свойство
performance.navigation.type.Мы в Поиске Яндекса тоже когда-то давно догадались до оптимизации путём складывания статики в LocalStorage.
Для нас это было более актуально, так как мы много инлайним в страницу. Не от хорошей жизни – вариативность страницы большая, и HTTP-кэш практически не работает на кусках статики, которые нужны множеству уникальных блоков.
Так вот, внедрили кэширование в LS, увидели драматическое уменьшение размера HTML, не смогли увидеть ухудшение в DevTools – обрадовались и стали использовать.
Шли годы, скорость обрастала аналитикой и прочим А/Б тестированием, и в голову пришла идея перепроверить – примерно на двухтысячном тикете про баги в фиче, где не оттестировали сценарий, когда статика берётся из кэша. Дело близилось к середине 2017, на тот момент мы уже умели получать со всей аудитории скоростной фидбек в виде метрик. У нас были:
Провели А/Б эксперимент и увидели:
После этого кэширование в LS благополучно отключили, а после удаления машинерии по управлению этим кэшированием и множества noscript на случай отключенного JS, увидели на потоке ещё большее ускорение.
И про ServiceWorker мне есть что рассказать. Как-то раз мы решили его попробовать, и начать не сразу с места в карьер, а с умом и пошагово – сперва снять показания с самой лёгкой вариации. Добавили sw.js, который ничего не умел, кроме как устанавливаться и навешивать пустой обработчик на событие fetch.
И снова поймали замедление. Сотни миллисекунд по всем метрикам, начиная со времени до первого байта. Так что для кэширования я бы рекомендовал SW только после серьёзного исследования – иначе есть риск сделать всё не правильно, а совсем наоборот. Если попадание в HTTP-кэш хорошее (у нас 80–90%) – будет точно медленнее.
Если это SPA, где не так важны сотни миллисекунд загрузки оболочки, зато важен оффлайн – вопрос совершенно обратный, тут оно стоит того и используется именно для того, для чего задумывалось.
В итоге сейчас мы пришли к следующей схеме:
Можно заметить, что это сильно отличается от рекомендуемого в постах "Как по-быстрому оптимизировать фронденд". И так же как рекомендации из этих постов строго не рекомендуется к применению бездумно.
Есть, конечно, очевидные вещи, которые можно внедрять не размышляя: вечное кэширование всего, что можно, gzip/brotli для сжатия, скрипты не должны блокировать отрисовку, не нужно сушить кошку в микроволновке. Но в остальном – нужно измерять скорость на реальных пользователях своего сервиса, считать статистику и полагаться на эксперименты. Сервисы разные, пользователи разные – оптимизации подходят разные.
Там почему-то неправильные данные. Указано, что Chrome не поддерживает, но это не так. Можно убедиться на практике – попробовать отдать этот заголовок на каком-то ресурсе и попробовать нажать Ctrl+R – если он в кэше, и кэш ещё валиден – ресурс не будет скачан.
Уже вполне неплохая. Chromium поддерживает, так же как и Safari. Так что уже можно – мы пользуемся, например
Вряд ли это решение подойдёт для давно разрабатываемого проекта или для разработки в команде, где пишут только на чистом JS. А это не такой уж вырожденный случай, я вот так и работаю, например, как и многие фрондендеры в крупных компаниях.
Никак не проверяете, что вирусов действительно нет?
{extends: 'eslint:recommended'}=)В тёплые LAMP'овые времена в проектах не было такого количества мелких зависимостей – всё писалось самостоятельно.