В данной ситуации, вопрос в том, что при uri http://abc.com/foo/abc.jpg и http://abc.com/foo/abc.webp — есть явное указание, что это разные ресурсы, а в случае с http://abc.com/foo/abc без обработки заголовка accept — это один и тот же ресурс.
Это может выйти боком не только в SEO, но и даже при банальном использовании стандартного механизма кеширования, например в том же nginx согласно документации proxy_cache_key строка;
Умолчание: proxy_cache_key $scheme$proxy_host$request_uri;
.....
и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемы
Список адресов картинок отдается часто. Если соблюдать правила хорошего тона «один URL однозначно определяет один ресурс», то расширение у image должно быть и тогда это проблема.
Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp
Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет
Я про то, что на практике, описанные методологии больше заточены под повышение КПД конкретной рабочей единицы в проекте, под возможность более гибкой манипуляцией проектом, но мало заточены под качество кода.
Все основные методологии повышения качества кода, были придуманы задолго до scrum-а и прочего. В том числе и методология коротких итераций в разработке.
Отсюда я делаю вывод, что scrum/agile больше всего преследуют коммерческие интересы конкретной группы лиц в проекте.
И заметьте, я нигде не говорю, что это плохо. Я вообще не сторонник «черно-белой парадигмы». Но то, что эта группа лиц частенько использует эти возможности в целях «замыливания» или скрытия истинного положения дел в проекте — это факт. Отсюда возникают такие публикации как эта.
Я с большим удовольствием прочитал обсуждение, все таки это правильно, иногда всколыхнуть болото-трясину.
На ум пришла одна аналогия, объясняющая как мне кажется, причины таких бурных споров. Вот возьмем большое производство. Там обязательно есть НИОКР (в том или ином виде), назовем его отделом «перспективных исследований», есть конвейер где монотонно согласно строгому ТЗ собирается из деталей готовый продукт, есть худо-бедно собственное производство таких деталей, где ТЗ меняются, редко но всеж меняются.
В отделе «перспективных и не очень» исследований большая свобода, есть время поизучать и поставить эксперименты.
В отделе производства деталей работают высококлассные токари и мастера инструментальщики, которые могут сами придумать (или технолог поможет) и изготовить оправку/приблуду для сборки изделия на конвейере, могут выточить нужные детали с точностью, большей чем можно купить у поставщика.
На конвейере… ну кароче обычные «галеры» этот конвейер.
Вот в случае с программированием, во всех этих отделах, работает как правило один и тот же человек. Отсюда такие разнополярные мнения и возникают.
Я перефразирую, пришел человек который был заинтересован в повышении качества кода (как минимум). scrum то причем? парное программирование и кодревью известны и употребляются повсеместно года этак с 2002..03-го
Стандарты все же есть, для каждой области свои, но так или иначе есть. Для ракеты пво одни, для космоса другое, для томографа третье, для веба четвертое, для банка пятое.
А вот архитектура, вот ее «хорошесть» — определяется более просто, Архитектура — это субстанция, которая завязана на «бизнес-процессы», которые в свою очередь могут очень быстро меняться, а могут годами быть жестко регламентированными (например законодательством). Поэтому, я считаю, что «хорошая архитектура», это прежде всего та, которая построена на хорошем и глубоком анализе бизнес-процессов.
Помните «метод бумажных карточек ограниченного размера»? Помните «сформулируйте, свои пожелания короткими предложениями не больше 5 слов?» Нудно долго итеративно…
А сейчас ведь как модно, быстро пара совещаний, копи-пасте с другого проекта, 2..3 «фреймоворка-на-слуху» на выбор… коммерческое предложение и вперед шашки наголо, пока бизнес не передумал.
Я думаю, что фраза «делать все сразу правильно» подразумевает прежде всего «давайте сразу не делать все неправильно». Если стандарты качества будут постоянно понижаться, в скором будущем они выродятся во что угодно, но не в качество.
А agile тут мог навлечь на себя гнев автора по причине того, что его основные концепции некоторые товарищи используют как проститутку, в угоду своим корыстным целям и/или непрофессионализму.
http://abc.com/foo/abc.jpgиhttp://abc.com/foo/abc.webp— есть явное указание, что это разные ресурсы, а в случае сhttp://abc.com/foo/abcбез обработки заголовка accept — это один и тот же ресурс.Это может выйти боком не только в SEO, но и даже при банальном использовании стандартного механизма кеширования, например в том же nginx согласно документации
proxy_cache_key строка;
Умолчание: proxy_cache_key $scheme$proxy_host$request_uri;
.....
и если забыть переопределить такой ключ, можно получить кучу веселых часов в поисках проблемы
Так что, все равно придется в сессию писать признак для webp.
В 40е...70е года расцвет был любительской связи на КВ частотах (qsl в частности), это ввело в обычный язык много сленга https://ru.m.wikipedia.org/wiki/Радиожаргон
Если грубо то да. На деле у нас свой cdn которому можно сказать "дай картинку с шириной 200", или дай jpg вместо этого png. И куча слоев кешерования, так как больше 50% медиа — это сгенеренные картинки на базе 2...3..4 других. И вот сейчас можно сказать cdn-у "а дай ка братец мне вот такой webp!".
Ну и ессно выходной html поток пока что фильтруется подменой .jpg на .webp если в accept у клиента указана поддержка webp
Устарел не устарел, но результаты перехода на webp впечатляют. Вот буквально вчера допилили сервер который на лету трансформирует jpg в webp, сегодня грубую оценку проводили на стенде с копией прода. Минимум!!! -25%, а в среднем под 30..35% уменьшение трафика, плюс оптимизация хром-движка под декодинг webp впечатляет
"Господи! Спасибо тебе, что взял деньгами!"
Все основные методологии повышения качества кода, были придуманы задолго до scrum-а и прочего. В том числе и методология коротких итераций в разработке.
Отсюда я делаю вывод, что scrum/agile больше всего преследуют коммерческие интересы конкретной группы лиц в проекте.
И заметьте, я нигде не говорю, что это плохо. Я вообще не сторонник «черно-белой парадигмы». Но то, что эта группа лиц частенько использует эти возможности в целях «замыливания» или скрытия истинного положения дел в проекте — это факт. Отсюда возникают такие публикации как эта.
На ум пришла одна аналогия, объясняющая как мне кажется, причины таких бурных споров. Вот возьмем большое производство. Там обязательно есть НИОКР (в том или ином виде), назовем его отделом «перспективных исследований», есть конвейер где монотонно согласно строгому ТЗ собирается из деталей готовый продукт, есть худо-бедно собственное производство таких деталей, где ТЗ меняются, редко но всеж меняются.
В отделе «перспективных и не очень» исследований большая свобода, есть время поизучать и поставить эксперименты.
В отделе производства деталей работают высококлассные токари и мастера инструментальщики, которые могут сами придумать (или технолог поможет) и изготовить оправку/приблуду для сборки изделия на конвейере, могут выточить нужные детали с точностью, большей чем можно купить у поставщика.
На конвейере… ну кароче обычные «галеры» этот конвейер.
Вот в случае с программированием, во всех этих отделах, работает как правило один и тот же человек. Отсюда такие разнополярные мнения и возникают.
зы: в первом отделе подписку не давали? :)
А вот архитектура, вот ее «хорошесть» — определяется более просто, Архитектура — это субстанция, которая завязана на «бизнес-процессы», которые в свою очередь могут очень быстро меняться, а могут годами быть жестко регламентированными (например законодательством). Поэтому, я считаю, что «хорошая архитектура», это прежде всего та, которая построена на хорошем и глубоком анализе бизнес-процессов.
Помните «метод бумажных карточек ограниченного размера»? Помните «сформулируйте, свои пожелания короткими предложениями не больше 5 слов?» Нудно долго итеративно…
А сейчас ведь как модно, быстро пара совещаний, копи-пасте с другого проекта, 2..3 «фреймоворка-на-слуху» на выбор… коммерческое предложение и вперед шашки наголо, пока бизнес не передумал.
А agile тут мог навлечь на себя гнев автора по причине того, что его основные концепции некоторые товарищи используют как проститутку, в угоду своим корыстным целям и/или непрофессионализму.
Code review это никак не часть agile