Т.е. вы исходите из того, что 15% в Германии уже переболели? Чего тогда вообще бояться, если у них 5000 смертей на 15% населения? Это а разы меньше, чем летальность гриппа.
Если что, я не утверждаю, что коронавирус менее летален, чем грипп. Судя по общей статистики смертей Италии, это не так. Хотя может быть и там, как-то умудрились искуственно повысить смертность с помощью карантина и паники. Но скорее всё-таки исследование, на которое вы ссылаетесь, несостоятельно.
Так что моё утверждение остаётся прежним: люди скорее умрут от голода, чем будет изобретено лекарство/вакцина или все медленно переболеют, не перегружая здравоохранение. Наверное, я чего-то не понимаю. Надеюсь, что кто-нибудь объяснит.
Тоесть вы предлагаете сидеть дома, пока не будет вакцины или лекарства? Это как минимум год. Вы считаете, что возможно большей части населения не работать в течение года? А если лекарства или вакцины не будеи создано, то сидеть 10 лет?
Пожалуйста, объясните, какой смысл в растягивании эпидемии, если понадобится десяток лет, чтобы переболели все? Люди раньше умрут с голоду, даже если через год-два появится вакцина.
Это называется "компонентный подход". Раньше не было удобного способа разбивать код на основе логических связей. Всё что мы могли — это разделить HTML, CSS и JS.
Хочу добавить пять копеек: в веб-версии отсутствует функция ответа на сообщение, т.е. нельзя своё сообщение связать с чужим, как в вотсапе или телеграме. А ещё каким-то невероятным способом они сломали копирование выделенного текста. При чем работает по Ctrl+C (по-моему, через раз), а через контекстное меню — нет. Не представляю, зачем этим пользоваться по собственной воле.
Спасибо за упоминание, не знал что fluent умеет читать из journald. Есть ещё journalbeat. Несколько месяцев назад там был неприятный баг, дублирующий сообщения. Но сейчас всё хорошо работает.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
Именно поэтому и костыль. То что вы описали, это костыль для костыля. Например, страниц может быть запредельно много. Да и SSR нужен не только для SEO.
Я сам предпочитаю обычный импорт из-за простоты, но в данном случае нужно признать, что это может вызвать проблемы. Лучше доставать стор из контекса реакта.
Костылем я назвал puppeter.
Разговор был не о готовой архитектуре, а о том, что мы строим под приложение. Но если хотите пример хорошей архитектуры, где уже решены эти вопросы, посмотрите фреймворк DerbyJS.
Не хочется ввязываться в споры про коммунизм, но марксистские идеи пока ещё никто не реализовывал. Маркс предсказывал, что капитализм по мере развития перейдёт в коммунизм. И никаких других способов «строительства» не предлагалось.
Key-prop — это частный случай общей проблемы. Сами по себе шаблоны статичны. Если их описывать декларативно, то можно точно сопоставить, какие изменения данных как именно изменяют DOM. Императивно перевычислять куски шаблона и сравнивать их со старыми кусками не нужно. Поэтому хотелось бы видеть к MobX нормальный View-слой, который не будет отбрасывать информацию об изменениях данных, чтобы потом перебирать Virtual DOM в поисках изменений.
vintage говорит о полном ререндеринге вашего компонента App, когда достаточно заменить innerText у h1. В шаблоне всё написано (будь он декларативным, этой информацией можно было бы пользоваться), mobx может точно сказать, какие именно данные изменились, но реакт не может этой информацией воспользоваться, а может только перевычислять рендер-функцию заново. Так что такой отличной вещи, как MobX очень не хватает нормальный View.
Приведу другой пример для объяснения. Использование key-prop при генерации html в цикле по значениям массива — это жуткий костыль. MobX может дать информацию, как именно изменился массив и из этой информации и декларативного шаблона однозначно понятно, как менять DOM — добавить/удалить куски или поменять что-то местами.
Если что, я не утверждаю, что коронавирус менее летален, чем грипп. Судя по общей статистики смертей Италии, это не так. Хотя может быть и там, как-то умудрились искуственно повысить смертность с помощью карантина и паники. Но скорее всё-таки исследование, на которое вы ссылаетесь, несостоятельно.
Так что моё утверждение остаётся прежним: люди скорее умрут от голода, чем будет изобретено лекарство/вакцина или все медленно переболеют, не перегружая здравоохранение. Наверное, я чего-то не понимаю. Надеюсь, что кто-нибудь объяснит.
Тоесть вы предлагаете сидеть дома, пока не будет вакцины или лекарства? Это как минимум год. Вы считаете, что возможно большей части населения не работать в течение года? А если лекарства или вакцины не будеи создано, то сидеть 10 лет?
Пожалуйста, объясните, какой смысл в растягивании эпидемии, если понадобится десяток лет, чтобы переболели все? Люди раньше умрут с голоду, даже если через год-два появится вакцина.
И что они будут делать дальше?
Это называется "компонентный подход". Раньше не было удобного способа разбивать код на основе логических связей. Всё что мы могли — это разделить HTML, CSS и JS.
Хочу добавить пять копеек: в веб-версии отсутствует функция ответа на сообщение, т.е. нельзя своё сообщение связать с чужим, как в вотсапе или телеграме. А ещё каким-то невероятным способом они сломали копирование выделенного текста. При чем работает по Ctrl+C (по-моему, через раз), а через контекстное меню — нет. Не представляю, зачем этим пользоваться по собственной воле.
Хотелось на конечный интерфейс к логам посмотреть. Не получилось быстро нагуглить. Как выше уже написали, Kibana для чтения логов прекрасна. По некоторым причинам использую вместо неё Graylog и не перестаю плеваться. Интересно, может ли Grafana составить конкуренцию.
Полностью разделяю ваш восторг от ClickHouse. У нас он заменил связку ElasticSearch+Spark. Я был в шоке, когда увидел, что ClickHouse с легкостью делает в реальном времени то, для чего требовались кластеры ES и DataBricks и много минут на перегонку данных.
Хочу поделиться одним из кейсов. Из API стороннего сервиса грузим отчёт в десятки тысяч строк. Потом этот отчёт мапится в миллионы строк. Памяти категорически не хватает, а нужно сделать агрегацию, прежде чем сложить всё в базу. Думал, что придётся писать модуль на Сях. Но ClickHouse оказался просто магией: загрузил во временную таблицу промежуточные данные и сагрегировал за секунды. Сами данные съедали в разы меньше, чем удалось выжать из Питона с NumPy, но во время агрегации памяти уже не хватало. Достаточно поменять настройку КликХауса, и он волшебным образом как-то всё проделывает с использованием диска, по-прежнему за считанные секунды.
Так что рекомендую попробовать не только как хранилище, но и как число-дробилку.
Я сам предпочитаю обычный импорт из-за простоты, но в данном случае нужно признать, что это может вызвать проблемы. Лучше доставать стор из контекса реакта.
Костылем я назвал puppeter.
Разговор был не о готовой архитектуре, а о том, что мы строим под приложение. Но если хотите пример хорошей архитектуры, где уже решены эти вопросы, посмотрите фреймворк DerbyJS.
Или можно построить нормальную архитектуру без костылей в виде жирного браузера, подставляющего переменные в текстовый шаблон.
Подключение стора через import сделает невозможным SSR.
Без этого не обойтись? Почему-то в последние годы бойлерплейт стал повсеместным.
Приведу другой пример для объяснения. Использование key-prop при генерации html в цикле по значениям массива — это жуткий костыль. MobX может дать информацию, как именно изменился массив и из этой информации и декларативного шаблона однозначно понятно, как менять DOM — добавить/удалить куски или поменять что-то местами.