Pull to refresh
0
0
Dmitrii 'Mamut' Dimandt @dmitriid

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

Send message

Как мы ускоряли комментарии Хабра

...

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

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

Этому есть несколько причин. Во-первых, Хабр стал одностраничным приложением (SPA, Single Page Application) на Vue, то есть теперь переходы между страницами рисуются на клиенте с помощью JS вместо классического серверного рендеринга (Server-Side Rendering, SSR).

...

серверный рендеринг — операция дорогая.

авигация по сайту в режиме SPA (без перезагрузки страницы) оставляла желать лучшего. Если у вас медленный смартфон, то вы имели шанс вообще не увидеть комментарии: память кончалась быстрее, чем успевали отработать скрипты и рендеринг.

Ну то есть когда оно было в SSR в старой версии, все работало густро, без задержек и т.п. Придумали себе «модномолодежно» Vue, и перестало работать всё. Почему вы этим гордитесь и еще целые статьи выкатываете про это?

Наша задача подразумевала максимальные улучшения ценой минимальных усилий.

...

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

всю разметку с сервера необходимо «гидрировать» на клиенте, иными словами ... ленивая гидрация

Предотвращение избыточной перерисовки

Ленивый рендеринг

[только для Хрома] Content Visibility

стриминг-рендеринг... проблему мы решили путём долгого и скрупулёзного изучения исходников Vue... Внедрение стриминг-рендера для комментариев не прошло безболезненно..

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

Поэтому при переходе на новую версию сайта было важно сделать работу с комментами не хуже, чем было.

В итоге:

  • счечик не работает

  • открытые в нескольих табах страницы не грузят контент

  • accessibility сломан

  • используются экспериментальные фичи, которые работают только в хроме, на остальных пользователей насрать

  • <вписать свое>

Зато 13 человек полгода пилили модно-молодёжно.

я надеюсь где-нибудь есть хорошая методичка по логике что-бы я мог просто кидать на неё ссылку

Да, было бы хорошо такую найти. Мне она не нужна, правда. А вот тебе вполне понадобится.


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

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


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


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


но главный вопрос который волнует лично меня это: стало ли вам ясно что позволение сделать что-то сразу, согласно логике не приводит к тому что это что-то будет сделано сразу?

Это — бессмысленное словоблудие.


аналогию про проприетарный водопровод сами придумывайте,

Любые доказательства по аналогии ложны, поэтому придумывать какой-то бред про какие-то водопроводы не собираюсь.

перечитайте простые тезисы, описывающие простые факты и прекратите добавлять к ним свои домыслы.

А прочитал эти «простые факты». Никаких домыслов. Только реальность: эти «факты» в реальности — мифы.


давайте ещё сравним кирпичи и доски и увидим что в реальности они абсолютно одинаковые

Да-да. Давайте возьмем побольше идиотских аналогий.

если называть простые и проверяемые факты мифами

Ээээ. В том-то и дело, что это не факты, а что ни на есть самые настоящие мифы. Сравнительные исследования качества софта уже проводились. Опенсорс ни по каким параметрам не лучше (и не хуже) клозедсорса.


Но я понимаю, что если «факты» не соотносятся с реальностью, тем хуже для реальности, ага

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


На практике и в реальности качество кода и продуктов у опенсорса и «клозедсорса» одинаковое. То есть и количество багов, и количество проблем, и прочее и прочее и прочее.


Все остальное — демагогия, к реальности не имеющая отношения

Я не игнорирую реальность.


Количество ошибок в опенсорсе/СПО не меньше и не больше, чем в закрытом софте. Так что «позволяет» или «повзоляет сразу» — это миф, граничащий с ложью


«возможности контроля» — это вариант мифа про «миллионы глаз». Нет там возможностей контроля, если только не считать какие-нибудь совсем простые проекты, в которых может разобраться даже Вася Пупкин с двумя классами образования. Могу просто повторить еще раз: для грамотного аудита того же OpenSSL нужны специалисты, которых можно пересчитать по пальцам на руках. Это — большие возможности для контроля? «Позволяют сразу найти»? Рассказывайте эти сказки на LOR'е.

Программисты со стажем видят такие ошибки мгновенно.

Ну да. Простейшие типа конкатенации строк в sql-запросе. И при этом они остаются в top-10 OWASP из года в год. Как-то не помогают «программисты со стажем».


А опенсорс повышает вероятность, что её найдут

Не повышает. Миф о «миллионе глаз» всего лишь миф.

Серьёзная ошибка — в данном контексте

О, уже пошли поиски контекстов


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

Ничем не отличается от любой другой ошибки. Ни «опенсорнсность» ни «СПОшность» кода не способствуют нахождению этой ошибки сразу.

фраза: «Открытые исходники позволяют сразу найти серьёзные ошибки» не является ложной

Большой толковый словарь:


СРАЗУ, нареч.


  1. В один приём; одним разом.
  2. В тот же момент; немедленно.
  3. Рядом, в непосредственной близости от чего-л.

Какое значение ни бери, фраза ложная.


в дальнейшем стоит перейти к обсуждению тезиса: открытое ПО даёт обществу больше возможностей контроля качества. а именно контроль и возможности в данном случае важны.

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

Ты давай не демагожь мне тут.

Демагогия — это «вот как только узнали, сразу закрыли».


Весь изначальный тезис про «сразу находить ошибки» и большинство мифов типа «миллионы глаз» говорят об одном и том же: открытый код позволяет находить ошибки быстро и вообще лучше закрытого кода именно потому что ошибки находятся сразу миллионами глаз (и прочие вариации на эту тему).


Это — ложь. Серьезные ошибки существуют в опенсорсе годами. То, что про них не знает значительная часть опенсорса до тех пор, пока что-нибудь типа 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/

http://patternlab.io предлагают думать о GUI в терминах Атом -> Молекула -> Организм -> Шаблон -> Страница:

ЦА Ubuntu Phone == ЦА Tizen == ЦА Meego == пара сотен гиков, писающих кипятком от всего нежизнеспособного и которых можно спокойно игнорировать.
Не мечите бисер перед гиками. Особенно на Хабре. Тут 99% населения уверено, что гиковские желание == желания всего остального мира. Проверено на печальном опыте
Да, верно. Я как-то постоянно забываю (хотя другим постоянно напоминаю :) ), что Apple весьма активно пользуется опенсорс-технологиями

Information

Rating
Does not participate
Location
Stockholm, Stockholms Län, Швеция
Date of birth
Registered
Activity