Pull to refresh
90
Karma
0
Rating
Андрей Прокопюк @Andre_487

Пользователь

Можно ли быть немножко беременным, или Российское проклятье Open Source

Тут смущает вот эта формулировка:


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

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

Можно ли быть немножко беременным, или Российское проклятье Open Source

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


Есть ли прецеденты, когда кто-то судился за несоблюдения этих лицензий?

Обман обманщиков: форк-бомба нового уровня

Это очень удобно, кстати. Особенно для скриптов, устанавливающих в систему ноду ботнета, например. Будет бекапиться каждую ночь и восстановится если какой-то шутник вдруг пришлёт очередной rm -rf /*

Обман обманщиков: форк-бомба нового уровня

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


Вот так правильно:


sudo wget xxx && sudo chmod 777 xxx && sudo ./xxx

Но на этом проблемы могут не закончиться. Бывает ведь что при подключении к хосту выскакивает надоедливая ошибка про невалидный TLS сертификат. Поэтому совсем надёжным будет такой способ запуска программы установки:


sudo wget --no-check-certificate xxx && sudo chmod 777 xxx && sudo ./xxx

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

Обман обманщиков: форк-бомба нового уровня

Я вот только после этой статьи узнал, что есть такой формат


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


Надо подумать, можно ли как-то пошутить над теми, кто раскодирует онлайн…

Работа распределённой команды в условиях самоизоляции: как мы почти не заметили разницы

Тут есть несколько моментов. Возможно, каждому дома удобно, но вот всей команде вместе может быть не так удобно от того, что все дома, и работа замедляется. Есть люди, которые действительно страдают без офиса. Да, среди работников IT есть экстраверты.


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


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

Системный подход к скорости: онлайн-измерения на фронтенде

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


Для критерия Манна-Уитни используем функцию mannwhitneyu из scipy, никак её не кастомизируем.

Системный подход к скорости: онлайн-измерения на фронтенде

Спасибо!


По поводу шрифтов – интересный вопрос. Могу сказать, что first contentful paint точно не ожидает появления шрифта и считается временем, когда отрисовалось что-либо кроме белой страницы или цвета фона.


А вот по поводу наших приближений TTFMP – скажу честно, пока не проверяли.

Сохранение JS и CSS ресурсов в Локальном хранилище браузера

К сожалению не так всё хорошо ) Процент медленных запросов на мобильных сетях не превосходит 10%, но достаточно близок. Это примерно и есть доля Бабули.


Учитывая наш опыт, я бы всё-таки рекомендовал попробовать вместо кэширования в LS сжатие в brotli и вечное кэширование в HTTP-кэше для преодоления проблем сети:


Cache-Control: max-age=315360000, public, immutable

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


Статистику о типе навигации можно собрать через Navigation Timing API, свойство performance.navigation.type.

Сохранение JS и CSS ресурсов в Локальном хранилище браузера

Мы в Поиске Яндекса тоже когда-то давно догадались до оптимизации путём складывания статики в LocalStorage.


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


Так вот, внедрили кэширование в LS, увидели драматическое уменьшение размера HTML, не смогли увидеть ухудшение в DevTools – обрадовались и стали использовать.


Шли годы, скорость обрастала аналитикой и прочим А/Б тестированием, и в голову пришла идея перепроверить – примерно на двухтысячном тикете про баги в фиче, где не оттестировали сценарий, когда статика берётся из кэша. Дело близилось к середине 2017, на тот момент мы уже умели получать со всей аудитории скоростной фидбек в виде метрик. У нас были:


  • все стандартные метрики Navigation Timing API
  • время отрисовки шапки (страница отдаётся чанками, и шапка приходит сильно раньше выдачи)
  • начало парсинга выдачи
  • окончание инициализации клиентского фреймворка
  • разработанные другими командами метрики поведения пользователя на странице

Провели А/Б эксперимент и увидели:


  • +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 для сжатия, скрипты не должны блокировать отрисовку, не нужно сушить кошку в микроволновке. Но в остальном – нужно измерять скорость на реальных пользователях своего сервиса, считать статистику и полагаться на эксперименты. Сервисы разные, пользователи разные – оптимизации подходят разные.

Сохранение JS и CSS ресурсов в Локальном хранилище браузера

Там почему-то неправильные данные. Указано, что Chrome не поддерживает, но это не так. Можно убедиться на практике – попробовать отдать этот заголовок на каком-то ресурсе и попробовать нажать Ctrl+R – если он в кэше, и кэш ещё валиден – ресурс не будет скачан.

Сохранение JS и CSS ресурсов в Локальном хранилище браузера

Уже вполне неплохая. Chromium поддерживает, так же как и Safari. Так что уже можно – мы пользуемся, например

Runtyper — инструмент для проверки типов при выполнении JavaScript кода

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

Бывший разработчик Firefox: удалите сторонние антивирусы

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

Вышел ReactOS 0.4.3 под кодовым именем «Haters gonna hate»

Никак не проверяете, что вирусов действительно нет?

Выбираем состав изоморфных React-приложений на следующие 12 месяцев

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

В тёплые LAMP'овые времена в проектах не было такого количества мелких зависимостей – всё писалось самостоятельно.

Тонкости благополучного git-merge

Отвечает ggray:
мне кажется что рекурсивная стратегия никак не связана с решениме конфликтов при ребейзе, а автору я бы посоветововал включить rerere если у него часто такие кейсы возникают :)

Вернется ли Павел Дуров в Россию и каким его видят западные СМИ

Ну не просто же так он был упомянут. Вряд ли на IT-ресурсе напишут «Иосиф Кобзон не считает Telegram безопасным. Зачем мы это написали? Да так просто». Если человек упоминается в контексте, значит, его мнение считается значимым для темы.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity