Вы когда-нибудь открывали в старом дизайне Хабра пост с большим числом комментариев? Страничка даже с тысячей сообщений грузится шустро, на ней без серьёзных задержек работает форма для ответа, кнопки голосования и закладок. Но когда мы начали переход на новую версию Хабра, стало понятно, что добиться такой же скорости будет непросто.
То есть вы их не ускоряли. Они и так работали быстро, без задержек и без проблем. Потому вы все это сломали, а потом героически боролись с проблемами, которые сами себе создали. И, судя по комментариям к этой статье, поломали и до сих пор не починили базовый функционал.
Этому есть несколько причин. Во-первых, Хабр стал одностраничным приложением (SPA, Single Page Application) на Vue, то есть теперь переходы между страницами рисуются на клиенте с помощью JS вместо классического серверного рендеринга (Server-Side Rendering, SSR).
...
серверный рендеринг — операция дорогая.
авигация по сайту в режиме SPA (без перезагрузки страницы) оставляла желать лучшего. Если у вас медленный смартфон, то вы имели шанс вообще не увидеть комментарии: память кончалась быстрее, чем успевали отработать скрипты и рендеринг.
Ну то есть когда оно было в SSR в старой версии, все работало густро, без задержек и т.п. Придумали себе «модномолодежно» Vue, и перестало работать всё. Почему вы этим гордитесь и еще целые статьи выкатываете про это?
Наша задача подразумевала максимальные улучшения ценой минимальных усилий.
...
Чтобы создать ощущение, что комментарии рисуются быстрее, с определённого порога нужно переключаться на исключительно серверный рендеринг.
всю разметку с сервера необходимо «гидрировать» на клиенте, иными словами ... ленивая гидрация
Предотвращение избыточной перерисовки
Ленивый рендеринг
[только для Хрома] Content Visibility
стриминг-рендеринг... проблему мы решили путём долгого и скрупулёзного изучения исходников Vue... Внедрение стриминг-рендера для комментариев не прошло безболезненно..
Странное у вас понимание «минимальных усилий» для того, чтобы оно хоть как-то было похоже по работе на то, что у вас уже было.
Поэтому при переходе на новую версию сайта было важно сделать работу с комментами не хуже, чем было.
В итоге:
счечик не работает
открытые в нескольих табах страницы не грузят контент
accessibility сломан
используются экспериментальные фичи, которые работают только в хроме, на остальных пользователей насрать
я надеюсь где-нибудь есть хорошая методичка по логике что-бы я мог просто кидать на неё ссылку
Да, было бы хорошо такую найти. Мне она не нужна, правда. А вот тебе вполне понадобится.
качество этого кода находится на одном уровне и количество ошибок тоже, но безопасность использования открытого кода при том же количестве ошибок выше, по одной простой причине: возможность поиска ошибок, скорость их исправления, качество аудита и многое другое больше не утыкается в потолок возможностей фирмы разработавшей ПО( а практика показывает что такие фирмы иногда вообще исчезают вместе с исходными кодами) и при желании\необходимости может быть повышено.
Повторю в последний раз: реальность, а не твои хотелки и слепая вера в мифы, говорит о том, что вся эта фраза ложна. Это — факт. Можно много разглагольствовать, рассказывать о каких-то мифических возможностях, но факт остается фактом — софт с открытым исходным кодом ничем не лучше и не хуже кода с закрытым исходным кодом. Качество кода одинаковое. Количество ошибок одинаковое. Скорость исправления ошибок одинаковая. Опасность и серьезность ошибок одинаковая.
Понятно, что немного упрощено. Что в каких-то единичных случаях наличие исходных кодов может помочь с чем-то там. Что не отменяет всей картины в целом. Вплоть до того, что опенсорс в своей массе не несет репутационных потерь, и срать хотел, например, на исправления ошибок (примеры — сплошь и рядом).
Возвращаясь конкретно к описываемому в посте софту. Закрыт он, или открыт — в случае с российским государством это не имеет никакого значения. Потому что государственный софт в Росси делается не для заявленных софтом целей. Будь там открытый код, авторы кода так же плевать хотели бы на ваши хотелки, закрывали бы API и доступ к данным и прочая и прочая и прочая. И все — абсолютно в рамках опенсорса.
но главный вопрос который волнует лично меня это: стало ли вам ясно что позволение сделать что-то сразу, согласно логике не приводит к тому что это что-то будет сделано сразу?
Это — бессмысленное словоблудие.
аналогию про проприетарный водопровод сами придумывайте,
Любые доказательства по аналогии ложны, поэтому придумывать какой-то бред про какие-то водопроводы не собираюсь.
Ээээ. В том-то и дело, что это не факты, а что ни на есть самые настоящие мифы. Сравнительные исследования качества софта уже проводились. Опенсорс ни по каким параметрам не лучше (и не хуже) клозедсорса.
Но я понимаю, что если «факты» не соотносятся с реальностью, тем хуже для реальности, ага
Вы продолжаете разговаривать о каких-то мифических возможностях из области чистой теории.
На практике и в реальности качество кода и продуктов у опенсорса и «клозедсорса» одинаковое. То есть и количество багов, и количество проблем, и прочее и прочее и прочее.
Все остальное — демагогия, к реальности не имеющая отношения
Количество ошибок в опенсорсе/СПО не меньше и не больше, чем в закрытом софте. Так что «позволяет» или «повзоляет сразу» — это миф, граничащий с ложью
«возможности контроля» — это вариант мифа про «миллионы глаз». Нет там возможностей контроля, если только не считать какие-нибудь совсем простые проекты, в которых может разобраться даже Вася Пупкин с двумя классами образования. Могу просто повторить еще раз: для грамотного аудита того же OpenSSL нужны специалисты, которых можно пересчитать по пальцам на руках. Это — большие возможности для контроля? «Позволяют сразу найти»? Рассказывайте эти сказки на LOR'е.
Программисты со стажем видят такие ошибки мгновенно.
Ну да. Простейшие типа конкатенации строк в sql-запросе. И при этом они остаются в top-10 OWASP из года в год. Как-то не помогают «программисты со стажем».
А опенсорс повышает вероятность, что её найдут
Не повышает. Миф о «миллионе глаз» всего лишь миф.
фраза: «Открытые исходники позволяют сразу найти серьёзные ошибки» не является ложной
Большой толковый словарь:
СРАЗУ, нареч.
В один приём; одним разом.
В тот же момент; немедленно.
Рядом, в непосредственной близости от чего-л.
Какое значение ни бери, фраза ложная.
в дальнейшем стоит перейти к обсуждению тезиса: открытое ПО даёт обществу больше возможностей контроля качества. а именно контроль и возможности в данном случае важны.
Не дает. Качество зарытого и открытого ПО примерно одинаковое, исследования уже проводились.
Демагогия — это «вот как только узнали, сразу закрыли».
Весь изначальный тезис про «сразу находить ошибки» и большинство мифов типа «миллионы глаз» говорят об одном и том же: открытый код позволяет находить ошибки быстро и вообще лучше закрытого кода именно потому что ошибки находятся сразу миллионами глаз (и прочие вариации на эту тему).
Это — ложь. Серьезные ошибки существуют в опенсорсе годами. То, что про них не знает значительная часть опенсорса до тех пор, пока что-нибудь типа heartbleed'а не становится достоянием общественности, — это слабое утешение.
Но, в отличие от проприетарщины, монополист не помешает сделать патч.
В отличие от проприетарщины опенсорс не несет репутационных потерь и патч может быть легко не принят. Или просто не найдутся люди, вообще способные решить проблему (в частности, для полного аудита OpenSSL нужны специалисты, которые стоят невменяемых денег и которых можно пересчитать чуть ли не по пальцам одной руки. Неудивительно, что в итоге аудит спонсируется теми самыми «монополистами»).
И вообще, весь разговор про опенсорс обычно упирается в один и тот же миф: опенсорс лучше потому что он опенсорс. Хотя уже есть далеко не одно исследование, что опенсорс и клозедсорс — близнецы-братья, потому что и тот и другой пишутся людьми.
Вопрос не в «дыра, о которой известно месяц до закрытия». Напомнить первоначальный тезис?
Открытые исходники позволяют сразу найти серьёзные ошибки
^ ложь
За примерами далеко ходить не надо. Все что угодно от дырявого, как решето OpenSSL до последних CVE для гит'а, меркуриала и SVN. Дыры, которые существуют годами. А когда их в итоге находят, то да, начинается паника «о боже, как так можно, надо срочно пропатчить». Собственно, ничем не отличается от софтвера с закрытыми исходниками.
БЭМ от Яндекса — это костыль, который пытается бороться с отсутствием вложенности и namespace'ов в СSS. Туда же все эти OOCSS и прочие извращения.
Любить button button--state-danger или там .media__img--rev — это стокгольмский синдром.
То, что предлагает http://patternlab.io ортогонально BEM'у. Это подход к проектированию интерфейсов:
выделяем из интерфейса самые мелкие самодостаточные переиспользуемые компоненты: кнопки, поля ввода и т.п. Это «атомы»
Эти мелкие компоненты объединяются в более крупные блоки, которые тоже можно произвольно использовать заново: «поле поиска с кнопкой поиска» (состоящее из «поле ввода», «кнопка»), «меню» (состоящее из «кнопка», «список»(который состоит из «элемент для показа текста»)). Это «молекулы»
и так далее: «молекулы» компонуются в более сложные структуры. Эти более сложные структуры в еще более сложные и т.п.
Не мечите бисер перед гиками. Особенно на Хабре. Тут 99% населения уверено, что гиковские желание == желания всего остального мира. Проверено на печальном опыте
То есть вы их не ускоряли. Они и так работали быстро, без задержек и без проблем. Потому вы все это сломали, а потом героически боролись с проблемами, которые сами себе создали. И, судя по комментариям к этой статье, поломали и до сих пор не починили базовый функционал.
Ну то есть когда оно было в SSR в старой версии, все работало густро, без задержек и т.п. Придумали себе «модномолодежно» Vue, и перестало работать всё. Почему вы этим гордитесь и еще целые статьи выкатываете про это?
Странное у вас понимание «минимальных усилий» для того, чтобы оно хоть как-то было похоже по работе на то, что у вас уже было.
В итоге:
счечик не работает
открытые в нескольих табах страницы не грузят контент
accessibility сломан
используются экспериментальные фичи, которые работают только в хроме, на остальных пользователей насрать
<вписать свое>
Зато 13 человек полгода пилили модно-молодёжно.
Да, было бы хорошо такую найти. Мне она не нужна, правда. А вот тебе вполне понадобится.
Повторю в последний раз: реальность, а не твои хотелки и слепая вера в мифы, говорит о том, что вся эта фраза ложна. Это — факт. Можно много разглагольствовать, рассказывать о каких-то мифических возможностях, но факт остается фактом — софт с открытым исходным кодом ничем не лучше и не хуже кода с закрытым исходным кодом. Качество кода одинаковое. Количество ошибок одинаковое. Скорость исправления ошибок одинаковая. Опасность и серьезность ошибок одинаковая.
Понятно, что немного упрощено. Что в каких-то единичных случаях наличие исходных кодов может помочь с чем-то там. Что не отменяет всей картины в целом. Вплоть до того, что опенсорс в своей массе не несет репутационных потерь, и срать хотел, например, на исправления ошибок (примеры — сплошь и рядом).
Возвращаясь конкретно к описываемому в посте софту. Закрыт он, или открыт — в случае с российским государством это не имеет никакого значения. Потому что государственный софт в Росси делается не для заявленных софтом целей. Будь там открытый код, авторы кода так же плевать хотели бы на ваши хотелки, закрывали бы API и доступ к данным и прочая и прочая и прочая. И все — абсолютно в рамках опенсорса.
Это — бессмысленное словоблудие.
Любые доказательства по аналогии ложны, поэтому придумывать какой-то бред про какие-то водопроводы не собираюсь.
А прочитал эти «простые факты». Никаких домыслов. Только реальность: эти «факты» в реальности — мифы.
Да-да. Давайте возьмем побольше идиотских аналогий.
Ээээ. В том-то и дело, что это не факты, а что ни на есть самые настоящие мифы. Сравнительные исследования качества софта уже проводились. Опенсорс ни по каким параметрам не лучше (и не хуже) клозедсорса.
Но я понимаю, что если «факты» не соотносятся с реальностью, тем хуже для реальности, ага
Вы продолжаете разговаривать о каких-то мифических возможностях из области чистой теории.
На практике и в реальности качество кода и продуктов у опенсорса и «клозедсорса» одинаковое. То есть и количество багов, и количество проблем, и прочее и прочее и прочее.
Все остальное — демагогия, к реальности не имеющая отношения
Я не игнорирую реальность.
Количество ошибок в опенсорсе/СПО не меньше и не больше, чем в закрытом софте. Так что «позволяет» или «повзоляет сразу» — это миф, граничащий с ложью
«возможности контроля» — это вариант мифа про «миллионы глаз». Нет там возможностей контроля, если только не считать какие-нибудь совсем простые проекты, в которых может разобраться даже Вася Пупкин с двумя классами образования. Могу просто повторить еще раз: для грамотного аудита того же OpenSSL нужны специалисты, которых можно пересчитать по пальцам на руках. Это — большие возможности для контроля? «Позволяют сразу найти»? Рассказывайте эти сказки на LOR'е.
Ну да. Простейшие типа конкатенации строк в sql-запросе. И при этом они остаются в top-10 OWASP из года в год. Как-то не помогают «программисты со стажем».
Не повышает. Миф о «миллионе глаз» всего лишь миф.
О, уже пошли поиски контекстов
Ничем не отличается от любой другой ошибки. Ни «опенсорнсность» ни «СПОшность» кода не способствуют нахождению этой ошибки сразу.
Большой толковый словарь:
СРАЗУ, нареч.
Какое значение ни бери, фраза ложная.
Не дает. Качество зарытого и открытого ПО примерно одинаковое, исследования уже проводились.
Демагогия — это «вот как только узнали, сразу закрыли».
Весь изначальный тезис про «сразу находить ошибки» и большинство мифов типа «миллионы глаз» говорят об одном и том же: открытый код позволяет находить ошибки быстро и вообще лучше закрытого кода именно потому что ошибки находятся сразу миллионами глаз (и прочие вариации на эту тему).
Это — ложь. Серьезные ошибки существуют в опенсорсе годами. То, что про них не знает значительная часть опенсорса до тех пор, пока что-нибудь типа heartbleed'а не становится достоянием общественности, — это слабое утешение.
В отличие от проприетарщины опенсорс не несет репутационных потерь и патч может быть легко не принят. Или просто не найдутся люди, вообще способные решить проблему (в частности, для полного аудита OpenSSL нужны специалисты, которые стоят невменяемых денег и которых можно пересчитать чуть ли не по пальцам одной руки. Неудивительно, что в итоге аудит спонсируется теми самыми «монополистами»).
И вообще, весь разговор про опенсорс обычно упирается в один и тот же миф: опенсорс лучше потому что он опенсорс. Хотя уже есть далеко не одно исследование, что опенсорс и клозедсорс — близнецы-братья, потому что и тот и другой пишутся людьми.
Вопрос не в «дыра, о которой известно месяц до закрытия». Напомнить первоначальный тезис?
^ ложь
За примерами далеко ходить не надо. Все что угодно от дырявого, как решето OpenSSL до последних CVE для гит'а, меркуриала и SVN. Дыры, которые существуют годами. А когда их в итоге находят, то да, начинается паника «о боже, как так можно, надо срочно пропатчить». Собственно, ничем не отличается от софтвера с закрытыми исходниками.
Если бы они позволяли, да еще и «сразу», то в опенсорсе не было бы серьезнейших ошибок, не закрываемых годами.
Это в лучшем случае миф, в худшем случае ложь.
В проприетарном софте исали бы не дольше. Потому что у серьезного секьюрити аудита проверка исходников занимает далеко на самый большой кусок работы.
БЭМ от Яндекса — это костыль, который пытается бороться с отсутствием вложенности и namespace'ов в СSS. Туда же все эти OOCSS и прочие извращения.
Любить
button button--state-dangerили там.media__img--rev— это стокгольмский синдром.То, что предлагает http://patternlab.io ортогонально BEM'у. Это подход к проектированию интерфейсов:
Более подробно в Atomic Design: http://atomicdesign.bradfrost.com/table-of-contents/
medium.com/@dmitriid/erlang-is-dead-long-live-e-885ccbcbc01f
medium.com/@dmitriid/designing-for-anything-with-erlang-cfadb6833bc0