Меры выглядят избыточными для автора статьи и его единомышленников.
Лично я их не оцениваю никак, потому что не эпидемиолог (и кстати, принятые в Москве меры были далеко не самыми жесткими из принятых в мире).
Комментарий же был про другое — про то, что на момент принятия решения точных данных не было.
Не согласен про неправильные данные (на основе которых были действия властей). Данные нормальные.
Какие же они нормальные, эти данные, если в марте, когда принималось большинство решений о карантинных мерах, просто не было имеющихся сейчас данных данных о реальном числе зараженных, и о доле бессимптомных или ведущих к несущественному недомоганию случаев заражения (а следовательно — и реальной летальности, и об уровне потенциальной угрозы населению)? Данные эти появились, только начиная где-то с апреля, когда были разработаны тест-системы для выявления антител в крови и началось более менее-массовое тестирование. И тогда стало понятно, что число зараженных, выявленное по тестам ПЦР и просто по проявишимся более тяжелым случаям заболевания, требующим госпитализации — это верхушка айсберга: доля людей, имеющих антитела, превосходит отношение числа выявленных заражений к численности населения, минимум, на порядок (например, по моим подсчетам на начало июля, в Москве — в 12 раз, в Подмосковье — в 24 раза). А потому и летальность новой короновирусной инфекции оказалась примерно во столько же раз завышенной.
Но дело в том, что других данных на момент, когда начались вспышки инфекции, ни у кого не было, а со вспышкой что-то делать было надо. Поэтому правительства основывались на той информации которая имелась, и меры предпринимали на ее основе, с учетом худшего случая.
Так что, сейчас, задним числом да на основе нынешних данных, легко осуждать правительства за избыточность карантинных мер — но это сейчас они выглядят избыточными, а тогда они так отнюдь не выглядели.
Я так понял, что вы писали не про менеджмент, а про разработчиков.
Люди коннечно — и там, и там, но вот материальные интересы у этих разных групп людей явно разные.
На мой взгляд проблема не в людях. Люди — они просто стремятся делать то, что приносит им наибольшую личную выгоду. То есть — поступают именно так, как принято среди людей из современного общества.
Это работа менеджмента — сделать так, чтобы наибольшую личную выгоду сотрудникам приносили (или, хотя бы, казалось что приносят — тоже вариант) те действия, которые приносят выгоду предприятию.
Защитники скрама видят причину неприятностей в плохом менеджменте. Вот что говорит пользователь Llewellyn, подводя итоги: «Менеджмент, по сути, игнорирует разработчиков. Существуют фиксированные дедлайны, которые нужно выдержать, достигнув заранее заданных результатов. Работой занимается не команда, сосредоточенная на достижении одной и той же цели, а группа людей, в которой каждый беспокоится лишь о себе. ...».
На мой взгляд, это и есть основная проблема скрама. Только источник проблемы — не менеджмент, а проблема тут — объективная. Потому что, если подойти к вопросу чисто материально, то работой ведь объективно занимается как раз не команда, объединенная общим материальным интересом, а группа людей, каждый из которых имеет свой интерес.
Команда была бы, если бы разработчики были объединены во что-то вроде самостоятельной артели — которая подрядилась сделать разработку для предприятия за оговоренную плату, которая коллективно отвечает за результат, и которая сама определяет кому из своих членов сколько платить, кого надо принять, а кого — и уволить. Вот у такой команды был бы общий интерес, который бы объединял ее.
А в современных реалиях разработки уровень оплаты каждого разработчика (и будет ли он вообще работать) определяется на индивидуальной основе, менеджментом фирмы (по договоренности с самим разработчиком, естественно). Поэтому общего материального интереса у группы разработчиков нет. А отсюда проистекают неизбежные трудности эффективного использования методик, рассчитанных на управление разработчиками как коллективом, в том числе — и скрамом: сложно побудить людей (к тому же — образованных, а потому неглупых), что они должны действовать вопреки своим материальным интересам.
Ну, я, наверное, в тот интернет не хожу, потому такие ресурсы не вижу, и рассуждать мне о них трудно.
Но давайте попробую угадать: для таких ресурсов обязательно есть мобильное приложение (или прям сейчас планируется)?
Если я угадал, то эти ресурсы — тоже приложения, хоть и специфические, развлекательные.
В принципе, для них и на десктопе браузер не особо нужен: под Win10, вроде как (ни разу не пользовался), тоже есть нечто подобное мобильным приложениям. Отстаются, кончено, еще десктопы на Linux, но что-то мне подсказывает, что аудитории таких приложений и пользовтаелей десктопного Linux пересекаются слабо.
Зачем так сравнивать? Собственно основной плюс клиентского рендеринга в том, что не надо рендерить каждый раз страницу полностью, если очевидно, что только часть отображаемых данных нужно изменить в ответ на действие пользователя.
Это не является эксклюзивным преимуществом именно клиентского рендеринга. То же самое можно реализовать и при генерации HTML на серверной стороне: кэшировать ранее сгенерированные куски HTML и при ответе на запрос собирать страницу из кэшированных не изменившихся кусков и сгенеренных новых изменившихся. Все это, например, было почти изначально в древнем (хоть и не 90-х годов) SSR-фреймворке ASP.NET Web Forms.
Но даже при таком сравнении несколько запросов к API могут оказаться быстрее для конечного пользователя, потому что будут исполняться параллельно и пользователь быстрее получит доступ к основному контенту
Это тоже не является эксклюзивным преимуществом клиентского рендеринга. Ничто не мешает делать несколько асинхронных параллельных запросов данных и при генерации HTML на серверной стороне. В уже упомянутом Web Forms такая возможность появилась, хоть и не сразу, но лет семь назад она уже точно была.
В целом, конечно, клиентский рендеринг может дать меньшие задержки, чем SSR (кроме как на сосвем уж слабых клиентах), но смысл утверждения п.1 обсуждаемой статьи как раз в том, что благодаря росту мощности серверов и скорости сетей эта разница может стать для пользователя несущественной.
Вот это — private static bool sost = true; — надо исправить: добавить volatile. Вот так: private static volatile bool sost = true;
Иначе у оптимизатора, если он вдруг захочет соптимизировать ваш код, появится искушение вынести sost как инвариант вот из этого цикла: while (sost) Thread.Sleep(1);//Приостановить поток И тогда ваша программа по Esc не закончится.
И у кучи стартапов вообще нет монетизации, нас приучили к бесплатной почте, облакам, хостингам, стримам и видео. Как говорится, за чей счёт банкет?
За счет рекламодателей, вестимо. А в конечном счете — за счет тех, кто принимает решение на основе рекламы. Крупные фирмы, вроде Гугла, на продаже рекламы неплохо зарабатывают. Ну, а стартапы и их инвесторы надеются стать крупными — чтобы тоже на этом зарабатывать.
Образованных людей не удивляет, что «яма» по-японски означает «гора». А вот то, что async в языках F# и С# означает разные понятия — почему-то удивляет, хотя эти языки — тоже сильно разные.
IMHO легче всего понять смысл ключевого слова async в заголовке метода в C# — это запомнить, что оно вообще не для кода, который вызывает метод. Вызывающему коду достаточно знать, что вызов этого метода возвращает что-то типа Task (и, возможно, — какой именно класс, чтобы получить результат), а это в сигнатуре метода прописывается вне зависимости от наличия async (с исключением для void, хотя IMHO вот это исключение сделано было зря). И потому, например, виртуальный метод без async в заголовке в базовом классе вполне успешно перекрывается методом с async в производном — т.е., по факту, сигнатуры у них одинаковые.
Ключевое слово async в C# описывает исключительно реализацию метода — дает возможность использовать в нем оператор await, т.е. служит для указанием для компилятора о необходимости преобразовать весьма хитрым способом тело метода, чтобы обеспечить временный возврат управления в планировщик в коде, который выглядит как последовательно выполняющийся безо всякой передачи управления (ну, и удостовриться, что в сигнатуре прописано возвращение Task или производного от него класса, т.к. с другим типом возвращаемого значения этот фокус с преобразованием проделать не получится).
PS Я тут, наверное, Капитаном Очевидность поработал, не спорю. Но факт появления такой статьи явно указывает на то, что услуги Капитана в данном вопросе востребованы.
PPS IMHO заголовок переведен неточно — я бы вообще не стал переводить первое слово «Async», т.к. из-за этого теряется смысл.
Если вы о lib.ru, куда ведет ваша ссылка, то тут дело в другом.
В вебе есть два принципиально разных класса ресурсов.
Первый класс — это документы. Изначально они были текстовые, содержали ссылки, иногда — рисунки (которых со временем становилось все больше), в более позднее время время — видеофрагменты. К классу документов можно, на самом деле, отнести также и фотоальбомы, и видео. Ценность документов для пользователя — в их содержании, которое уже готово к отображению и дополнительных действий от пользователя почти не требует. Ключевая особенность документов — неинтерактивность: пользователи ограниченно взаимодействуют с ними, причем — малым количеством заранее предусмотренных способов: текст можно прокручивать в окне, выделять и копировать в буфер обмена, по ссылке можно перейти, видео — запускать, останавливать, менять громкость и т.д. Веб изначально был основан на концепции документов. Поддержка текста с картинками была сразу после появления — поэтому развитие веб мало что дало сайтам с документами типа lib.ru. Cтандартизация поддержки видео появилась сильно позднее, но видео в концепцию документов тоже укладывается.
Второй класс ресурсов — это интерактивные приложения. Их ценность для пользователя — служить интерфейсом доступа к ресурсам в вебе — разнообразным внешним хранилищам информации (службы поиска типа Яндекса и Гугля, расписания транспорта и т.д.), средам общения (от гостевых книг до соцсетей), заказу товаров и услуг(интернет-магазины). Ключевой особенностью интерактивных приложений является именно их интерактивность — они предназначены для принятия запроса от пользователя и предоставления ему ответа. И вот с интерактивностью в вебе изначально было плохо, и основная часть развития веба — это развитие средств общения с пользователем с целью улучшения работы интеракивных приложений.
PS Есть ещё третий класс, с позволения сказать, ресурсов — реклама (тут чисто личное — рекламу я не люблю, сильно). Но поскольку она IMHO не является самостоятельной ценностью для пользователя (а служит лишь для оповещения его о наличии других ценностей), то я её рассматривать не буду. Хотя именно улучшение возможностей рекламы было на само деле одной из движущих сил развития веба, об этом — как-нибудь в другой раз.
20% НДС (который при продаже за бугор = 20% с ДОХОДА
При продаже товаров изначально было 0% (ст. 164 НК РФ).
А с 1 июля 2019 — и при экспорте работ и услуг (точнее — призводится вычет вхолного НДС, на НК ссылку не даю — там черт ногу сломит, неспециалисту не разобраться, но об этом много писала год назад и обычная пресса: например)
Ну, насчет снятия карантинных мер как причины отказа от дальнейшего моделирования — это всего лишь мои предположения, не более. Автор статьи это прямо не пишет. Я его понял именно так, но я мог ошибиться.
Изменение методики — подсчета заболевших (данные Минздрава) — где-то в это время (не помню число) тоже было: к числу больных перестали относить бессимпомных зараженных.
Но для моделирования важно не это число, а число выявленных зараженных (которое предоставляет Роспотребнадзор) — то, которое оглашается в ежедневной сводке. А для него, судя по тому, что там по-прежнему оглашается существенный процент бессимптомных, методика существенно не поменялась.
В случае данной статьи вы не правы. Потому что в статье речь идет об ASP.NET Core. А эта среда выполнения отличается от классического ASP.NET в IIS тем, что в ней используется SynchronizationContext по умолчанию — контекст синхронизации пула потоков. В нем задачи завершения (в которые компилятор преобразует части кода после await) могут выполняться параллельно сразу в нескольких потоках. Поэтому блокировка одной из задач в этом контексте на ожидании не приведет к ситуации тупика (deadlock).
Ваше замечание было бы правильным для ASP.NET в IIS. Там использутся контекст синхронизации AspNetSynchronizationContext, который запускает задачи завершения не параллельно, а по одной. И из-за этого событие, которого ожидает блокируемый код, может не произойти, потому что оно должно возникнуть в другой задаче завершения — стоящей в очереди без шансов на выполнение. Поэтому там для надежности в случае ожидания надо переключаться в контекст синхронизации пула потоков, что и делает Task.Run.
В ASP.NET Core необходимости в этом нет.
PS Для ожидания завершения Task.Run() тоже лучше (если вы обрабатываете исключения, конечно) использовать не Result, а GetAwaiter().GetResult(), как делает автор — эта конструкция позволяет не выковыривать исключение для обработки из AggregateException, а получить его сразу.
PPS А еще вместо Task.Run() можно (но осторожно) использовать ConfigureAwait(false).
Вы не совсем правы. Начиная с 15 мая не данные перестали укладываться в модель, а стали заведом неприменимыми исходные предположения модели. Произошло это вследствие начашегося снятия карантинных мер. В модели используется почти постоянное и даже медленно спадающее значение c(t) (в данной статье я формулу для него, к сожалению не увидел — то ли она пропущена, то ли спрятана под какой-то спойлер, — но ее можно найти в оригинальном препринте), в то время как снятие карантинных мер означает скачкообразное увеличение коэффициента q_1, входящего в эту формулу, и, соотвественно — значения c(t).
На самом деле, модель в этой части, скорее всего, была неадекватна российской действительности и до 15 мая — в силу известной особенности этой самой действительности: «строгость российских законов смягчается необязательностью их выполнения». Значение c(t) после начала рассматриваемого периода на практике, скорее всего, росло, по мере того, как меры изоляции для незараженных и необноруженных зараженных стали исполняться все хуже. Свидетельством этому стал, например, рост транспортных потоков, отображаемый «индексом самоизоляции» Яндекса. А этого явления использованная модель (исходно сделанная для Китая, где этой российской особенности нет), похоже, не отражает.
Так избыточную смертность не промоделируешь. Избыточная смертность при эпидемии возникает не только из-за прямой (пневмония со смертельным исходом) или косвенной (из-за обострения хронического заболевания по причине заболевания короновирусом) смертности из-за заражения, но и из-за избыточной смертности по другим причинам — из-за перегрузки здравоохранения, перепорфилирования лечебных учреждений на борьбу с эпидемией с прекращением плановой медпомощи и ухудшением качества экстренной, задержкой с обращением за помощью из-за страха заражения… Есть данные, что в очагах эпидемии в Италии и Испании полная избыточная смертность была в разы выше, чем смертность от короновируса (картинки есть, например у Ющука). А какова эта доля в других странах — заранее сказать нельзя.
Кроме того, чтобы промоделировать смертность на основе обнаруженного числа зараженных, нужно знать, кроме истинной летальности, ещё и обнаруживаемую долю полного числа зараженных. А эта доля, по данным анализа на антитела, оказывается, как минимум, на порядок меньше полного числа зараженных. Причем её нельзя определить априори — она зависит от многих параметров реальной процедуры выявления, а потому может непредсказуемо различаться для разных стран (да что там стран — даже регионов: к примеру, разница в этой доли между Москвой и Подмосковьем — двукратная). Более того, эта доля может меняться со временем — как это и произошло в РФ: ускорение процедуры проведения анализов дало всплеск обнаруженного числа зараженных в районе 1-го мая, при том, что хоть сколько-нибудь пропорционального всплеска случаев госпитализации не было.
Благодарю вас, что вы потрудились, провели моделирование и написали эту интересную статью по его результатам.
Однако сейчас, при имеющихся данных (тоже вполне официальных), уже становится ясно, что такое моделирование имеет весьма ограниченную ценность. Причина — большая и неустранимая неточность исходных данных.
Когда я писал про имеющиеся данные, я имел в виду результаты исследований на долю людей в популяции, имеющих антитела к новому короновирусу — то есть, так или иначе заражавшихся. Эти исследования — естественно, выборочные, но объем выборки достаточно большой (десятки тысяч людей), и при составлении выборки были приняты меры ее по рандомизции, чтобы сделать ее репрезентативной.
Наилучшие данные есть, естественно, по Москве (они есть здесь, со ссылкой на официальный источник). Согласно этим данным, в Москве в первой половине мая антитела к новому короновирусу имели 12,5% обследованных, в начале июля — 21,7%. В пересчете на население Москвы (~12,5 млн.) это дает 1,56 млн. и 2,7 млн. зараженных соответственно. В то же время число выявленых зараженных было в те же периоды (примерно) 130 тыс. и 220 тыс. То есть отношение числа реально зараженных к числу выявленных — примерно 12 раз.
По Московской области данных у меня меньше: есть только одна цифра, на 3 июля — 17,7% обследованных, имеющих антитела. В пересчете на численность населения Московской области (~7,8 млн.) это дает примерно 1,38 млн. зараженных, при том что число выявленных на 3 июля было 58,5 тыс — т.е. разница уже почти в 24 раза.
Какой из этого можно сделать вывод. Только один — число реально зараженных отличается от числа выявленных на большой (не менее порядка величины) коэффициент, меняющийся, к тому же, в широких пределах даже между соседними субъектами РФ. Т.е. — и величина коэффициента неизвестна. А это означает, что данные по числу выявленных зараженных для сколь-нибудь точного моделирования динамики развития эпидемии не годятся.
PS Такая ситуация с выявлением — разница на порядок имеющих антитела с числом выявленных зараженных — она обнаруживается не только в РФ, а по всему миру (я видел аналогичные данные по очагам эпидемии в Германии, Италии, Испании, по штату Нью-Йорк в США). Так что простым смертным, например — хаброжителям, в такой ситуации IMHO надлежит проявить смирение: ничего правдоподобного они промоделировать не смогут.
PPS Ещё один результат: оценку летальности короновирусной болезни (помимо устранения особенностей национальной статистики) следует ещё и поделить на этот самый коэффициент — большой и, вообще говоря, неизвестный.
Тут есть нюанс, отличающий эту самую строительную фирму в 500-1000 человек (т.е. среднего размера) от крупного предприятия типа Сбербанка. Точнее — два взаимосвязанных.
Во-первых, для фирмы среднего размера будет слишком накладно содержать по одной полноценной ИТ-команде на каждое направление. Потому что объем работ скорее всего окажется недостаточным, чтобы загрузить полноценную команду. А то — и одного сотрудника-админа нужного уровня квалификации. В результате этот сотрудник будет либо большую часть времени заниматься низкоквалифицированной работой за свою большую зарплату (причем, работа эта ему, по понятным причинам, нравиться не будет), либо просто заниматься посторонними делами. Не говоря уж о том что один сотрудник — это bus factor=1. В большой фирме такой проблемы нет — там объемы большие, работы хватит всем.
Во-вторых, в такой структуре естественным образом возникает зоопарк решений, что способствует увеличению затрат за счет эффектов масштаба (в данном случае — малого). Плюс — чрезмерно осложняет совместную работу, буде такая необходимость возникнет.
В качестве примера, мне близкого. Возьмем пару направлений, которые исходно сидели каждая в своем офисе, со своей IT службой, но теперь они съезжаются в один. У офиса есть общие ресурсы (переговорные комнаты, например), использование которых обычно так или иначе автоматизируется. Так вот, эти две команды могут запросто выбрать для управления ресурсами разные несовместимые решения. Например, одна команда использует в качестве почтового сервера MS Exchange+Outlook — у которого функция управления ресурсами (комнатами и т.д.) есть «из коробки», а другая — какое-то другое почтое решение, бронирование же ресурсов сделано на какой-нибудь дешевой (или вообще бесплатной) веб-программе (коих немало). И вот они съезжаются — и как теперь прикажете управлять общими для всего офиса переговорками? Поделить переговорки по-честному и оставить все как есть? Поставить для всех пользователей второго направления Outlook (а он ведь — отнюдь не бесплатный)? Лишить пользователей первого направления удобных возможностей, которых дает интеграция управления ресурсами с электронной почтой? Всех этих затруднений можно было бы избежать, если проводить единую политику в области средств ИТ. Но без департамента ИТ это на практике невозможно.
В большой фирме, конечно, подобные проблемы тоже возникают. Но там в реальности зоопарк — дело естественное и практически неизбежное. И опять-таки использование разных решений может там дать выигрыш, который в средней фирме на ее масштабах не получишь. Ну, а если надо — то у большого педприятия есть ресурсы, чтобы организовать взаимодействие в рамках зоопарка систем.
«Здесь всё не так однозначно»(с)
Обучение фреймворку (и даже 2-3 фреймворкам) по видеокурсам обходится существенно дешевле, чем обучение специалиста в ВУЗе. Так что «поменять на современных» экономический смысл на первый взгляд есть.
Но есть он только при одном условии: результат их труда по производительности и качеству должен быть хотя бы близок. Соблюдается ли на практике это условие — и, если не соблюдается, можно ли что-нибудь сделать, чтобы оно соблюдалось — я не знаю.
Да, это субъективно. Мне, например, наоборот, значительно легче читать текст с программы с однострочными if, если в if — один оператор, а не c многострочными конструкции с операторными скобками (особенно — с такими тяжеловесными, как begin/end в Pascal): во-первых, в поле зрения помещается больше имеющего смысловую значимость текста программы, во-вторых, при перемещении по тексту глаз легче находит реперные точки — нет этих однообразных begin и end.
Но, опять-таки — это всё субъективно.
PS А вообще мне кажется, что и исходный, и учлучшенный варианты одинаково хороши (ну, или для критиков — одинаково плохи). Я бы пожалел тратить время на такую переделку — если это единственная переделка и если она не вызвана внешней причиной вроде руководства по стилю программирования, принятому в проекте.
Лично я их не оцениваю никак, потому что не эпидемиолог (и кстати, принятые в Москве меры были далеко не самыми жесткими из принятых в мире).
Комментарий же был про другое — про то, что на момент принятия решения точных данных не было.
Какие же они нормальные, эти данные, если в марте, когда принималось большинство решений о карантинных мерах, просто не было имеющихся сейчас данных данных о реальном числе зараженных, и о доле бессимптомных или ведущих к несущественному недомоганию случаев заражения (а следовательно — и реальной летальности, и об уровне потенциальной угрозы населению)? Данные эти появились, только начиная где-то с апреля, когда были разработаны тест-системы для выявления антител в крови и началось более менее-массовое тестирование. И тогда стало понятно, что число зараженных, выявленное по тестам ПЦР и просто по проявишимся более тяжелым случаям заболевания, требующим госпитализации — это верхушка айсберга: доля людей, имеющих антитела, превосходит отношение числа выявленных заражений к численности населения, минимум, на порядок (например, по моим подсчетам на начало июля, в Москве — в 12 раз, в Подмосковье — в 24 раза). А потому и летальность новой короновирусной инфекции оказалась примерно во столько же раз завышенной.
Но дело в том, что других данных на момент, когда начались вспышки инфекции, ни у кого не было, а со вспышкой что-то делать было надо. Поэтому правительства основывались на той информации которая имелась, и меры предпринимали на ее основе, с учетом худшего случая.
Так что, сейчас, задним числом да на основе нынешних данных, легко осуждать правительства за избыточность карантинных мер — но это сейчас они выглядят избыточными, а тогда они так отнюдь не выглядели.
Люди коннечно — и там, и там, но вот материальные интересы у этих разных групп людей явно разные.
Это работа менеджмента — сделать так, чтобы наибольшую личную выгоду сотрудникам приносили (или, хотя бы, казалось что приносят — тоже вариант) те действия, которые приносят выгоду предприятию.
На мой взгляд, это и есть основная проблема скрама. Только источник проблемы — не менеджмент, а проблема тут — объективная. Потому что, если подойти к вопросу чисто материально, то работой ведь объективно занимается как раз не команда, объединенная общим материальным интересом, а группа людей, каждый из которых имеет свой интерес.
Команда была бы, если бы разработчики были объединены во что-то вроде самостоятельной артели — которая подрядилась сделать разработку для предприятия за оговоренную плату, которая коллективно отвечает за результат, и которая сама определяет кому из своих членов сколько платить, кого надо принять, а кого — и уволить. Вот у такой команды был бы общий интерес, который бы объединял ее.
А в современных реалиях разработки уровень оплаты каждого разработчика (и будет ли он вообще работать) определяется на индивидуальной основе, менеджментом фирмы (по договоренности с самим разработчиком, естественно). Поэтому общего материального интереса у группы разработчиков нет. А отсюда проистекают неизбежные трудности эффективного использования методик, рассчитанных на управление разработчиками как коллективом, в том числе — и скрамом: сложно побудить людей (к тому же — образованных, а потому неглупых), что они должны действовать вопреки своим материальным интересам.
Но давайте попробую угадать: для таких ресурсов обязательно есть мобильное приложение (или прям сейчас планируется)?
Если я угадал, то эти ресурсы — тоже приложения, хоть и специфические, развлекательные.
В принципе, для них и на десктопе браузер не особо нужен: под Win10, вроде как (ни разу не пользовался), тоже есть нечто подобное мобильным приложениям. Отстаются, кончено, еще десктопы на Linux, но что-то мне подсказывает, что аудитории таких приложений и пользовтаелей десктопного Linux пересекаются слабо.
Это тоже не является эксклюзивным преимуществом клиентского рендеринга. Ничто не мешает делать несколько асинхронных параллельных запросов данных и при генерации HTML на серверной стороне. В уже упомянутом Web Forms такая возможность появилась, хоть и не сразу, но лет семь назад она уже точно была.
В целом, конечно, клиентский рендеринг может дать меньшие задержки, чем SSR (кроме как на сосвем уж слабых клиентах), но смысл утверждения п.1 обсуждаемой статьи как раз в том, что благодаря росту мощности серверов и скорости сетей эта разница может стать для пользователя несущественной.
private static bool sost = true;— надо исправить: добавить volatile. Вот так:private static volatile bool sost = true;Иначе у оптимизатора, если он вдруг захочет соптимизировать ваш код, появится искушение вынести sost как инвариант вот из этого цикла:
while (sost) Thread.Sleep(1);//Приостановить поток
И тогда ваша программа по Esc не закончится.За счет рекламодателей, вестимо. А в конечном счете — за счет тех, кто принимает решение на основе рекламы. Крупные фирмы, вроде Гугла, на продаже рекламы неплохо зарабатывают. Ну, а стартапы и их инвесторы надеются стать крупными — чтобы тоже на этом зарабатывать.
IMHO легче всего понять смысл ключевого слова async в заголовке метода в C# — это запомнить, что оно вообще не для кода, который вызывает метод. Вызывающему коду достаточно знать, что вызов этого метода возвращает что-то типа Task (и, возможно, — какой именно класс, чтобы получить результат), а это в сигнатуре метода прописывается вне зависимости от наличия async (с исключением для void, хотя IMHO вот это исключение сделано было зря). И потому, например, виртуальный метод без async в заголовке в базовом классе вполне успешно перекрывается методом с async в производном — т.е., по факту, сигнатуры у них одинаковые.
Ключевое слово async в C# описывает исключительно реализацию метода — дает возможность использовать в нем оператор await, т.е. служит для указанием для компилятора о необходимости преобразовать весьма хитрым способом тело метода, чтобы обеспечить временный возврат управления в планировщик в коде, который выглядит как последовательно выполняющийся безо всякой передачи управления (ну, и удостовриться, что в сигнатуре прописано возвращение Task или производного от него класса, т.к. с другим типом возвращаемого значения этот фокус с преобразованием проделать не получится).
PS Я тут, наверное, Капитаном Очевидность поработал, не спорю. Но факт появления такой статьи явно указывает на то, что услуги Капитана в данном вопросе востребованы.
PPS IMHO заголовок переведен неточно — я бы вообще не стал переводить первое слово «Async», т.к. из-за этого теряется смысл.
В вебе есть два принципиально разных класса ресурсов.
Первый класс — это документы. Изначально они были текстовые, содержали ссылки, иногда — рисунки (которых со временем становилось все больше), в более позднее время время — видеофрагменты. К классу документов можно, на самом деле, отнести также и фотоальбомы, и видео. Ценность документов для пользователя — в их содержании, которое уже готово к отображению и дополнительных действий от пользователя почти не требует. Ключевая особенность документов — неинтерактивность: пользователи ограниченно взаимодействуют с ними, причем — малым количеством заранее предусмотренных способов: текст можно прокручивать в окне, выделять и копировать в буфер обмена, по ссылке можно перейти, видео — запускать, останавливать, менять громкость и т.д. Веб изначально был основан на концепции документов. Поддержка текста с картинками была сразу после появления — поэтому развитие веб мало что дало сайтам с документами типа lib.ru. Cтандартизация поддержки видео появилась сильно позднее, но видео в концепцию документов тоже укладывается.
Второй класс ресурсов — это интерактивные приложения. Их ценность для пользователя — служить интерфейсом доступа к ресурсам в вебе — разнообразным внешним хранилищам информации (службы поиска типа Яндекса и Гугля, расписания транспорта и т.д.), средам общения (от гостевых книг до соцсетей), заказу товаров и услуг(интернет-магазины). Ключевой особенностью интерактивных приложений является именно их интерактивность — они предназначены для принятия запроса от пользователя и предоставления ему ответа. И вот с интерактивностью в вебе изначально было плохо, и основная часть развития веба — это развитие средств общения с пользователем с целью улучшения работы интеракивных приложений.
PS Есть ещё третий класс, с позволения сказать, ресурсов — реклама (тут чисто личное — рекламу я не люблю, сильно). Но поскольку она IMHO не является самостоятельной ценностью для пользователя (а служит лишь для оповещения его о наличии других ценностей), то я её рассматривать не буду. Хотя именно улучшение возможностей рекламы было на само деле одной из движущих сил развития веба, об этом — как-нибудь в другой раз.
При продаже товаров изначально было 0% (ст. 164 НК РФ).
А с 1 июля 2019 — и при экспорте работ и услуг (точнее — призводится вычет вхолного НДС, на НК ссылку не даю — там черт ногу сломит, неспециалисту не разобраться, но об этом много писала год назад и обычная пресса: например)
Изменение методики — подсчета заболевших (данные Минздрава) — где-то в это время (не помню число) тоже было: к числу больных перестали относить бессимпомных зараженных.
Но для моделирования важно не это число, а число выявленных зараженных (которое предоставляет Роспотребнадзор) — то, которое оглашается в ежедневной сводке. А для него, судя по тому, что там по-прежнему оглашается существенный процент бессимптомных, методика существенно не поменялась.
Ваше замечание было бы правильным для ASP.NET в IIS. Там использутся контекст синхронизации AspNetSynchronizationContext, который запускает задачи завершения не параллельно, а по одной. И из-за этого событие, которого ожидает блокируемый код, может не произойти, потому что оно должно возникнуть в другой задаче завершения — стоящей в очереди без шансов на выполнение. Поэтому там для надежности в случае ожидания надо переключаться в контекст синхронизации пула потоков, что и делает Task.Run.
В ASP.NET Core необходимости в этом нет.
PS Для ожидания завершения Task.Run() тоже лучше (если вы обрабатываете исключения, конечно) использовать не Result, а GetAwaiter().GetResult(), как делает автор — эта конструкция позволяет не выковыривать исключение для обработки из AggregateException, а получить его сразу.
PPS А еще вместо Task.Run() можно (но осторожно) использовать ConfigureAwait(false).
На самом деле, модель в этой части, скорее всего, была неадекватна российской действительности и до 15 мая — в силу известной особенности этой самой действительности: «строгость российских законов смягчается необязательностью их выполнения». Значение c(t) после начала рассматриваемого периода на практике, скорее всего, росло, по мере того, как меры изоляции для незараженных и необноруженных зараженных стали исполняться все хуже. Свидетельством этому стал, например, рост транспортных потоков, отображаемый «индексом самоизоляции» Яндекса. А этого явления использованная модель (исходно сделанная для Китая, где этой российской особенности нет), похоже, не отражает.
Кроме того, чтобы промоделировать смертность на основе обнаруженного числа зараженных, нужно знать, кроме истинной летальности, ещё и обнаруживаемую долю полного числа зараженных. А эта доля, по данным анализа на антитела, оказывается, как минимум, на порядок меньше полного числа зараженных. Причем её нельзя определить априори — она зависит от многих параметров реальной процедуры выявления, а потому может непредсказуемо различаться для разных стран (да что там стран — даже регионов: к примеру, разница в этой доли между Москвой и Подмосковьем — двукратная). Более того, эта доля может меняться со временем — как это и произошло в РФ: ускорение процедуры проведения анализов дало всплеск обнаруженного числа зараженных в районе 1-го мая, при том, что хоть сколько-нибудь пропорционального всплеска случаев госпитализации не было.
Однако сейчас, при имеющихся данных (тоже вполне официальных), уже становится ясно, что такое моделирование имеет весьма ограниченную ценность. Причина — большая и неустранимая неточность исходных данных.
Когда я писал про имеющиеся данные, я имел в виду результаты исследований на долю людей в популяции, имеющих антитела к новому короновирусу — то есть, так или иначе заражавшихся. Эти исследования — естественно, выборочные, но объем выборки достаточно большой (десятки тысяч людей), и при составлении выборки были приняты меры ее по рандомизции, чтобы сделать ее репрезентативной.
Наилучшие данные есть, естественно, по Москве (они есть здесь, со ссылкой на официальный источник). Согласно этим данным, в Москве в первой половине мая антитела к новому короновирусу имели 12,5% обследованных, в начале июля — 21,7%. В пересчете на население Москвы (~12,5 млн.) это дает 1,56 млн. и 2,7 млн. зараженных соответственно. В то же время число выявленых зараженных было в те же периоды (примерно) 130 тыс. и 220 тыс. То есть отношение числа реально зараженных к числу выявленных — примерно 12 раз.
По Московской области данных у меня меньше: есть только одна цифра, на 3 июля — 17,7% обследованных, имеющих антитела. В пересчете на численность населения Московской области (~7,8 млн.) это дает примерно 1,38 млн. зараженных, при том что число выявленных на 3 июля было 58,5 тыс — т.е. разница уже почти в 24 раза.
Какой из этого можно сделать вывод. Только один — число реально зараженных отличается от числа выявленных на большой (не менее порядка величины) коэффициент, меняющийся, к тому же, в широких пределах даже между соседними субъектами РФ. Т.е. — и величина коэффициента неизвестна. А это означает, что данные по числу выявленных зараженных для сколь-нибудь точного моделирования динамики развития эпидемии не годятся.
PS Такая ситуация с выявлением — разница на порядок имеющих антитела с числом выявленных зараженных — она обнаруживается не только в РФ, а по всему миру (я видел аналогичные данные по очагам эпидемии в Германии, Италии, Испании, по штату Нью-Йорк в США). Так что простым смертным, например — хаброжителям, в такой ситуации IMHO надлежит проявить смирение: ничего правдоподобного они промоделировать не смогут.
PPS Ещё один результат: оценку летальности короновирусной болезни (помимо устранения особенностей национальной статистики) следует ещё и поделить на этот самый коэффициент — большой и, вообще говоря, неизвестный.
Во-первых, для фирмы среднего размера будет слишком накладно содержать по одной полноценной ИТ-команде на каждое направление. Потому что объем работ скорее всего окажется недостаточным, чтобы загрузить полноценную команду. А то — и одного сотрудника-админа нужного уровня квалификации. В результате этот сотрудник будет либо большую часть времени заниматься низкоквалифицированной работой за свою большую зарплату (причем, работа эта ему, по понятным причинам, нравиться не будет), либо просто заниматься посторонними делами. Не говоря уж о том что один сотрудник — это bus factor=1. В большой фирме такой проблемы нет — там объемы большие, работы хватит всем.
Во-вторых, в такой структуре естественным образом возникает зоопарк решений, что способствует увеличению затрат за счет эффектов масштаба (в данном случае — малого). Плюс — чрезмерно осложняет совместную работу, буде такая необходимость возникнет.
В качестве примера, мне близкого. Возьмем пару направлений, которые исходно сидели каждая в своем офисе, со своей IT службой, но теперь они съезжаются в один. У офиса есть общие ресурсы (переговорные комнаты, например), использование которых обычно так или иначе автоматизируется. Так вот, эти две команды могут запросто выбрать для управления ресурсами разные несовместимые решения. Например, одна команда использует в качестве почтового сервера MS Exchange+Outlook — у которого функция управления ресурсами (комнатами и т.д.) есть «из коробки», а другая — какое-то другое почтое решение, бронирование же ресурсов сделано на какой-нибудь дешевой (или вообще бесплатной) веб-программе (коих немало). И вот они съезжаются — и как теперь прикажете управлять общими для всего офиса переговорками? Поделить переговорки по-честному и оставить все как есть? Поставить для всех пользователей второго направления Outlook (а он ведь — отнюдь не бесплатный)? Лишить пользователей первого направления удобных возможностей, которых дает интеграция управления ресурсами с электронной почтой? Всех этих затруднений можно было бы избежать, если проводить единую политику в области средств ИТ. Но без департамента ИТ это на практике невозможно.
В большой фирме, конечно, подобные проблемы тоже возникают. Но там в реальности зоопарк — дело естественное и практически неизбежное. И опять-таки использование разных решений может там дать выигрыш, который в средней фирме на ее масштабах не получишь. Ну, а если надо — то у большого педприятия есть ресурсы, чтобы организовать взаимодействие в рамках зоопарка систем.
Обучение фреймворку (и даже 2-3 фреймворкам) по видеокурсам обходится существенно дешевле, чем обучение специалиста в ВУЗе. Так что «поменять на современных» экономический смысл на первый взгляд есть.
Но есть он только при одном условии: результат их труда по производительности и качеству должен быть хотя бы близок. Соблюдается ли на практике это условие — и, если не соблюдается, можно ли что-нибудь сделать, чтобы оно соблюдалось — я не знаю.
Да, это субъективно. Мне, например, наоборот, значительно легче читать текст с программы с однострочными if, если в if — один оператор, а не c многострочными конструкции с операторными скобками (особенно — с такими тяжеловесными, как begin/end в Pascal): во-первых, в поле зрения помещается больше имеющего смысловую значимость текста программы, во-вторых, при перемещении по тексту глаз легче находит реперные точки — нет этих однообразных begin и end.
Но, опять-таки — это всё субъективно.
PS А вообще мне кажется, что и исходный, и учлучшенный варианты одинаково хороши (ну, или для критиков — одинаково плохи). Я бы пожалел тратить время на такую переделку — если это единственная переделка и если она не вызвана внешней причиной вроде руководства по стилю программирования, принятому в проекте.